Bug 587592
| Summary: | Crashes if SLAAC and stateful DHCPv6 is enabled at the same time | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tore Anderson <tore> | ||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 12 | CC: | 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 08:16:06 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 538499 | ||||||
| Attachments: |
|
||||||
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 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. (In reply to comment #2) > Tore, do you have your connection configured as "Automatic" or "Automatic, DHCP > only"? Automatic. Tore I believe this crash to be fixed by the 20100502 update; but if it's not, please reopen and we'll dig into it. (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 |
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