FW: udhcpc: DHCP packet size and friends

Vladislav Grishenko themiron at mail.ru
Wed Oct 20 17:09:27 UTC 2010


> From: Denys Vlasenko
> Sent: Wednesday, October 20, 2010 10:06 PM
> To: Vladislav Grishenko
> Cc: busybox at busybox.net
> Subject: Re: FW: udhcpc: DHCP packet size and friends
> 
> 2010/10/20 Vladislav Grishenko <themiron at mail.ru>:
> > Windows(tm) DHCP clients doesn't include MSZ option, and eats all
> > packets up to if's MTU. We could achieve similar buggy-free behavior
> > by setting UDHCPC_SLACK_FOR_BUGGY_SERVERS to the maximum (924),
> > overall dhcp packet size will be 1500.
> > But, ihmo, it's redundant in terms of bss consumption. Am I right?
> 
> I guess for many cases this would be quick and acceptable solution.

In this case, what UDHCPC_SLACK_FOR_BUGGY_SERVERS is stand for?
It doesn't need to be configurable, or we could face with no huge packets
are accepted.
Note, that I havn't check udhcpd dependencies yet.

> > So, just malloc ip_udp_dhcp_packet struct with max. option size, get
> > rid of static buffer and cleat up redundant slack record member.
> 
> What static buffer? We have static packet buffer? Where?

My fault, I was thinking it's static. Actually it's in stack. Have no
opinion is it much more worse then allocated.
 
> > Second way is to include actual MSZ to DISCOVER, REQUEST and INFORM
> > packets, rfc says that client may do it.
> 
> Yes, I think we can do this, if it convinces some servers to not send
oversize
> packets.
It forces servers to not to continue to fill the options buffer, and to
start using file/sname override. It expands options, but not sufficient for
a possible large routes lists.

 
> > Actual MSZ means it should be set to sizeof(struct
> > ip_udp_dhcp_packet), if it less than current interface MTU. If struct
> > size is equal or greater then MTU, we really doesn't need to set MSZ,
> > no oversized broadcast packets could arrive which could be sent with
pmtu
> assumption.
> > In the simple case, we have to get MTU on start, but there's need of
> > interface mtu polling on every outgoing packet.
> 
> How about just using DHCP_MAX_SIZE = 576 always, without regard to MTU?
> I bet not many people run on networks with MTU smaller than that (is it
even
> allowed by IP protocol to have MTU < 576?).
It could be the solution, but any large packets which don't fit in 576 bytes
will be lost.
I've seen 572 packets (without override), and it's almost the limit. So,
forcing MSZ to 576 is really could be wrong, not now, but tomorrow.
 
> > Proposed patch is attached, needs review, and several questions are
> > still
> > open:
> > What if mtu gets lower than buffer in the middle of discover/request
> stages.
> > What if DHCP server sends MTU options and pretty sure it will be used
> > instead of local current MTU.
> > What if jumbo frames are enabled and MTU is greater than 1500.
> >
> > p.s also patch fixes typo UPD->UDP and interface index polling while
> > running on a bridge.
> 
> Let's commit typo fix first... done in git, please pull.

Refreshing interface index is also important, if udhcpc is running on a
bridge.

Thank you,
Best Regards, theMIROn
ICQ: 303357
Skype: the.miron






More information about the busybox mailing list