Bug 587592 - Crashes if SLAAC and stateful DHCPv6 is enabled at the same time
Crashes if SLAAC and stateful DHCPv6 is enabled at the same time
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 538499
  Show dependency treegraph
 
Reported: 2010-04-30 06:21 EDT by Tore Anderson
Modified: 2010-05-03 04:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-03 04:16:06 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)
/var/log/messages (84.42 KB, text/plain)
2010-04-30 06:21 EDT, Tore Anderson
no flags Details

  None (edit)
Description Tore Anderson 2010-04-30 06:21:35 EDT
Created attachment 410364 [details]
/var/log/messages

NetworkManager-0.8.0-9.git20100429.fc12.x86_64

If SLAAC is enabled simultaneously with stateful DHCPv6, ie. the following radvd.conf:

interface eth0 {
	AdvSendAdvert on;
	AdvOtherConfigFlag on;
	AdvManagedFlag on;
	MaxRtrAdvInterval 30;
	prefix 2001:16d8:ee47::/64 {
		AdvAutonomous on;
	};
};

NM appears to crash during device activation.  See attached log.

This should be a supported configuration, if I understand the description of AdvManagedFlag i radvd.conf's manual page correctly.  Win7 handles it just fine, and adds the DHCPv6-provided address in addition to its own auto-generated (SLAAC-based) address.

Tore
Comment 1 Tore Anderson 2010-05-02 17:56:13 EDT
The crash appears to have been fixed in git20100502, but I'm not entirely happy about how this situation is handled still.

This appears to happen when connecitng to the network, in chronological order:

1) An ICMPv6 Router Solicitation is replied to and a SLAAC-based address is added to the interface
2) DHCPv6 transaction happen and a DHCPv6 address is added to the interface and the SLAAC-based address removed (most of the time)
3) A periodic RA arrives, the SLAAC-based address is re-added

Now, the behaviour I'm objecting to here is the initial removal of the SLAAC-based address.  I can't see any reason why this should be done.

Also I've seen the following error being reported in my logs:

<error> [...] [nm-system.c:274] sync_addresses(): (eth0): error -17 returned from rtnl_addr_add():#012Unknown message type 52 (errno = No such file or directory)

Not sure if it's relevant, though, it shows up both in step #2 and #3.

Tore
Comment 2 Scott Schmit 2010-05-02 18:37:57 EDT
Tore, do you have your connection configured as "Automatic" or "Automatic, DHCP only"? For the former, I agree with your comment. For the latter, I think I have to disagree (or Bug 588163 isn't a bug). But if we go with the latter, I don't see why a separate method for DHCP only is needed.
Comment 3 Tore Anderson 2010-05-03 02:10:40 EDT
(In reply to comment #2)

> Tore, do you have your connection configured as "Automatic" or "Automatic, DHCP
> only"?

Automatic.

Tore
Comment 4 Dan Williams 2010-05-03 04:16:06 EDT
I believe this crash to be fixed by the 20100502 update; but if it's not, please reopen and we'll dig into it.
Comment 5 Tore Anderson 2010-05-03 04:22:01 EDT
(In reply to comment #4)
> I believe this crash to be fixed by the 20100502 update; but if it's not,
> please reopen and we'll dig into it.    

The crash is fixed, but as I pointed out in comment #1, it doesn't really behave 100% in the situation with DHCPv6 + SLAAC yet.  Do you want a new bug for this?  I thought we could just use this one (perhaps changing the title)?

Tore

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