This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 587592

Summary: Crashes if SLAAC and stateful DHCPv6 is enabled at the same time
Product: [Fedora] Fedora Reporter: Tore Anderson <tore>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dcbw, i.grok
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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:
Bug Depends On:    
Bug Blocks: 538499    
Attachments:
Description Flags
/var/log/messages none

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