dhcrelay '-A' command line option does nothing

mark mckinstry mark.mckinstry at alliedtelesis.co.nz
Tue May 6 02:51:02 UTC 2008

Thanks Evan for the quick response!

dhcrelay(8) describes the '-A' parameter as "maximum packet size (e.g. 1400)" which would tend to suggest it is IP packet length. The initialization values in the code for the variable  dhcp_max_agent_option_packet_length also suggest this.

But our take on it is that dhcrelay has no control over the length of the whole IP packet because it can't assume a standard IP header length of 20 bytes and UDP header of 8 bytes - there may be all sorts of tunneling going on which could increase the IP header length considerably. dhcrelay can limit only the DHCP message length, so our code patch takes the '-A' parameter to mean DHCP message length. Also the corresponding user configuration command on the box we are developing (a network switch) allows a range of 548 to 1472, with a default of 1400.  These values correspond to an IP packet length of 576 to 1500 (default 1428) when the IP and UDP headers are "standard" length (20 + 8).

Do you think our slant on this is reasonable? If so, then I guess the initialization of dhcp_max_agent_option_packet_length in the code needs to reflect this, and dhcrelay(8) needs to be modified accordingly?

>>> Evan Hunt <Evan_Hunt at isc.org> 05/06/08 12:55 PM >>> 

Thanks very much for the report, Mark.  As it happens I'm working on
dhcrelay at the moment for other reasons, so your timing is excellent.

On Tue, May 06, 2008 at 11:06:13AM +1200, mark mckinstry wrote:
> The '- A' command line option for dhcrelay does not work. According to dhcrelay(8)  it is supposed to set the maximum size to which a DHCP request packet can grow after dhcrelay inserts option 82, before forwarding the packet to the server -  but the code to achieve this is missing. In the code the '- A' option does set the value of global variable dhcp_max_agent_option_packet_length, but this variable is then never used! Currently dhcrelay will insert option 82 only if there is sufficient option padding,> 
> Some DHCP clients seem to insert sufficient option padding to allow option 82 insertion (e.g. ISC dhclient), but others don't (e.g. Windows XP), and this is a problem for us.
> We are currently using dhcrelay 3.0.4, but comparing it to 4.0.0 I can see no relevant code changes, so presumably the issue still exists. I searched the forum archives, but could find nothing relevant. I'm surprised nobody has noticed this before!
> We have done our own fix for this -  see patch below -  but we'd prefer not to have to maintain such patches, so could ISC please implement a fix in the next release?
> ---  dhcp- 3.0.4/relay/dhcrelay.c	2008- 04- 22 10:02:20.000000000 +1200
> +++ dhcp- 3.0.4/relay/dhcrelay.c.new	2008- 04- 22 10:05:02.000000000 +1200
> @@ - 873,6 +873,17 @@
>  	if (memcmp(packet- >options, DHCP_OPTIONS_COOKIE, 4))
>  		return length;
> +  /* ATL addition -  for support when the option 82 cannot be inserted to the DHCP message, 
> +   * if there is not enough paddings after the option field in the DHCP message.
> +   * Change the DHCP msg length. It is actually implementing the - A option setting that 
> +   * was missing in the code.
> +   */
> +  if ( length != dhcp_max_agent_option_packet_length )
> +  {
> +    length = dhcp_max_agent_option_packet_length;
> +  }
> +  /* ATL addition end */
> +
>  	max = ((u_int8_t *)packet) + length;
>  	/* Commence processing after the cookie. */
> Thanks
> Mark
> ----------------------------
> Mark McKinstry
> Senior Software Engineer
> Allied Telesis Labs
> Christchurch, New Zealand

Evan Hunt --  evan_hunt at isc.org
Internet Systems Consortium, Inc.

More information about the dhcp-users mailing list