option 82 logging error

[Marc Perea]

Thanks for the help so far - knowing that I should be looking at option 125 I discovered that indeed, wireshark also claims that option 125 is providing unknown data. The packet sniff shows:
7d = option 125
24 = length 36 bytes
0000113d = Broadcom chipset

Wireshark doesn't care to interpret the rest of the option, which is:

01063030
32323135
020c3030
32323135
34374634
43440308
522d344d
2d31364d

The option 125 info is indeed 36 bytes long.

The next option listed in the packet is 55, which looks normal, and then option 82 which has the stuff I'm trying to log.
Option 55 is 6 bytes in length, so including the type and length fields = 8 bytes.

The ASCII 002215 that Bruce points out relates exactly to the bytes 303032323135, which you can see above, so I'm not sure what that means. My log directive in the .conf should only match if agent.circuit-id exists, which it will in this case, but I'm logging only the agent.circuit-id, not the Vendor-Identifying Vendor Options (OPTION_V-I_VENDOR_OPTS (125)). Why would my dhcp configuration care about option 125 - do I have a malformed log statement? I checked the different modems that are used in my network and it seems we have standardized on modems with the Broadcom chipset, so I'm seeing this "broken" option 125 across the board. I verified this behavior does not occur on a different stack, such as that of a Windows XP machine, which doesn't even send option 125 at all.

It looks to me like the order in the packet is option 125, option 55, then option 82. The first 2 bytes of 125 determine the option and length, then the next 4 bytes tell me it's a certain chipset modem trying to get DHCP. If option 125 "bleeds" into or overwrites options 55 and 82, from DHCPD's perspective, that would explain why I'm seeing the behavior that syslog shows 808464946 Decimal, which converts to 30303232 Hex... 0022 ASCII, which you can see in the bytes above.

Is this a bug? Does DHCPD assume that option 125 should only be 4 bytes in length? The packet capture shows that option 125 is specified with a length of 36 bytes, yet DHCPD appears to be considering it as overflowing into option 82 (hence the log states parse_option_buffer: option <unknown> (808464946:49) larger than buffer, or so I assume). I'm reading RFC 3925 which specifies option 125, and it states: Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it. I haven't set any directives to handle option 125 - so shouldn't dhcpd be ignoring this option and just skipping over those 36 bytes? Is there a way I can specify for dhcpd to explicitly ignore option 125? Am I completely off base here or am I making any sense?

Glenn also stated:
>Hi Mark
>
>you're testing
>
>  if exists agent.circuit-id
>
>that should be
>
>  if exists option agent.circuit-it
>
>
>regards,
>-glenn

but when I do that, dhcpd complains and won't even start the daemon - dhcpd -t shows:
/etc/dhcpd.conf line 17: no option named option in space dhcp
if exists option agent.
          ^
Configuration file errors encountered -- exiting

Again, thanks for progressing this troubleshooting. What to do next, anyone?

Marc Perea
Network Support Engineer
SRT Communications, Inc.
(701)858-5235
marccp at srttel.com


>>> Bruce Hudson <Bruce.Hudson at Dal.Ca> 12/11/2008 1:23 PM >>>

    As David Hankins pointed out in list, it is probable that the option
125 provided by the client is causing the problem rather than option 82.
The encapsulation used by option 125 uses the 4-byte sub-option numbers
I saw in your original post, so that is one mystery solved. I am afraid
it means I have no clue why removing you log message prevents the error
from occuring. The tag and length in the error correspond to "00221" in
ASCII. If that means anything coming from this client or it matches the
36 bytes in the packet; this is definitely where the error is coming
from. 
--
Bruce A. Hudson				| Bruce.Hudson at Dal.CA 
UCIS, Networks and Systems		|
Dalhousie University			|
Halifax, Nova Scotia, Canada		| (902) 494-3405