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

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.

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

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.

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

Note

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