Bug 821679

To ensure certain connections get used with specific interfaces, you need to set the "MAC Address" property for that connection in nm-connection-editor the MAC address of the interface.  If you do that, then only that interface will be used with that connection.  Does this fix your problem?  You may only need to delete the 'eth1' connection and things will work.

As you've seen, interfaces can get renamed at will, so interface names are not used in any of the matching logic.  Only MAC addresses are.  Any connection not locked to a specific interface via MAC address is available for use with any ethernet interface, because it is "any" and not locked to a specific MAC address.

Created attachment 584967 [details]
interface settings

(In reply to comment #1)
> To ensure certain connections get used with specific interfaces, you need to
> set the "MAC Address" property for that connection in nm-connection-editor the
> MAC address of the interface.

please see the attached screenshot - I don't have the possibility to specify the MAC address, I can only choose between existing interface names

=> RFE for KNetworkManager?

> If you do that, then only that interface will be
> used with that connection.  Does this fix your problem?  You may only need to
> delete the 'eth1' connection and things will work.

hm, and if I want to keep the 'eth1' configuration?

- I'm not sure whether this would fix the problem even if I could specify the MAC address ...

the problem is not what should be used with the particular interface but rather what should *not* be used with it

> As you've seen, interfaces can get renamed at will, so interface names are not
> used in any of the matching logic.  Only MAC addresses are.  Any connection not
> locked to a specific interface via MAC address is available for use with any
> ethernet interface, because it is "any" and not locked to a specific MAC
> address.

that doesn't make much sense for my usecase ...

I'd like to have one configuration, let's call it USB0, for all the devices creating usb0 I connect to my computer, not having to create a new configuration for every single one that I connect

still this configuration should not apply to the (immutable) network adapter inside the computer (called eth0), that one should have different configuration (let's call it ETH0) - if the configuration we called USB0 matches the adapter eth0 and sets values for USB0 on eth0, that's bad, eth0 should have values set in ETH0 if ETH0 is tied to eth0 (or its MAC address for that matter) ... OTOH I wouldn't mind (in fact I'd expect) if the configuration called USB0 would match eth1 as eth1 doesn't have any specific configuration (that we would call ETH1 in this example), thus falls under the "any" match of USB0

(In reply to comment #3)
> I'd like to have one configuration, let's call it USB0, for all the devices
> creating usb0 I connect to my computer, not having to create a new
> configuration for every single one that I connect
> 
> still this configuration should not apply to the (immutable) network adapter
> inside the computer (called eth0), that one should have different
> configuration (let's call it ETH0) - if the configuration we called USB0
> matches the adapter eth0 and sets values for USB0 on eth0, that's bad, eth0
> should have values set in ETH0 if ETH0 is tied to eth0 (or its MAC address
> for that matter) ... OTOH I wouldn't mind (in fact I'd expect) if the
> configuration called USB0 would match eth1 as eth1 doesn't have any specific
> configuration (that we would call ETH1 in this example), thus falls under
> the "any" match of USB0

You can put HWADDR_BLACKLIST to ifcfg-* file to exclude devices from using the connection. Something like:
HWADDR_BLACKLIST="00:22:68:11:55:32 00:11:22:11:44:55"

(In reply to comment #4)
> You can put HWADDR_BLACKLIST to ifcfg-* file to exclude devices from using
> the connection. Something like:
> HWADDR_BLACKLIST="00:22:68:11:55:32 00:11:22:11:44:55"

hm, so I have to do this for all connection configurations I will ever create, if I don't want them to touch the device which is configured already?

- doesn't sound too comfortable ... and also I don't see an option for this in the GUI (wouldn't the GUI overwrite the manual changes?)

btw, Jirka, you're welcome to discuss this in person, just stop by my cube when you have a minute

Ahoj,

please see upstream feature request:

https://bugzilla.gnome.org/show_bug.cgi?id=673537

(In reply to comment #6)
> Ahoj,
> 
> please see upstream feature request:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=673537

thanks for the pointer

however, I believe that the RFE doesn't cover this problem for %100

So...

When you use Dan Williams' information on how to bind configuration to a specific MAC address, Jirka Klimes' information on how to blacklist specific MAC addresses and when there is a possibility to disable autocreated configurations,
what else is missing and how would you describe a preferable solution?

hmm, so, if you read comment #3 (and comment #5 for that matter) ...

"I'd like to have one configuration, let's call it USB0, for all the devices creating usb0 I connect to my computer, not having to create a new configuration for every single one that I connect"

... the missing piece is how to do all of this on per-interface (or interface class) basis, not having to deal with MACs (which are unknown to me in advance)

plus the fact that I'm trying to deal with this via KNetworkManager GUI and not via GNOME GUI or vim TUI


now back to the point in subject; this was described as

"eth0" is tied to eth0
"eth1" has "cokoliv" ("any"?)

where "eth1" settings got wrongly applied to eth0, because it matched "any" - this is not a matter of "disabling autocreated configurations"

so my preferable solution is

1) the configuration could be specified based on _any_ piece of information that specifies the interface

2) there should be defined a hierarchy of matches from the most common to the most specific, e.g.

 [0] is it a network interface?
 [1] is it ethernet [ethX], wifi [wlanX], usb [usbX] ...?
 [2] which number in its class does it have [e.g. eth0, eth1 ...]?
 [3] what MAC address does it have?

now these rules should be flexible enough to be able to do matches like "(is it eth0) or (any wlan interface which has MAC beginning 12:34:*)"

note that this is just a proposal what comes to my mind right now, there may be many more possibilities, for example there may be also
 [1.1] if it is wifi, does it use iwl, broadcom, atheros or some other driver?
 [1.2] it if is wifi, which SSID is selectable?

3) when configuring an interface, the most specific match should have preference over the more common ones

4) there should be an option to identify an interface as not to be touched by NM  (not just via HWADDR_BLACKLIST) and also to make it as global default (= touch only those explicitly configured, the whitelist solution proposed in that GNOME bug)

> "I'd like to have one configuration, let's call it USB0, for all the devices
> creating usb0 I connect to my computer, not having to create a new
> configuration for every single one that I connect"

So you want to sometimes match interface name instead of MAC address, right?

> ... the missing piece is how to do all of this on per-interface (or
> interface class) basis,

Or interface class?

> not having to deal with MACs (which are unknown to
> me in advance)
> 
> plus the fact that I'm trying to deal with this via KNetworkManager GUI and
> not via GNOME GUI or vim TUI

Matching against various criteria will probably be regarded as advanced usage
so you will have to edit your connections properly.

> now back to the point in subject; this was described as
> 
> "eth0" is tied to eth0

Again, connection matching interface name?

> "eth1" has "cokoliv" ("any"?)

I can only guess what you mean by that, could you please be more specific? A
setting available for *any* interface?

> where "eth1" settings got wrongly applied to eth0, because it matched "any"
> - this is not a matter of "disabling autocreated configurations"

Correct, it is not. And it is not 'wrongly' if you interpret it as above. It
is perfectly ok to match eth1 as *any* device.

> so my preferable solution is
> 
> 1) the configuration could be specified based on _any_ piece of information
> that specifies the interface

Please be more specific. So far we have 'mac' and you would like to have
'interface name'.

> 2) there should be defined a hierarchy of matches from the most common to
> the most specific, e.g.

I don't see a reason for that. IMO it is enough to just match on all stuff
that user puts into his configuration file. If any specified match fails,
the whole connection should fail.

>  [0] is it a network interface?
>  [1] is it ethernet [ethX], wifi [wlanX], usb [usbX] ...?
>  [2] which number in its class does it have [e.g. eth0, eth1 ...]?
>  [3] what MAC address does it have?
> 
> now these rules should be flexible enough to be able to do matches like "(is
> it eth0) or (any wlan interface which has MAC beginning 12:34:*)"

I don't think we well implement a matching language in NetworkManager. Simple
'and' matching should be enough.

But if anyone really needs this, he could make an external tool to do that.
Or just a simple script.

> note that this is just a proposal what comes to my mind right now, there may
> be many more possibilities, for example there may be also
>  [1.1] if it is wifi, does it use iwl, broadcom, atheros or some other
> driver?
>  [1.2] it if is wifi, which SSID is selectable?

OK.

> 3) when configuring an interface, the most specific match should have
> preference over the more common ones

I think the matching should be just boolean. Either it matches (all) or
it doesn't match. Do you have any use case that would fail with this
solution?

> 4) there should be an option to identify an interface as not to be touched
> by NM  (not just via HWADDR_BLACKLIST) and also to make it as global default
> (= touch only those explicitly configured, the whitelist solution proposed
> in that GNOME bug)

Yep, that's a commonly requested feature e.g. by virtualization people.

(In reply to comment #10)
> > "I'd like to have one configuration, let's call it USB0, for all the devices
> > creating usb0 I connect to my computer, not having to create a new
> > configuration for every single one that I connect"
> 
> So you want to sometimes match interface name instead of MAC address, right?

yes

> > ... the missing piece is how to do all of this on per-interface (or
> > interface class) basis,
> 
> Or interface class?

yes, both and more, see below
(but in this case, interface name would be sufficient)

> > not having to deal with MACs (which are unknown to
> > me in advance)
> > 
> > plus the fact that I'm trying to deal with this via KNetworkManager GUI and
> > not via GNOME GUI or vim TUI
> 
> Matching against various criteria will probably be regarded as advanced usage
> so you will have to edit your connections properly.

advanced usage? - yes, I'm really not talking about doing that in GNOME ...

> > now back to the point in subject; this was described as
> > 
> > "eth0" is tied to eth0
> 
> Again, connection matching interface name?

yes

> > "eth1" has "cokoliv" ("any"?)
> 
> I can only guess what you mean by that, could you please be more specific? A
> setting available for *any* interface?

yes, a setting applied to *any* interface = all interfaces

> > where "eth1" settings got wrongly applied to eth0, because it matched "any"
> > - this is not a matter of "disabling autocreated configurations"
> 
> Correct, it is not. And it is not 'wrongly' if you interpret it as above. It
> is perfectly ok to match eth1 as *any* device.

no, it is not okay, as eth0 has different settings and so this should not be applied to eth0 even if it matches "any interface" criteria, which is the point of this report ...

> > so my preferable solution is
> > 
> > 1) the configuration could be specified based on _any_ piece of information
> > that specifies the interface
> 
> Please be more specific. So far we have 'mac' and you would like to have
> 'interface name'.

please read further before you ask ... or is the list below not enough specific?

> > 2) there should be defined a hierarchy of matches from the most common to
> > the most specific, e.g.
> 
> I don't see a reason for that. IMO it is enough to just match on all stuff
> that user puts into his configuration file.

it is not enough which is the point of this report

> If any specified match fails,
> the whole connection should fail.

maybe I do not understand what do you mean by "whole connection" here, but if one match fails, it doesn't imply that there is no other match which matches (doesn't fail)

> >  [0] is it a network interface?
> >  [1] is it ethernet [ethX], wifi [wlanX], usb [usbX] ...?
> >  [2] which number in its class does it have [e.g. eth0, eth1 ...]?
> >  [3] what MAC address does it have?
> > 
> > now these rules should be flexible enough to be able to do matches like "(is
> > it eth0) or (any wlan interface which has MAC beginning 12:34:*)"
> 
> I don't think we well implement a matching language in NetworkManager. Simple
> 'and' matching should be enough.

why to reinvent wheel?
aren't there libraries which can resolve such statements (once you feed them input in canonical form which doesn't seem that hard to me ...)?

> But if anyone really needs this, he could make an external tool to do that.
> Or just a simple script.

and does NM provide interface for that?
or do you suggest to turn off NM completely which is unsupported?

> > 3) when configuring an interface, the most specific match should have
> > preference over the more common ones
> 
> I think the matching should be just boolean. Either it matches (all) or
> it doesn't match. Do you have any use case that would fail with this
> solution?

yes, I do have use case - the very one which led to this report

> > So you want to sometimes match interface name instead of MAC address, right?
> 
> yes

https://bugzilla.gnome.org/show_bug.cgi?id=683102

> 
> > > ... the missing piece is how to do all of this on per-interface (or
> > > interface class) basis,
> > 
> > Or interface class?
> 
> yes, both and more, see below
> (but in this case, interface name would be sufficient)

Same as above.

> > > not having to deal with MACs (which are unknown to
> > > me in advance)
> > > 
> > > plus the fact that I'm trying to deal with this via KNetworkManager GUI and
> > > not via GNOME GUI or vim TUI
> > 
> > Matching against various criteria will probably be regarded as advanced usage
> > so you will have to edit your connections properly.
> 
> advanced usage? - yes, I'm really not talking about doing that in GNOME ...

Then it's fine for me.

> > > now back to the point in subject; this was described as
> > > 
> > > "eth0" is tied to eth0
> > 
> > Again, connection matching interface name?
> 
> yes

Good.

> > > "eth1" has "cokoliv" ("any"?)
> > 
> > I can only guess what you mean by that, could you please be more specific? A
> > setting available for *any* interface?
> 
> yes, a setting applied to *any* interface = all interfaces

All interfaces, good then.

> > > where "eth1" settings got wrongly applied to eth0, because it matched "any"
> > > - this is not a matter of "disabling autocreated configurations"
> > 
> > Correct, it is not. And it is not 'wrongly' if you interpret it as above. It
> > is perfectly ok to match eth1 as *any* device.
> 
> no, it is not okay, as eth0 has different settings and so this should not be
> applied to eth0 even if it matches "any interface" criteria, which is the
> point of this report ...

As stated above, it means all interfaces. The only thing we could do is to prefer connections with some matches. That said, I now probably understand what
you mean by 'more specific connections first'. 

But then what will be used when the 'more specific' connection fails? Stop trying / try again / try another (less specific)?

> > > so my preferable solution is
> > > 
> > > 1) the configuration could be specified based on _any_ piece of information
> > > that specifies the interface
> > 
> > Please be more specific. So far we have 'mac' and you would like to have
> > 'interface name'.
> 
> please read further before you ask ... or is the list below not enough
> specific?
>
> > > 2) there should be defined a hierarchy of matches from the most common to
> > > the most specific, e.g.
> > 
> > I don't see a reason for that. IMO it is enough to just match on all stuff
> > that user puts into his configuration file.
> 
> it is not enough which is the point of this report

This is not a report on one thing which actually makes it hard to triage.
 
> > If any specified match fails,
> > the whole connection should fail.
> 
> maybe I do not understand what do you mean by "whole connection" here, but
> if one match fails, it doesn't imply that there is no other match which
> matches (doesn't fail)

Maybe we just didn't understand each other.

> > >  [0] is it a network interface?
> > >  [1] is it ethernet [ethX], wifi [wlanX], usb [usbX] ...?
> > >  [2] which number in its class does it have [e.g. eth0, eth1 ...]?
> > >  [3] what MAC address does it have?
> > > 
> > > now these rules should be flexible enough to be able to do matches like "(is
> > > it eth0) or (any wlan interface which has MAC beginning 12:34:*)"
> > 
> > I don't think we well implement a matching language in NetworkManager. Simple
> > 'and' matching should be enough.
> 
> why to reinvent wheel?
> aren't there libraries which can resolve such statements (once you feed them
> input in canonical form which doesn't seem that hard to me ...)?

We don't actually need such complexity.

> > But if anyone really needs this, he could make an external tool to do that.
> > Or just a simple script.
> 
> and does NM provide interface for that?
> or do you suggest to turn off NM completely which is unsupported?

It does provide quite a rich interface and you can still file feature request
for anything you miss there. It's the way how it works, currently.

> > > 3) when configuring an interface, the most specific match should have
> > > preference over the more common ones
> > 
> > I think the matching should be just boolean. Either it matches (all) or
> > it doesn't match. Do you have any use case that would fail with this
> > solution?
> 
> yes, I do have use case - the very one which led to this report

Then you probably need to describe the use case more carefully and include reasoning why boolean match + match attribute preference is not enough.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.