I’ve literally tried everything, downgrading to an older version (2.4.5), going back to 2.5.1, back to 2.5.2 even went and upgraded to the 2.6.x DEV version (which I’m still running today.) Try as a may, my internet connection disconnected every 30 minutes on the clock.
Click here to jump to my solution
Debugging the issue was kind of hard, all I had to go was this pattern:
Oct 15 13:27:18 router dpinger[50793]: WANIPTV_DHCP 10.10.56.1: sendto error: 65
Oct 15 13:27:20 router dpinger[50793]: WANIPTV_DHCP 10.10.56.1: Alarm latency 0us stddev 0us loss 100%
Oct 15 13:27:21 router dpinger[67943]: send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 45.146.56.1 identifier "WAN_DHCP "
Oct 15 13:27:21 router dpinger[68139]: send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.10.56.1 identifier "WANIPTV_DHCP "
Oct 15 13:27:21 router dpinger[68139]: WANIPTV_DHCP 10.10.56.1: sendto error: 65
Oct 15 13:27:22 router dpinger[71301]: send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 45.146.56.1 identifier "WAN_DHCP "
Oct 15 13:27:22 router dpinger[71688]: send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.10.56.1 identifier "WANIPTV_DHCP "
Oct 15 13:27:22 router dpinger[71688]: WANIPTV_DHCP 10.10.56.1: sendto error: 65
Oct 15 13:27:24 router dpinger[71688]: WANIPTV_DHCP 10.10.56.1: Alarm latency 0us stddev 0us loss 100%
Oct 15 13:57:37 router dpinger[71301]: WAN_DHCP 45.146.56.1: Alarm latency 505us stddev 27us loss 22%
What is clear about this pattern is that we lose connection to the default gateway (45.146.56.1) every 30 minutes on the clock, I’ve removed a lot of excess lines, but the log continues on like this. Moreover, in the dashboard of pfSense you can see that the gateway is highlighted in red, claiming it is offline, but that didn’t make any sense since my connection on my old consumer router kept on working without a problem.
Attempted fixes, which didn’t work
I’ve tried debugging the problem by fixing things one by one, starting with putting the gateway in always online mode, which ofcourse didn’t work… thus I tried changing the IP address dpinger attempts to ping to 1.1.1.1 as this server always replies extremely fast (since Cloudflare is located within 1ms of most internet connections.)
After a while it was clear to me that the timings were incorrect in the new default settings of pfSense, at least for my provider, thus I went ahead and changed those trying to get it right. In the end I opted for the FreeBSD default timing. You can do this at Interfaces > WAN > DHCP Client Configuration there you enable Advanced Configuration and then click on Presets > FreeBSD default (which is better than the pfSense defaults for my provider.)
Still not having solved the problem I decided to manually install an older binary version of dpinger, which I pulled from the pfSense GitHub repo, this also didn’t solve the WAN connection being dropped by dpinger. Moving on I knew for sure that I was facing a DHCP issue, so I tried replacing the dhclient-script and even went to the trouble of using an older binary version of dhclient which also did not fix any of my problems.
Eventually I even thought that it was a hardware problem, so I went out and bought a new card (Intel DA520-X2) again, but to my surprise, the problem persisted and my connection kept getting dropped. Eventually I decided to attempt manually refreshing my lease and this finally worked! thus I stumbled upon the solution which I am now sharing with the world as I hope others can benefit from this too.
Solution
I’ve solved my internet connectivity problems by adding a cronjob in the shell which does a DHCP query on my WAN interfaces every 5 minutes, of every hour, every day, every month, every day of the week as follows:
*/5 * * * * killall dhclient; dhclient ix0.34; dhclient ix0.4
It was easy to implement via the shell, I’m assuming you know how to do this, but if not, try to follow these steps after you’ve entered the BSD terminal as the admin user.
- crontab -e
- <press key: i>
- <copy/paste rule above, don’t forget to change to your adapters, e.g. re1>
- <press key: esc>
- : x
- <press key: enter>
You should have no more problems with your internet connection, if you had the exact same problem as me. Ofcourse I’ve tested this solution manually first by running the command in the terminal first before I put I made a cronjob.
Eventually I found that the true issue was caused by a missing directory (/var/run/dhclient) creating this directory as the admin user ( mkdir /var/run/dhclient ) with the default rights also seemed to do the trick for me, I commented out the inital crontab, but ofcourse you can decide which of these two routes you want to go.
Hope this helps some of you out there.
Final words
Since I am an ICT specialist, I needed to get to the bottom of this problem, I just had to know why this happened.
I’ve done my research and found out that the provider BNG router (Google: BNG/BRAS if you don’t know what this is) leases out address at 1800 second intervals, this was obvious when I used Wireshark and sniffed out their traffic, basically what happened in my case was that my pfSense box didn’t check back in (in time) with my provider, thus the BNG decided to forget and close the session between my ISP and me as the lease time had expired after 30 minutes, meaning that no traffic was able to flow back until pfSense requested an IP address again.
My box is directly connected to the ISP by means of a single mode simplex fiber connected to a BiDi SFP optic housed in a NIC in the form a PCIe x8 Intel X520-DA2 card.
Comments are closed