nitrus,

Any possiblity of a patch or hack on 1.2 release?

look like it worked after all…i have other bug but its not pfsense and/or dhcp related

thanks a lot

:-pfsense :- for life !!!!!!

:)

Did you clean /var/dhcpd/var/db/dhcpd.leases~  and /var/dhcpd/var/db/dhcpd.leases  as suggested in the linked thread?
The problem should go away then.

Great and thanks again for the quick response.
After some searches, I believe the message is harmless as you've pointed out.

In our case, we set our dhcp lease to a very short period  (600 sec - 10min), so the client machine may be in sleep mode/power save mode and wake up trying to use the previous assigned IP and hence the system rejects it.

The livecd has a dhcp server running at lan by default. This is not a problem. It must have been something welse but I'm glad you got it working somehow.

Set this one up in the lab and banged on it (I was pretty sure I wasn't just doing it wrong).
Here's what I found:
The advskew check only goes wrong when there are type 'other' VIPs on the box.
I have several 'other' VIPs on the WAN, and when I deleted these, the DHCP config on the backup unit correctly set itself to secondary.
This is however, a bad solution for the production system, as the 'other' VIPs are used to failover IPs that are on additional subnets assigned to the customer (that's the subject of another rambling post).

Thanks, commited.

In the future please submit patches through this process http://devwiki.pfsense.org/SubmittingPatches

Please show us an "ipconfig /all" (if these are windows machines) from one of your clients and show us the firewallrules you added for your clients interface. Cabling seems to be ok as you can ping the clients from the pfSense.

No, you did not mis-understand for the most part.  You are just failing to see that DJBDns is in 2 parts:  TinyDNS and DNSCache.  We only run TinyDNS in the dnsserver and use dnsmasq for the DNS Forwarder.

Thanks for the pointer to dns-server.  Perhaps that will do the job.

tested it out, it works

thanks alot

Any news on this?

@jahonix:

Have those machines been assigned a DHCP lease dynamically from the pool before the MAC got a static mapping (with a different IP?

I have the exact same messages in my log, and I think that I also assigned a dynamic address to the device before it got a static one.
I've tried to remove it from the lease file, restarting the DHCP server, but nothing seems to work.

How do you solve this?

[edit]
I should've looked a bit more carefully on the forum, the solution is in this thread:
[/edit]

5 days since I upgraded to 1.2RC4 … 
All of sudden today, my pfsense box stop responding.
At the console, I see this message repeated:

xl0:  connection watch dog time-out

Tried to switch to another virtual console but nothing.  I hit the power button, pfsense started the shutdown process and power off.
I boot the box again. 
I did not setup remote syslog before therefore I couldn't see what had happen.  Remote syslog is now setup & I'll monitor the box...
I found several threads regarding timeout issue under heavy load but that was a while back.  Not sure if that is the case here.

note: xl0 is the LAN interface.

edit: caught this in syslog

Jan 23 14:22:16 kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes
Jan 23 14:22:16 kernel: xl0: transmission error: 90

edit2:  sorry, I shouldn't put this here. I will start a new post in hardware section.

if you edit /usr/local/www/diag_dhcp_leases.php there is a function in the middle that removes duplicates from the array.

Try commenting that function out and see if the lease shows up then.