option 82 logging error

Marc Perea marccp at srttel.com
Tue Dec 16 16:16:33 UTC 2008

I don't understand why option 125 is causing my problem. If I'm reading RFC3925 correctly, the DISCOVER packet I'm seeing has properly encapsulated option 125 information. Using wireshark I can see:

7d = that option 125 is set
24 = length of this option (36 bytes)
0000113d = Enterprise number (Broadcom chipset modem)
01 = data-len1 (suboption1)
06 = length of this option
303032323135 = Data (002215 ASCII)
02 = data-len2 (suboption2)
0c = length of this option (12 bytes)
303032323135343746344344 = Data (00221547F4CD)
03 = data-len3
08 = length of this option
522d344d2d31364d = Data (R-4M-16M)

next comes option 55, then option 82.

Is that not a properly formatted option 125? Some other questions are: Why does option 125 break my option 82 logging if it's set like this? Is there any way I can give dhcpd a directive to ignore option 125? Why does logging even care about option 125 when I'm only logging agent.circuit-id? It's been recommended that I attempt to modify a DISCOVER and send it to dhcpd, putting option 125 AFTER option 82 instead of before it, but would that even prove anything? I imagine it would solve this logging error, but I still wouldn't know if the client is sending bad option 125 or if the server isn't interpreting this option 125 formatting - is it worth checking into?

Marc Perea
Network Support Engineer
SRT Communications, Inc.
marccp at srttel.com

>>> Marc Perea 12/12/2008 10:58 AM >>>
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:


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

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.
marccp at srttel.com 

More information about the dhcp-users mailing list