FW: udhcpc: DHCP packet size and friends

Denys Vlasenko vda.linux at googlemail.com
Wed Oct 20 22:13:44 UTC 2010


On Wednesday 20 October 2010 23:21, Vladislav Grishenko wrote:
> > From: Denys Vlasenko
> > Sent: Thursday, October 21, 2010 1:43 AM
> > To: Vladislav Grishenko
> > Cc: busybox at busybox.net
> > Subject: Re: FW: udhcpc: DHCP packet size and friends
> > 
> > > It doesn't need to be configurable, or we could face with no huge
> > > packets are accepted.
> > 
> > ?
> It should be at maximum for the long run to accept any huge packets.
> Same dangerous configurable thing as FEATURE_SYSLOGD_READ_BUFFER_SIZE, which
> should be de-facto 1024 miminum.

You can set FEATURE_SYSLOGD_READ_BUFFER_SIZE to 20000 if you want.
Why do you want to tell other people what THEY should do?

> > > > > 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.
> > 
> > Show me example packets where 0.5k is not enough.
> 
> Here tcpdump's log. And I'm afraid that the number of routes will grow over
> the time.

Perhaps an option to set advertized DHCP packet size is in order.

-- 
vda


More information about the busybox mailing list