DHCP and wireless clients
Pakken last edited by
Hi, I'm currently running a pfsense custom made box with a Supermicro A1SAi-2550F, 60GB SSD and a quad gigabit intel network pci-e card. At the moment I'm happily running 2.3 beta snapshot without any kind of problems. The only thing I can't get to work properly, even though I doubt it's pfsense-related, is dhcp with wireless clients, mostly phones and tablets.
I have 2 wireless AP at the 2 extreme edges of the building, on the same vlan, so that clients are roaming between channel 6-11.
Sometimes, mostly when a client gets away and comes back in wireless range later on, they can't get a dhcp lease anymore.
On pfsense system logs I can clearly see that the client requests an IP, the pfsense' dhcp server offers an IP but then there's no bloody way the dhcpack process completes.
Mar 3 17:56:08 dhcpd DHCPOFFER on 192.168.2.50 to 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:56:08 dhcpd DHCPDISCOVER from 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:56:06 dhcpd DHCPOFFER on 192.168.2.50 to 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:56:06 dhcpd DHCPDISCOVER from 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:56:05 dhcpd DHCPOFFER on 192.168.2.50 to 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:56:04 dhcpd DHCPDISCOVER from 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:54:43 dhcpd DHCPOFFER on 192.168.2.50 to 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:54:43 dhcpd DHCPDISCOVER from 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:54:35 dhcpd DHCPOFFER on 192.168.2.50 to 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:54:35 dhcpd DHCPDISCOVER from 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:54:27 dhcpd DHCPOFFER on 192.168.2.50 to 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
Mar 3 17:54:27 dhcpd DHCPDISCOVER from 04:4b:ed:22:5d:3c (iPhone-6s) via lagg0_vlan20
And this goes on and on forever until I reboot the AP. Once it's rebooted the clients are once again able to get a lease but as soon as they get off the wireless range and jump in again everything breaks again.
Even though I know this is unlikely to be a pfsense issue (cabled clients work like a charm) I just wanted to know if anyone of you ever faced this problem.
Thank you in advance :)
well clearly its a AP issue, since you see pfsense getting the discover and sending out the offer. So either wifi client is NOT getting this offer, or he doesn't like it for some reason. Since your saying once you reboot the AP it works.. I would have to assume the AP is not sending on the offer for some reason.
What is the AP your using??
Pakken last edited by
Thanks for the answer, what I forgot to mention is that with wireless notebooks, for example, I don't have any kind of problem. Tested with many kind of clients like Macbook pro, dell XPS, some low range HP probooks and so on.
The AP is a Netgear D6400 in full AP mode.
I have the exact same problem. In my case I use pfSense at home (so I am something of an amateur). My laptop and Surface are able to lease DHCP addresses just fine over wireless, but my son's phone and Xbox cannot. I see the same thing that the OP sees, namely that the request gets through to pfSense, the offer is sent back, but it never seems to reach the phone/xbox. I am at a loss to explain it. The previous system I used, before installing pfSense, always worked just fine for all wireless clients.
cmb last edited by
Guessing maybe the phones switch APs, but something on your switches doesn't switch those MACs over to the new AP possibly. It's definitely something on the network, and most likely the APs since power cycling them fixes it. But that could trigger something else that fixes it, like the affected clients switching to a different AP (where if they'd just switched APs without power cycling them, the same thing would have happened). The lagg might be suspect if something switch-side is making some of the requests it sends get dropped by the switch.
I have the exact same problem.
You have the same symptom, highly unlikely the same reason for it. You'd be best off starting a new thread describing your setup, AP, anything else that's relevant.
Well what I would do to troubleshoot such an issue is sniff on the client does it get the offer? Does it try and send a request?
If you don't understand the sniffs than post them.. Plenty of people here to look over them.
I have done a bit more investigation and I think I see the problem. In the devices that don't work, the DHCP DISCOVER and DHCP REQUEST messages have the Broadcast flag set to OFF. The DHCP server therefore unicasts the response, and that, for reasons I don't yet understand, does not get through my wireless AP (an old SMC Barricade). The clients that work have the Broadcast flag set to ON.
Although I have not been able to verify this, I suspect my previous DHCP server disregarded the flag and always broadcast the responses. The RFC (1541), allows servers to do this, but clearly pfSense does not do it.
Is there a setting somewhere that would allow me to modify the behaviour of the DHCP server, so that it always broadcasts responses?
Why don't you just toggle their broadcast bit to on?
I would if I could. The particular clients I have had problems with are an android phone and an Xbox. Today I have been looking at the android phone, and I can't find anything that would allow me to change this setting. I suspect it is baked into the DHCP client and probably can't be changed.
Well that is pretty shitty client.. But anywho - you say it clears up when reboot the AP?? IF so its an issue with the AP not sending on the dhcp offer.. and or request back from the client.
Actually, my situation isn't exactly the same as the OP's. In my case the problem does not go away with a restart of the AP. I can see the AP pass on the Discover to pfSense, and pfSense sending back the Offer, but in a Unicast which the AP does not send on. The client is an Android phone in this case. I suspect other DHCP servers (my previous one was the one built into Windows Server) just broadcast the response all the time regardless, which the RFC allows.
To resolve this it looks like I need to do one of three things:
1. Get the client to request Broadcast. I can't see how to get Android to do this.
2. Get the AP to pass the Unicast Offer through, based on the MAC address, rather than the IP (I suspect it is an ARP problem). Perhaps replacing the AP would fix this, and I have a longer term plan to do this at some point, although that is no guarantee it will solve the problem.
3. Get pfSense to always broadcast its Offers.
I suspect option 2 is the easiest one, but whether it would fix the problem I don't know.
jahonix last edited by
I've seen "DHCP helper" in some of the switches I use. Though I'm not completely sure about what it does I would expect it to work in this category. Maybe your AP offers this as well?
(I have to do some reading on the helper and "option 82" if I have an hour to kill…)