WAN interfaces fail to return after power outage
-
Hmm, no 'arpresolve' errors though?
Did you ever try running
ifconfig -avduring the working and non-working states to compare them?Steve
-
Did you see the above images? One of them is of the syslog while it was happening after putting in the string into the Option Modifiers field.
Yes I did, but it's on my other computer, I'll paste it here later.
-
Yes I see those. I don't see any arpresolve errors in there but I thought you may have seen some that aren't in that shot. That only shows 10s worth of logs.
Steve
-
yeah that's the last few entries from it booting, then there's nothing else after that.
Here's the output from ifconfig -v but according to www.diffchecker.com there's no difference in the output whether it's working properly or not:
Petes-MBP:~ Peter$ ifconfig -v lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 index 1 eflags=12000000<ECN_DISABLE,SENDLIST> options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD> link quality: 100 (good) state availability: 0 (true) timestamp: disabled qosmarking enabled: no mode: none gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 index 2 eflags=1000000<ECN_ENABLE> state availability: 0 (true) qosmarking enabled: no mode: none stf0: flags=0<> mtu 1280 index 3 eflags=1000000<ECN_ENABLE> state availability: 0 (true) qosmarking enabled: no mode: none XHC20: flags=0<> mtu 0 index 4 eflags=41000000<ECN_ENABLE,FASTLN_ON> state availability: 0 (true) qosmarking enabled: yes mode: none en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 5 eflags=41200880<TXSTART,ARPLL,NOACKPRI,ECN_ENABLE,FASTLN_ON> ether a0:99:9b:14:37:55 inet6 fe80::42d:fd6:9a6d:c5ec%en0 prefixlen 64 secured scopeid 0x5 inet 10.20.63.133 netmask 0xffffff00 broadcast 10.20.63.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active type: Wi-Fi link quality: 100 (good) state availability: 0 (true) scheduler: FQ_CODEL (driver managed) link rate: 53.95 Mbps qosmarking enabled: yes mode: none p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304 index 6 eflags=41000080<TXSTART,ECN_ENABLE,FASTLN_ON> ether 02:99:9b:14:37:55 media: autoselect status: inactive type: Wi-Fi state availability: 0 (true) scheduler: FQ_CODEL (driver managed) link rate: 10.00 Mbps qosmarking enabled: yes mode: none awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484 index 7 eflags=413e0080<TXSTART,LOCALNET_PRIVATE,ND6ALT,RESTRICTED_RECV,AWDL,NOACKPRI,ECN_ENABLE,FASTLN_ON> ether 0a:60:dd:0c:a4:0f inet6 fe80::860:ddff:fe0c:a40f%awdl0 prefixlen 64 scopeid 0x7 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active type: Wi-Fi state availability: 0 (true) scheduler: FQ_CODEL (driver managed) link rate: 10.00 Mbps qosmarking enabled: yes mode: none en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 index 8 eflags=41000080<TXSTART,ECN_ENABLE,FASTLN_ON> options=60<TSO4,TSO6> ether 6a:00:00:9f:55:50 media: autoselect <full-duplex> status: inactive type: Ethernet state availability: 0 (true) scheduler: FQ_CODEL qosmarking enabled: yes mode: none en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 index 9 eflags=41000080<TXSTART,ECN_ENABLE,FASTLN_ON> options=60<TSO4,TSO6> ether 6a:00:00:9f:55:51 media: autoselect <full-duplex> status: inactive type: Ethernet state availability: 0 (true) scheduler: FQ_CODEL qosmarking enabled: yes mode: none bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 10 eflags=41000000<ECN_ENABLE,FASTLN_ON> options=63<RXCSUM,TXCSUM,TSO4,TSO6> ether 6a:00:00:9f:55:50 Configuration: id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0 maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200 root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0 ipfilter disabled flags 0x2 member: en1 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 8 priority 0 path cost 0 hostfilter 0 hw: 0:0:0:0:0:0 ip: 0.0.0.0 member: en2 flags=3<LEARNING,DISCOVER> ifmaxaddr 0 port 9 priority 0 path cost 0 hostfilter 0 hw: 0:0:0:0:0:0 ip: 0.0.0.0 media: <unknown type> status: inactive state availability: 0 (true) qosmarking enabled: yes mode: none utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000 index 11 eflags=1002080<TXSTART,NOAUTOIPV6LL,ECN_ENABLE> inet6 fe80::aae2:a7ca:ad8a:540%utun0 prefixlen 64 scopeid 0xb nd6 options=201<PERFORMNUD,DAD> agent domain:ids501 type:clientchannel flags:0xc3 desc:"IDSNexusAgent ids501 : clientchannel" state availability: 0 (true) scheduler: FQ_CODEL qosmarking enabled: no mode: none utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380 index 12 eflags=1002080<TXSTART,NOAUTOIPV6LL,ECN_ENABLE> inet6 fe80::a4b9:a2b2:95c:b086%utun1 prefixlen 64 scopeid 0xc inet6 fdb7:98e5:bc83:2490:a4b9:a2b2:95c:b086 prefixlen 64 nd6 options=201<PERFORMNUD,DAD> state availability: 0 (true) scheduler: FQ_CODEL qosmarking enabled: no mode: none Petes-MBP:~ Peter$ -
@peter_richardson said in WAN interfaces fail to return after power outage:
yeah that's the last few entries from it booting, then there's nothing else after that.
Here's the output from ifconfig -v but according to www.diffchecker.com there's no difference in the output whether it's working properly or not:
That appears to be from your Mac, not pfSense. Try that command on pfSense when it works and when it doesn't.
-
@jimp sorry, that was a silly mistake! I'll test again later today and report back.
-
@jimp said in WAN interfaces fail to return after power outage:
hat command on pfSense when it works and when it doesn't.
Hey guys, sorry for the late reply, I have finally had a spare minute to do some testing. Please see attached.
EDIT: I CAN'T REPLY BECAUSE I GET THIS ERROR:
ERROR
Post content was flagged as spam by Akismet.com -
What are you trying to post? The ifconfig output?
It will probably allow you to post a screenshot of it if it's still blocking you.
Steve
-
Yes, 2 of then but that would make 4 images plus the other image, and then you can't copy and paste text for analysis. Can we please fix this issue? Why would it mark my post as spam when I am a registered user, replying to a thread that I created, from the same public ip as always? And why not also tell me why it has been marked as spam so I can try to fix whatever it's issue is?
-
for now, click here to view my reply:
https://www.evernote.com/l/ADhKbADk7v9OEqpkJOKxMDlLcgZZPWWDJXs -
anyone?
-
I up-voted enough of your posts that you should not get hit by Akismet again.
Do you see anything logged showing it getting the 0.0.0.0 address? It looks like the WAN doesn't come back up because it sees that as a valid address. If something giving that to it you can exclude a particular DHCP server as a source.
Steve
-
Thanks Stephen!
So you're saying that it appears that pfSense is giving the WWAN interface the address of 0.0.0.0?
-
No, more likely it's something upstream giving it that before the connection comes up. Cable modems do that with monotonous regularity.
But I'm not sure what sort of hand-off you have. I know NBN can be several different things.
If that is the case though you should see something logged in the DHCP logs as the dhclient pulls the bad address.Steve
-
I see. No, the WWAN isn't NBN, the WWAN is 4G with a Telstra SIM card, using a Netgear Nighthawk M1.
So changing the WWAN interface from DHCP to static with an IP address that is in the M1's usual DHCP range should fix this. IE: set the IP to 192.168.0.50 but alas, it just shows on the dashboard as "gateway down". So it looks like this isn't the issue. In fact, once I set the IP to static, it didn't work at all, which makes me wonder what is going on since previously, any changes to the WWAN connection would make the connection come back online, and giving it a static address shouldn't prevent it from working under normal conditions, so long as the address is within the M1's normal DHCP range.
-
Hmm, well the DHCP logs should still show if the bad address is coming from somewhere upstream. If it's coming from a different DHCP server you can block it as a source and the client will continue to look for other servers. That works well with cable modems that do this.
Anyway check the logs for 0.0.0.0 messages.Steve
-
I can't see anything in the DHCP logs for 0.0.0.0 I even lengthened the log to 1,000 entries, which took me back to about 11am today, should I go back further?
Here's what's in there, I can't make much sense of it, can you?
what's the "fail" all about?Nov 16 13:20:13 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 1 Nov 16 13:20:14 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 2 Nov 16 13:20:16 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 3 Nov 16 13:20:19 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 5 Nov 16 13:20:24 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 13 Nov 16 13:20:37 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 14 Nov 16 13:20:51 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 12 Nov 16 13:21:03 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 8 Nov 16 13:21:11 dhclient 99656 No DHCPOFFERS received. Nov 16 13:21:11 dhclient 99656 No working leases in persistent database - sleeping. Nov 16 13:21:11 dhclient FAIL Nov 16 13:21:26 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 1 Nov 16 13:21:27 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 1 Nov 16 13:21:28 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 2 Nov 16 13:21:30 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 2 Nov 16 13:21:32 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 5 Nov 16 13:21:38 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 14 Nov 16 13:21:52 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 11 Nov 16 13:22:03 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 16 Nov 16 13:22:11 dhcpd DHCPREQUEST for 10.20.63.134 from 80:5e:c0:07:7f:9c (W60B) via igb3 Nov 16 13:22:11 dhcpd DHCPACK on 10.20.63.134 to 80:5e:c0:07:7f:9c (W60B) via igb3 Nov 16 13:22:19 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 8 Nov 16 13:22:27 dhclient 99656 No DHCPOFFERS received. Nov 16 13:22:27 dhclient 99656 No working leases in persistent database - sleeping. Nov 16 13:22:27 dhclient FAIL Nov 16 13:22:42 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 1 Nov 16 13:22:43 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 2 Nov 16 13:22:45 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 4 Nov 16 13:22:49 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 9 Nov 16 13:22:58 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 21 Nov 16 13:23:19 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 16 Nov 16 13:23:36 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 7 Nov 16 13:23:43 dhclient 99656 No DHCPOFFERS received. Nov 16 13:23:43 dhclient 99656 No working leases in persistent database - sleeping. Nov 16 13:23:43 dhclient FAIL Nov 16 13:23:58 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 2 Nov 16 13:24:00 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 5 Nov 16 13:24:05 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 8 Nov 16 13:24:13 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 16 Nov 16 13:24:29 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 19 Nov 16 13:24:48 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 11 Nov 16 13:24:59 dhclient 99656 No DHCPOFFERS received. Nov 16 13:24:59 dhclient 99656 No working leases in persistent database - sleeping. Nov 16 13:24:59 dhclient FAIL Nov 16 13:25:14 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 2 Nov 16 13:25:16 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 5 Nov 16 13:25:21 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 9 Nov 16 13:25:30 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 9 Nov 16 13:25:40 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 12 Nov 16 13:25:52 dhclient 99656 DHCPDISCOVER on igb1 to 255.255.255.255 port 67 interval 15 -
Hmm, disappointing. The fail simply indicates the dhcp client failed to get get a lease from a server after completing its sequence and starts again after a pause.
Does the Nigthhawk log anything for this connection or is it entirely bridging?
Steve
-
I will have a look but I'm not holding my breath for any decent logging in a Netgear piece of equipment. I don't think this is a Netgear problem though, it doesn't happen with any other device such as a laptop. You can restart the laptop and it gets an IP address just fine. It's only when pfSense is restarted that this happens. And it's not just isolated to the Netgear device, it also happens with the WAN connection - so both connections fail to come back when the router is restarted. If the power goes off or I need to reboot the router for any reason, I have to go into the router, disable the interfaces and then re-enable the interfaces for them to work again.
-
Had to re-read the thread as I'd assumed it was a powerfailure on the upstream devices the prevented it connecting. Not connecting to either WAN after rebooting pfSense is even more weird.
Can you restore the connection by pulling the cable and reconnecting it? Or does it need logically disabled while remaining connected?
Steve
