Bug 574677 - First confirm message elapsed-time is not zero.
First confirm message elapsed-time is not zero.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 574679
  Show dependency treegraph
 
Reported: 2010-03-18 03:58 EDT by Yang Ren
Modified: 2010-05-04 23:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 574679 (view as bug list)
Environment:
Last Closed: 2010-05-04 23:40:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Wireshark screenshot (88.76 KB, image/png)
2010-03-23 09:00 EDT, Jiri Popelka
no flags Details

  None (edit)
Description Yang Ren 2010-03-18 03:58:20 EDT
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:
Comment 1 Jiri Popelka 2010-03-23 09:00:05 EDT
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.
Comment 2 Yang Ren 2010-03-23 22:19:22 EDT
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
Comment 3 Yang Ren 2010-03-23 22:22:54 EDT
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
Comment 4 Jiri Popelka 2010-03-24 11:05:06 EDT
(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
Comment 5 Jiri Popelka 2010-03-26 06:35:52 EDT
(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=================================
Comment 6 Yang Ren 2010-03-26 06:54:21 EDT
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.
Comment 7 Yang Ren 2010-04-12 04:24:56 EDT
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.
Comment 8 Yang Ren 2010-04-15 00:49:37 EDT
tahi give out a patch to fix this problem la. This is not our software problem. It's a bug of test suite.
Comment 9 Yang Ren 2010-05-04 00:55:41 EDT
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
Comment 10 Jiri Popelka 2010-05-04 02:00:42 EDT
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.
Comment 11 Yang Ren 2010-05-04 23:40:24 EDT
Retest it. It passed. Sorry for disturb.

Note You need to log in before you can comment on or make changes to this bug.