View Issue Details

IDProjectCategoryView StatusLast Update
0007116Kali LinuxGeneral Bugpublic2022-12-07 16:36
Reportervom Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionopen 
Product Version2021.1 
Summary0007116: NetworkManager/dhclient/something causing race condition on DHCP server, not releasing previous lease IPs
Description

I've been troubleshooting this for about a week. I believe I have finally distilled it down to what is happening. I will try my best to articulate that here...

This is a Kali 2021.1 running on a Thinkpad x301. The machine has an Intel wifi (Intel Corporation PRO/Wireless 5100 AGN [Shiloh]). It is connected via wifi (no wired / eth0).

Lately I have let the machine sit on my desk and run for an extended period. The other day my son complained his PC "didn't have internet". Troubleshooting this showed me that my DHCP server (ISC dhcpd on Linux) was pinging the address first, getting a response, and then moving on to a different IP. This next potential IP was also responding. Lather, rinse, repeat. I managed to catch it red handed, and all the ARP / MACs for these IPs came back to the Kali laptop.

What's really interesting (and confusing and frustrating...) - is that only one IP at a time is visible on the machine via 'ip addr show'. Yet the machine responds to previous IPs it had had.

I was thinking this was perhaps some kind of "promiscuous" issue where the machine was just responding to anything sent to it. However, I temporarily configured a static arp for an unused IP to point to the Kali laptop, and it did NOT respond. So it seems that these "phantom" IPs it's holding on to are only the ones it had on previous leases.

This problem grows and grows over a period of days and weeks. Eventually it will exhaust my DHCP pool.

Here is the current ARP entries on my firewall (MAC sanitized):

192.168.64.154 lladdr 00:22:fa:11:22:33 STALE
192.168.64.252 lladdr 00:22:fa:11:22:33 STALE

Only 252 is assigned right now:

root@x301:/home/vom# ip -f inet addr show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.64.252/24 brd 192.168.64.255 scope global dynamic noprefixroute wlan0
valid_lft 41371sec preferred_lft 41371sec

154 is not there. But 154 responds:

root@ice:~# ping -c 3 192.168.64.154
PING 192.168.64.154 (192.168.64.154) 56(84) bytes of data.
64 bytes from 192.168.64.154: icmp_seq=1 ttl=64 time=5.02 ms
64 bytes from 192.168.64.154: icmp_seq=2 ttl=64 time=4.62 ms
64 bytes from 192.168.64.154: icmp_seq=3 ttl=64 time=3.32 ms

--- 192.168.64.154 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.320/4.320/5.020/0.725 ms

Here's what this looks like on the DHCP server when this kicks over:

Mar 23 19:30:42 ice dhcpd[5419]: reuse_lease: lease age 3332 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.64.154
Mar 23 19:30:42 ice dhcpd[5419]: DHCPDISCOVER from 00:22:fa:11:22:33 (x301) via enp7s0.10
Mar 23 19:30:42 ice dhcpd[5419]: ICMP Echo reply while lease 192.168.64.154 valid.
Mar 23 19:30:42 ice dhcpd[5419]: Abandoning IP address 192.168.64.154: pinged before offer
Mar 23 19:30:42 ice dhcpd[5419]: Wrote 0 class decls to leases file.
Mar 23 19:30:42 ice dhcpd[5419]: Wrote 0 deleted host decls to leases file.
Mar 23 19:30:42 ice dhcpd[5419]: Wrote 0 new dynamic host decls to leases file.
Mar 23 19:30:42 ice dhcpd[5419]: Wrote 79 leases to leases file.
Mar 23 19:30:44 ice dhcpd[5419]: DHCPDISCOVER from 00:22:fa:11:22:33 via enp7s0.10
Mar 23 19:30:45 ice dhcpd[5419]: DHCPOFFER on 192.168.64.252 to 00:22:fa:11:22:33 (x301) via enp7s0.10
Mar 23 19:30:45 ice dhcpd[5419]: DHCPREQUEST for 192.168.64.252 (192.168.64.1) from 00:22:fa:11:22:33 (x301) via enp7s0.10
Mar 23 19:30:45 ice dhcpd[5419]: DHCPACK on 192.168.64.252 to 00:22:fa:11:22:33 (x301) via enp7s0.10

You can see that 154 was still pingable, so 252 was offered (and accepted). This will happen again soon and then 154 + 252 will be pingable and the client will consume a third address...

Over about a 4 day period, this machine consumed 97 IPs. I spot checked these and the mac address / x301 was always the culprit:

root@ice:/home/vom# zgrep offer /var/log/syslog*.gz | awk '{print $9}' | sort | uniq | wc -l
97

I'm going to put some other (possibly related) bug reports (different distros, upstream, etc) in the Additional section.

Steps To Reproduce

Connect laptop to wifi.
Leave running (no sleep, on AC power) for days / weeks.
See DHCP pool slowly get consumed as Kali machine "holds on" to old lease addresses.

Additional Information

This one reads almost exactly as what I am seeing (marked as Incomplete :( )
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1793763

There's also this one (auto-closed :( ):
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/166

Activities

vom

vom

2021-06-08 13:58

reporter   ~0014688

This is still happening on 2021.2.

Michu

Michu

2021-06-11 15:32

reporter   ~0014700

try to set address statically in gnome-network-manager

vom

vom

2021-06-11 15:36

reporter   ~0014701

try to set address statically in gnome-network-manager

With all due respect - how does that help ? If I do that, there will be no more lease requests and therefore this problem won't manifest. I'm not interested in how to prevent this from consuming my pool on DHCP (I'll just turn the machine off...) - I'm concerned with fixing this problem.

Michu

Michu

2021-06-11 15:41

reporter   ~0014703

i told you to set ip manually because this problem is a perfect example why dhcp sometimes sucks maybe try to see dhcp settings in router maybe lease time is too short or this address is reserved

vom

vom

2021-06-11 15:50

reporter   ~0014704

i told you to set ip manually because this problem is a perfect example why dhcp sometimes sucks maybe try to see dhcp settings in router maybe lease time is too short or this address is reserved

It's none of these issues. The Kali machine is holding onto and responding to "old" IPs. My DHCP server is doing it's job properly.

Michu

Michu

2021-06-14 17:28

reporter   ~0014712

i got an idea try to reserve address for yourself on router on kali take this ip from dhcp and see if this will work if not maybe driver or ethernet card is messing with you try this see if this will work

g0tmi1k

g0tmi1k

2022-12-07 16:36

administrator   ~0017189

This report has been filed against an old version of Kali. We will be closing this ticket due to inactivity.

Please could you see if you are able to replicate this issue with the latest version of Kali Linux (https://www.kali.org/get-kali/)?

If you are still facing the same problem, feel free to re-open the ticket. If you choose to do this, could you provide more information to the issue you are facing, and also give information about your setup?
For more information, please read: https://www.kali.org/docs/community/submitting-issues-kali-bug-tracker/

Issue History

Date Modified Username Field Change
2021-03-24 18:19 vom New Issue
2021-06-08 13:58 vom Note Added: 0014688
2021-06-11 15:32 Michu Note Added: 0014700
2021-06-11 15:36 vom Note Added: 0014701
2021-06-11 15:41 Michu Note Added: 0014703
2021-06-11 15:50 vom Note Added: 0014704
2021-06-14 17:28 Michu Note Added: 0014712
2022-03-25 13:57 g0tmi1k Severity major => minor
2022-12-07 16:36 g0tmi1k Note Added: 0017189
2022-12-07 16:36 g0tmi1k Status new => closed