I was trying to find out why my boot process was stalling for over 5 seconds at bringing up wicked. Yesterday, I did
bart@UNIVAC:~> ip -p a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether d8:cb:8a:e9:d6:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.5/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.3.5/24 brd 192.168.3.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::dacb:8aff:fee9:d6b5/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 34:68:95:59:32:d3 brd ff:ff:ff:ff:ff:ff
bart@UNIVAC:~>
Looking at the result for eth0, It shows two ip addresses, 192.168.3.5 (which is want I want) and 192.168.1.5. The .3.5 is correct for this computer. I have no idea where the .1.5 is coming from. This computer gets a reserved address from the dhcp server on my router. I have verified that the dhcp server is showing the .3.5 address.
How can I find out where it .1.5 address is coming form? Is there a command that will list any dhcp server on my net?
I am not sure what “should” implies here. There should be as many addresses as has been configured on interface. We know nothing about your configuration or infrastructure so we have no way to guess, whether this is expected or not. Output of “journalctl -b” would give at least some overview what happens on your system after boot.
It could be that, the unwanted IP address is present in a Name Service cache …
A hint may be shown by “ip route show
”. - If, you have the systemd “Name Service Cache Daemon
” service running, restarting the “nscd.service” may help. - Another place, may be the IP routing cache – “ip route show cache
” – in this case “ip route flush cache” may help.
In this case, “should” implies that I was under the impression that one, and only one address could be assigned to a network card. Obviously, this is not the case and is the reason for my question. The relevant portion of the journalctl output is here:
Feb 08 18:32:31 UNIVAC [RPM][2035]: Transaction ID 6021e62f started
Feb 08 18:32:32 UNIVAC wickedd-dhcp4[1555]: eth0: Committed DHCPv4 lease with address 192.168.3.5 (lease time 86400 sec, renew in 43200 sec, rebind in 75600 sec)
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.3.5.
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: New relevant interface eth0.IPv4 for mDNS.
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: Registering new address record for 192.168.3.5 on eth0.IPv4.
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: Registering new address record for 192.168.1.5 on eth0.IPv4.
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::dacb:8aff:fee9:d6b5.
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: New relevant interface eth0.IPv6 for mDNS.
Feb 08 18:32:32 UNIVAC avahi-daemon[1388]: Registering new address record for fe80::dacb:8aff:fee9:d6b5 on eth0.*.
Feb 08 18:32:32 UNIVAC ModemManager[1545]: <info> Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
Feb 08 18:32:32 UNIVAC ModemManager[1545]: <info> Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.6/0000:07:00.0': not supported by any plugin
Feb 08 18:32:32 UNIVAC [RPM][2035]: erase kernel-default-5.3.18-lp152.57.1.x86_64: success
Feb 08 18:32:33 UNIVAC kernel: fuse: init (API version 7.31)
Feb
No, that is incorrect. You can assign multiple addresses and it was always possible - otherwise no HA clusters could be created at all.
The relevant portion of the journalctl output is here
My usual reaction to such reply is - if you knew what is relevant you would not need to ask this question in the first place. The fact is that something is adding IP address to your interface. It may have happened well before log lines you show. Full log may give someone an idea where to look further.
I have no idea how that got in there, but there it was! I’ve changed it and now I’ll reboot only because it’s easier that looking up how to restart the network from the command prompt.
The file /etc/sysconfig/network/ifconfig-eth0 had the line
IPADDR='192.168.1.5/24'
in it. I changed it to 192.168.3.5 and all is well now. I couldn’t find that setting in yast2.
A month ago, I replaced my router and can only assume that during that process that the 192.168.1.x address got placed in that file. As I’m not happy with that router and have a new, different brand coming in a few days, I now know where to look to make sure everything is as I want.
That means that you do not use DHCP (at least for this fixed address), but it also looks as if you also used DHCP and that gave you the other other address from the DHCP server in the router. Better check again in YaST > Network devices if DHCP is on or not. And then recheck if what YaST shows is in conformance with ifconfig-eth0.