Using following network configuration /etc/conf.d/net: config_lan0="dhcp" dhcp_lan0="release nodns nontp nonis nogateway nosendhost" routes_lan0="default via 192.168.100.1" On system boot everything works fine: $ ifconfig lan0 lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.100.5 netmask 255.255.255.0 broadcast 192.168.100.255 ether e0:d5:5e:25:95:89 txqueuelen 1000 (Ethernet) RX packets 85260 bytes 70550116 (67.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 59249 bytes 10993354 (10.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xf7300000-f7320000 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.100.1 0.0.0.0 UG 2 0 0 lan0 192.168.100.0 0.0.0.0 255.255.255.0 U 2 0 0 lan0 But if occasionally happens router's reset I see new non-ordinar IP: $ ifconfig lan0 lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 169.254.241.50 netmask 255.255.0.0 broadcast 169.254.255.255 ether e0:d5:5e:25:95:89 txqueuelen 1000 (Ethernet) RX packets 94006 bytes 78185500 (74.5 MiB) RX errors 0 dropped 1 overruns 0 frame 0 TX packets 64060 bytes 11916203 (11.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xf7300000-f7320000 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.0.0 0.0.0.0 255.255.0.0 U 2 0 0 lan0 And inoperable network. DHCP-client (in my case net-misc/dhcpcd) even don't receive ordinar IP. In my case dropping «nogateway» option fixes issue (received route is simple and correct). But such behaviour provides unexpected surprises. Although I'm not resposible about proper fix. P.S. System packages used: $ equery u sys-apps/openrc [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-apps/openrc-0.44.10: U I - - audit : Enable support for Linux audit subsystem using sys-process/audit - - bash : enable the use of bash in service scripts (experimental) - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces + + ncurses : Add ncurses support (console display library) + + netifrc : enable Gentoo's network stack (net.* scripts) - - newnet : enable the new network stack (experimental) + + pam : Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip - - sysv-utils : Install sysvinit compatibility scripts for halt, init, poweroff, reboot and shutdown + + unicode : Add support for Unicode $ equery u net-misc/dhcpcd [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for net-misc/dhcpcd-9.4.1: U I - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces + + embedded : Embed the definitions of dhcp options in the dhcpcd executable - - ipv6 : Add support for IP version 6 - - privsep : Enable support for privilege separation + + udev : Enable virtual/udev integration (device discovery, power and storage device support, etc)
I suspect it goes something like this: 1. netifrc calls dhcpcd -G (nogateway). This adds a 192.168.100.x/24 address to the interface. 2. netifrc adds the "default via 192.168.100.1" route. This is bound implicitly to the 192.168.100.x address on the interface. 3. Your router resets. 4. dhcpcd attempts to renew the lease and fails somehow. It removes the 192.168.100.x address and replaces it with a 169.254.0.0 address. This also removes the "default via 192.168.100.1" route since it was tied to the 192.168.100.x address. This seems to be more of a dhcpcd problem than a netifrc problem.
# eix -Ic netifrc [I] net-misc/netifrc (0.7.3@09.04.2021): Gentoo Network Interface Management Scripts (In reply to Mike Gilbert from comment #1) > This seems to be more of a dhcpcd problem than a netifrc problem. I think, it will be right to enshure, that other DHCP clients handle this case correctly. I can make such check, but think it would be better to ask native users.