Bug 587003

Summary: nm-tool shows confusion w.r.t. eth0/usb0 IP-info
Product: [Fedora] Fedora Reporter: udo <udovdh>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dcbw
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-04-28 19:56:55 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:

Description udo 2010-04-28 16:39:14 UTC
Description of problem:
nm-tool shows confusion w.r.t. eth0/usb0 IP-info

Version-Release number of selected component (if applicable):
NetworkManager-0.8.0-6.git20100408.fc12.x86_64

How reproducible:
nm-tool [enter]

Steps to Reproduce:
1. nm-tool
2.
3.
  
Actual results:
See below

Expected results:
No confusion w.r.t. IP-settings; eth0 shows IP-info of usb0, which differs from actual values. Gateway is wrong as well, maybe related to this issue.

Additional info:
See https://bugzilla.redhat.com/show_bug.cgi?id=550280 for related discussion.

$ nm-tool 

NetworkManager Tool

State: connected

- Device: eth0  [System usb0] --------------------------------------------------
  Type:              Wired
  Driver:            r8169
  State:             connected
  Default:           no
  HW Address:        blabla

  Capabilities:
    Carrier Detect:  yes
    Speed:           1000 Mb/s

  Wired Properties
    Carrier:         on

  IPv4 Settings:
    Address:         192.168.1.200
    Prefix:          24 (255.255.255.0)
    Gateway:         0.0.0.0



- Device: usb0  [System usb0] --------------------------------------------------
  Type:              Wired
  Driver:            cdc_subset
  State:             connected
  Default:           no
  HW Address:        blabla

  Capabilities:
    Carrier Detect:  yes

  Wired Properties
    Carrier:         on

  IPv4 Settings:
    Address:         192.168.1.200
    Prefix:          24 (255.255.255.0)
    Gateway:         0.0.0.0

Yes, I obfuscated stuff a bit.

Comment 1 Dan Williams 2010-04-28 19:56:55 UTC
This is the same bug as bug 586427 since you're not locking the connections to the specific MAC address of the device you want them for, since you want to apply only specific configuration to specific devices.

If you lock the connections to their respective MAC addresses, then this will work correctly.

*** This bug has been marked as a duplicate of bug 586427 ***

Comment 2 udo 2010-04-29 13:19:28 UTC
If you think that setting the right info on the interfaces (for a change) but showing the wrong info is the same as setting the wrong info you are very much on your own.
To blame it on misconfiguration is even worse because how could NM assign the right numbers to the right interfaces in the first place?

I hate to repeat mantras so I won't but there is room for improvement.
Fix the udev setup, at least document recommended configs for taht part, so that you can trust on udev and don't have to think for all types of unnneeded workarounds which are unexpected, not useful nor pretty.
Let udev do what it needs to do.
Let NM do what it needs to do. Not what udev should do.
Make it sane. Not insane.

Comment 3 Dan Williams 2010-04-29 19:32:06 UTC
At some point we do get to blame it on misconfiguration.  Nobody complains about misconfiguration when they assign the wrong IP address to an interface and their network doesn't work.  The point is *by default* the installer and system-config-network will create ifcfg files that contain HWADDR.  But if you're creating an ifcfg file yourself, then of course you need to know how to do it correctly.  And since device names change *anyway* based on bus enumeration or other reasons (which has nothing to do with NM) when creating ifcfg files without HWADDR you'll already be in a situation where your configuration will not be applied correctly even by 'ifup'.

It's not a problem specific to NetworkManager.

You could argue however that we should, by default, MAC-lock ethernet connections in the connection editor.  That's certainly a valid point and there's room for improvement here.

And you can also argue that we should more clearly document this behavior, which is also a valid point.  And also one we are working on already.