WAN does not renew after reboot

stephenw10

Hmm, there's something else going on there. It's not a timing a reboot issue for starters.

More importantly I don't see a single log showing:

kernel 		igb0: link state changed to UP

Or DOWN. Is the link actually flapping or is it just race conditions with a number of scripts?

Steve

Patch

@stephenw10 said in WAN does not renew after reboot:

Is the link actually flapping

It is flapping up stream ( probably due to moisture in joints on the cable shared between a group of NBN customers).

I don’t actually know what the NBN modem does to the Ethernet line to pfsense when this occurs.

stephenw10

Do you only have one WAN? If so try disabling the gateway montoring action for it. It looks like there are a bunch of scripts being fired each time it flaps that doing nothing useful.
Are you running Snort or Suricata in in-line mode? That could explain why it's showing the link go down/up but the NIC driver isn't reporting that.

Steve

Patch

@stephenw10 said in WAN does not renew after reboot:

Do you only have one WAN? If so try disabling the gateway montoring action for it.

Yes one lan. I will disable monitoring to see if that help.
Testing will be a challange as the failure is not frequent (about 1 / month atm).

@stephenw10 said in WAN does not renew after reboot:

Are you running Snort or Suricata in in-line mode?

Neither.
Have loaded pfBlockerNG-devel but notice no change since and not actually configured it.
no other packages have been loaded

stephenw10

Hmm, well unclear why it's logging a hotplug event then. But disabling monitoring action is a good test anyway.

RyanM

@stephenw10 said in WAN does not renew after reboot:

How exactly is it connected? Just to the main router or via some wifi bridge/extension?

Right now I just have the WAN plugged into a switch on my network at this location. When I ship it home, it will be connected directly to the ethernet cable coming from the fiber optic "modem".

@bingo600 good idea on disconnect/reconnect WAN after boot. I may see if that is a temporary work-around.

@stephenw10 said in WAN does not renew after reboot:

@RyanM When you generated that log was it only pfSense that was rebooted? The upstream router was not? Yet it still hadn't linked by that point?

Steve

Correct, I did not reboot the modem/router. I just booted pfSense.

@Gertjan fascinating write-up on the timing of when dhclient is initialized and when my interfaces are "up".

I am going to try adding that shellcmd package and the suggested command here after boot to see if it helps it pull an IP on this network. And I understand the behavior may be different at the other location, but I would at least like to see it work here first...

RyanM

I used a different cable and am now seeing "1000baseT <full-duplex>" for WAN. I also moved the router to be on a switch connected directly to the Google WiFi that is acting as the router. Now my pfSense router is pulling an IP for the WAN when it boots. I think I am good. Will hopefully be able to ship this box home and get friend to plug it in and get internet at home working again.

stephenw10

Nice result!

RyanM

Did a test where I plugged pfSense router directly into cable modem and was able to connect on mobile phone using VPN. I think I am in business. Thanks for the help.

hoegge

This is still an issue. On both my pfSense boxes, they do not take a WAN address by DHCP if the pfSense box is up before the Fiber modem connection, which is always the case after a power outage. That means you have to drive to the location to press the renew DHCP button. This cannot be right and is a real problem

viragomann

@hoegge
That was discussed here recently. Also there were solutions or workarounds given: https://forum.netgate.com/topic/177429/3100-tries-to-configure-wan-before-fiber-modem-has-uplink/3

hoegge

@viragomann Thanks a lot - I'll try that. Still don't understand, why netgate has not made the client continue retrying, if it has no lease. Must be a common problem, and e.g. in my case, I have to drive 200 km to fix it :-(

hoegge

@viragomann Ah - looks as if this will be fixed in an upcoming release according to https://redmine.pfsense.org/issues/13671#note-2

stephenw10

It's a timing issue. The client cannot run on an interface that has no link so if it detects that it stops. When the NIC sees a link it triggers the client to start and it pulls a lease.
However during boot linkup events are suppressed because they are otherwise run repeatedly as each interface is configured. If your upstream device happens to have a boot delay that means the link comes up between the interface being configured and bootup completing you can hit this problem. It's not a huge window. Most users never see it.
It is a problem though and the patch on that bug report prevents it. Or just set the boot wait time higher to avoid it.

Steve

hoegge

@stephenw10 Thanks - I'll apply the patch - a delay is not really a robust solution, since you never know, what boots when and how fast.

stephenw10

Please leave feedback on that bug report if it works for you.