Re: [Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[Ian D. <ie...@ma...>]

In message <200...@ke...>, ke...@us...
.net writes:
>
>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?

Yes, the wording is certainly unclear. isc-dhcpd takes the safe
option, and ensures that the whole packet, including the ethernet
header, fits into the client-specified maximum length. FreeBSD's
bootpd should probably do the same.

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

Etherboot's definition and use of MAX_BOOTP_EXTLEN is actually
quite confusing; it is used to determine the size of the
bootp_extension[] array in struct bootpd_t yet its value includes
the size of the IP and UDP headers. These certainly aren't part of
bootp_extension[]. I have included a patch below that changes
MAX_BOOTP_EXTLEN to actually mean the maximum bootp extension
length.

This patch obviously has the side-effect of avoiding the problem
I reported, but I guess if you want to stick to the one interpretation
of RFC2132 you could use sizeof(struct bootpip_t) instead of
sizeof(struct bootpd_t) when setting up the RFC2132_MAX_SIZE tag:

	RFC2132_MAX_SIZE,2,     /* request as much as we can */
	sizeof(struct bootpip_t) / 256, sizeof(struct bootpip_t) % 256,

However, it would be nicer to just interpret RFC2132 in the way that
is most likely to work with all servers :-)

>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.

I'm not sure, but I would guess that it dates back to before the
Maximum DHCP Message Size option existed. The bootpd code in FreeBSD
hasn't changed much since 1994 anyway. It looks as if the old
(probably unofficial) way for a bootp client to specify that it
could handle a long bootp reply was for it to send a request packet
that was as long as the maximum reply it would accept. The bootpd
code just changed the request into a reply and resent it without
changing the length. I guess when support for the DHCP max message
size was added, this mechanism was still used.

Ian

--- etherboot.h.orig	Mon Sep 24 00:54:31 2001
+++ etherboot.h	Mon Sep 24 00:58:11 2001
@@ -76,7 +76,8 @@
 #ifdef	BOOTP_DATA_AT_0x93C00
 #define MAX_BOOTP_EXTLEN	(1024-sizeof(struct bootp_t))
 #else
-#define MAX_BOOTP_EXTLEN	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct bootp_t))
+#define MAX_BOOTP_EXTLEN	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct iphdr)- \
+				 sizeof(struct udphdr)-sizeof(struct bootp_t))
 #endif
 
 #ifndef	MAX_ARP_RETRIES