WAN starts cycling link after Ethernet link loss



  • I've just installed pfSense on new hardware, and am having trouble with the behavior of the WAN port. It'll work fine after I boot the machine UNTIL the first time I lose Ethernet link. This typically happens because the CMTS link goes down, causing my cable modem to drop the Ethernet link.

    Once the Ethernet link goes down the first time, I see the WAN port go down for about five seconds every 20 seconds or so. Usually this is behavior that I associated with one side of the link trying to run autonegotiation, with the other side having a fixed setting. However, it negotiates the link just fine the FIRST time after the machine boots.

    If I put an Ethernet switch between the cable modem and the WAN port, this means that the WAN port never loses Ethernet link and everything works fine.

    Any suggestions on a good way to get this to tolerate the Ethernet link going down?

    Thanks!

    I'm running the following versions:

    2.4.4-RELEASE-p1 (amd64)
    built on Mon Nov 26 11:40:26 EST 2018
    FreeBSD 11.2-RELEASE-p4

    Hardware is Intel(R) Celeron(R) CPU J1900 @ 1.99GHz with Intel NIC's running under the Intel PRO/1000 driver.



  • I'll also add that it falls into this state if I do anything that causes the WAN interface configuration to reload.

    ISP is Comcast with IPv6 enabled.



  • I had the same happen on my APU2C4s.

    This may sound strange, but the workaround there is to set WAN Speed and Duplex to 'Default' instead of 'Autoselect'.



  • @jitguy That seems to have fixed it, thank you!

    I'd call this a "bug"...it acts like setting "Autoselect" actually disables auto-negotiation!


  • LAYER 8 Netgate

    It runs another ifconfig to explicitly set autoselect. When it does it bounces the link. That is probably freaking out what it is connecting do and it is bouncing the link too, initiating a negotiation loop.

    I wouldn't call it a bug in pfSense. It could be a bug in the modem. :)

    I would call it an incompatibility caused by someone that shouldn't be tweaking settings and checking boxes unnecessarily since default (usually autoselect) is the default for a reason.



  • @derelict It sounds like a timing/race condition between the script code that's trying to configure the port and the Ethernet driver.

    Why is the pfSense GUI doing ifconfig's to the running port configuration instead of updating the default configuration in the filesystem and then telling the port to reload defaults? If the current GUI settings match the filesystem defaults, then you don't need to touch the port. This also helps avoid potential race conditions between the initial operating system initialization of the Ethernet driver and the later initialization performed after pfSense has started.

    I've configured plenty of network devices in my time, and I've never before had explicitly setting a port to auto-negotiation take the port down while the other end of the link was also set to auto-negotiate. Saying that the "user shouldn't do that" doesn't make pfSense any more robust or reliable.


  • LAYER 8 Netgate

    If you really believe it is a bug and have steps to reproduce, a bug can be opened at https://redmine.pfsense.org/

    Of course, a pull request with a fix is always appreciated.



  • @derelict said in WAN starts cycling link after Ethernet link loss:

    It runs another ifconfig to explicitly set autoselect. When it does it bounces the link. That is probably freaking out what it is connecting do and it is bouncing the link too, initiating a negotiation loop.

    I wouldn't call it a bug in pfSense. It could be a bug in the modem. :)

    I would call it an incompatibility caused by someone that shouldn't be tweaking settings and checking boxes unnecessarily since default (usually autoselect) is the default for a reason.

    Nice explanation. Not sure of the need to slam those of us that have run into that problem though. After all, the GUI text specifically says:

    "WARNING: MUST be set to autoselect (automatically negotiate speed) unless the port this interface connects to has its speed and duplex forced."

    A bit of a stretch to blame us for heeding the bold warning.