Bug 470017 - [TAHI] did not get Solicit if service send a advertise message with StatusCode= 2 NoAddrsAvail
[TAHI] did not get Solicit if service send a advertise message with StatusCod...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-05 05:28 EST by Yang Ren
Modified: 2010-11-09 07:49 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-08 05:14:32 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 packet capture from server (56.60 KB, image/png)
2010-03-05 08:00 EST, Jiri Popelka
no flags Details
attach dump file for reference (5.38 KB, application/octet-stream)
2010-06-08 05:07 EDT, Shirley Zhou
no flags Details

  None (edit)
Description Yang Ren 2008-11-05 05:28:16 EST
Description of problem:
A TAHI test case failed in client mode
62 Reception of Advertise messages
http://focus.bne.redhat.com/~ryang/DHCPv6_Self_Test_P2_1_0_13_client/rfc3315/62.html

What the test case do is:
1.Start a dhcpv6 client get it's solicit message.
2.return a advertise message with StatusCode= 2 NoAddrsAvail 
3.wait solicit message for 30s.

Our client did not send a solicit after get a advertise message with StatusCode= 2 NoAddrsAvail in 30s.

Version-Release number of selected component (if applicable):
dhcpv6-client-1.0.10-16.el5
libdhcp6client-1.0.10-16.el5
libdhcp6client-devel-1.0.10-16.el5


How reproducible:
Always

Steps to Reproduce:
1.start a client and a server 
2.return a advertise message with StatusCode= 2 NoAddrsAvail 
3.wait solicit message
  
Actual results:
did not receive solicit

Expected results:
client should send another solicit message

Additional info:
Comment 1 Lawrence Lim 2008-11-05 09:56:46 EST
2 bugs outstanding for us to obtain the certification.

Bug 470015 and Bug 470017.
Comment 2 Lawrence Lim 2009-03-25 02:27:23 EDT
This is the only bug which prevent us from obtaining the certification in RHEL5.4 timeframe. Any chance of exception?
Comment 3 Shirley Zhou 2009-05-27 02:18:02 EDT
Any update for this issue?
Comment 7 Jiri Popelka 2010-03-05 08:00:55 EST
Created attachment 398048 [details]
Wireshark packet capture from server

Hi,

I was trying to reproduce this problem but without success.
In my case the client is correctly sending another Solicit message(s)
after he receives Advertise with NoAddrsAvail status code.

My test:
One RHEL-5.4 server with dhcpv6-1.0.10-17.el5
Three RHEL-5.4 clients with dhcpv6-client-1.0.10-17.el5

# cat /etc/dhcp6s.conf
interface eth1{
	renew-time 600;
	rebind-time 900;
	prefer-life-time 1000;
	valid-life-time 1000;
	link AAA{
		range 3ffe:501:ffff:100::2 to 3ffe:501:ffff:100::3/64;
	};
};

1. Start server: dhcp6s -Df eth1
2. Start first client: dhcp6c -df eth1
	- client gets 3ffe:501:ffff:100::3 address
3. Start second client: dhcp6c -df eth1
	- client gets 3ffe:501:ffff:100::2 address
4. Start Wireshark on server to see incoming/outgoing packets
5. Start third client: dhcp6c -df eth1
	- client repeatedly sends Solicit in response to 'Advertise with NoAddrsAvail status code' from server (server has no free address for him).

Wireshark packet capture from server is attached.
You can see several Solicit/Advertise message exchanges there.
fe80::a00:27ff:feb4:3330 is link local address of third client
fe80::a00:27ff:fee0:62b4 is link local address of server
In packet details of one selected Advertise message you can see NoAddrAvail (2) status code.

Can you please help me to find how to reproduce this problem ?
Comment 8 Yang Ren 2010-03-08 21:21:30 EST
hmm... very old bug. This bug should be already out of date.
We did not test the dhcpv6-1.0.10-17.el5 yet, the failed pkg version is dhcpv6-client-1.0.10-16.el5.
If this is fixed in 1.0.10-17 We need test it.
Comment 9 Radek Vokal 2010-04-13 07:33:01 EDT
(In reply to comment #8)
Can you please re-test your bug with the most recent version of dhcpv6-client package? If this issue is fixed, the bug can be closed.
Comment 10 Jiri Popelka 2010-06-04 12:15:50 EDT
I tested this situation (see comment #7) again
on RHEL-5.5 (dhcpv6-1.0.10-18.el5, dhcpv6-client-1.0.10-18.el5)
couple days ago with the same result.

So I believe the initial fail was only configuration or TAHI test suite
problem.
Comment 11 Shirley Zhou 2010-06-08 04:21:57 EDT
(In reply to comment #10)
> I tested this situation (see comment #7) again
> on RHEL-5.5 (dhcpv6-1.0.10-18.el5, dhcpv6-client-1.0.10-18.el5)
> couple days ago with the same result.
> 
> So I believe the initial fail was only configuration or TAHI test suite
> problem.    

Hi, Jiri

I verified this bug on rhel5.5(kernel-2.6.18-194.el5,dhcpv6-1.0.10-18.el5, dhcpv6-client-1.0.10-18.el5) according to Comment7.

We can capture solicit message from client after step5.

Please feel free to close this bug.

Thanks,
Shirley
Comment 12 Shirley Zhou 2010-06-08 05:07:00 EDT
Created attachment 422112 [details]
attach dump file for reference
Comment 13 Jiri Popelka 2010-06-08 05:14:32 EDT
Thanks Shirley,

closing as notabug then.

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