Description of problem: While System Facts list my IPv4 addresses, it does not list my IPv6 addresses. Version-Release number of selected component (if applicable): subscription-manager-0.93.2-1.git.1.c76a8b0.el6.x86_64 How reproducible: always Steps to Reproduce: 1. list system facts 2. show details of net group Actual results: Ipv4 only is listed Expected results: Both Ipv4 and IPv6 are listed.
Just note: recent python-ethtool (0.4) is able to retrieve IPv6 addresses.
Committed ed5bf74acf118784f7abcd4fc956730e4f2ed9f3 Available in 0.99.4+ This patch changes fact names! Most notably, net.interface.eth0.broadcast -> net.interface.eth0.ipv4_broadcast net.interface.lo.netmask -> net.interface.lo.ipv4_netmask net.interface.lo.ipaddr -> net.interface.lo.ipv4_address net.interface.lo.hwaddr -> net.interface.lo.mac_address network.ipaddr -> network.ipv4_address This change is meant to reflect that some of the fact information is only relevant for IPv4 and to bring the fact names more in-line with what ethtool calls the various interface properties. Also, the ipv6 facts are suffixed by the scope for the address. For example, net.interface.eth0.ipv6_address.link: fe80::5054:ff:feb5:8309 The "link" portion is the scope. As I understand it, the same interface can have multiple IPv6 addresses each with a different scope.
Please note some comments: * ethtool returns different scope for "public" IPv6 address. On EL6 it is "universe", while on EL5 is is "global". In rhn_client_tools we put there: scope = ip6.scope if scope == 'global': scope = 'universe' Just to be uniform across platform. It may not bother you, but you should be aware that you will get on el6: net.interface.eth0.ipv6_address.universe: 2620:52:0:221b:dad3:85ff:fe81:bda7 while on el5 you will get: net.interface.eth0.ipv6_address.global: 2620:52:0:221b:dad3:85ff:fe81:bda7 * I did not find in IPv6 documentation if it possible of if it is forbidden to have for one interface and one scope two ip addresses (in two or even one netmask). It is definitelly possible for IPv4. If it is possible for IPv6 then you have problem with your current code. * in getNetworkInfo you have: host = socket.gethostname() which does not need to return FQDN. And may not be resolvable from outside of this one particular machine. In rhn_client_tools we recently flipped to: for family in (AF_INET6, AF_INET): try: s = socket.socket(family) except socket.error: continue try: s.settimeout(5) s.connect((server, port)) intf_tmp = s.getsockname()[0] if family == AF_INET: intf = intf_tmp else: intf6 = intf_tmp hostname_tmp = socket.getfqdn(intf_tmp) if hostname_tmp != intf_tmp: hostname = hostname_tmp which I find more robust. It returns you hostname which you can safely use in kickstats or generaly in management tools (like Katello). And it prefer IPv4 hostnames rather then IPv6 hostnames - as they can be different. I will leave up to you if you address this issues in this BZ, or if you clone it, or if you will ignore it.
Moving to verified.. RPM used: [root@dhcp201-162 ~]# rpm -qa | grep subscription-manager subscription-manager-firstboot-0.99.9-1.git.2.0e7297c.el6.x86_64 subscription-manager-0.99.9-1.git.2.0e7297c.el6.x86_64 subscription-manager-migration-0.99.9-1.git.2.0e7297c.el6.x86_64 subscription-manager-migration-data-1.12.2-1.git.0.ede4958.el6.noarch subscription-manager-debuginfo-0.99.9-1.el6.x86_64 subscription-manager-gnome-0.99.9-1.git.2.0e7297c.el6.x86_64 [root@dhcp201-162 ~]# subscription-manager facts --list | grep ipv6 net.interface.br0.ipv6_address.global: 2620:52:0:41c9:be30:5bff:fed4:a098 net.interface.br0.ipv6_address.link: fe80::be30:5bff:fed4:a098 net.interface.br0.ipv6_netmask.global: 64 net.interface.br0.ipv6_netmask.link: 64 net.interface.eth0.ipv6_address.link: fe80::be30:5bff:fed4:a098 net.interface.eth0.ipv6_netmask.link: 64 net.interface.lo.ipv6_address.host: ::1 net.interface.lo.ipv6_netmask.host: 128 net.interface.vnet0.ipv6_address.link: fe80::fc54:ff:fe71:b99b net.interface.vnet0.ipv6_netmask.link: 64 network.ipv6_address: ::1
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-2012-0804.html