Snap builder problems
-
High latency on non-default interfaces. Incorrect rules reloading on system bootup/link state change. These effectively break PBR, load balancing and traffic shaping.
-
High latency on non-default interfaces. Incorrect rules reloading on system bootup/link state change. These effectively break PBR, load balancing and traffic shaping.
I just updated to a snapshot from yesterday afternoon and had some issues with pfSctl blocking on boot (making my second WAN DHCP connection on OPT1 seem to hang at boot), and similar issues with my OpenVPN connections, but that's it.
My OPT1 WAN latency once up is normal (54ms), my rules load fine, my load balancing and policy-based routing work fine.
Haven't checked traffic shaping though, but I'd suspect it's also fine.
-
High latency on non-default interfaces. Incorrect rules reloading on system bootup/link state change. These effectively break PBR, load balancing and traffic shaping.
I just updated to a snapshot from yesterday afternoon and had some issues with pfSctl blocking on boot (making my second WAN DHCP connection on OPT1 seem to hang at boot), and similar issues with my OpenVPN connections, but that's it.
My OPT1 WAN latency once up is normal (54ms), my rules load fine, my load balancing and policy-based routing work fine.
Haven't checked traffic shaping though, but I'd suspect it's also fine.
The 'incorrect rule reloading' refers to this four-month unfixed issue:
http://forum.pfsense.org/index.php/topic,25405.msg131941.html#msg131941
I've sent a detailed report to emarl.
The 'high latency' refers to my recent topic on Sep 16-17 snapshot.
-
any1 reading this i recommend staying on the 13th September snap coz lof of builder updates have been going on and latest snap have quiet a bit of things broken, not to mention cron is broken on the 13th September snap
13 sep snapshots had gateway/loadbalancing issues. I'd recommend snapshots fro the 9th or earlier
-
some issue with latest snap include
Sep 19 11:57:06 php: : The command '/sbin/kldload dummynet' returned exit code '1', the output was 'kldload: can't load dummynet: No such file or directory'
Sep 19 11:57:06 php: : The command '/sbin/ipfw /tmp/rules.limiter' returned exit code '1', the output was 'Line 2: setsockopt(IP_DUMMYNET_CONFIGURE): Protocol not available' -
There are a bunch of modules missing from the builds still, it's being worked on now. That's what is breaking CP/dummynet/etc.
-
As mentioned elsewhere, this should be fixed in the most recent set of snapshots.
-
dummynet seems to have been solved but cron still remains an issue
-
dummynet seems to have been solved but cron still remains an issue
I'm not sure what is not working for you, but cron is operating properly in current snapshots. I can add a cron job and it executes as expected in the normal cron entries in config.xml. The items the system runs by minicron work as well.
If something you expect to happen by cron is not happening, the problem is likely elsewhere, not with cron, unless you have more evidence.
-
its just that during boot, when it says configuring cron, instead of saying done, it says no process found so basically something goes wrong there.
-
No, it's trying to -HUP cron if it's already running, which at that point it isn't.
Look later in the boot log, cron is actually started farther down. I'm committing a fix to suppress that error you're seeing.
