DHCP clients randomly get 192.168.1.x when configured for 10.8.8.x
-
Hi all,
Hope everyone had a great New Year!
I've been having an issue recently where devices on the network are randomly getting 192.168.1.x when the DHCP server is configured for the 10.8.8.100 to 10.8.8.254 range. This is happening on just about every device (randomly), no matter if it's the smart TV, an Android device, or a Linux/Windows computer. I've had the exact same setup for a year now and nothing has changed in the network besides having a few new devices (tablets/phones). I have a very simple setup:
SB6141 modem -> pfsense -> 8-port unmanaged switch -> 3 wireless APs -> devices --- 192.168.100.1 -> SB6141 modem 10.8.8.1 -> pfsense 10.8.8.2 -> ASUS AC66U Wireless AP 10.8.8.4 -> Linksys WRT310N V2 Wireless AP 10.8.8.8 -> ASUS AC68U Wireless AP 10.8.8.2 - 10.8.8.99 -> Range for static IPs 10.8.8.100 - 10.8.8.254 -> Range for DHCPMy pfsense box is running 2.2.6 and the DHCP server configuration is just the default, except for the range being set to 10.8.8.100-10.8.8.254. I've double-checked to make sure the wireless routers are set to AP mode and do not have a DHCP server running on them:
chenxiaolong@cxl-4270cto ~ » sudo dhcping -s 10.8.8.1 Got answer from: 10.8.8.1 chenxiaolong@cxl-4270cto ~ » sudo dhcping -s 10.8.8.2 no answer chenxiaolong@cxl-4270cto ~ » sudo dhcping -s 10.8.8.4 no answer chenxiaolong@cxl-4270cto ~ » sudo dhcping -s 10.8.8.8 no answerI looked at the dhcpd.log file and I see a lot of lines like this:
Jan 2 02:36:50 pfsense dhcpd: DHCPREQUEST for 192.168.1.8 from f4:09:d8:ed:44:3a via dc0: wrong network.I'm really not sure what might be causing this and I don't even know if pfsense is at fault. The issue is quite frustrating though since my TV and Android devices have no way to manually renew the DHCP lease so sometimes, I'll need to constantly disconnect and connect until they get a 10.8.8.x IP.
I've attached the dhcpd.log file and also a screenshot of my DHCP config. Any help is greatly appreciated.
Thanks in advance!
dhcpd.log.txt -
Are they actually getting those addresses or are you just seeing the requests?
If they are actually being assigned those addresses then you have another DHCP server on your network.
If you are just seeing those requests logged, then the DHCP server is NAKing them and assigning them addresses out of the proper scope then that is normal. A client will often request the last address it received even if on another network. This is logged by the server then the address in the proper scope is leased.
Run a packet capture to see what's really going on.
-
Thanks for the quick reply. Yes, the devices are actually getting the incorrect addresses. I don't know if it's important or not, but this issue is only happening with IPV4. Whenever the issue occurs, the devices always have a valid IPV6 address. I'll look into the NetworkManager logs on one of my Linux boxes to see if I can find any indication of a second DHCP server.
Regarding the packet capture, do I do this on the pfsense box or the client? (Sorry, I've never done this before.)
-
I'd start with your "APs" which are actually routers and have DHCP servers onboard. Each of the 3 listed.
Chances are one of them is not disabled.
If a host gets a wrong IP then have a look at its gateway address given by DHCP. That's pretty sure the IP of the DHCP-serving device. -
Thanks for the reply, jahonix. That was the first thing I tested. I used the "dhcping" tool and none of the wireless routers (which are set to AP mode) responded. I've SSH'd/telnet'd into the 3 routers just to make sure that the dhcp binary isn't running (also did a netstat to make sure there's nothing on UDP 67).
10.8.8.2: ASUS router (uses dnsmasq, which not running)
chenxiaolong@cxl-4270cto ~ » ssh admin@10.8.8.2 admin@10.8.8.2's password: ASUSWRT-Merlin RT-AC66U_3.0.0.4 Fri Apr 3 07:01:03 UTC 2015 admin@RT-AC66U:/tmp/home/root# ls /usr/sbin/dnsmasq /usr/sbin/dnsmasq admin@RT-AC66U:/tmp/home/root# ps | grep dnsmasq 517 admin 1420 S grep dnsmasq admin@RT-AC66U:/tmp/home/root# netstat -a -u Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 0.0.0.0:37000 0.0.0.0:* udp 0 0 10.8.8.255:netbios-ns 0.0.0.0:* udp 0 0 router.asus.com:netbios-ns 0.0.0.0:* udp 0 0 0.0.0.0:netbios-ns 0.0.0.0:* udp 0 0 10.8.8.255:netbios-dgm 0.0.0.0:* udp 0 0 router.asus.com:netbios-dgm 0.0.0.0:* udp 0 0 0.0.0.0:netbios-dgm 0.0.0.0:* udp 0 0 0.0.0.0:9999 0.0.0.0:* udp 0 0 localhost.localdomain:38032 0.0.0.0:* udp 0 0 0.0.0.0:42000 0.0.0.0:* udp 0 0 localhost.localdomain:42032 0.0.0.0:* udp 0 0 localhost.localdomain:40500 0.0.0.0:* udp 0 0 router.asus.com:58428 0.0.0.0:* udp 0 0 localhost.localdomain:37064 0.0.0.0:* udp 0 0 0.0.0.0:5474 0.0.0.0:* udp 0 0 0.0.0.0:18018 0.0.0.0:* udp 0 0 0.0.0.0:upnp 0.0.0.0:* udp 0 0 0.0.0.0:upnp 0.0.0.0:* udp 0 0 0.0.0.0:38000 0.0.0.0:* udp 0 0 0.0.0.0:43000 0.0.0.0:* admin@RT-AC66U:/tmp/home/root#10.8.8.8: ASUS router (does not support SSH or telnet, but web interface has netstat)
[hide]```
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:51459 0.0.0.0:*
udp 0 0 0.0.0.0:9999 0.0.0.0:*
udp 0 0 0.0.0.0:42000 0.0.0.0:*
udp 0 0 127.0.0.1:42032 0.0.0.0:*
udp 0 0 0.0.0.0:5474 0.0.0.0:*
udp 0 0 0.0.0.0:18018 0.0.0.0:*
udp 0 0 0.0.0.0:38000 0.0.0.0:*
udp 0 0 127.0.0.1:38032 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 0.0.0.0:5355 0.0.0.0:*
udp 0 0 0.0.0.0:43000 0.0.0.0:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 1304 /var/run/avahi-daemon/socket
DGRAM 363 /dev/log
DGRAM 1253
DGRAM 1182
DGRAM 36710.8.8.4: Linksys router running tomato (uses dnsmasq, which is not running)chenxiaolong@cxl-4270cto ~ » ssh root@10.8.8.4
root@10.8.8.4's password:Tomato v1.28.0000 MIPSR2-108 K26 Mini
root@unknown:/tmp/home/root# which dnsmasq
/usr/sbin/dnsmasq
root@unknown:/tmp/home/root# ps | grep dnsmasq
19914 root 1236 S grep dnsmasq
root@unknown:/tmp/home/root# netstat -a -u -n
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 127.0.0.1:38032 0.0.0.0:*
udp 0 0 127.0.0.1:38000 0.0.0.0:*
root@unknown:/tmp/home/root# -
Alright, the issue turned out to be a buggy WRT54GL (running Tomato) that I set up for my laser printer, which only supports 802.11G. I completely forgot I even had this router. When I set it to AP mode, it did not kill the dnsmasq process and for whatever reason, it comes back after rebooting, despite being disabled in the web UI. I just extracted the firmware, deleted the dnsmasq binary, and flashed it again. Now everything is fine.
Thanks for the help and sorry about the pfsense-unrelated noise!
-
Which means you're running 4 AccessPoints (two of them with 802.11AC) at the same time.
You either live on quite big a ranch or your steely prison only has 4 chambers. ;D -
So does your laser printer move about a lot? Why don't you just wire it and retire the old G stuff?
-
So does your laser printer move about a lot? Why don't you just wire it and retire the old G stuff?
Nope, but the ethernet jack is in a horrible spot :) I'd love to get rid of the old G stuff since nothing else uses it, but that means the printer is going in another room or I have to tear down the wall to put the port in a better place.
-
Which means you're running 4 AccessPoints (two of them with 802.11AC) at the same time.
You either live on quite big a ranch or your steely prison only has 4 chambers. ;DIt's not a really big house :D For whatever reason, the 802.11AC routers have a very, very hard time getting the signal to the basement (maybe because of the air ducts?), so one goes in the basement, the other goes in the second floor. The 802.11N is actually set to repeater mode so it can provide a wired connection to a Raspberry Pi that has a busted USB port thanks to my cats. The misbehaving 802.11G router provides internet to the brand-new printer with only wireless-G support.
It always feels like I have half-broken setup and have to make compromises to get anything to work haha ;)
-
It is true, metal obstructions can interfere with and bounce signals, another possibility may be that the piece of equipment getting a weak signal is located directly above or below the router. Most router antennas broadcast 360 degrees parallel to the ground, geometrically speaking, on the X and Y axis, and the signal will go diagonally up and down. You get the weakest signal, however, within 8-10 degrees of straight up and down. If you have a another AP with external antennas than you can bend, you could try pointing the antennas straight out behind the router, or, keeping the antennas bent and mounting the whole unit vertically on a wall.
Ultimately, if it ain't broke now, don't fix it. Most folks aren't aware of the inherent dead spot in Radio Frequency fields.
