2.0 DHCPd problem, dont give ip

vaf0r

I installed pfsense 2.0 two nights ago after running 1.2.3 a few months, i cant figure out why my dhcpd on LAN does not work, for WAN i have static ip, and for LAN i also have static ip for the firewall when i was asigning ip in the console i choiced "Y" for enable dhcp server i have checked settings like dhcp server and advanced, general well all but i cant understand what is wrong i tryed to switch network cards but same problem, when i check logs for dhcpd it shows nothing like its not running but when checking in pfsense it is running and is enabled i have tryed to search here on the forum but did not find any that helped me, some one said if WAN and LAN is in same sub like 255.255.255.0 both my static ip from my isp use that subnet but my isp ip is 77.x.x.x and my lan ip is 192.168.1.x and i used the same setup i have now with version 1.2.3 and that worked with out problems.
One thing that hit me as i said i tryed to switch network cards but both my card are intel can i have something to do with that?
I can ping the firewall if i set a static ip on my pc and i can ping my pc from the firewall.
Any suggestions or help would be great :)

wallabybob

Which logs did you check? system AND DHCP AND Firewall?

Suggest you run a packet capture on your LAN interface while your PC is doing its DHCP thing. This should establish whether or not the DHCP requests are getting to your pfSense box.

vaf0r

@wallabybob:

Which logs did you check? system AND DHCP AND Firewall?

Suggest you run a packet capture on your LAN interface while your PC is doing its DHCP thing. This should establish whether or not the DHCP requests are getting to your pfSense box.

I checked dhcp log with is blank noting at all, i tryed tcpdump -i em0 -port 67 but that did not work i found that here on the forum how to run tcpdump but that did not work its like something is missing in the command i tested with -p insted of -port but same not the right "string" tcpdump only show how to use it but i dont see where i missed.
Is there any other packet capture i can try? Sorry to be so noob :)
If i should installed 1.2.3 agian and use that i know it work with dhcp but once the 2.0 go to stable do anyone know if a good idea to update to 2.0 from 1.2.3 or can settings etc be messed up?

wallabybob

@vaf0r:

i tryed tcpdump -i em0 -port 67 but that did not work

"did not work" might cover a variety of behaviours. Its difficult to guess which one you might have meant.

@vaf0r:

i found that here on the forum how to run tcpdump

I presume you mean your command should have been tcpdump -i em0 port 67

@vaf0r:

but that did not work

again its difficult to guess what particular meaning of "did not work" you intend to convey.

@vaf0r:

i tested with -p insted of -port but same not the right "string" tcpdump only show how to use it but i dont see where i missed.

Sorry, but I don't understand this part of your reply after the first "but". I suspect full stops might help me.

Until you are familiar with tcpdump it might be worthwhile logging all traffic (in this case, # tcpdump -i em0) so you don't miss traffic because your tcpdump filter is incorrectly specified. Alternatively, # tcpdump -i em0 port 67 should show any DHCP traffic but might show other traffic as well (TCP traffic using port 67).

vaf0r

@wallabybob:

@vaf0r:

i tryed tcpdump -i em0 -port 67 but that did not work

"did not work" might cover a variety of behaviours. Its difficult to guess which one you might have meant.

@vaf0r:

i found that here on the forum how to run tcpdump

I presume you mean your command should have been tcpdump -i em0 port 67

@vaf0r:

but that did not work

again its difficult to guess what particular meaning of "did not work" you intend to convey.

@vaf0r:

i tested with -p insted of -port but same not the right "string" tcpdump only show how to use it but i dont see where i missed.

Sorry, but I don't understand this part of your reply after the first "but". I suspect full stops might help me.

Until you are familiar with tcpdump it might be worthwhile logging all traffic (in this case, # tcpdump -i em0) so you don't miss traffic because your tcpdump filter is incorrectly specified. Alternatively, # tcpdump -i em0 port 67 should show any DHCP traffic but might show other traffic as well (TCP traffic using port 67).

Sorry my english is not the best what i mean with not work is that i just got printed on the screen how to use tcpdump -aAIfFa#fp etc etc like the command is not right sry its hard to explain, with out - just tcpdump em0 port 67 tcpdump work like i should and give me some output i dont really understand "oui unknown" and some more about dhcp/boot… not anything that look like a error or say error just that "oui unknown" i got this once i try to request a ip from another pc but still dont get any ip can you or someone maybe try explain why it work with 1.2.3 and not 2.0 there is no change in hardware and i followed the steps how to set it up a few times on 1.2.3 and it always worked i dont it atlest 4 times on 2.0 and cant get it to work or see what the problem is...
Here is all of tcpdump gives me when requesting ip from a pc on the network
listening on fxp1, link-type EN10MB (Ethernet), capture size 96 bytes
18:32:24.720265 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:38:58:4a:ca (oui Unknown), length 300
18:32:24.724665 IP pfsense.localdomain.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

vaf0r

Can someone please try to help me out here… :)

clarknova


tcpdump -n -i vr1_vlan102 port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vr1_vlan102, link-type EN10MB (Ethernet), capture size 96 bytes
19:28:11.299677 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:4e:95:d4:62, length 548
19:28:14.298385 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:4e:95:d4:62, length 548
19:28:17.297122 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:4e:95:d4:62, length 548
19:28:20.295950 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:4e:95:d4:62, length 548
19:28:23.294711 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:4e:95:d4:62, length 548
19:28:23.297322 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:e6:ba:ee:61:b9, length 548
19:28:26.296072 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:e6:ba:ee:61:b9, length 548
19:28:29.294869 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:e6:ba:ee:61:b9, length 548
19:28:29.295240 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 48:5b:39:5b:6c:8d, length 548
19:28:32.292808 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 48:5b:39:5b:6c:8d, length 548
19:28:35.292981 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 48:5b:39:5b:6c:8d, length 548
19:28:38.291368 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 48:5b:39:5b:6c:8d, length 548
19:28:41.289809 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 48:5b:39:5b:6c:8d, length 548

Snapshot from November 11, nanobsd. Clients on multiple interfaces are not getting dhcp service despite the service showing as enabled in the web UI. The dhcp server worked right up until today, perhaps until the moment that I added a new interface and then disabled the dhcp server on that interface.

clarknova

Rebooting didn't fix it, updating to the latest firmware didn't fix it. I found the problem in my case though. Here's how I did it, but I can't afford to try to recreate it now as I don't have a disposable system at the moment:

1. Create an interface and enable the dhcp server on it with a valid range. (vr1_vlan51, 192.168.51.254/24, dhcp:192.168.51.11-20)
2. Delete above interface.
3. Create a new interface with a different address from above and disable the dhcp server.*

Some time soon or immediately after this the dhcp server stopped serving on all interfaces. When I looked at the dhcp server settings on the new interface, the radio button showed that the server was active on that interface, and the address range was set to 192.168.51.11-20 which is not on the current subnet of the interface.

I'm not 100% sure this step is exactly how I did it, but if I had enabled dhcp on that interface with an invalid address range, wouldn't it have thrown an error? It's also possible that I never visited the dhcp page for that interface after recreating it in step 3.

vaf0r

@clarknova:

Rebooting didn't fix it, updating to the latest firmware didn't fix it. I found the problem in my case though. Here's how I did it, but I can't afford to try to recreate it now as I don't have a disposable system at the moment:

1. Create an interface and enable the dhcp server on it with a valid range. (vr1_vlan51, 192.168.51.254/24, dhcp:192.168.51.11-20)
2. Delete above interface.
3. Create a new interface with a different address from above and disable the dhcp server.*

Some time soon or immediately after this the dhcp server stopped serving on all interfaces. When I looked at the dhcp server settings on the new interface, the radio button showed that the server was active on that interface, and the address range was set to 192.168.51.11-20 which is not on the current subnet of the interface.

I'm not 100% sure this step is exactly how I did it, but if I had enabled dhcp on that interface with an invalid address range, wouldn't it have thrown an error? It's also possible that I never visited the dhcp page for that interface after recreating it in step 3.

Did u upgrade from 1.2.3 to 2.0? and keept your 1.2.3 settings? or was it a fresh install?
Dont know if my problem is the same like your but i installed from a fresh install upgraded to the latest firmware and config interfaces i can ping and accses the firewall from http but dhcp is not giving ips my dhcpd is enabled. As i had it working in the older version 1.2.3 i think it is a bug that hopefully get solved soon… :)

clarknova

This particular system was never 1.2.3. The original install was a 2.0 snapshot and it's been through a few updates since. In my case the dhcp address range seems to have stayed in the config file when I deleted an OPT interface. when I created a new OPT interface later, the legacy dhcp information for that interface stuck to it, and the address range was at that point invalid.

You may want to check the dhcpd section of your config file for errors that might be causing an issue. You can download just this section ("dhcp server") in the Diagnostics: Backup/Restore section. Mine looks something like this and is working fine at the moment (interfaces omitted for brevity):


 <dhcpd><lan><range><from>192.168.85.51</from>
			<to>192.168.85.60</to></range> 
		 <defaultleasetime><maxleasetime><netmask><failover_peerip><gateway><domain><domainsearchlist><ddnsdomain><tftp><ldap><next-server><filename><rootpath><numberoptions><staticmap><mac>00:1e:8c:83:9b:93</mac>
			<ipaddr>192.168.85.2</ipaddr>
			<hostname>ren</hostname></staticmap></numberoptions></rootpath></filename></next-server></ldap></tftp></ddnsdomain></domainsearchlist></domain></gateway></failover_peerip></netmask></maxleasetime></defaultleasetime></lan></dhcpd>

If you find errors in yours, correct them, save the corrected file, then upload it again. You may have to restart your dhcp server at that point, or just reboot to test.