Bug 1323571 - failed to disable userspace IPv6LL address handling
Summary: failed to disable userspace IPv6LL address handling
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Thomas Haller
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-04 07:04 UTC by Alexander Koksharov
Modified: 2018-10-23 08:10 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 19:08:37 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2581 normal SHIPPED_LIVE Low: NetworkManager security, bug fix, and enhancement update 2016-11-03 12:08:07 UTC
Red Hat Knowledge Base (Solution) 2797011 None None None 2018-10-23 08:10:37 UTC

Description Alexander Koksharov 2016-04-04 07:04:28 UTC
Description of problem:
In the message logs of the application node I can see the following messages:

Mar 24 12:46:17 node04 NetworkManager[607]: <warn>  (lbr0): failed to detach bridge port veth849200e
Mar 24 12:46:17 node04 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl add-port br0 veth849200e
Mar 24 12:46:17 node04 NetworkManager[607]: <warn>  (veth849200e): failed to disable userspace IPv6LL address handling
Mar 24 12:46:17 node04 nm-dispatcher: Dispatching action 'down' for veth849200e
Mar 24 12:46:17 node04 kernel: device veth849200e entered promiscuous mode 

Are the warnings visible there something to be concerned about?

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
From the SME thread this seems to be an issue with the RHEL 7.2 NM code, and would be a bug (in that these warning should have been suppressed).

Comment 1 Ben Bennett 2016-05-26 16:07:36 UTC
I think this is a NM issue, not an openshift SDN one.

Comment 2 Rashid Khan 2016-05-26 17:33:48 UTC
Luckily we have the chief architect of NM working in our team. 
sending it to him. :-)

Comment 3 Dan Williams 2016-06-02 14:45:52 UTC
The warning doesn't actually indicate a problem, and it should probably be suppressed.  NM is reporting events that already occurred as it catches up with what openshift-node is doing.

Reassigning to NM team for more analysis.  NM should probably handle ENODEV better here by not warning, if we can detect those cases accurately.

Comment 4 Dan Williams 2016-06-02 14:46:49 UTC
Warning comes from nm-device.c::set_nm_ipv6ll(); it's a bit hard to grep for since the 'disabled' is actually dynamically decided.

Comment 6 Thomas Haller 2016-07-05 13:18:44 UTC
branch for review: th/avoid-wrong-warnings-rh1323571

Comment 7 Beniamino Galvani 2016-07-05 17:04:52 UTC
(In reply to Thomas Haller from comment #6)
> branch for review: th/avoid-wrong-warnings-rh1323571

LGTM

Comment 11 Vladimir Benes 2016-09-23 13:02:05 UTC
harmless bug, moving to verified sanity only as the code is in and I haven't seen any errors like this and obviously customer is OK with it as well as the ticket was closed a long time ago.

Comment 13 errata-xmlrpc 2016-11-03 19:08:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2581.html


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