sendto error: 65
-
stephenw10...thanks for the path. I was able to download it to my Ubuntu desktop.
I've imported the cap file into Wireshark. Now, it's not that I haven't used Wireshark in the past, I mean way past, but in this case for the issue I'm trying to resolve, I'm not sure what I should be looking for.
-
If the pcap shows it is continually broadcasting dhcp requests then it looks like it's something at the other end.
If it stops sending after a while you could be hitting the referenced dhclient bug that required the timeout increase. It will still timeout and fail to restart though if so.
Steve
-
I wrote a Python program a while ago that goes out and checks for internet connectivity every so many seconds. The program writes to a log file when the internet is unreachable. In this particular instance, the internet became unreachable between 07:06am and 07:07am. I've changed the display times in Wireshark to be able to see the dates and times as we would normally see them.
I'm not sure that I'm seeing any entries that says or describes dhcp. I'm looking in the time frame that internet connectivity was lost, just before and after.
After a search for dhcp traffic (udp.port == 68), the only entries I'm seeing is:
20633 2019-11-29 23:25:15.602566 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
52915 2019-11-30 00:25:15.623471 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
69178 2019-11-30 01:25:15.288596 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
84088 2019-11-30 02:25:15.350459 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
100715 2019-11-30 03:25:15.408722 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
116291 2019-11-30 04:25:15.462404 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
167247 2019-11-30 05:25:15.512665 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56f
183374 2019-11-30 06:25:15.560319 138.88.12.1 138.88.12.188 DHCP 334 DHCP ACK - Transaction ID 0xa348e56fThe times seem to correspond hourly to the Protocol timing Timeout I changed to 3600, 1 hour.
-
Well those TCP ACK packets look to be replies from some external site so I'd suggest the WAN was not down at that moment.
I expect to see it start to send DHCP requests if the WAN went down, unless the link actually failed... -
Sorry, I just changed my reply, up two posts. Those were the only DHCP entries I could find. Sorry for the confusion.
-
I just found this post which may be a temporary answer. I haven't read all of it yet.
https://redmine.pfsense.org/issues/9267
After reading, it looks a little too complicated for me to try
. Looks like I'll have to wait for the next pfSense release for this to be fixed. -
Yup, that's the bug we are referring to. The dhcp client fails to handle that error correctly and instead of simply retrying until it gets a reply it just stops. If the cause of that is the upstream device booting slowly for example then simply increasing the timeout there can get past it. But if there is some bigger delay it can be a problem.
Steve
-
stephenw10...Thanks for that information. It's great to know the issue is being addressed. I just hope as Jim Pingle mentioned in the redmine link, it's not much longer now. I just can't wait for it to be resolved. Thanks for the assistance.
-
It just hit me to ask. Since this issue affects the user base of pfSense, have the pfSense developers thought of releasing a fix at least just for this issue before the next version of pfSense is released? This would at least alleviate a lot of restart frustration. Just wondering.
-
In System > Update, would anyone happen to know if the fix for the dhclient is in the "Latest 2.4.x development version (2.4.5)", Latest Base System 2.4.5.a.20101222.1312? I would be willing to install just to fix the issue.
When I login to the terminal, would anyone know what the release/renew command is so I don't have to keep restarting?
Thanks.
-
It doesn't look like it made 11 stable so not in 2.4.5 either:
https://github.com/pfsense/FreeBSD-src/commits/RELENG_2_4_5/sbin/dhclient/dhclient.cSteve
-
So this is really affecting me. Any idea how to do what is mentioned in this post?
https://redmine.pfsense.org/issues/9267 -
You would need to apply those patches, rebuild the binaries on an equivalent FreeBSD system and upload them to pfSense. A non-trivial task.
-
Any ideas on what I can do in the mean time?
-
@newuser2pfsense said in sendto error: 65:
https://forum.netgate.com/topic/96923/pfsense-not-recovering-from-wan-failure
I am having the same issue using 2.5.1-RELEASE
After around 8 hrs of use, I cannot reach internet, neither pfsense through LAN interface
This is happening since I installed the latest version of pfsense
On Status/System Logs/System/Gateways I see this error:
WAN_DHCP 8.8.8.8: Alarm latency 3143us stddev 155us loss 21%I don't see any additional info in the logs that can help
I am using suricata, I wouldn't want to disable it, but I will try to disable service by service to try to find the guilty
Thanks
-
You are seeing the DHCP client timeout and stop requesting a lease?
As shown in the now resolved bug: https://redmine.pfsense.org/issues/9267 ?
If not then you're seeing something different and replying on this thread is just confusing.
Steve
-
This post is deleted! -
Hi
My pfsense is presenting the same sympthons as the others: the "sendto error: 65" error, but as someone pointed out, it is just dpinger showing there is not connectivity
I was using DHCP for WAN. Looking for a workaround I set up a static IP on WAN, and I set up my modem to use another range of IPs, where my WAN IP is not part of. I did that because someone commented that maybe it was due to a DHCP lease problem
But unfurtanately the issue continues happening
One question, those patches that you mentioned, were not already implemented somehow in 2.5.1-RELEASE?
Maybe if I install pfsense in another appliance will solve it
Thanks guys
-
-
@stephenw10 I'm having the same issue on 2.5.2, is that still not fixed in pfsense itself?
