Description of problem: In rfc. It said "the elapsed-time field is set to 0 in the first message in the message exchange" rfc3315 chapter 22.9 And the elapsed-time field of our first confirm message is not zero. Version-Release number of selected component (if applicable): dhcp-4.1.1-10.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1.start dhcp and dhclient on two machine 2.after dhclient got ip. restart network. 3.got confirm message Actual results: elapsed-time field is not zero Expected results: elapsed-time field is zero Additional info:
Created attachment 402045 [details] Wireshark screenshot Hi, how did you discovered the zero value ? I was trying to send all types of messages and the first one send by client has always zero value in elapsed-time option. I used Wireshark on server to see the value and here's screenshot. First Confirm message is selected.
This maybe a regression. It passed in dhclient-4.1.1-9.fc12 in Feb 26. But failed in dhclient-4.1.1-10.fc12 in Mar 18. THis is the confirm message I got. Frame_Ether (length:142) | Hdr_Ether (length:14) | | DestinationAddress = 33:33:00:01:00:02 | | SourceAddress = 00:1d:09:23:a9:1f | | Type = 34525 | Packet_IPv6 (length:128) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 88 | | | NextHeader = 17 | | | HopLimit = 64 | | | SourceAddress = fe80::21d:9ff:fe23:a91f | | | DestinationAddress = ff02::1:2 | | Upp_UDP (length:88) | | | Hdr_UDP (length:8) | | | | SourcePort = 546 | | | | DestinationPort = 547 | | | | Length = 88 | | | | Checksum = 4635 calc(4635) | | | Udp_DHCPv6_Confirm (length:80) | | | | Type = 4 | | | | Identifier = 12203226 | | | | Opt_DHCPv6_CID (length:18) | | | | | Code = 1 | | | | | Length = 14 | | | | | DHCPv6_DUID_LLT_Ether (length:14) | | | | | | Type = 1 | | | | | | HardwareType = 1 | | | | | | Time = 322212595 | | | | | | LinkLayerAddress = 00:1d:09:23:a9:1f | | | | Opt_DHCPv6_OptionRequest (length:8) | | | | | Code = 6 | | | | | Length = 4 | | | | | OptionCode = 23 | | | | | OptionCode = 24 | | | | Opt_DHCPv6_ElapsedTime (length:6) | | | | | Code = 8 | | | | | Length = 2 | | | | | Time = 305 | | | | Opt_DHCPv6_IA_NA (length:44) | | | | | Code = 3 | | | | | Length = 40 | | | | | Identifier = 153331999 | | | | | Time1 = 0 | | | | | Time2 = 0 | | | | | Opt_DHCPv6_IA_Address (length:28) | | | | | | Code = 5 | | | | | | Length = 24 | | | | | | Address = 3ffe:501:ffff:100::abcd | | | | | | PreferredLifetime = 0 | | | | | | ValidLifetime = 0 ===dhcp6_confirm================================= The elapsed time field is not zero. The test process is Start a dhcp client, after got ip. ifdown ifup network interface. Got the confirm msg. elasped time is not zero
The failed pkg version now is dhclient-4.1.1-11.fc12.x86_64. The client configure is interface "eth0" { }; using this command to start dhclient -6 -nw -lf /var/lib/dhclient/dhclient6-eth0.leases -N -cf /root/dhcp6c.conf eth0 This is the test result link. http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/25.html
(In reply to comment #3) > This is the test result link. > http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/25.html Hi, The packet, which you show in comment #2 is the third Confirm message received. The first is here http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/25.html#vRecvPKT31 and has | | | | Opt_DHCPv6_ElapsedTime (length:6) | | | | | Code = 8 | | | | | Length = 2 | | | | | Time = 0
(In reply to comment #4) > The packet, which you show in comment #2 is the third Confirm message received. > The first is here > http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/25.html#vRecvPKT31 The URI changes as you rerun the test, but I still see the test doesn't recognize the first and second Confirm message. The complete first Confirm message is: Frame_Ether (length:142) | Hdr_Ether (length:14) | | DestinationAddress = 33:33:00:01:00:02 | | SourceAddress = 00:1d:09:23:a9:1f | | Type = 34525 | Packet_IPv6 (length:128) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 88 | | | NextHeader = 17 | | | HopLimit = 64 | | | SourceAddress = fe80::21d:9ff:fe23:a91f | | | DestinationAddress = ff02::1:2 | | Upp_UDP (length:88) | | | Hdr_UDP (length:8) | | | | SourcePort = 546 | | | | DestinationPort = 547 | | | | Length = 88 | | | | Checksum = 64725 calc(64725) | | | Udp_DHCPv6_Confirm (length:80) | | | | Type = 4 | | | | Identifier = 9936320 | | | | Opt_DHCPv6_CID (length:18) | | | | | Code = 1 | | | | | Length = 14 | | | | | DHCPv6_DUID_LLT_Ether (length:14) | | | | | | Type = 1 | | | | | | HardwareType = 1 | | | | | | Time = 322912411 | | | | | | LinkLayerAddress = 00:1d:09:23:a9:1f | | | | Opt_DHCPv6_OptionRequest (length:8) | | | | | Code = 6 | | | | | Length = 4 | | | | | OptionCode = 23 | | | | | OptionCode = 24 | | | | Opt_DHCPv6_ElapsedTime (length:6) | | | | | Code = 8 | | | | | Length = 2 | | | | | Time = 0 | | | | Opt_DHCPv6_IA_NA (length:44) | | | | | Code = 3 | | | | | Length = 40 | | | | | Identifier = 153331999 | | | | | Time1 = 0 | | | | | Time2 = 0 | | | | | Opt_DHCPv6_IA_Address (length:28) | | | | | | Code = 5 | | | | | | Length = 24 | | | | | | Address = 3ffe:501:ffff:100::abcd | | | | | | PreferredLifetime = 0 | | | | | | ValidLifetime = 0 ===rs_nut_to_server1================================= ng compare _HETHER_nut_to_linkallrouter.DestinationAddress received:33:33:00:01:00:02 = 33:33:00:00:00:02 ng compare _HDR_IPV6_rs_nut_to_server1.NextHeader received:17 = 58 ng compare _HDR_IPV6_rs_nut_to_server1.HopLimit received:64 = 255 ng compare _HDR_IPV6_rs_nut_to_server1.DestinationAddress received:ff02::1:2 = ff02::2 ng meta Packet_IPv6.ICMPv6_RS != Packet_IPv6.Upp_UDP But I don't know why the test marks it as 'recv unexpect packet at 17:53:53'. When I compare the first and the third (which the test recognizes) Confirm messages I see they differ only in Checksum, Time and some comment (or whatever it is) in the footnote. Here's the diff: $ diff Confirm1.txt Confirm3.txt 21c21 < | | | | Checksum = 64725 calc(64725) --- > | | | | Checksum = 64414 calc(64414) 41c41 < | | | | | Time = 0 --- > | | | | | Time = 311 54,59c54 < ===rs_nut_to_server1================================= < ng compare _HETHER_nut_to_linkallrouter.DestinationAddress received:33:33:00:01:00:02 = 33:33:00:00:00:02 < ng compare _HDR_IPV6_rs_nut_to_server1.NextHeader received:17 = 58 < ng compare _HDR_IPV6_rs_nut_to_server1.HopLimit received:64 = 255 < ng compare _HDR_IPV6_rs_nut_to_server1.DestinationAddress received:ff02::1:2 = ff02::2 < ng meta Packet_IPv6.ICMPv6_RS != Packet_IPv6.Upp_UDP --- > ===dhcp6_confirm=================================
wow u did the same thing I did. I also not sure why it can not recognise the confirm msg. I alread sent a mail to tahi list for help. Will update it here when people reply me. I think it might be a bug of tahi test suit. But need the test case developer confirm me this. Thanks for your replay.
No one reply me on tahi list. So I debug this problem again today. I think I may find the problem. After ifdown ifup interface. tahi expect a RS from client first. Then it send RA back. After this message exchange client should send confirm message. So before client send confirm message it should raise a RS/RA message exchange. And for now even test suit did not send RS it still will send RA. For other test if suite got confirm message it will make it pass ignore if the confirm message is the first or the third one.
tahi give out a patch to fix this problem la. This is not our software problem. It's a bug of test suite.
Reopen this bug. Because I find in dhcp-4.1.1-16.fc12 the first elapsed time of first confirm message is not zero. http://10.66.65.86/DHCPv6_Self_Test_P2_1_1_0_client/rfc3315/25.html
In my test dhcp-4.1.1-16.fc12 still sets the elapsed time of first confirm message to zero. See also Bug #582939, comment #10.
Retest it. It passed. Sorry for disturb.