Bug 587003 - nm-tool shows confusion w.r.t. eth0/usb0 IP-info
Summary: nm-tool shows confusion w.r.t. eth0/usb0 IP-info
Status: CLOSED DUPLICATE of bug 586427
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-28 16:39 UTC by udo
Modified: 2010-04-29 19:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-28 19:56:55 UTC
Type: ---

Attachments (Terms of Use)

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):

How reproducible:
nm-tool [enter]

Steps to Reproduce:
1. nm-tool
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

    Carrier Detect:  yes
    Speed:           1000 Mb/s

  Wired Properties
    Carrier:         on

  IPv4 Settings:
    Prefix:          24 (

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

    Carrier Detect:  yes

  Wired Properties
    Carrier:         on

  IPv4 Settings:
    Prefix:          24 (

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.

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