Bug 838123 - system fact net.interface.sit0.mac_address appears unstable and facts --update doesn't seem to load the current system value.
system fact net.interface.sit0.mac_address appears unstable and facts --updat...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: subscription-manager (Show other bugs)
5.9
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Bryan Kearney
Entitlement Bugs
:
: 851398 (view as bug list)
Depends On:
Blocks: 771748 866645
  Show dependency treegraph
 
Reported: 2012-07-06 13:33 EDT by John Sefler
Modified: 2013-01-07 22:56 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The ethtool libraries are providing random mac addresses for sit* interfaces. Consequence: The facts are updated too often. Fix: Omit the mac address for lo and sit* interfaces, Result: Less updates of facts.
Story Points: ---
Clone Of:
: 866645 (view as bug list)
Environment:
Last Closed: 2013-01-07 22:56:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Sefler 2012-07-06 13:33:30 EDT
Description of problem:
Not sure about this bug since I know nothing about ipv6, but here's what I observe....

The value of system fact "net.interface.sit0.mac_address" seems to change over time which means that it's value stored on the consumer object may not be current.  Moreover, when I call subscription-manager facts --update attempting to re-sync their values, the update on the consumer does not seem to have an effect.


Version-Release number of selected component (if applicable):
[root@jsefler-59server ~]# rpm -q subscription-manager python-rhsm
subscription-manager-1.0.8-1.git.8.b51785c.el5
python-rhsm-1.0.3-1.git.0.583d26c.el5


How reproducible:
inconsistent and unpredictable

Steps to Reproduce:
[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:31:00

[root@jsefler-59server ~]# subscription-manager register --username testuser1 --password password --org adminThe system has been registered with id: 5814b300-40f9-4064-b389-42e0c2bc942f 

[root@jsefler-59server ~]# curl --stderr /dev/null --insecure --user testuser1:password --request GET https://jsefler-f14-candlepin.usersys.redhat.com:8443/candlepin/consumers/5814b300-40f9-4064-b389-42e0c2bc942f | python -m simplejson/tool | grep net.interface.sit0.mac_address
        "net.interface.sit0.mac_address": "00:00:00:00:11:01", 

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:31:00

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:31:00

[root@jsefler-59server ~]# subscription-manager facts --update
Successfully updated the system facts.

[root@jsefler-59server ~]# curl --stderr /dev/null --insecure --user testuser1:password --request GET https://jsefler-f14-candlepin.usersys.redhat.com:8443/candlepin/consumers/5814b300-40f9-4064-b389-42e0c2bc942f | python -m simplejson/tool | grep net.interface.sit0.mac_address
        "net.interface.sit0.mac_address": "00:00:00:00:21:00", 

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:31:00

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:31:00


[root@jsefler-59server ~]# subscription-manager unregister
System has been un-registered.

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:31:00

[root@jsefler-59server ~]# subscription-manager register --username testuser1 --password password --org adminThe system has been registered with id: afae4ac2-1421-49b0-aba3-fb8a7c7f0507 

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_address
net.interface.sit0.mac_address: 00:00:00:00:61:01

[root@jsefler-59server ~]# curl --stderr /dev/null --insecure --user testuser1:password --request GET https://jsefler-f14-candlepin.usersys.redhat.com:8443/candlepin/consumers/afae4ac2-1421-49b0-aba3-fb8a7c7f0507 | python -m simplejson/tool | grep net.interface.sit0.mac_address
        "net.interface.sit0.mac_address": "00:00:00:00:21:00", 

[root@jsefler-59server ~]# subscription-manager facts --list | grep net.interface.sit0.mac_addressnet.interface.sit0.mac_address: 00:00:00:00:61:01

[root@jsefler-59server ~]# 

  
Actual results:
AS demonstrated above the value of net.interface.sit0.mac_address seems to change a lot and the call to update facts did not seem to set the consumer with the current value

Expected results:


Additional info:
Comment 1 RHEL Product and Program Management 2012-07-06 13:47:33 EDT
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.
Comment 2 John Sefler 2012-08-15 14:23:34 EDT
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
Comment 3 Bryan Kearney 2012-09-19 16:52:46 EDT
*** Bug 851398 has been marked as a duplicate of this bug. ***
Comment 4 Petr Pisar 2012-10-08 05:53:10 EDT
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.
Comment 5 Bryan Kearney 2012-10-09 09:49:45 EDT
fixed in master at

bc07a7656274f7821bab3a22b0d55ce43dc83e90
51a69328255f29fa872ce73d86af10e858041808
Comment 6 Bryan Kearney 2012-10-09 11:27:45 EDT
the fix will omit the following facts since they are not usefule:

net.interface.sit0.mac_address
net.interface.lo.mac_address
Comment 7 Petr Pisar 2012-10-09 12:35:51 EDT
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.)
Comment 9 John Sefler 2012-10-12 15:51:55 EDT
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)
Comment 10 Petr Pisar 2012-10-15 03:59:59 EDT
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.
Comment 11 Adrian Likins 2012-10-15 13:07:42 EDT
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.
Comment 12 Bryan Kearney 2012-10-15 15:19:07 EDT
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.
Comment 13 John Sefler 2012-10-15 16:06:40 EDT
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.
Comment 14 Dmitri Dolguikh 2012-10-16 08:27:20 EDT
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?
Comment 15 Petr Pisar 2012-10-16 09:15:31 EDT
(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.
Comment 17 errata-xmlrpc 2013-01-07 22:56:34 EST
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

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