Bug 612857 - Default dhclient config ignores interface-mtu option
Default dhclient config ignores interface-mtu option
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-09 05:09 EDT by Steve Hill
Modified: 2010-07-09 06:25 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-09 06:25:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Hill 2010-07-09 05:09:41 EDT
Description of problem:
In environments that use PPPoE links, an MTU of 1492 (at most) must be used on the PPPoE link instead of the usual 1500 used over Ethernet.  In theory this should require no further configuration elsewhere on the network since all endpoints should be able to do PMTU discovery.  Unfortunately, many firewalls/servers on the internet are administered by idiots and block the "ICMP frag needed" packets which are required for PMTU to work.  This results in intermittently broken TCP connections (a TCP connection will freeze indefinitely as soon as a packet greater than the MTU size is sent).

The work-around for this problem is to set the MTU on at least one of the endpoints to match the path MTU.  i.e. set the MTU on all of the machines on the local side of the PPPoE link to 1492.  This ensures that the TCP stacks of both endpoints will not attempt to exceed this packet size.

The DHCP protocol provides an "interface-mtu" option, which can be used to automatically set the MTU appropriately as client machines connect to the network.  Unfortunately, the default dhclient config ignores this option.


Version-Release number of selected component (if applicable):
dhclient-4.1.1-22.P1.fc13.i686


How reproducible:
Always


Steps to Reproduce:
1. Add a "option interface-mtu 1492;" line to the dhcp server's config file and restart the DHCP server.
2. Restart the NIC on the client Fedora 13 machine.
3. Use "ip li" to observe that the MTU remains unchanged.
  

Actual results:
dhclient ignores the option and leaves the MTU unchanged.


Expected results:
dhclient should change the MTU to match what the DHCP server is advising.


Additional info:
Adding "also request interface-mtu;" to the client machine's /etc/dhcp/dhclient.conf resolves this issue.  This should be added to the dhclient package's default config.
Comment 1 Jiri Popelka 2010-07-09 05:29:11 EDT
(In reply to comment #0)
> Adding "also request interface-mtu;" to the client machine's
> /etc/dhcp/dhclient.conf resolves this issue.  This should be added to the
> dhclient package's default config.    

This is strange. I'm sure the interface-mtu option has been requested by default since dhcp-4.1.1-9.fc12 (see bug #566873 and bug #574629).
I'll check this later.
Comment 2 Jiri Popelka 2010-07-09 06:19:22 EDT
Just tested with dhclient-4.1.1-22.P1.fc13.i686 and it works for me.

Would it be possible to capture network traffic
on client machine with wireshark ?

Configure server to send interface-mtu option and
on client machine:
1) delete /etc/dhcp/dhclient.conf
2) install wireshark-gnome, start wireshark
3) Capture->Options select the Interface, press Start
4) restart the interface or run 'dhclient -d interface'
5) stop the capture
6) File -> Save, save the packet dump and attach it to this bug report

thanks
Comment 3 Steve Hill 2010-07-09 06:25:15 EDT
Hmm, strange.  I've just retested and it works, so I'm a bit confused.  Looks like I was wrong - apologies for raising this issue, I'll close it - many thanks.

Note You need to log in before you can comment on or make changes to this bug.