Thanks, I should probably check redmine first before posting :)

Fixed earlier today.

I'm seeing the same thing on at least one 2.3 box here that has the DNS Resolver enabled. It works fine with the DNS Forwarder on though. I opened https://redmine.pfsense.org/issues/5775 to track it.

This should be fixed now on new snaps

@Ofloo:

at that time that was the recent version, also your answer is like 10mins after mine.

No, it was not the most recent. You posted about the "December 25th" version and your post was on December 30th. There are multiple new snapshots every day. And it's still not relevant to the thread you posted in.

I split this tangent off into its own thread.

Great, thanks, snapshotting sounds very good!

@cmb:

Yes anything there that made columns unnecessarily wide should be reverted.

Anyone see anything outside of what Steve reverted back that's problematic?

diag_states_summary.php:
Source Ports; Either abbreviate both source and destination or neither.

firewall_nat.php:
return all to as was.
Frequently many of those fields have nothing in them but an asterisk.

status_logs_filter.php:
return all to as was.
space better utilized by descriptions displayed as column.

status_logs_filter_dynamic.php:
if desired for consistency with status_logs_filter.php
descriptions are not display in this mode so space is not so much a concern.

Spelling out destination on the widget is probably fine since the field contents is pretty wide anyways.

thanks

Just pushed a fix.

Thanks.

The revision section of config.xml has a good-looking description format

<revision><time>1452883508</time> <username>admin@192.168.1.100</username></revision>

and that is what is written to and used by diag_confbak to display the reason for each config in the history.
So it looks good to be multi-lingual.

its strange, it happened only once, imtrying to reproduce but havent been successful, will try a few more times and see if it happens again

Yeah 'rate' doesn't show IPv6 traffic, that's to be expected (for now at least). The counters the actual graph pulls from show everything.

I know for system updates we've decided to use "Update" over the classic "firmware" misnomer.

I'm not sure we've officially decided on that distinction for packages yet. So long as it's internally consistent (system = update, packages = upgrade) it's likely OK. Some of that terminology may be bleeding over from pkg(ng) where "update" fetches new pkg metadata and "upgrade" installs the items with newer versions available.

Merged.

Thanks Phil

Yes. There is a Redmine ticket open and assigned to Renato.

https://redmine.pfsense.org/issues/5690

this seems better now but now i also get a lot of these

Jan 14 16:07:15 xinetd 19396 xinetd Version 2.3.15 started with libwrap loadavg options compiled in. Jan 14 16:07:15 xinetd 19396 Started working: 10 available services Jan 14 16:08:55 xinetd 19396 Starting reconfiguration Jan 14 16:08:55 xinetd 19396 Swapping defaults Jan 14 16:08:55 xinetd 19396 readjusting service 6969-udp Jan 14 16:08:55 xinetd 19396 readjusting service 19000-tcp Jan 14 16:08:55 xinetd 19396 readjusting service 19000-udp Jan 14 16:08:55 xinetd 19396 readjusting service 19001-tcp Jan 14 16:08:55 xinetd 19396 readjusting service 19001-udp Jan 14 16:08:55 xinetd 19396 readjusting service 19002-tcp Jan 14 16:08:55 xinetd 19396 readjusting service 19003-tcp Jan 14 16:08:55 xinetd 19396 readjusting service 19004-tcp Jan 14 16:08:55 xinetd 19396 readjusting service 19004-udp Jan 14 16:08:55 xinetd 19396 readjusting service 19005-tcp Jan 14 16:08:55 xinetd 19396 Reconfigured: new=0 old=10 dropped=0 (services) Jan 14 16:15:02 xinetd 19396 Starting reconfiguration Jan 14 16:15:02 xinetd 19396 Swapping defaults Jan 14 16:15:02 xinetd 19396 readjusting service 6969-udp Jan 14 16:15:02 xinetd 19396 readjusting service 19000-tcp Jan 14 16:15:02 xinetd 19396 readjusting service 19000-udp Jan 14 16:15:02 xinetd 19396 readjusting service 19001-tcp Jan 14 16:15:02 xinetd 19396 readjusting service 19001-udp Jan 14 16:15:02 xinetd 19396 readjusting service 19002-tcp Jan 14 16:15:02 xinetd 19396 readjusting service 19003-tcp Jan 14 16:15:02 xinetd 19396 readjusting service 19004-tcp Jan 14 16:15:02 xinetd 19396 readjusting service 19004-udp Jan 14 16:15:02 xinetd 19396 readjusting service 19005-tcp Jan 14 16:15:02 xinetd 19396 Reconfigured: new=0 old=10 dropped=0 (services) Jan 14 16:30:02 xinetd 19396 Starting reconfiguration Jan 14 16:30:02 xinetd 19396 Swapping defaults Jan 14 16:30:02 xinetd 19396 readjusting service 6969-udp Jan 14 16:30:02 xinetd 19396 readjusting service 19000-tcp Jan 14 16:30:02 xinetd 19396 readjusting service 19000-udp Jan 14 16:30:02 xinetd 19396 readjusting service 19001-tcp Jan 14 16:30:02 xinetd 19396 readjusting service 19001-udp Jan 14 16:30:02 xinetd 19396 readjusting service 19002-tcp Jan 14 16:30:02 xinetd 19396 readjusting service 19003-tcp Jan 14 16:30:02 xinetd 19396 readjusting service 19004-tcp Jan 14 16:30:02 xinetd 19396 readjusting service 19004-udp Jan 14 16:30:02 xinetd 19396 readjusting service 19005-tcp Jan 14 16:30:02 xinetd 19396 Reconfigured: new=0 old=10 dropped=0 (services) Jan 14 16:45:02 xinetd 19396 Starting reconfiguration Jan 14 16:45:02 xinetd 19396 Swapping defaults Jan 14 16:45:02 xinetd 19396 readjusting service 6969-udp Jan 14 16:45:02 xinetd 19396 readjusting service 19000-tcp Jan 14 16:45:02 xinetd 19396 readjusting service 19000-udp Jan 14 16:45:02 xinetd 19396 readjusting service 19001-tcp Jan 14 16:45:02 xinetd 19396 readjusting service 19001-udp Jan 14 16:45:02 xinetd 19396 readjusting service 19002-tcp Jan 14 16:45:02 xinetd 19396 readjusting service 19003-tcp Jan 14 16:45:02 xinetd 19396 readjusting service 19004-tcp Jan 14 16:45:02 xinetd 19396 readjusting service 19004-udp Jan 14 16:45:02 xinetd 19396 readjusting service 19005-tcp Jan 14 16:45:02 xinetd 19396 Reconfigured: new=0 old=10 dropped=0 (services)

Yep. gitsync'ed and now it works perfectly!
Thanks guys!

Thanks man!
Exactly what I needed to know and your answer explains it :)

ok i deleted 2 v4 gateways after upgrade look good

Nothing changed there. It was clog before, clog now.

Maybe nginx is sending it as some other mime type but even so, it's the same content before and after.

If you think a file is "OK" it's likely only because it hasn't had enough data inside to roll over.