Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    WAN interfaces fail to return after power outage

    Scheduled Pinned Locked Moved
    General pfSense Questions
    4
    49
    6.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      Actually that should have been resolved already in https://redmine.pfsense.org/issues/8507

      If it does work that has somehow missed your install.

      Steve

      B 1 Reply Last reply Reply Quote 0
      • B
        bfeitell
        last edited by bfeitell

        From what I have read, I see references to the 576 MTU related to dialup connections. This might be an old fall-back that is being exposed only because dhclient now respects the option interface-mtu value being sent by the DHCP server. The value shows up in the issued lease. The changes in dhclient upstream are now exposing this.

        This is worth exploring in connection with reports of WAN interface disconnections, unpredictable website connectivity, and may affect things like name resolution. When combined with the "IP Do-Not-Fragment compatibility" option in System/Advanced/Firewall&NAT, the small MTU breaks connectivity with some websites. I saw problems with the iHeart Radio website and streams, and with loading newyorker.com. Please propagate this up the chain. My earlier post has links to the issues as they are discussed in the FreeBSD development system.

        https://forum.netgate.com/topic/136089/solved-and-revised-2-4-4-release-arpresolve-can-t-allocate-llinfo-for-gateway-on-interface0-dhcp-mtu-576

        1 Reply Last reply Reply Quote 0
        • B
          bfeitell @stephenw10
          last edited by bfeitell

          @stephenw10

          The fix discussed in Redmine doesn't seem to have made it into 2.4.4-RELEASE.

          Rather, the fix of using the patched version of dhclient now in the FreeBSD tree is that the user must issue "supersede interface-mtu 0" to ignore the requested option 26 information. Dhclient is still requesting option 26 info from the DHCP server. The patch allows being able to supersede option 26 as issued with the lease.

          1 Reply Last reply Reply Quote 0
          • B
            bfeitell
            last edited by

            I have opened a Redmine account, and posted in the relevant thread.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              I agree, it's certainly worth exploring. It could explain a number of threads here.

              The value supersede interface-mtu 0 should be in the dhclient conf files in /var/etc by default. It is on everything I've just checked. If some connections are still seeing a 576 MTU then there must be some combination of factors that prevent it being added. If that is the case we need to find out what they are and stop that happening.

              Steve

              1 Reply Last reply Reply Quote 0
              • B
                bfeitell
                last edited by

                I have a sneaking suspicion that a prior manual setting of MTU on the interface may be interfering with the the setting of supersede interface-mtu 0 in dhclient.conf on upgrade. I know that I have previously hard set the MTU to 1500 on a number of boxes as a matter of course. In this instance, the hard set MTU will not be respected if supersede interface-mtu 0 is not making it into dhclient.conf.

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  I think you're right. Working on something now....

                  1 Reply Last reply Reply Quote 0
                  • B
                    bfeitell
                    last edited by

                    Jim Pingle, the developer working on this has entered a new diff. Apparently, checking the advanced options checkbox and then saving and applying the config with no other changes entered, and then upgrading to 2.4.4-RELEASE, is enough to disrupt the fix the developers had put in place for the option 26 interface-mtu bug introduced by the new dhclient.

                    1 Reply Last reply Reply Quote 0
                    • jimpJ
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      I added a new note with a workaround to the Upgrade Guide: https://www.netgate.com/docs/pfsense/install/upgrade-guide.html#upgrading-from-versions-older-than-pfsense-2-4-4

                      A patch is available that can be added with the System Patches package.

                      The fix is discussed on https://redmine.pfsense.org/issues/8507

                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

                      1 Reply Last reply Reply Quote 1
                      • B
                        bfeitell
                        last edited by

                        Thank you! This is wonderful.

                        1 Reply Last reply Reply Quote 0
                        • B
                          bfeitell
                          last edited by bfeitell

                          I think this bug also applies to fresh installs using a restored config, not just on in-place upgrades. That is the case for the system I encountered this on.

                          jimpJ 1 Reply Last reply Reply Quote 0
                          • jimpJ
                            jimp Rebel Alliance Developer Netgate @bfeitell
                            last edited by

                            @bfeitell said in WAN interfaces fail to return after power outage:

                            I think this bug also applies to fresh installs using a restored config, not just on in-place upgrades. That is the case for the system I encountered this on.

                            Since it is a setting in the configuration and not a problem on the filesystem, that is correct. If you restore a config with advanced or custom options set there, it would fail this way.

                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                            Need help fast? Netgate Global Support!

                            Do not Chat/PM for help!

                            1 Reply Last reply Reply Quote 0
                            • B
                              bfeitell
                              last edited by

                              It is an insidious bug. I triggered the DHCP renewal problems by saving and applying on the WAN with or without changes. Unless triggered by the user, it will lurk until the next DHCP renewal fails, and that may not happen for 30 minutes or more. Looking through recent forum posts, I suspect this bug is in play whenever a user notices arpresolve: can't set llinfo for $GATEWAY on $INTERFACE errors.

                              1 Reply Last reply Reply Quote 0
                              • P
                                peter_richardson
                                last edited by

                                Okay so it went a bit over my head there. Can someone please break it down for me? Where are we up to with this one? Is there a patch? Or a configuration change is needed?

                                1 Reply Last reply Reply Quote 1
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  First try just adding the following to the option modifiers field in the advanced section of the dhcp setup on WAN. Check the 'Advanced Configuration' box to see that field if it's not already.
                                  supersede interface-mtu 0

                                  If that works then you can try the patch instead. That would be a helpful test for us.

                                  Steve

                                  1 Reply Last reply Reply Quote 0
                                  • P
                                    peter_richardson
                                    last edited by peter_richardson

                                    Hey Steve, okay I tried it (see screenshot) but didn't change anything. System log didn't report any errors this time though.2_1538947004879_Screenshot_20181008-080516.png 1_1538947004850_Screenshot_20181008-080614.png 0_1538947004779_Screenshot_20181008-080428.png I didn't have the WWAN connected this time so that's why it's not showing up. To get the WAN connection going again after power out, I need to either unplug the Ethernet cable and re plug, or disable and re enable the interface, or make some change in the WAN interface and save.

                                    1 Reply Last reply Reply Quote 1
                                    • stephenw10S
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      Hmm, no 'arpresolve' errors though?

                                      Did you ever try running ifconfig -av during the working and non-working states to compare them?

                                      Steve

                                      1 Reply Last reply Reply Quote 0
                                      • P
                                        peter_richardson
                                        last edited by

                                        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.

                                        1 Reply Last reply Reply Quote 1
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by

                                          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

                                          1 Reply Last reply Reply Quote 0
                                          • P
                                            peter_richardson
                                            last edited by peter_richardson

                                            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$
                                            jimpJ 1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post