Package: dibbler-client Version: 0.4.2.dfsg-2 Severity: serious
Coin, dibbler-client is sending an option type 2 (Server Identifier) instead of an option type 1 (Client Identifier) in SOLICIT messages, as requested in RFC3315. Here is the client configuration: # 8 (Debug) is most verbose. 7 (Info) is usually the best option log-level 7 iface eth0 { # ask for address ia # ask for options #option dns-server option domain #option ntp-server } Here is the client log: 14:15:19 Info Processing msg (SOLICIT,transID=0x22bed2,opts: 2 3 8 6) 14:15:19 Notice Sleeping for 113 second(s). and the server one: 14:17:10 Warning Option 2 not allowed in message type=1. Ignoring. 14:17:10 Notice Received SOLICIT on eth-lan/3,TransID=0x22bed2, 3 opts: 3 8 6, 0 relay(s). 14:17:10 Warning Invalid message received. 14:17:10 Notice Accepting connections. Next event in 4294967295 second(s). tshark confirms the bug: DHCPv6 Message type: Solicit (1) Transaction-ID: 0x000a5007 Server Identifier option type: 2 option length: 14 DUID type: link-layer address plus time (1) Hardware type: NET/ROM pseudo (0) Time: 1175096748 Link-layer address: 00508D4D3358 Identity Association for Non-temporary Address option type: 3 option length: 40 IAID: 1 T1: infinity T2: infinity IA Address option type: 5 option length: 24 IPv6 address: :: Preferred lifetime: infinity Valid lifetime: infinity Elapsed time option type: 8 option length: 4 ELAPSED-TIME: malformed option Option Request option type: 6 option length: 2 Requested Option code: Domain Search List (24) It seems the option type 2 problem is not the only one, as the server said to ignore it. So, i wonder if the missing option type 1, or perhaps the malformed option type 8 (see tshark dump), is reponsible for SOLICIT requests to be discarded. Whatever, this bug renders the package unusuable, thus the bug severity. Regards. -- Marc Dequènes (Duck)
pgpa7ktYceBwL.pgp
Description: PGP signature