After some changes (not sure whether updates or from my connection provider) my network no longer works. The cause is that dhcpcd drops the acquired settings immediately - if I stop the interface and set it up manually with static address corresponding to the one offered by the router then the network works fine. Reproducible: Always Steps to Reproduce: 1. have bad luck with dhcpcd :-) 2. tail /var/log/messages Actual Results: Dec 24 09:16:31 jarmilka dhcpcd[1811]: eth0: probing address 192.168.3.117/24 Dec 24 09:16:36 jarmilka dhcpcd[1811]: eth0: leased 192.168.3.117 for 3600 seconds Dec 24 09:16:36 jarmilka dhcpcd[1811]: eth0: adding route to 192.168.3.0/24 Dec 24 09:16:36 jarmilka dhcpcd[1811]: eth0: adding default route via 192.168.3.1 Dec 24 09:16:36 jarmilka dhcpcd[1811]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.117 Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.117 Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: 10 second defence failed for 192.168.3.117 Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: deleting route to 192.168.3.0/24 Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: deleting default route via 192.168.3.1 Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: rebinding lease of 192.168.3.117 Dec 24 09:16:37 jarmilka dhcpcd[1811]: arp_read: eth0: Resource temporarily unavailable Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: probing address 192.168.3.117/24 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: leased 192.168.3.117 for 3600 seconds Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: adding route to 192.168.3.0/24 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: adding default route via 192.168.3.1 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.117 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.117 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: 10 second defence failed for 192.168.3.117 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: deleting route to 192.168.3.0/24 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: deleting default route via 192.168.3.1 Dec 24 09:16:42 jarmilka dhcpcd[1811]: eth0: rebinding lease of 192.168.3.117 Dec 24 09:16:43 jarmilka dhcpcd[1811]: arp_read: eth0: Resource temporarily unavailable ... and so on ad infinity Expected Results: the lease lasts for 1 hour, not 1 second 00:0a:5e:5a:b4:fc is the router - for sure it doesn't claim the address it has assigned to the dhcp client ...
Is 10.0.6 any better?
I see three issues here, none likely fixed in 10.0.6 1) Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.117 Dec 24 09:16:37 jarmilka dhcpcd[1811]: eth0: 10 second defence failed for 192.168.3.117 2) arp_read: eth0: Resource temporarily unavailable 3) eth0: rebinding lease of 192.168.3.117 The first one is the most serious and is an issue only you can solve - another device on your network is claiming the same IP address as the one you have leased. Looks like someone is doing an ARP attack on you. I say this because you are getting a DEFEND fail rather than a PROBE fail. This means someone is deliberately ignoring your probes for "Is this address in use?" but responding to your announcements of "I am now using this address". I wrote this functionality into parpd just to test this in dhcpcd! The second one is interesting and I cannot replicate it. The third one is a bug which I have fixed here: https://github.com/NetworkConfiguration/dhcpcd/commit/8ab7ca1eb4e9bb797d6e6d955c83d8a82f69a663 The above fix should also stop the looping you see and get you working again.
Roy, thank you as ever for your quick assistance.
(In reply to Roy Marples from comment #2) > The first one is the most serious and is an issue only you can solve - > another device on your network is claiming the same IP address as the one > you have leased. > Looks like someone is doing an ARP attack on you. > I say this because you are getting a DEFEND fail rather than a PROBE fail. > This means someone is deliberately ignoring your probes for "Is this address > in use?" but responding to your announcements of "I am now using this > address". that doesn't make any sense ... why would the router try to claim the very address it has assigned to my computer? FTR, it is MikroTik with RouterOS v6.48.2 (any known bugs there?) and it is not under my control, so I can hardly do anything about that I've tried to grep tcpdump for ARP and it looks like this: 22:55:21.660792 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 192.168.3.142, length 28 22:55:22.229634 00:0a:5e:5a:b4:fc (oui Unknown) > 58:11:22:c8:da:dd (oui Unknown), ethertype ARP (0x0806), length 60: Reply 192.168.3.142 is-at 00:0a:5e:5a:b4:fc (oui Unknown), length 46 22:55:22.229744 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 192.168.3.142, length 28 22:55:22.309630 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:22.549735 00:0a:5e:5a:b4:fc (oui Unknown) > 58:11:22:c8:da:dd (oui Unknown), ethertype ARP (0x0806), length 60: Reply 192.168.3.142 is-at 00:0a:5e:5a:b4:fc (oui Unknown), length 46 22:55:22.569266 24:5a:4c:f6:7b:3f (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.158.212 tell 0.0.0.0, length 46 22:55:22.611319 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 0.0.0.0, length 28 22:55:23.309646 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:23.632580 c4:73:1e:aa:2d:b6 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 192.168.3.1 tell 192.168.3.145, length 46 22:55:23.935700 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 0.0.0.0, length 28 22:55:23.949288 24:5a:4c:f6:7b:3f (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.158.212 (24:5a:4c:f6:7b:3f (oui Unknown)) tell 169.254.158.212, length 46 22:55:24.314263 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:24.646674 24:5a:4c:f6:7b:3f (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.250.159 tell 0.0.0.0, length 46 22:55:25.309410 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:25.557645 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 0.0.0.0, length 28 22:55:25.721567 24:5a:4c:f6:7b:3f (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.250.159 tell 0.0.0.0, length 46 22:55:26.309704 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:26.648590 c4:73:1e:aa:2d:b6 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 192.168.3.1 tell 192.168.3.145, length 46 22:55:27.128780 24:5a:4c:f6:7b:3f (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.250.159 tell 0.0.0.0, length 46 22:55:27.314918 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:27.560212 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 192.168.3.142, length 28 22:55:28.279708 00:0a:5e:5a:b4:fc (oui Unknown) > 58:11:22:c8:da:dd (oui Unknown), ethertype ARP (0x0806), length 60: Reply 192.168.3.142 is-at 00:0a:5e:5a:b4:fc (oui Unknown), length 46 22:55:28.279816 58:11:22:c8:da:dd (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.3.142 tell 192.168.3.142, length 28 22:55:28.309696 00:0a:5e:5a:b4:fc (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.17.7 tell 10.1.17.254, length 46 22:55:28.719704 00:0a:5e:5a:b4:fc (oui Unknown) > 58:11:22:c8:da:dd (oui Unknown), ethertype ARP (0x0806), length 60: Reply 192.168.3.142 is-at 00:0a:5e:5a:b4:fc (oui Unknown), length 46 (huh, pretty mess, mixing several networks, these should be separated ...) so the Request who-has 192.168.3.142 tell 192.168.3.142 gets the wrong response, but then Request who-has 192.168.3.142 tell 0.0.0.0 doesn't get any response I don't know how these things work and don't have the capacity to study it now, sorry if I ask stupid question, but ... it seems strange to me to ask about the address when you already use it, so I'd expect only 'tell 0.0.0.0' and not 'tell 192.168.3.142'...??? > The third one is a bug which I have fixed here: > https://github.com/NetworkConfiguration/dhcpcd/commit/ > 8ab7ca1eb4e9bb797d6e6d955c83d8a82f69a663 > > The above fix should also stop the looping you see and get you working again. thanks pls could you ping me when it gets released so I can test? - for now, I have worked around by using static settings of what I'm getting from dhcp
You can install the dhcpcd-9999 ebuild and get the fix to test with already. Gentoo is good like that. I'll look at your ARP logs later.
The MikroTik router can do Proxy ARP https://wiki.mikrotik.com/wiki/Manual:IP/ARP Here's another case similar to yours with a similar issue: https://forum.mikrotik.com/viewtopic.php?t=155523 I use parpd to simulate your issue - looks at the name - it's a Proxy ARP daemon. https://github.com/NetworkConfiguration/parpd I would suggest there is a misconfiguration or bug with the router. You can work around the issue by adding `noarp` to `/etc/dhcpcd.conf` - it does what it says and dhcpcd won't look for or perform ARP, thus ignoring the fact another device is trying to defend the address you want via ARP.
(In reply to Roy Marples from comment #5) > You can install the dhcpcd-9999 ebuild and get the fix to test with already. > Gentoo is good like that. ah, thanks, I've completely forgotten that vcs ebuild might be available so ... it doesn't help to workaround the issue Dec 26 09:49:03 jarmilka dhcpcd[517]: eth0: soliciting a DHCP lease Dec 26 09:49:07 jarmilka dhcpcd[517]: eth0: offered 192.168.3.130 from 109.238.41.17 Dec 26 09:49:07 jarmilka dhcpcd[517]: eth0: probing address 192.168.3.130/24 Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: leased 192.168.3.130 for 3600 seconds Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.3.130. Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: adding route to 192.168.3.0/24 Dec 26 09:49:12 jarmilka avahi-daemon[1899]: New relevant interface eth0.IPv4 for mDNS. Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: adding default route via 192.168.3.1 Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Registering new address record for 192.168.3.130 on eth0.IPv4. Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.130 Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.130 Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: 10 second defence failed for 192.168.3.130 Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Withdrawing address record for 192.168.3.130 on eth0. Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: deleting route to 192.168.3.0/24 Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: deleting default route via 192.168.3.1 Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.3.130. Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Interface eth0.IPv4 no longer relevant for mDNS. Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: soliciting a DHCP lease Dec 26 09:49:13 jarmilka dhcpcd[517]: eth0: offered 192.168.3.128 from 109.238.41.17 ... and repeats (In reply to Roy Marples from comment #6) > The MikroTik router can do Proxy ARP > https://wiki.mikrotik.com/wiki/Manual:IP/ARP > Here's another case similar to yours with a similar issue: > https://forum.mikrotik.com/viewtopic.php?t=155523 > > I use parpd to simulate your issue - looks at the name - it's a Proxy ARP > daemon. > https://github.com/NetworkConfiguration/parpd > > I would suggest there is a misconfiguration or bug with the router. well, might be, but as I said, I have no control over the device - I can try to contact the provider, but ... well, it took almost a year to resolve an obvious routing loop on another cable :-( I just wonder, if such issue is not totally unique - could the client be made more robust, coping with that somehow? - one of the answers mentions possible echoing, isn't there a way to distinguish that the client is getting back the packet it sent? detect that the client is getting the same address over and over, so trust the server that this is really the one that should be used? (do the check 3-5 times to allow its original purpose of trying another IP if the one appears to be used, then give up) > You can work around the issue by adding `noarp` to `/etc/dhcpcd.conf` - it > does what it says and dhcpcd won't look for or perform ARP, thus ignoring > the fact another device is trying to defend the address you want via ARP. yes, this fixes my issue, thanks now restarting the interface looks like Dec 26 09:51:51 jarmilka dhcpcd[1636]: sending signal TERM to pid 1332 Dec 26 09:51:51 jarmilka dhcpcd[1636]: waiting for pid 1332 to exit Dec 26 09:51:51 jarmilka dhcpcd[1332]: received SIGTERM, stopping Dec 26 09:51:51 jarmilka dhcpcd[1332]: eth0: removing interface Dec 26 09:51:51 jarmilka dhcpcd[1332]: dhcpcd exited Dec 26 09:51:51 jarmilka avahi-daemon[1899]: Withdrawing address record for 192.168.3.118 on eth0. Dec 26 09:51:51 jarmilka avahi-daemon[1899]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.3.118. Dec 26 09:51:51 jarmilka avahi-daemon[1899]: Interface eth0.IPv4 no longer relevant for mDNS. Dec 26 09:51:51 jarmilka kernel: r8169 0000:09:00.0 eth0: Link is Down Dec 26 09:51:51 jarmilka avahi-daemon[1899]: Withdrawing address record for fe80::5a11:22ff:fec8:dadd on eth0. Dec 26 09:51:51 jarmilka kernel: Generic FE-GE Realtek PHY r8169-0-900:00: attached PHY driver (mii_bus:phy_addr=r8169-0-900:00, irq=MAC) Dec 26 09:51:51 jarmilka kernel: r8169 0000:09:00.0 eth0: Link is Down Dec 26 09:51:51 jarmilka dhcpcd[1903]: dhcpcd-10.0.6 starting Dec 26 09:51:51 jarmilka dhcpcd[1905]: DUID 00:01:00:01:2c:b5:1f:8d:58:11:22:c8:da:dd Dec 26 09:51:51 jarmilka dhcpcd[1905]: eth0: waiting for carrier Dec 26 09:51:53 jarmilka dhcpcd[1905]: eth0: carrier acquired Dec 26 09:51:53 jarmilka kernel: r8169 0000:09:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx Dec 26 09:51:53 jarmilka kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Dec 26 09:51:53 jarmilka dhcpcd[1905]: eth0: IAID 22:c8:da:dd Dec 26 09:51:53 jarmilka dhcpcd[1905]: eth0: rebinding lease of 192.168.3.118 Dec 26 09:51:53 jarmilka dhcpcd[1905]: eth0: leased 192.168.3.118 for 3600 seconds Dec 26 09:51:53 jarmilka dhcpcd[1905]: eth0: adding route to 192.168.3.0/24 Dec 26 09:51:53 jarmilka dhcpcd[1905]: eth0: adding default route via 192.168.3.1 Dec 26 09:51:53 jarmilka avahi-daemon[1899]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.3.118. Dec 26 09:51:53 jarmilka avahi-daemon[1899]: New relevant interface eth0.IPv4 for mDNS. Dec 26 09:51:53 jarmilka avahi-daemon[1899]: Registering new address record for 192.168.3.118 on eth0.IPv4. Dec 26 09:51:54 jarmilka avahi-daemon[1899]: Registering new address record for fe80::5a11:22ff:fec8:dadd on eth0.*. and no further messages, address being kept, network running without any problem - I just wonder whether the error message could give some hint without being overly verbose (it's not a manpage...), as trying to google it doesn't look very helpful (like "RPi losing static address" - no "ARP" even mentioned in the answer etc.)
(In reply to kavol from comment #7) > (In reply to Roy Marples from comment #5) > > You can install the dhcpcd-9999 ebuild and get the fix to test with already. > > Gentoo is good like that. > > ah, thanks, I've completely forgotten that vcs ebuild might be available > > so ... it doesn't help to workaround the issue > > Dec 26 09:49:03 jarmilka dhcpcd[517]: eth0: soliciting a DHCP lease > Dec 26 09:49:07 jarmilka dhcpcd[517]: eth0: offered 192.168.3.130 from > 109.238.41.17 > Dec 26 09:49:07 jarmilka dhcpcd[517]: eth0: probing address 192.168.3.130/24 > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: leased 192.168.3.130 for 3600 > seconds > Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Joining mDNS multicast group on > interface eth0.IPv4 with address 192.168.3.130. > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: adding route to 192.168.3.0/24 > Dec 26 09:49:12 jarmilka avahi-daemon[1899]: New relevant interface > eth0.IPv4 for mDNS. > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: adding default route via > 192.168.3.1 > Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Registering new address record > for 192.168.3.130 on eth0.IPv4. > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: > 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.130 > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: > 00:0a:5e:5a:b4:fc(00:0a:5e:5a:b4:fc) claims 192.168.3.130 > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: 10 second defence failed for > 192.168.3.130 > Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Withdrawing address record for > 192.168.3.130 on eth0. > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: deleting route to 192.168.3.0/24 > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: deleting default route via > 192.168.3.1 > Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Leaving mDNS multicast group on > interface eth0.IPv4 with address 192.168.3.130. > Dec 26 09:49:12 jarmilka avahi-daemon[1899]: Interface eth0.IPv4 no longer > relevant for mDNS. > Dec 26 09:49:12 jarmilka dhcpcd[517]: eth0: soliciting a DHCP lease > Dec 26 09:49:13 jarmilka dhcpcd[517]: eth0: offered 192.168.3.128 from > 109.238.41.17 > ... > > and repeats As I suspected sadly. dhcpcd is now doing all that it possibly can though - declining the leased address on failure and as you can see, it gets a new address when it re-tries. There is nothing more I can do here. At least you have the option to turn it off. > > (In reply to Roy Marples from comment #6) > > The MikroTik router can do Proxy ARP > > https://wiki.mikrotik.com/wiki/Manual:IP/ARP > > Here's another case similar to yours with a similar issue: > > https://forum.mikrotik.com/viewtopic.php?t=155523 > > > > I use parpd to simulate your issue - looks at the name - it's a Proxy ARP > > daemon. > > https://github.com/NetworkConfiguration/parpd > > > > I would suggest there is a misconfiguration or bug with the router. > > well, might be, but as I said, I have no control over the device - I can try > to contact the provider, but ... well, it took almost a year to resolve an > obvious routing loop on another cable :-( Well, nothing stops you from putting a router in front of the router and isolating it from your network entirely. Then you only have the first router dealing with the ARP proxying going on and not all your clients. > > I just wonder, if such issue is not totally unique - could the client be > made more robust, coping with that somehow? > - one of the answers mentions possible echoing, isn't there a way to > distinguish that the client is getting back the packet it sent? > > detect that the client is getting the same address over and over, so trust > the server that this is really the one that should be used? (do the check > 3-5 times to allow its original purpose of trying another IP if the one > appears to be used, then give up) But that the thing - we now do get a different address and that still fails. I don't see how more robust we can get. You have two subnets in play as noted in your ARP logs - I can't help but wonder if this is the issue on the router somehow. > > > You can work around the issue by adding `noarp` to `/etc/dhcpcd.conf` - it > > does what it says and dhcpcd won't look for or perform ARP, thus ignoring > > the fact another device is trying to defend the address you want via ARP. > > yes, this fixes my issue, thanks Well, it's not a fix, more like a band-aid. > - I just wonder whether the error message could give some hint without being > overly verbose (it's not a manpage...), as trying to google it doesn't look > very helpful (like "RPi losing static address" - no "ARP" even mentioned in > the answer etc.) I think ARP failure is good enough. ARP failed - turn off ARP is the solution once all other paths have been exhausted.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae217d6b14343ea5ff772fd149f7b92195e69e99 commit ae217d6b14343ea5ff772fd149f7b92195e69e99 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-28 04:14:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-28 04:14:09 +0000 net-misc/dhcpcd: backport rebinding fix Closes: https://bugs.gentoo.org/920652 Signed-off-by: Sam James <sam@gentoo.org> net-misc/dhcpcd/dhcpcd-10.0.6-r1.ebuild | 169 +++++++++++++++++++++ .../dhcpcd/files/dhcpcd-10.0.6-rebinding.patch | 46 ++++++ 2 files changed, 215 insertions(+)
