Rogue Device or Malware Saturating DHCP Server?

On my SOHO lan I tend to use fixed IPs on wired workstations and DHCP for wireless connected laptops. From time to time and only on laptops (running openSUSE 13.2) I lose access to the WAN although still being connected to wifi access point. In trying to trouble shoot this I recently found that the problem was not with the laptops but that all the available IP addresses on the relevant subnet were shown on the DHCP server as “offered.” If I killed any of these leases they were almost immediately re assigned and shown as offered once more. The effect of this was that no new laptop connection could be made. Unfortunately the DHCP server only shows the MAC address of connected devices not supplicants so I cannot easily find the source of the problem. Possible causes I can think of include a rogue client device such as a Chromecast video, a network media renderer or possible a mobile phone. It could also be some kind of malware, a virus on a machine within range or even a scanner.

I appreciate this is slightly OT but am posting here hoping somebody can point me to a good technical wireless forum where I can get some help using wireshark or similar network tool to pin down the source of this problem or possible PM me with assistance.
Grateful for some help on this please.
Budgie2

Have you tried using MAC address filtering in your router?

Are you using a good WPA2 password? (The longer, the better, increasing encryption with length.)

Or, is your router wide open?

Best practice would be to keep a list of all devices you want authorized to access the network along with their MAC addresses (in some cases, both their wired & wireless MAC addresses). This helps a lot when controlling your LAN.

Hi and thanks for the suggestions. Password is 13 characters long, numbers and letters and upper and lower case. I don’t think that is the problem because if it had been cracked a lease would have been granted.

I could use MAC filtering on this particular router but it will take some time to set it up. Trouble is it is not very friendly if family visit as giving them the password would not then be sufficient.

Any thoughts on the repeated supplicant requests. Symptoms seemed similar to a DoS attack in that all the subnet IP addresses were used up. Not been repeated for a while.
Budgie2

Any thoughts on the repeated supplicant requests. Symptoms seemed similar to a DoS attack in that all the subnet IP addresses were used up. Not been repeated for a while.
Budgie2

What’s confusing to me is that you mention about the address pool being used up, but if these wireless devices are not successful with authentication then they don’t get connected, so DHCP requests/leases won’t be occurring from these ‘attempts’. That only leaves connected devices. Can you identify the MAC addresses registered for these DHCP IP addresses?

Use nmap or arp-scan to identify connected hosts on the LAN eg

nmap -sn 192.168.1.0/24
arp-scan --interface=eth0 192.168.1.0/24

Hi Deano, see my initial post. The addresses seem stuck in the lease negotiation as they are marked “offered.” In this state the supplicants are not yet connected and the MAC address is not displayed so I have no idea which device is causing the problem.

Use nmap or arp-scan to identify connected hosts on the LAN eg

nmap -sn 192.168.1.0/24
arp-scan --interface=eth0 192.168.1.0/24

I can only do this when problem next occurs, which I shall. Thanks for the suggestion.
Budgie2

Problem identified and it was a rogue device. The problem stared again yesterday and this time I was able to search the log of the DHCP server and found the repeating UDP broadcast DHCPDISCOVER packet traffic with the MAC address of the device sending the packets.

The DHCPDISCOVER packets were prompting the expected DHCPOFFER from the server but the client device was apparently not getting the offer so was sending out another discovery packet. Each discovery packet resulted in an offer which quickly used up all the available addresses which were then shown as “offered” on the control page and clearly not available for legitimate clients.

Problem solved by setting blocking filter in DHCP server to block the offending MAC address. I was then able to find the rogue device, an ethernet wireless bridge, and turn it off.

Good to know that you finally found the culprit device.

Good sleuth-work!:good: