It's not a bug, we just don't automatically allow DHCP traffic over bridges anymore. You have to add rules to pass that traffic just as you do with any other kind of traffic. Auto added rules are bad. And this auto added rule wasn't even intended to allow DHCP traffic over bridges, that was just a consequence. Allowing that traffic was a bug, this is a bug fix that you now have to add that rule.
It's very, very unlikely there was a driver regression between September and December, almost nothing changed in FreeBSD 7.0 between then. It's also highly unlikely any changes in the pfSense code base would have caused anything like that, since nothing at all related to Ethernet interface code has changed in a long time, longer ago than September.
Can you reliably replicate this being resolved going back to an earlier release, then breaking going back to 1.2.1 release? If so, what date is the one that works? Given the lack of changes in any related areas, I doubt if that's truly the case. If so, I have a bunch of 1.2.1 snapshots that I can make available to help narrow down further.
The Atheros based wireless PCI NIC I'm using as my 'production' wireless access point gives service over many days without requiring a reboot. On the other hand, a USB wireless NIC I played with only a little bit (rum driver) doesn't seem to sustain connections very long but I've not seriously investigated that yet.
After upgrading to 1.2.1-RC3 on Monday, and letting it run a few days, the problem appears to be gone.
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 386 0.0 0.2 5696 1960 con- S Mon12PM 0:05.94 /usr/sbin/tcpdump -s 256 -v -l -n -e -ttt
I'm still not sure what may have caused the symptoms I saw in my original post. Something sure made tcpdump chew through a lot of CPU time and memory in less than a week, but as long as it doesn't happen again it was probably a fluke or a side effect of the testing I had done.
It's a while since I thought about this one. I've been running 1.2.1-RCx with SLBD (3 failover groups) for weeks now on a quad core xeon rackmount (DL140). I've not seen SLBD grab 100% of a core for a long time now. And stability seems good.
One thing I do see is some mis-reporting in the GUI. A line may show "Offline" whereas the logs show that line as up ie. "marking service UP" was the most recent log for that line. I consistently see this on the primary firewall (SMB) but not on the backup firewall (uniprocessor). The backup firewall uses the same synched-over settings and correctly shows all the lines as "online".
I agree - sort of. It should at least prompt the user that a reboot might be necessary to complete the change. This has been an issue for some time now, though I'm not sure it affects everyone, though I have experienced it many times.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.