WAN DHCP Problem
-
If I goggle it, there are lots of posts from people with cable line quality issues so it could be that, I will log a call with the cable supplier and see what they say.
But the way that error reads to me is that it doesn't like something about the request sent from pfsense?
-
I see that other people with similar problems (as you say there are many) have the date/time on the modem logs completely wrong. Is it possible that pfSense is requesting a dhcp lease with a timestamp that is way in future from the modems point of view? I.e. excessive time discrepancy causes dhcp to fail.
Steve
-
Yeah I saw that too, I will see if I can sync pfsense with the cable modems time, I also think there might be something like them blocking too many/frequent DHCP requests going on.
-
Well it seems to have been ok for 24 hours now but that is the annoying thing with this problem, you think you have it fixed for days/weeks then it resurfaces to bite you! :(
-
I knew it was too good to be true!!
It has just started again, in the sk1_error_output log file I get this, it seems to try twice then the interface goes down for about 1 second, not sure if that is the cable modem or PFsense taking it down then it loops again:
sk1: no link ….. got link
dhclient: PREINIT
DHCPREQUEST on sk1 to 255.255.255.255 port 67
DHCPREQUEST on sk1 to 255.255.255.255 port 67The only way to get it working again is to reboot pfsense :(
A reboot of the cable modem does not fix it, any more ideas guys?
-
I wonder if it is timing out waiting for a reply as there doesn't seem to be much of a delay between DHCPREQUEST attempts.
Is it possible to change the dhclient wait time?
-
I also seem to get stuck in this loop of doom if I reboot or uplug the cable modem, the only way to get it back is to reboot pfsense
When it happens here is the pfsense log.
This just loops constantly:
Apr 13 19:56:31 kernel: sk1: link state changed to DOWN
Apr 13 19:56:31 check_reload_status: Linkup starting sk1
Apr 13 19:56:31 php: : HOTPLUG: Configuring interface opt1
Apr 13 19:56:31 php: : DEVD Ethernet attached event for opt1
Apr 13 19:56:27 php: : The command '/sbin/dhclient -c /var/etc/dhclient_opt1.conf sk1 > /tmp/sk1_output > /tmp/sk1_error_output' returned exit code '15', the output was ''
Apr 13 19:56:27 dhclient[16283]: exiting.
Apr 13 19:56:27 dhclient[16283]: exiting.
Apr 13 19:56:27 dhclient[16283]: connection closed
Apr 13 19:56:27 dhclient[16283]: connection closed
Apr 13 19:56:27 php: : DEVD Ethernet detached event for opt1
Apr 13 19:56:27 dhclient[31620]: DHCPREQUEST on sk1 to 255.255.255.255 port 67
Apr 13 19:56:26 dhclient[31620]: DHCPREQUEST on sk1 to 255.255.255.255 port 67
Apr 13 19:56:26 dhclient: PREINIT
Apr 13 19:56:25 kernel: sk1: link state changed to UP
Apr 13 19:56:25 check_reload_status: Linkup starting sk1 -
Right hopefully a bit of success!
I got it in to a position where it was stuck in the loop of doom
Then I changed the interface from auto select to 1000 Base T full duplex
That brought it out of its loop of death and is working without a reboot!
So fingers crossed this is now fixed! :D
I think there is a problem with it trying to negotiate speed/duplex and get an IP at the same time, possibly only a problem with certain cable modems?
-
Hmm, seems odd.
When you change the connection type like that the interface is brought down and back up so that may have triggered the reconnect.
Good luck!Steve
-
yeah that's true, but the connection was going up and down like a yoyo before unless it is a full reset of the connection as opposed to just the link state?
-
The link state is reported by the driver to the OS in order to trigger the DHCP client etc. Bringing the interface up and down is more than that. You can test it easily enough if it starts flapping again:
ifconfig sk1 down ifconfig sk1 upSteve
-
Ok thanks I will keep an eye on it and keep you posted.
I really hope this is fixed, I love pfSense but it is driving me absolutely balmy almost to the point I want to scrap this FW and get something else :(
-
Well that does indeed seemed to have fixed it! fingers crossed :)
-
I have this EXACT same issue. It only affects DHCP on the WAN. My static interfaces are not affected. Only a reboot will correct it.
I too found the manual duplex work around, and that does seem to work. However, here is the problem..
So, you force pfsense to a manual duplex setting. You better hope you can do the same on the cable modem, or you WILL have a duplex mismatch. In my case, I cannot manually set the duplex on my cable modem. Since the cable modem only supports auto negotiation on its interface, the instant you manually set your duplex in pfsense the cable modem's NIC will default to half duplex. So, you have 100 full duplex set in pfsense, and the cable modem will be running at 100 half duplex. This is by design.
I'm left with two options here.. a duplex mismatch or force everything to 100 half duplex. This isn't a great work around.
Now, what I said works a little different with gig links (I'm limited to 10/100), but the bottom line is that you should always set auto or manual duplex on both ends. You should never set auto on one end, and manual on the other.
I'd love to know what is causing this so I don't have to fool with manually adjusting my duplex settings.
-
The link state is reported by the driver to the OS in order to trigger the DHCP client etc. Bringing the interface up and down is more than that. You can test it easily enough if it starts flapping again:
ifconfig sk1 down ifconfig sk1 upSteve
I tried this the last time the problem occurred, and it made no difference. I'd down the interface, but something kept automatically bringing it back up - and the link state kept flapping.
-
It's a NIC driver issue that's outside of our control, may want to try a 2.1 snapshot since it has a newer base OS where that may not be an issue. See the 2.1 board heree.
-
Thanks for the info. I've been searching for problems related to the VR4 driver which supports the VT6105M NIC on 8.1, but I'm coming up empty. Can you share where you found that? I'm curious as to the exact issue, and in what release it's fixed.
-
An earlier post reported this problem on sk interfaces. Are you seeing a similar problem on vr interfaces?
-
I have the same issue with my Cable Modem and em interface when I do mac address cloning. Interface flaps up and down sometimes. I don't know what triggers it. Now that I have selected 100BT Half Duplex, it seems to be working good. I don't think it is as simple as driver issues in FreeBSD.
-
Did you ever try JimP's suggestion, here?
Steve
