Bug 511323 - Problems handling NotOnLink error in REPLY
Summary: Problems handling NotOnLink error in REPLY
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6
Version: 5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jiri Popelka
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 598439
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-14 17:12 UTC by Bryan Mason
Modified: 2011-01-13 22:30 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-13 22:30:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Log file (16.78 KB, text/plain)
2009-07-14 17:32 UTC, Bryan Mason
no flags Details
tcpdump capture of traffic between client and server (4.89 KB, application/octet-stream)
2009-07-14 17:36 UTC, Bryan Mason
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0034 0 normal SHIPPED_LIVE dhcpv6 bug fix update 2011-01-12 17:39:40 UTC

Description Bryan Mason 2009-07-14 17:12:09 UTC
Description of problem:

  During the SOLICIT/ADVERTISE/REQUEST/REPLY process, if the server
  sends a NotOnLink error in it's REPLY message, the client restarts
  the process by sending a SOLICIT message, but then ignores the
  ADVERTISE message sent by the server.

Version-Release number of selected component (if applicable):

  dhcpv6-1.0.10-16.el5

How reproducible:

  Every time.

Steps to Reproduce:

  1. Configure the DHCPv6 server so that it will return a NotOnLink
     error to REQUESTs for IP addresses.  (More on this in Additional
     Info.
  2. Run dhcp6c.
  
Actual results:

  The client will eventually get an IP address, but in the process,
  it ignores the second ADVERTISE message sent by the server.

Expected results:

  The client should not ignore the second ADVERTISE message.

Additional info:

  This issue was found while testing the patch that fixes Bug 476974.
  That patch causes dhcp6c to copy the IAADR options received in the
  ADVERTISE message to the REQUEST message that is sent.  A bug or
  misconfiguration in the test server is causing a NotOnLink error to
  be sent back from the server.  When this happens, the client
  re-sends a SOLICIT message, but when it receives the ADVERTISE
  message, it ignores the server "because it is known."  As a result,
  the client sends the REQUEST message without the IAADR options sent
  by the server.

  I believe the fix for this issue may be to call free_servers() when
  the NotOnLink error is detected.

Comment 1 Bryan Mason 2009-07-14 17:27:25 UTC
A little more detail on what I believe is happening:

  1) Client sends SOLICIT.  
  2) Server sends ADVERTISE
  3) Client receives ADVERTISE and adds the server DUID to it's list
     of servers in the ifp structure.
  4) Client sends REQUEST.
  5) Server sends REPLY with NotOnLink error.
  6) Client responds to the NotOnLink error by restarting in the
     SOLICIT state.  The options are cleared, but the ifp structure is
     not.  A new SOLICIT message is sent.
  7) Server sends ADVERTISE message.
  8) Client receives ADVERTISE message, but ignores the message
     options because we "ignore the server if it is known".

It seems like dhcp6c assumes that if it sees two ADVERTISE messages from the same server, only the first ADVERTISE message has anything of value.  This may be a valid assumption, but if that's the case, then I think free_servers(ifp) should be called when the client detects to the NotOnLink error.  Something like:

--- dhcpv6-1.0.10.old/src/dhcp6c.c	2009-06-25 15:29:12.000000000 -0700
+++ dhcpv6-1.0.10.new/src/dhcp6c.c	2009-07-14 09:54:55.793792000 -0700
@@ -1620,6 +1633,7 @@
 			dprintf(LOG_DEBUG, "%s" 
 			    "got a NotOnLink reply for request/rapid commit,"
 			    " sending solicit.", FNAME);
+			free_servers(ifp);
 			newstate = DHCP6S_SOLICIT;
 			break;
 		case DH6OPT_STCODE_NOADDRAVAIL:

Comment 2 Bryan Mason 2009-07-14 17:32:55 UTC
Created attachment 351643 [details]
Log file

The log files shows the sequence of events.

Line 135 shows the NotOnLink error:

Jul/01/2009 16:18:53 got a NotOnLink reply for request/rapid commit, sending solicit.

Line 156 shows the receipt of the ADVERTISE message:

Jul/01/2009 16:18:53 receive advertise from fe80::211:43ff:fee8:54af%eth0 scope id 2 eth0

Line 172 shows the ADVERTISE message being ignored:

Jul/01/2009 16:18:53 duplicated server (ID: 00:01:00:01:11:de:8e:f9:00:11:43:e8:54:af)

Comment 3 Bryan Mason 2009-07-14 17:36:58 UTC
Created attachment 351645 [details]
tcpdump capture of traffic between client and server

Comment 5 Jiri Popelka 2010-03-05 16:47:34 UTC
Hi Bryan,

The patch looks reasonable.
Thanks for your investigation and complex description of the problem.

I know e.g. how to configure server (and client) to send NotOnLink error in response to CONFIRM (bug #466251), but I have problem to mis-configure the server (and client) so it it will return a NotOnLink error to REQUESTs.

Do you remember what was wrong with the server configuration that it sent NotOnLink error to REQUESTs ?

Comment 6 Bryan Mason 2010-03-18 19:58:23 UTC
Hi Jiri,

Sorry for taking so long to reply.

The server configuration that generated the NotOnLink error to REQUESTs seemed to be that it was configured to ADVERTISE two sets of addresses:

    link MYLINK {
        pool{
            range fc07:1::1:3 to fc07:1::1:ff/112;
            range 2007:1::1:3 to 2007:1::1:ff/112;
        };
    };

I thought that since the NIC was configured with a link-local address:

    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
       state UP  qlen 1000
       link/ether 00:14:22:1e:64:cc brd ff:ff:ff:ff:ff:ff
       inet 172.16.64.5/18 brd 172.16.127.255 scope global eth1
       inet6 fe80::214:22ff:fe1e:64cc/64 scope link 
          valid_lft forever preferred_lft forever

when the client REQUESTed the the addresses in fc07:1::1:0/122 and 2007:1::1:0/112 ranges, the server was complaining because the REQUESTed addresses didn't have the same scope as the link-local address assigned to the NIC.

However, when the server configuration was changed to:

    link MYLINK {
        pool{
            range fc07:1::1:3 to fc07:1::1:ff/112;
        };
    };

then the problem went away (the server stopped sending NotOnLink errors).

So although I'm now not sure exactly why the server was sending the NotOnLink error, I believe that configuring the server with range options like the one above should make it generate the errors.

Comment 7 Jiri Popelka 2010-05-14 10:23:32 UTC
(In reply to comment #1)
>   [...]
>   8) Client receives ADVERTISE message, but ignores the message
>      options because we "ignore the server if it is known".
> 
Hi,

with the configuration from comment #6 server really sends NotOnLink status in REPLY.
I'm not sure now why it is and whether it's a bug or configuration problem.

But with your patch the client works as expected, i.e. it doesn't ignore the
second ADVERTISE message and sends the REQUEST message with the IAADR options to server.
Problem is that the server then again sends NotOnLink in REPLY,
client again goes to SOLICIT and so on.
So the client never gets his addresses.

So I think we can fix this "ignoring ADVERTISE" problem with your patch and decide whether the sending of NotOnLink status in REPLY (when using the above mentioned configuration) is bug (worth filling) or not.

I'm lowering the Priority because there's no impact on any customer reported.

Comment 8 Jiri Popelka 2010-05-14 13:57:04 UTC
(In reply to comment #7)
> with the configuration from comment #6 server really sends NotOnLink status in
> REPLY.
> I'm not sure now why it is and whether it's a bug or configuration problem.
Same situation with the latest (and most likely also the last) dhcpv6 released, i.e. dhcpv6-1.2.0 (Fedora-11).

Comment 9 Bryan Mason 2010-05-14 15:29:11 UTC
(In reply to comment #7)
> Problem is that the server then again sends NotOnLink in REPLY,
> client again goes to SOLICIT and so on.
> So the client never gets his addresses.

Yeah, I remember thinking that the bug was preventing the client from going into an endless loop, but in this case, that may actually be the "correct" behavior.  :)

Comment 10 Jiri Popelka 2010-06-01 12:14:39 UTC
Bryan,

I filled another bug #598439 report for the "sending of NotOnLink status in REPLY" problem.
But I'm not sure whether we want to fix these two bugs now.
- It teases no customer
- risk of regressions
- client eventually gets his addresses (but in non-correct way)

Comment 14 errata-xmlrpc 2011-01-13 22:30:20 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0034.html


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