Is there a problem with today's snap shot?
-
Had to revert back to Wednesday's after performing this update.
Current version: 2.2-RC Built On: Wed Jan 07 12:14:37 CST 2015 New version: Thu Jan 08 16:57:41 CST 2015 Update source: https://snapshots.pfsense.org/FreeBSD_releng/10.1/amd64/pfSense_RELENG_2_2/.updaters/
After reverting VM back to "Built On: Wed Jan 07 12:14:37 CST 2015" worked fine again.
-
a problem with what? None I'm aware of, and I've upgraded several systems immediately after that came out.
-
Trying again before I "Cry Wolf"… :0
-
It was caused by the "standard" (From the forums) balanced internet "Limiter" and a Virtual IP. After removing the "Limiter" Queues it started working.
01-08-15 20:40:31 [ There were error(s) loading the rules: /tmp/rules.debug:234: syntax error - The line in question reads [234]: pass in quick on $LAN inet proto { tcp udp } from { 192.168.1.0/24 10.10.10.1/32 } to any port $Outgoing_Ports tracker 1408205499 keep state dnqueue( 1,) label USER_RULE: Allow LAN to needed Outgoing ports.]
10.10.10.1/32 is a VIP that processes outgoing traffic thru NAT.
Same setup works on yesterdays release, is broken on today's.
-
Something changed between yesterday's "Wed Jan 07 12:14:37 CST 2015" and today's, "Thu Jan 08 16:57:41 CST 2015" versions. It's repeatable on my setup. This gets corrupted.
<dnshaper><queue><name>Download</name> <number>1</number> <qlimit><plr><description><bandwidth><bw>3225</bw> <burst><bwscale>Kb</bwscale> <bwsched>none</bwsched></burst></bandwidth> <enabled>on</enabled> <buckets><mask>none</mask> <maskbits><maskbitsv6><delay>0</delay> <queue><name>Download_LAN</name> <number>1</number> <qlimit><description><weight><enabled>on</enabled> <buckets><mask>dstaddress</mask> <maskbits><maskbitsv6></maskbitsv6></maskbits></buckets></weight></description></qlimit></queue></maskbitsv6></maskbits></buckets></description></plr></qlimit></queue> <queue><name>Upload</name> <number>2</number> <qlimit><plr><description><bandwidth><bw>512</bw> <burst><bwscale>Kb</bwscale> <bwsched>none</bwsched></burst></bandwidth> <enabled>on</enabled> <buckets><mask>none</mask> <maskbits><maskbitsv6><delay>0</delay> <queue><name>Upload_LAN</name> <number>2</number> <qlimit><description><weight><enabled>on</enabled> <buckets><mask>srcaddress</mask> <maskbits><maskbitsv6></maskbitsv6></maskbits></buckets></weight></description></qlimit></queue></maskbitsv6></maskbits></buckets></description></plr></qlimit></queue></dnshaper>
-
I hope I didn't break it! This commit changed some related code:
https://github.com/pfsense/pfsense/commit/91b9a02fb131746c67fdf9f34282f123a13f1b13
I tried some of the stuff on my test system, and was getting the same answers back in shaper.inc function read_dummynet_config()
I am updating now to the latest snapshot and will see if I can reproduce it.
If you still have the system with the problem code, try putting the previous /etc/inc/shaper.inc on it and see if that fixes it. -
That does appear to be the source of the issue. I reverted those changes since the errors it was silencing are harmless and it appears to have broken at least something in limiters if not other things. You can gitsync to fix, or grab the next snapshot in a few hours.
-
@cmb:
That does appear to be the source of the issue. I reverted those changes since the errors it was silencing are harmless and it appears to have broken at least something in limiters if not other things. You can gitsync to fix, or grab the next snapshot in a few hours.
Yes, I agree - good to revert it. I thought the changes were harmless updates to coding standards in PHP5.something, but obviously not!
Might be good to really test the "PEAR static method call warning" one also:
https://github.com/pfsense/pfsense/commit/4751f76a6772147097906b699d4216ae38c58c39
or revert it. (It works for me, but then I thought the other changes worked and were harmless also) -
I thought it looked harmless too, apparently we both missed something there. The other one I'm thinking is pretty harmless, but given the unexpected fallout on the other, I went ahead and reverted that too.
-
Everything is back to normal with:
2.2-RC (amd64)
built on Fri Jan 09 09:55:04 CST 2015
FreeBSD 10.1-RELEASE-p3Thanks for all your hard work.