Created attachment 709980 [details] Configuration in NM Description of problem: If a NIC card has multiple IPv4 addresses, ifconfig shows only the first one, not the aliases Version-Release number of selected component (if applicable): net-tools 1.60 ifconfig 1.42 (2001-04-13) How reproducible: Always Steps to Reproduce: 1. Configure IP addresses in NM (see attached image) 2. Restart the network 3. run /sbin/ifconfig Actual results: $ /sbin/ifconfig em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 147.231.137.2 netmask 255.255.255.0 broadcast 147.231.137.255 inet6 fe80::21f:c6ff:fee9:79b5 prefixlen 64 scopeid 0x20<link> ether 00:1f:c6:e9:79:b5 txqueuelen 1000 (Ethernet) RX packets 658092 bytes 343995672 (328.0 MiB) RX errors 0 dropped 51 overruns 0 frame 0 TX packets 276096 bytes 318880660 (304.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 $ netstat -natu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN tcp 0 0 147.231.137.5:443 0.0.0.0:* LISTEN tcp 0 0 147.231.137.4:443 0.0.0.0:* LISTEN tcp 0 0 147.231.137.2:443 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN tcp 0 0 147.231.137.5:80 0.0.0.0:* LISTEN tcp 0 0 147.231.137.4:80 0.0.0.0:* LISTEN tcp 0 0 147.231.137.2:80 0.0.0.0:* LISTEN tcp 0 0 147.231.137.3:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:42257 0.0.0.0:* LISTEN tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN Expected results: All IP addresses should be shown by ifconfig, in CentOS 5.x they were displayed as eth0, eth0:1, eth0:2 etc Additional info:
What about 'ifconfig -a' ?
Please attach output of 'ip a' and 'ifconfig -a'.
(In reply to comment #2) > Please attach output of 'ip a' and 'ifconfig -a'. $ /sbin/ifconfig -a em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 147.231.137.2 netmask 255.255.255.0 broadcast 147.231.137.255 inet6 fe80::21f:c6ff:fee9:79b5 prefixlen 64 scopeid 0x20<link> ether 00:1f:c6:e9:79:b5 txqueuelen 1000 (Ethernet) RX packets 729549 bytes 356540424 (340.0 MiB) RX errors 0 dropped 51 overruns 0 frame 0 TX packets 299934 bytes 332490516 (317.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 $ /sbin/ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:1f:c6:e9:79:b5 brd ff:ff:ff:ff:ff:ff inet 147.231.137.2/24 brd 147.231.137.255 scope global em1 inet 147.231.137.3/24 brd 147.231.137.255 scope global secondary em1 inet 147.231.137.4/24 brd 147.231.137.255 scope global secondary em1 inet 147.231.137.5/24 brd 147.231.137.255 scope global secondary em1 inet6 fe80::21f:c6ff:fee9:79b5/64 scope link valid_lft forever preferred_lft forever
(In reply to comment #0) > If a NIC card has multiple IPv4 addresses, ifconfig shows only the first > one That's right. It's because ifconfig (and all the net-tools' tools) has been using ioctl kernel interface which is obsolete and lacks support for modern kernel features. In this case kernel returns only the first address for the interface. The fix would require to rewrite ifconfig to use netlink kernel interface instead of ioctl. This bug has been reported upstream as https://sourceforge.net/tracker/?func=detail&aid=3603853&group_id=146269&atid=764681 > CentOS 5.x they were displayed as eth0, eth0:1, eth0:2 etc Also correct. And ifconfig still does it if the secondary addresses are added with label, i.e. as interface aliases. AFAIK these network aliases (in general) are a relic of linux-2.0 and one should generally avoid them which is what NM does when configuring the secondary addresses. Try it yourself: # modprobe dummy # ip addr add 1.2.3.4/24 dev dummy0 # ip addr add 1.2.3.5/24 dev dummy0 # ip addr add 1.2.3.6/24 dev dummy0 label dummy0:0 # ip a dummy0: inet 1.2.3.4/24 scope global dummy0 inet 1.2.3.5/24 scope global secondary dummy0 inet 1.2.3.6/24 scope global secondary dummy0:1 # ifconfig -a dummy0: inet 1.2.3.4 netmask 255.255.255.0 broadcast 0.0.0.0 dummy0:1: inet 1.2.3.6 netmask 255.255.255.0 broadcast 0.0.0.0
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.