Project

General

Profile

Actions
Copy link

Bug #8507

closed

FreeBSD 11.2-BETA dhclient always uses server MTU value

Added by Jim Pingle over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Renato Botelho
Category:
Interfaces
Target version:
2.4.4
Start date:
05/11/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4
Affected Architecture:
All

Description

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            216.252.41.1       UGS       21213    576    mvneta0
8.8.8.8            216.252.41.1       UGHS      55825    576    mvneta0
208.123.73.7       216.252.41.1       UGHS     182429    576    mvneta0
209.51.181.2       216.252.41.1       UGHS     489319    576    mvneta0
216.252.41.0/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.

Files

supersede-advanced.diff (531 Bytes) supersede-advanced.diff Jim Pingle, 10/02/2018 02:38 PM
Actions
Copy link

Also available in: Atom PDF