Bug #6823
openNo connectivity after changing link state to UP
0%
Description
Hi guys,
I have pfSense 2.3.2 installed on a Soekris net6501-50 board. I recently noticed that when the link of the two bridged LAN interfaces comes back up again,after being down for a few hours, the device connected doesn't have network connectivity. Basically I have to reboot pfSense to make it work. I have tried plugging in other devices, cables, restarting services etc. but nothing helped.
You can see below the system log showing em0/LAN1 interface coming back up and honestly I don't know why newwanip and OpenVPN are mentioned since this has nothing to do with the WAN interface, my WAN is em3 actually. TFTP proxy is also not enabled at all.
I was thinking my issue might be a bug related to a driver and the way it initializes an interface, but I'm not really sure and that's why I'm posting it here. By the way, if I want to reinstall the latest pfSense on that board, I have to install 2.1.5 from memstick to my CF and then use the web UI to upgrade directly to 2.3.x and restore my config. If I install directly 2.3.x it doesn't boot from the CF for whatever reason and this is something other people have also noticed with Soekris boards.
Any feedback would be really appreciated, thank you in advance!
Sep 27 08:02:42 kernel em2: promiscuous mode enabled
Sep 27 08:02:42 kernel ath0_wlan0: promiscuous mode enabled
Sep 27 08:02:42 kernel bridge0: promiscuous mode enabled
Sep 27 08:02:40 xinetd 24203 Reconfigured: new=0 old=1 dropped=0 (services)
Sep 27 08:02:40 xinetd 24203 readjusting service 6969-udp
Sep 27 08:02:40 xinetd 24203 Swapping defaults
Sep 27 08:02:40 xinetd 24203 Starting reconfiguration
Sep 27 08:02:40 kernel em2: promiscuous mode disabled
Sep 27 08:02:40 kernel ath0_wlan0: promiscuous mode disabled
Sep 27 08:02:40 kernel bridge0: promiscuous mode disabled
Sep 27 08:02:39 check_reload_status Reloading filter
Sep 27 08:02:36 php-fpm 76611 /rc.start_packages: Restarting/Starting all packages.
Sep 27 08:02:35 check_reload_status Starting packages
Sep 27 08:02:35 php-fpm 76368 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 0.0.0.0 -> - Restarting packages.
Sep 27 08:02:33 php-fpm 76368 /rc.newwanip: Creating rrd update script
Sep 27 08:02:33 php-fpm 76368 /rc.newwanip: Resyncing OpenVPN instances for interface LAN1.
Sep 27 08:02:31 xinetd 24203 Reconfigured: new=0 old=1 dropped=0 (services)
Sep 27 08:02:31 xinetd 24203 readjusting service 6969-udp
Sep 27 08:02:31 xinetd 24203 Swapping defaults
Sep 27 08:02:31 xinetd 24203 Starting reconfiguration
Sep 27 08:02:29 xinetd 24203 Reconfigured: new=0 old=1 dropped=0 (services)
Sep 27 08:02:29 xinetd 24203 readjusting service 6969-udp
Sep 27 08:02:29 xinetd 24203 Swapping defaults
Sep 27 08:02:29 xinetd 24203 Starting reconfiguration
Sep 27 08:02:29 php-fpm 76368 /rc.newwanip: IP has changed, killing states on former IP 0.0.0.0.
Sep 27 08:02:28 php-fpm 76368 /rc.newwanip: rc.newwanip: on (IP address: ) (interface: LAN1[opt4]) (real interface: em0).
Sep 27 08:02:28 php-fpm 76368 /rc.newwanip: rc.newwanip: Info: starting on em0.
Sep 27 08:02:27 check_reload_status Reloading filter
Sep 27 08:02:27 check_reload_status rc.newwanip starting em0
Sep 27 08:02:27 php-fpm 76368 /rc.linkup: Hotplug event detected for LAN1 static IP ( )
Sep 27 08:02:26 kernel em0: link state changed to UP
Sep 27 08:02:26 check_reload_status Linkup starting em0
Updated by Jim Pingle about 8 years ago
Sounds like a problem that used to happen on older em chips, if you run "ifconfig em0 down; ifconfig em0 up
" for each affected interface, it might recover.
That was fixed in FreeBSD some time ago, but it's probably crept back in, or perhaps it only affects i386 now. It does not seem to affect other cards, though, so you may be out of luck if it's hardware specific.
It may be tough to do, but if the problem can be reproduced on a plain FreeBSD 10.3 installation using the same hardware, then reporting the issue to FreeBSD could potentially lead to a resolution, but the problem is generally at a level over which we have no control.
I don't believe any of us have any working net6501 units on hand any longer to test with (I had one but it no longer POSTs).
Updated by C S about 8 years ago
Thanks Jim! I'll report to FreeBSD. It's something that started happening a few months ago so I think one of the latest updates introduced the bug.
Updated by C S about 8 years ago
They had the same issue in OPNsense, so they created a FreeBSD port of the stock Intel driver version 7.6.2, which works fine.
Let's hope they get it into the tree soon.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212828
One of the issues mentioned: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211219
Updated by C S about 8 years ago
Patch for review here:
Updated by Jim Thompson about 8 years ago
- Category set to Interfaces
- Assignee set to Renato Botelho
We would have to provide the ports of the Intel drivers as packages, and then allow people to load the package on demand.
Updated by C S about 8 years ago
Jim Thompson wrote:
We would have to provide the ports of the Intel drivers as packages, and then allow people to load the package on demand.
Yes, that would be great! Any progress yet?