FreeBSD 11.2-BETA dhclient always uses server MTU value
I hit this while looking into #8506, it may not be related since it happens on other hardware. It also started around the switch to 11-stable.
Something is setting the MTU too low, and it's not in the configuration.
May 11 07:26:34 blooper kernel: nd6_setmtu0: new link MTU on mvneta0 (576) is too small for IPv6
That message happens on both an igb box and SG-3100. The routes for this interface only have that same low MTU:
: netstat -4rnW | egrep '(Mtu|mvneta0)' Destination Gateway Flags Use Mtu Netif Expire default 126.96.36.199 UGS 21213 576 mvneta0 188.8.131.52 184.108.40.206 UGHS 55825 576 mvneta0 220.127.116.11 18.104.22.168 UGHS 182429 576 mvneta0 22.214.171.124 126.96.36.199 UGHS 489319 576 mvneta0 188.8.131.52/24 link#1 U 0 576 mvneta0
The interface configuration is a DHCP WAN:
<opt1> <descr><![CDATA[Cable]]></descr> <if>igb2</if> <enable></enable> <alias-address></alias-address> <alias-subnet>32</alias-subnet> <spoofmac>00:xx:xx:xx:xx:xx</spoofmac> <monitorip>x.x.x.1</monitorip> <ipaddr>dhcp</ipaddr> <dhcphostname></dhcphostname> <dhcprejectfrom>192.168.100.1</dhcprejectfrom> <adv_dhcp_pt_timeout></adv_dhcp_pt_timeout> <adv_dhcp_pt_retry></adv_dhcp_pt_retry> <adv_dhcp_pt_select_timeout></adv_dhcp_pt_select_timeout> <adv_dhcp_pt_reboot></adv_dhcp_pt_reboot> <adv_dhcp_pt_backoff_cutoff></adv_dhcp_pt_backoff_cutoff> <adv_dhcp_pt_initial_interval></adv_dhcp_pt_initial_interval> <adv_dhcp_pt_values>SavedCfg</adv_dhcp_pt_values> <adv_dhcp_send_options></adv_dhcp_send_options> <adv_dhcp_request_options></adv_dhcp_request_options> <adv_dhcp_required_options></adv_dhcp_required_options> <adv_dhcp_option_modifiers></adv_dhcp_option_modifiers> <adv_dhcp_config_advanced></adv_dhcp_config_advanced> <adv_dhcp_config_file_override></adv_dhcp_config_file_override> <adv_dhcp_config_file_override_path></adv_dhcp_config_file_override_path> </opt1>
It does have a spoofed MAC, and there is a GIF interface on top of that interface as well as an OpenVPN and IPsec, but attempting to configure those on a fresh lab install doesn't trigger the issue, and removing them or disabling them here doesn't seem to affect it.
Other interfaces (PPPoE WAN, multiple local LANs) are unaffected.
I commented out every call to
pfSense_interface_mtu() in interfaces.inc and the low MTU still happened, so it doesn't appear to be related to that function at least.
This requires a patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721#c12 which garga has imported into the tree.
#1 Updated by Jim Pingle over 1 year ago
Same thing happens on a factory default configuration, so looking deeper at packet captures of the DHCP packets the ISP is sending an MTU of 576. This was not requested on 11.1, but is being requested and applied now.
/usr/local/sbin/pfSense-dhclient-script doesn't have any code to process the MTU, so it may be getting set by dhclient directly.
Comparing 2.4.3-p1 and 2.4.4, the only difference in the request is that the 2.4.4 client requests option 26 (Interface MTU) in addition to the other parameters.
#2 Updated by Jim Pingle over 1 year ago
Looks like this is a recent change in FreeBSD dhclient to add support for the MTU:
It seems they were aware it could cause link bounces, and changed dhclient so it doesn't exit when the link drops, but it appears to still trip up our link handling scripts.
Based on that, this could end up being the same root cause as #8506 but it manifested differently depending on the hardware.
#3 Updated by Jim Pingle over 1 year ago
I tried setting an explicit request list in the generated dhclient configuration which does not send a request for the MTU. Didn't help, if the server sends the MTU it still is taken and used.
I also tried setting a
supersede statement for interface-mtu with 0, 1, and other values (e.g. 1402), all of which appear to be ignored in favor of the server-side MTU value every time.
It looks like the way it was coded into dhclient in https://reviews.freebsd.org/D5675 that it can't be ignored or overridden, which is rather awful. We may need to back that patch out or convince FreeBSD that it needs fixed to at least have a way to turn that off or respect the supersede. Preferably disable it entirely.
#4 Updated by Jim Pingle over 1 year ago
- Subject changed from Interface MTU being set incorrectly in some cases to FreeBSD 11.2-BETA dhclient always uses server MTU value
Updated the subject to be more accurate.
I also dropped a note on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721#c10
#6 Updated by Jim Pingle over 1 year ago
The patch looks good. Setting a supersede of 0 in the dhclient config now allows the MTU change to be ignored. The test system I could replicate the MTU issue on is OK now, and there are multiple confirmations that the latest snapshot is working as expected from forum users.
We need to keep an eye on https://reviews.freebsd.org/D15484 as it evolves and is eventually committed to 11.2. Once it makes it into the tree, the manually added patch can be removed.
#7 Updated by Jim Pingle over 1 year ago
- Status changed from Feedback to Assigned
- Assignee set to Renato Botelho
- Priority changed from Very High to Normal
- Affected Architecture set to All
The supersede change was committed and now has been MFC'd as well:
We should be able to remove the patch we added manually in favor of the version now the tree.
#9 Updated by Bennett Feitell about 1 year ago
This is still causing problems in pfSense 2.4.4-RELEASE.
I believe that the upstream patches to FreeBSD introduce the ability to supersede the option 26 interface-mtu value being returned by the DHCP server. The user must affirmatively add "supersede interface-mtu 0", or the system will set the bad MTU in the DHCP server response. Option 26 information is still being requested, and if it is returned by the server with the lease it will be enforced to the point of overriding an explicitly set MTU. If the MTU given in the lease is bad, things break.
Please see these threads:
#10 Updated by Jim Pingle about 1 year ago
We already set that (see the linked commit above).
My edge firewall failed horribly because my ISP sent the MTU even when not requested, but it is working now. So there is something else happening here that isn't necessarily related to the dhclient config, but perhaps the presence of the proper code/patch in the binary.
#12 Updated by Jim Pingle about 1 year ago
The line should always be there by default, unless there is some other customization that prevented it from working. Check your copy of /etc/inc/interfaces.inc and make sure it matches the above line.
If you have any other custom settings in the WAN DHCP client settings, I'd be interested to know what they are.
#13 Updated by Bennett Feitell about 1 year ago
I suspect that a prior hard setting of MTU on the interface may be interfering with the propagation of the fix in dhclient.conf on upgrades. I know that I have routinely hard set an MTU of 1500 on the boxes I adminster. Is it possible that the hard setting of MTU is preventing dhclient.conf from picking up the change on upgrade? If so, it would explain the behavior I have seen.
#15 Updated by Jim Pingle about 1 year ago
Looks like there may be two ways this could happen:
#1: If you used advanced DHCP client options that clobber the default values. This case would be fixed by the attached patch.
#2: A custom dhclient configuration file, which would need to be fixed manually. Injecting automatic edits into that seems wrong, though. I'll add a note to the upgrade guide about it. Someone might conceivably need this behavior and not letting them override it seems like a bad idea.
#21 Updated by Jim Pingle about 1 year ago
No, that setting would not do it on its own, as it is handled in a different way.
It only happens when
adv_dhcp_config_advanced is set, which is the Advanced Configuration checkbox, or when Configuration Override is set pointing to a custom file, which is a different case.
#23 Updated by Jim Pingle about 1 year ago
If you check the box and save, it will overwrite the default DHCP values with what is in the boxes for Protocol Timings, Presets, or Lease Requirements and Requests, even if they are empty. The other settings do not require checking that box. So if someone did check it, they would lose the automatic supersede without my last patch, even if they made no other changes.