New to Pfsense wifi dhcp issue
-
every thing works fine as long as it's hardwired.
Does that mean wired computers get an IP address by DHCP? If so, you should see DHCP requests logged in Status -> System Logs, click on DHCP tab.
How are your APs configured? All with the same SSID and all using the same WiFi channel?
What WiFi clients do you have? Do the clients see the appropriate WiFi network(s)? What do the clients report anout their DHCP requests? (A packet capture on the client for comparison with the DHCP log on pfSense could be helpful for understanding what each party is seeing.)
I have found the WiFi Analyzer app for Android phones to be quite a useful tool for seeing what is happening in the WiFi environment - signal strength, channel occupancy etc.
-
Does that mean wired computers get an IP address by DHCP? If so, you should see DHCP requests logged in Status -> System Logs, click on DHCP tab.
Yes Wired Computers get IP, I will check the log when I get home. right now I'm not using pfsense since wifi don't work.
How are your APs configured? All with the same SSID and all using the same WiFi channel?
3 APs Same SSID all on different channels 1,6,11
What WiFi clients do you have? Do the clients see the appropriate WiFi network(s)? What do the clients report anout their DHCP requests? (A packet capture on the client for comparison with the DHCP log on pfSense could be helpful for understanding what each party is seeing.)
I have found the WiFi Analyzer app for Android phones to be quite a useful tool for seeing what is happening in the WiFi environment - signal strength, channel occupancy etc.
**If this is referring to wifi signal strength, this is not the cause since I have 3 APs spread out, so my entire property is covered from front yard to back yard.
There must be a setting within pfsense that I'm missing because as soon as I take pfsense out of the equation, everything works.**
-
**If this is referring to wifi signal strength, this is not the cause since I have 3 APs spread out, so my entire property is covered from front yard to back yard.
WiFi signals strength can be significantly reduced when passing through common building materials but that doesn't seem relevant to your particular situation.
There must be a setting within pfsense that I'm missing because as soon as I take pfsense out of the equation, everything works.
What do you mean "take pfSense out of the equation" - replace your pfSense by the Linksys e4200?**
-
What do you mean "take pfSense out of the equation" - replace your pfSense by the Linksys e4200?
Yes exactly if I shut down pfsense and plug the cable modem in the WAN of the e4200 and set the ip to 192.168.1.1, connect my main switch to it, everything works as is should, however I hate the stock firmware the wifi drops sometimes on it. When I was using tomato I never had drops or have to reboot the router unless there is a power outage that reboots it for me
-
Yes exactly if I shut down pfsense and plug the cable modem in the WAN of the e4200 and set the ip to 192.168.1.1, connect my main switch to it, everything works as is should
That suggests DHCP requests from the WiFi clients should reach pfSense and so should be logged in the pfSense DHCP log.
-
ok here is the log from pfsense
Here is the wireshark capture
-
Thanks for posting that information. In future, it would be better to post text information rather than screen shots because it is easier to search text for a character string than to search an image. You can get a text display of the pfSense DHCP log by pfSense shell command:```
clog /var/log/dhcpd.logWith regard to the wireshark capture : what is the MAC address of the machine on which it was captured? and how much of it corresponds with the DHCP log entries? Looking through the DHCP log at entries with MAC address 4c:eb:42:0b:6c:c4 I see repeated DHCPDISCOVER requests from that MAC address and repeated DHCPOFFERS sent to that MAC address. It would appear that system is either not seeing the DHCPOFFERS or is rejecting the DHCPOFFERs and sending another DHCPDISCOVER in the hope of getting an answer more to its liking. What OS is that system running? I remember a Windows laptop on my home network some time ago stopped accepting DHCP leases from my pfSense box. A bit hunting around with Google turned up a registry patch that persuaded it to accept the DHCPOFFERs. Some time later another Windows system suffered the same problem. I can't be certain, but I suspect a Windows update caused the problem. Another MAC address in the DHCP log (20:64:32:52:3f:ef) appears to also be ignoring DHCPOFFERs but the, all of a sudden, it starts issuing DHCPREQUESTS - perhaps for IP addresses it had previously (e.g. at 21:56:31 and 21:56:37). You will have to look on these client systems to see why they are apparently ignoring the DHCPOFFERs. For reference here is a completed DHCP assignment from the DHCP log on my pfSense: > Jun 7 12:55:32 pfsense dhcpd: DHCPDISCOVER from 00:03:47:81:cd:f7 via bridge0 > Jun 7 12:55:32 pfsense dhcpd: DHCPOFFER on 192.168.211.207 to 00:03:47:81:cd:f7 via bridge0 > Jun 7 12:55:32 pfsense dhcpd: DHCPREQUEST for 192.168.211.207 (192.168.211.173) from 00:03:47:81:cd:f7 via bridge0 > Jun 7 12:55:32 pfsense dhcpd: DHCPACK on 192.168.211.207 to 00:03:47:81:cd:f7 via bridge0 -
With regard to the wireshark capture : what is the MAC address of the machine on which it was captured? and how much of it corresponds with the DHCP log entries?
Mac of the laptop it was ran on is 4c:eb:42:0b:6c:c4 with a private ip of 169.254.170.37
Looking through the DHCP log at entries with MAC address 4c:eb:42:0b:6c:c4 I see repeated DHCPDISCOVER requests from that MAC address and repeated DHCPOFFERS sent to that MAC address. It would appear that system is either not seeing the DHCPOFFERS or is rejecting the DHCPOFFERs and sending another DHCPDISCOVER in the hope of getting an answer more to its liking. What OS is that system running? I remember a Windows laptop on my home network some time ago stopped accepting DHCP leases from my pfSense box. A bit hunting around with Google turned up a registry patch that persuaded it to accept the DHCPOFFERs. Some time later another Windows system suffered the same problem. I can't be certain, but I suspect a Windows update caused the problem.
The laptop is running windows 7 64bit, if a windows updates is the cause how come my android phone, my Blackberry z10, gf's Android phone, Android tablet and my son's ipad2 can't get ip either.
Another MAC address in the DHCP log (20:64:32:52:3f:ef) appears to also be ignoring DHCPOFFERs but the, all of a sudden, it starts issuing DHCPREQUESTS - perhaps for IP addresses it had previously (e.g. at 21:56:31 and 21:56:37).
above mac is my cell phone
You will have to look on these client systems to see why they are apparently ignoring the DHCPOFFERs.
wallabybob I just want to thank you for your continued help with this odd issue.
-
It is possible there are a number of different problems here.
Does the Windows laptop have a system log with reporting from the DHCP client? Can you enable extended logging from the Windows DHCP client? Can you find the registry patch I mentioned?
It might help to reduce the problem space by selecting one AP and one client for further investigation. I suggest that, if possible, you select an AP with packet capture capabilities. Save the AP configuration so you restore it later if needed. Then see if you can verify that DHCPOFFERs arrive at the AP on the wired interface. Can you verify the DHCPOFFERs are forwarded to the wireless interface? Monitor the wireless to see if DHCPOFFERs are transmitted. If there is no sign of DHCPOFFERs "in the air" tweak appropriate configuration items in the AP, recording what you have changed, until you see DHCPOFFERs "in the air". Does your client then get an IP address from DHCP?
-
So I managed to figure it out, it turns out that my motherboard with dual lan's. One of them the Nvidia one has an option in the bios to change the mac address on it and for some reason there is no mac address set on it. I put a mac address that's on the sticker on the lan port in my motherboard and all is well. I knew it was something stupid!!. Now on to the harder part getting my TP-Link N Card to work, Pfsense detects it and I managed to put an ip on it and enable dhcp, I set the wifi settings and for some unknown reason I can't get it to broadcast the SSID? is there something I have to put in the firewall for it to work?
pfsense LAN 192.168.1.1 - dhcp 192.168.1.50-99
pfsense WLAN 192.168.1.2 dhcp 192.168.1.100-149
external linksys e4200 ap 192.168.1.3
external Belkin N600 ap 192.168.1.4 -
Well done finding the problem.
pfsense LAN 192.168.1.1 - dhcp 192.168.1.50-99
pfsense WLAN 192.168.1.2 dhcp 192.168.1.100-149It appears you don't have the interfaces bridged so they need to be on distinct IP subnets, for example LAN: 192.168.1.1/24 and WLAN: 192.168.2.1/24.
PfSense does not yet support "WiFi N" though some cards which are "N capable" are supported in "G" mode. You might get better results with the WiFi by using a snapshot build of pfSense 2.1 which has much more up to date device drivers than pfSense 2.0.x.