Bug 566873

(In reply to comment #0)
> Client does not request the interface-mtu by default.
By default, the ISC DHCP client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, name-servers, domain-search, nis-domain, nis-servers, and ntp-servers options.
 
> Right now I need to go through every client manually and either set the MTU by
> hand or do:
> 
>   echo "request interface-mtu;" > /etc/dhclient.conf
> 
Note that if you enter a ’request’ statement, you over-ride the default requested options and these options will not be requested.
In this case, it is best to ’also request’ the additional options:
   echo "also request interface-mtu;" > /etc/dhclient.conf

> MTU should match what the dhcp server has configured..  And it shouldn't
> require me to touch every machine to specifically tell it to request the
> information -- what happens when I need to make the NEXT change to my network
> config?
This should help you:
https://lists.isc.org/mailman/htdig/dhcp-users/2007-December/005153.html

So in your case
add this line to your dhcpd.conf:
  option dhcp-parameter-request-list 1, 28, 2, 3, 15, 6, 12, 23, 24, 40, 41, 42, 26;
This force the server to send all above mentioned options plus interface-mtu (code 26). See RFC 2132 for these option codes.

I'll ask upstream if there's no problem with adding interface-mtu to the default requested options list. And if they answer ;-) I'll fix it in Fedora.

dhcp-4.1.1-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dhcp-4.1.1-8.fc12

(In reply to comment #1)
> (In reply to comment #0)
> > Client does not request the interface-mtu by default.
> By default, the ISC DHCP client requests the subnet-mask, broadcast-address,
> time-offset, routers, domain-name, domain-name-servers, host-name,
> name-servers, domain-search, nis-domain, nis-servers, and ntp-servers options.
I was wrong.
name-servers and domain-search are not requested by default by dhcpv4 client.
These are default for dhcpv6 client.

> So in your case
> add this line to your dhcpd.conf:
>   option dhcp-parameter-request-list 1, 28, 2, 3, 15, 6, 12, 23, 24, 40, 41,
> 42, 26;
Correct is:
    option dhcp-parameter-request-list 1, 28, 2, 3, 15, 6, 12, 40, 41, 42, 26;

dhcp-4.1.1-8.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2763

Derek,

can you test the dhclient from updates-testing (see above comment) to see if it correctly requests interface-mtu option ?       Thanks

dhcp-4.1.1-9.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2763

dhcp-4.1.1-9.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2763

dhcp-4.1.1-9.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

grrrr... I think this should have been optional behavior. Just spent a bit of time trying to figure out why my MTU went to 576 over the weekend. Thought it was a kernel upgrade (2.6.34-rc1) ... nope. Blamed Cablevision... that was a fun call... nope... searched and found this!

Broke quite a lot... dns for one isn't fragmenting properly (edns udp).

So yes, it works. But the fix should have included a default dhcp client conf file to disable until explicitly turned on by the user.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

So if I understand it right the DHCP server is sending you interface-mtu option (with value 576), but you don't want your dhclient to use it, because it breaks you your configuration ?

Whose is the server ? Your ISP (Cablevision) ?
I don't understand why is the server sending interface-mtu option with value which breaks quite a lot.

The server supplying mtu of 576 is Cablevision (Optimumonline). With MTU=576, I'm getting sky2 rx length errors on EDNS udp packet activity where the dns response is not being fragmented properly upstream. I'm assuming that pmtu upstream is larger than 576 and discovery through the cable modem isn't correct. 

The issue I've got isn't that CV has bad configuration, it's that a change to the dhcp client was pushed out that changed system default behaviour without sufficient warning.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Michael,
there's separate Bug #574629 for this problem.

Actually, that issue and mine is the result of the implementation of this fix.

My issue is that the default client behaviour changed from NOT requesting MTU to requesting and setting MTU. The change is correct, no argument there... it's the potential impact of manifesting problems due to incorrect dhcp server settings that is at issue - i.e., bug fixes that potentially cause manifestation of other issues needs to be dealt with more carefully.

Bug #574629 is what happened to me (and to others) as a direct consequence of the update made to fix this problem. The real issue (probably best moved to mailing lists) is policy for distributing fixes that can reasonable be anticipated to result in significant changes to systems beyond fixing the reported issue.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #10)
> So if I understand it right the DHCP server is sending you interface-mtu option
> (with value 576), but you don't want your dhclient to use it, because it breaks
> you your configuration ?
> 
> Whose is the server ? Your ISP (Cablevision) ?
> I don't understand why is the server sending interface-mtu option with value
> which breaks quite a lot.    

Same problem here with Comcast, at least for some DHCP servers.  Until I found this bug report I couldn't figure out why my interface kept coming up with MTU=576 on one machine while another got MTU=1500 (both FC-12, both connected directly to the cable modem).