parse_option_buffer: option <unknown> (808464740:50) larger than buffer.
sthaug at nethelp.no
sthaug at nethelp.no
Wed Sep 17 17:27:09 UTC 2008
> Has anyone seen this, I am running dhcp 3.1.1 and have noticed it quite a bit frequently in the logs.
>
> parse_option_buffer: option <unknown> (808464740:50) larger than buffer.
>
> Thanks for the help,
>
>
> Yes I have seen this in dhcp 4.0.0 with vivco/vivso options.
> I raised a bug report ISC-Bugs #18241.
> I do not know what the status of the bug is.
We've seen this too. I have a reasonably good idea of what is happening
here. Some logs, first from dhcpd:
Sep 15 21:43:44 slam2 dhcpd: parse_option_buffer: option <unknown> (808464433:51) larger than buffer.
Sep 15 21:43:44 slam2 dhcpd: DHCPREQUEST for 81.191.155.135 from 00:01:38:99:1f:bf via 81.191.144.1
Note that 808464433 = 0x30303031.
Then a tcpdump packet sniff of the same packet (watch out for line wrap):
21:43:43.927427 IP (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto UDP (17), length 376) 193.75.2.202.67 > 193.75.110.78.67: BOOTP/DHCP, Request from 00:01:38:99:1f:bf, length 348, hops 1, xid 0x17627bcc, Flags [none]
Client-IP 81.191.155.135
Gateway-IP 81.191.144.1
Client-Ethernet-Address 00:01:38:99:1f:bf
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Vendor-Class Option 60, length 14: "XAVI_WLAN_5669"
T125 Option 125, length 36: 4413,17182768,808530744,34353200,808530744,960049510,1650656008,959853365,945182514
Agent-Information Option 82, length 48:
Circuit-ID SubOption 1, length 46: ar1.osls:GigabitEthernet 1/2.31540108:3154-108
0x0000: 4500 0178 0000 0000 3e11 87c6 c14b 02ca E..x....>....K..
0x0010: c14b 6e4e 0043 0043 0164 0000 0101 0601 .KnN.C.C.d......
0x0020: 1762 7bcc 0000 0000 51bf 9b87 0000 0000 .b{.....Q.......
0x0030: 0000 0000 51bf 9001 0001 3899 1fbf 0000 ....Q.....8.....
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 6382 5363 3501 033c ........c.Sc5..<
0x0110: 0e58 4156 495f 574c 414e 5f35 3636 397d .XAVI_WLAN_5669}
0x0120: 2400 0011 3d01 0630 3030 3133 3802 0c30 $...=..000138..0
0x0130: 3030 3133 3839 3931 6662 6303 0839 3633 00138991fbc..963
0x0140: 3538 5657 3252 3001 2e61 7231 2e6f 736c 58VW2R0..ar1.osl
0x0150: 733a 4769 6761 6269 7445 7468 6572 6e65 s:GigabitEtherne
0x0160: 7420 312f 322e 3331 3534 3031 3038 3a33 t.1/2.31540108:3
0x0170: 3135 342d 3130 38ff 154-108.
The relevant portion of the packet is the Option 125 info starting at
tcpdump offset 0x011f: 7d 2400 0011 3d01 0630 3030 3133 ... We have
here an option 125 (0x7d) field, length 36 (0x24) which starts with
two zero bytes. Zero is the code for "pad" in the option space, and
I believe dhcpd gets out of step here and tries to interpret part of
the 36 byte string within the option 125 field as a suboption - note
the "30 3030 31" is the same as is logged by dhcpd as 808464740.
Whether dhcpd actually has a bug, or it's the vendor (Xavi) which
sends the option 125 field wrongly, I couldn't say. But it's quite
reproducible...
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
More information about the dhcp-users
mailing list