Problem with Dpinger
-
Late last night / early this am I noticed that my internet connection was not working - when I checked - the cable modem status lights looked fine. But when I pulled up the Pfsense admin screens - the gateway showed as down. When I looked in the router log I saw a ton of these: WAN_DHCP 174.49.92.1: sendto error: 65. Also when I looked in the firewall log - I saw a log of these blocks occurring during that same time: WAN 192.168.100.1:67 192.168.100.10:68 UDP and WAN 192.168.100.1:67 255.255.255.255:68 UDP.
At that point I decided to try to restart dpinger - but once dpinger went down it would not restart. I tried to restart it several times - but no luck. I ended up just rebooting the router and that did the trick.
I have had this happen a few times before. Not sure what other logs might help me diagnose this problem. Also not sure why the cable modem was trying to hit a 192.168.100.10 address. My internal network is natted to 192.168.1.x. Router / DHCP server address is 192.168.1.99.
Anyone seen something similar?
-
If Motorola models go offline (cable dead), it will offer 192.168.100.x ips
-
If Motorola models go offline (cable dead), it will offer 192.168.100.x ips
Hmm - perhaps - although I saw no indication of any offline problem on the cable modem itself. At least by the time I got down to where it is located in my basement and took a look at it. It certainly could have gone offline and then reconnected by the time I was looking at it. But the dpinger issue persisted past that point.
Are there logs that I should look at to see why dpinger could not restart successfully? Looking at the logs through the admin ui I wasn't able to find any info that would tell me why dpinger was not able to restart successfully.
-
https://forum.pfsense.org/index.php?topic=104110.0
-
https://forum.pfsense.org/index.php?topic=104110.0
Thanks for that link - I had missed this one in my searches on this problem. Certainly sounds like what I ran into. Currently I have the .1 address in the setting for rejecting the leases from that iP - next time it happens I will see if it is really the .1 address that is responding to the DHCP requests - but I am pretty sure that it is - not not sure why this block setting it not working in my case. FWIW - I am running 2.4.2-RELEASE-p1 (amd64) on a Netgate SG-4860 router. Also will pay attention to the current wan address and will retry the release / renew on the WAN IP to see if that fixes the problem as described in that thread. At least that is easier/faster/less disruptive than what I did by rebooting the router.
-
Also - I noticed that I accidentally posted this in the wrong section - moderator - feel free to move to more appropriate section - like maybe the General Q&A section.