Re: [Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[<ke...@us...>]

>To get Etherboot 5.0.3 working with FreeBSD 4.4's bootpd, I had to
>change the definition of MAX_BOOTP_EXTLEN from
>
>	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct bootp_t))
>to
>	(ETH_FRAME_LEN-ETH_HLEN-28-sizeof(struct bootp_t))
>
>where the 28 refers to the length of the IP and UDP headers (probably
>better written as "sizeof(struct iphdr) + sizeof(struct udphdr)").
>Without this, the RFC2132_MAX_SIZE field in the bootp request was
>being set to 1500, which is bigger than the largest bootp request
>that can fit in a single ethernet packet. FreeBSD's bootpd (for
>whatever reason) always sends a reply that is as large as the
>specified maximum size, so it gets fragmented on transmision. This
>causes the
>
>	ALERT: got a fragmented packet - reconfigure your server
>
>diagnostic to be triggered and the replies are dropped.
>
>Is this a bug in FreeBSD's bootpd or in Etherboot? I don't know what
>the precise meaning of the RFC2132_MAX_SIZE parameter to tell if
>Etherboot should be subtracting off the ip/udp header length.

Thanks for the report.

I had a look and the option that's being set in the DHCP packets is
Maximum DHCP Message Size (57). RFC2132 says:

<quote>

This option specifies the maximum length DHCP message that it is willing
to accept.  The length is specified as an unsigned 16-bit integer.  A
client may use the maximum DHCP message size option in DHCPDISCOVER or
DHCPREQUEST messages, but should not use the option in DHCPDECLINE
messages.

The code for this option is 57, and its length is 2.  The minimum legal
value is 576 octets.

</quote>

Which leaves us a bit unsure, but that stipulation that the minimum
should be 576 (a familiar constant) suggests strongly that this is a MTU
(datagram length) and not a payload length. Therefore it seems that
FreeBSD bootpd is wrong. Anybody know better?

However if you wish, you may send me a patch that puts the code you
suggest inside an #ifdef BROKEN_MTU_IN_BOOTPD.

Just curious, why is bootpd sending the maximum packet all the time? Is
it padding the packet with nulls? Surely the clever thing to do would be
to send only as big a packet as needed.