Bug 838123

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

A probable consequence of this "chatty" fact is that many CONSUMER MODIFIED events are likely being generated.  I have a bucket of automated EventTests that have been failing during this rhel5.9 test cycle due to unpredicatable extraneous CONSUMER MODIFIED events.  Below is a trace from three such events.  Notice that the description value is not informative enough to tell me why the event occurred.  It would really be nice to include a little more information to help decipher why the CONSUMER MODIFIED occurred.


Event feed for consumer b4b18df5-feaa-42ac-9951-11702f8c39f0 entries[1].title=CONSUMER MODIFIED description=jsefler-59server.usersys.redhat.com modified the consumer jsefler-59server.usersys.redhat.com
Event feed for consumer b4b18df5-feaa-42ac-9951-11702f8c39f0 entries[2].title=CONSUMER MODIFIED description=testuser1 modified the consumer jsefler-59server.usersys.redhat.com
Event feed for consumer b4b18df5-feaa-42ac-9951-11702f8c39f0 entries[3].title=CONSUMER MODIFIED description=jsefler-59server.usersys.redhat.com modified the consumer jsefler-59server.usersys.redhat.com

*** Bug 851398 has been marked as a duplicate of this bug. ***

sit0 network interface is an end of IPv6 over IPv4 tunnel. This is not a physical device and it does not have any real media-access-control (MAC) address.

The value you can see in RHEL-5 is just a dummy value, randomly generated or based on some serial number or based on a garbage.

However because "ip link show" or "ifconfig -a" does not show any MAC address properly, I guess the value produced by "fact" utility is just a bug in the utility or some underlying daemon. In other words it should not report any MAC address for SIT interface. The same as loop-back device (lo) has none.

fixed in master at

bc07a7656274f7821bab3a22b0d55ce43dc83e90
51a69328255f29fa872ce73d86af10e858041808

the fix will omit the following facts since they are not usefule:

net.interface.sit0.mac_address
net.interface.lo.mac_address

I cannot find the git repository, but I warn you on excluding interfaces based on names. You can give any arbitrary name to an interface. If you need need MAC address, you should pass interfaces belonging to IEEE.802 class like Ethernet only. (I have no idea how to obtain the type, but `ip link show' prints them, so it's possible.)

It appears in subscription-manager commit bc07a7656274f7821bab3a22b0d55ce43dc83e90 that the omitted mac_address facts were hard coded to start with "lo" and "sit".

Heeding the advice of Petr in comment 7 who says these device names can be arbitrary, would it be a better algorithm to do the following?

for each device_name in "ip link show"
  if "ip route show dev <device_name>" is empty
    omit the <device_name>.mac_address from the system facts
  else
    include the <device_name>.mac_address as a system fact

for example...
[root@rhsm-accept-rhel5 ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 52:54:00:c2:bb:6d brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
[root@rhsm-accept-rhel5 ~]# ip route show dev lo
[root@rhsm-accept-rhel5 ~]#         <====== OMIT net.interface.lo.mac_address
[root@rhsm-accept-rhel5 ~]# ip route show dev eth0
10.16.120.0/24  proto kernel  scope link  src 10.16.120.222 
169.254.0.0/16  scope link 
default via 10.16.120.254           <====== INCLUDE net.interface.eth0.mac_address
[root@rhsm-accept-rhel5 ~]# 
[root@rhsm-accept-rhel5 ~]# ip route show dev sit0
[root@rhsm-accept-rhel5 ~]#         <====== OMIT net.interface.sit0.mac_address


NEEDINFO to decide if this is a better algorithm. (Discalimer: jsefler is ip illiterate)

That's not good. There is no relation between devices with route and MAC address. Even you do not consider IPv6. Of course preferring devices with route is helpful as these devices are probably in use, but first you need to check the link type. E.g. in your output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 52:54:00:c2:bb:6d brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0

You can see the lo is of type loopback. sit0 is of type site. Instead of excluding devices on interface names, you should exclude on the type.

subscription-manager source code is at 
https://github.com/candlepin/subscription-manager

src/subscription_manager/hwprobe.py is module in question


the interface info here is coming from the "ethtool" python module, 
It's source is at 

import ethtool

for e in ethtool.get_interfaces_info(ethtool.get_devices()):
     print e


will show the same kind of info. Not sure why it's returning
a mac address at all, or why it's bogus. It kind of feels
like an uninitialized mem issue, but haven't dug deep into
the module.

http://fedorapeople.org/cgit/dsommers/public_git/python-ethtool.git/

Right fix is probably in python-ethtool, but the above subscription-manager work around should be forwards compatible if that changes.

Keeping bug as is given the low priority of getting it wrong. Opened new bug, https://bugzilla.redhat.com/show_bug.cgi?id=866645, to do it better in later versions.

Acknowledging that bug 866645 will be used to track a better fix for this bug.

In the meantime, we'll verify comment 6 as a temporary fix...

Verifying Version...
[root@jsefler-rhel59 ~]# rpm -q subscription-manager
subscription-manager-1.0.22-1.el5

[root@jsefler-rhel59 ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 52:54:00:65:c2:06 brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
[root@jsefler-rhel59 ~]# subscription-manager facts | grep mac_address
net.interface.eth0.mac_address: 52:54:00:65:C2:06
[root@jsefler-rhel59 ~]# 

^^^ VERIFIED: The mac_address fact for sit0 and lo were excluded from the facts.

there's also an interesting "noarp" flag on sit0 - which is an indication that arp (and thus mac address) is not being used. perhaps the presence of this flag can be used for filtering out of mac addresses?

(In reply to comment #14)
> there's also an interesting "noarp" flag on sit0 - which is an indication
> that arp (and thus mac address) is not being used. perhaps the presence of
> this flag can be used for filtering out of mac addresses?

Even this is good indicator it just means the ARP is disabled on the interface. One can disable the ARP with "ifconfig DEVICE -arp". Ridiculously, one can set /proc/sys/net/ipv4/conf/DEVICE/arp_ignore and /proc/sys/net/ipv4/conf/DEVICE/arp_accept what should have similar effect, but the flag does not flip.

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.

http://rhn.redhat.com/errata/RHBA-2013-0033.html