Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 598439 - Server sends NotOnLink status in Reply when more range statements configured
Summary: Server sends NotOnLink status in Reply when more range statements configured
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6
Version: 5.5
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Jiri Popelka
QA Contact: Release Test Team
Depends On:
Blocks: 511323
TreeView+ depends on / blocked
Reported: 2010-06-01 12:13 UTC by Jiri Popelka
Modified: 2011-01-13 22:30 UTC (History)
4 users (show)

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

Attachments (Terms of Use)
Patch that fixes setting of status code in Reply (deleted)
2010-06-01 12:13 UTC, Jiri Popelka
no flags Details | Diff
corrected patch (deleted)
2010-10-25 11:30 UTC, Jiri Popelka
no flags Details | Diff

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

Description Jiri Popelka 2010-06-01 12:13:07 UTC
Created attachment 418610 [details]
Patch that fixes setting of status code in Reply

Description of problem:
When we define more than one 'range' statement in dhcp6s.conf,
e.g. like stated in dhcp6s.conf(5) man page

interface eth1 {
        link AAA {
                range 3ffe:ffff:100::10 to 3ffe:ffff:100::110/64;
                prefix 3ffe:ffef:104::/64;
                pool {
                        range fec0:ffff::10 to fec0:ffff::110/64;
                        prefix fec0:fffe::/48;

server always sends NotOnLink status in Reply message.
That forces the client to restart the DHCP server discovery process.

This bug looks serious but actually it's not a big deal,
because his fellow bug #511323 backs him.
Because of bug #511323 client eventually get his IP addresses,
but in a 'non-correct' way.

To see in more detail how this all works see

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

Additional info:
There's no impact on any customer reported,
so I'm not sure whether we want this to have fixed.
Risk regressions for bug, which teases nobody ?
I suggest to leave this bug and bug #511323 be
until there's some customer who wants this to have fixed.

Comment 2 Jiri Popelka 2010-10-25 11:30:03 UTC
Created attachment 455513 [details]
corrected patch

The original patch was not correct. I have just committed this patch.

Comment 5 errata-xmlrpc 2011-01-13 22:30:28 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.

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