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
