pfSense not Reconnecting Automatically
-
I have been having a number of intermittent connectivity problems, and I am wondering if I have a misconfiguration error or I have found a problem with pfSense, or it's purely an ISP issue.
I woke up this morning to no internet. I started with rebooting cable modem/pfSense but pfSense did not reconnect, so I dug into the modem interface looking for clues and found the info included in this post.
I finally got reconnected by doing ifconfig ifdown/ifup em0 (wan). I was then able to ping 8.8.8.8 and after a minute or two the pfSense dashboard showed connectivity had been restored.
The CM-MAC is the mac address printed on the cable modem and not my equipment.
Can someone tell me what these messages mean?
(If it helps I am on Rogers (Canada) and the modem is a CODA-4582U. I have IPv6 disabled on all interfaces.)
Should I be looking at a modem swap from Rogers or is this totally an upstream error?Any input much appreciated.
Status DOCSIS Logs The DOCSIS event logs are shown here -------------------------------------------------------------------------------- No. || Time || Type || Priority || Event || -------------------------------------------------------------------------------- 1 || 11/19/2020 16:02:57 || 90000000 || Warning || MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=ac:20:2e:xx:xx:xx;CMTS-MAC=00:17:10:yy:yy:yy;CM-QOS=1.1;CM-VER=3.1; || -------------------------------------------------------------------------------- 2 || 11/19/2020 16:03:01 || 73050400 || Warning || REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=ac:20:2e:xx:xx:xx;CMTS-MAC=00:17:10:yy:yy:yy;CM-QOS=1.1;CM-VER=3.1; || -------------------------------------------------------------------------------- 3 || 11/19/2020 16:03:08 || 66030111 || Alert || CM Certificate Error;CM-MAC=ac:20:2e:xx:xx:xx;CMTS-MAC=00:17:10:yy:yy:yy;CM-QOS=1.1;CM-VER=3.1; || -------------------------------------------------------------------------------- -
Those messages indicate a temporary upstream problem in the cable system. Here is a link that describes the MIMO message in your log snippet: https://www.speedguide.net/faq/what-does-the-mimo-event-mimo-log-message-mean-393.
When your cable modem loses sync with the headend CMTS, it will usually default to issuing clients connected to its LAN port (like your pfSense firewall's WAN interface) an IP address from the 192.168.100.0/24 subnet. That subnet is not routable on the internet. When the modem resyncs with the CMTS, it should break out of the private IP mode, issue a DHCP renew sequence to pfSense, and pfSense should then pick up its valid public WAN IP coming down to your cable modem from the CMTS. But sometimes this resync does not work until you physically bounce the pfSense interface.
Most of us with cable modems tell pfSense to ignore any DHCP offers from the cable modem's default IP (that 192.168.100.1 address). You configure this using the Reject Leases From box down in the DHCP Client Configuration section of the WAN Interface setup tab (INTERFACES > WAN).
-
@bmeeks said in pfSense not Reconnecting Automatically:
When the modem resyncs with the CMTS, it should break out of the private IP mode, issue a DHCP renew sequence to pfSense, and pfSense should then pick up its valid public WAN IP coming down to your cable modem from the CMTS.
The DHCP renew sequence is initiated by the client == pfSense.
IMHO, the DHCP server (the modem) can't signal devices on it's LAN to tell them that they have to 'redo' their leases.
It's a client initiative protocol only.What the modem could do : as soon as a 'real' WAN IP is available because the modem connected, it should take it's LAN port down and up, which forces the clients (pfSense) to activate it's DHCP client to ask a new IP - it will be a usable WAN IP.
Next best :
Checkout out these DHCP Client options (on the WAN interface of pfSense ) : Visit DHCP Client Configuration and check the Advanced Configuration option.
Now you have these :
at your disposal.
The "Reject leases from" is also very usefull.
-
@bmeeks said in pfSense not Reconnecting Automatically:
Those messages indicate a temporary upstream problem in the cable system. Here is a link that describes the MIMO message in you log snippet: https://www.speedguide.net/faq/what-does-the-mimo-event-mimo-log-message-mean-393.
When your cable modem loses sync with the headend CMTS, it will usually default to issuing clients connected to its LAN port (like your pfSense firewall's WAN interface) an IP address from the 192.168.100.0/24 subnet. That subnet is not routable on the internet. When the modem resyncs with the CMTS, it should break out of the private IP mode, issue a DHCP renew sequence to pfSense, and pfSense should then pick up its valid public WAN IP coming down to your cable modem from the CMTS. But sometimes this resync does not work until you physically bounce the pfSense interface.
Most of us with cable modems tell pfSense to ignore any DHCP offers from the cable modem's default IP (that 192.168.100.1 address). You configure this using the Reject Leases From box down in the DHCP Client Configuration section of the WAN Interface setup tab (INTERFACES > WAN).
Thanks @bmeeks and @Gertjan... I've been struggling with this off and on for several months... fine for a month or so, then I get a few problems and then it goes away again. So it's likely upstream issues, but having said that if I can configure pfSense to recover without manual intervention that would be great.
I beleve it wa @Gertjan that recommended "reject leases", and I had the following configured at the time of the outage: 192.168.100.1,192.168.0.1
@Gertjan said in pfSense not Reconnecting Automatically:
@bmeeks said in pfSense not Reconnecting Automatically:
When the modem resyncs with the CMTS, it should break out of the private IP mode, issue a DHCP renew sequence to pfSense, and pfSense should then pick up its valid public WAN IP coming down to your cable modem from the CMTS.
The DHCP renew sequence is initiated by the client == pfSense.
IMHO, the DHCP server (the modem) can't signal devices on it's LAN to tell them that they have to 'redo' their leases.
It's a client initiative protocol only.What the modem could do : as soon as a 'real' WAN IP is available because the modem connected, it should take it's LAN port down and up, which forces the clients (pfSense) to activate it's DHCP client to ask a new IP - it will be a usable WAN IP.
Next best :
Checkout out these DHCP Client options (on the WAN interface of pfSense ) : Visit DHCP Client Configuration and check the Advanced Configuration option.
Now you have these :
at your disposal.
The "Reject leases from" is also very usefull.
This looks promising... can you offer any suggestions as to what parameters/values I should configure?
I read this https://www.freebsd.org/cgi/man.cgi?query=dhclient.conf&sektion=5#PROTOCOL_TIMING, and I suspect the problem is that pfSense is not immediately getting a response from DHCP, but the lease that was valid before the failure still has time on it, so pfSense doesn't keep trying. IIUC leases are 7 days, and even if they keep the same address, the modem must go though an authentication process if it drops off the network.
Any suggestions would be much appreciated.
-
I had a flaky cable modem connection a few years ago right after I switched over from DSL. During that time putting the cable modem's 192.168.100.1 IP address in the "Reject Leases From" box worked well enough. But there were still times when a physical "up/down" or forced Renew cycle was needed on the pfSense side.
If this happens often, then lean on your cable provider to help out on their plant side. In my case, two things helped big time.
The first was I purchased my own bi-directional CATV ampliflier and put it at the base of the pole on the street where my drop comes from. I have underground service from the pole on the street to my house. It's over 300 feet of underground cable, so there is a fair amount of signal loss in that much coax at the 500 MHz and up frequencies used for the downstream DOCSIS signals. So the bi-directional amp helped a lot. It amplifies in both directions (upstream and downstream signals). I can't remember the name and over the years it has weathered to the extent the label on the box is not readable. It is mounted outdoors at the base of the power pole. It is designed for outdoor use and is powered over the coax.
The second thing that helped was my cable provider eventually reworked some of their outside plant in my neighborhood when they bumped up their speed oferrings. Since they did that, I've had practically no outages unless they do maintenance in the early morning hours.
-
@bmeeks said in pfSense not Reconnecting Automatically:
I had a flaky cable modem connection a few years ago right after I switched over from DSL. During that time putting the cable modem's 192.168.100.1 IP address in the "Reject Leases From" box worked well enough. But there were still times when a physical "up/down" or forced Renew cycle was needed on the pfSense side.
If this happens often, then lean on your cable provider to help out on their plant side. In my case, two things helped big time.
The first was I purchased my own bi-directional CATV ampliflier and put it at the base of the pole on the street where my drop comes from. I have underground service from the pole on the street to my house. It's over 300 feet of underground cable, so there is a fair amount of signal loss in that much coax at the 500 MHz and up frequencies used for the downstream DOCSIS signals. So the bi-directional amp helped a lot. It amplifies in both directions (upstream and downstream signals). I can't remember the name and over the years it has weathered to the extent the label on the box is not readable. It is mounted outdoors at the base of the power pole. It is designed for outdoor use and is powered over the coax.
The second thing that helped was my cable provider eventually reworked some of their outside plant in my neighborhood when they bumped up their speed oferrings. Since they did that, I've had practically no outages unless they do maintenance in the early morning hours.
@bmeeks Thanks... I don't think my issue is signal strength, I think the issue is pfSense reconnecting after maintenance, or sometimes when the lease renews.
I have been rebooting, both the modem/pfsense, but I'm wondering if ifconfig ifdown && ifconfig ifup would do the trick. Is this enough to force release/renew of a lease?
From what I can see DHCP and sometimes DNS get confused after an outage and don't recover automatically.
When this happens the GUI is very very slow. Most of the time, I end up logging in with SSH and rebooting from the menu. If there is any data I could gather for the developers to improve fault tolerance/work around more quickly I'm open to suggestions.
-
When I was frequently having the problem, before I put the cable modem's private IP in the "Reject Leases From" field, I could usually get things working again using the "Release" button for my WAN on the STATUS > INTERFACES tab. There is also a checkbox there for "Relinquish Lease".
Honestly, since I've put the cable modem's IP in the "Reject Leases From" field I've never really had to do much (at least I don't remember the last time I had to manually intervene). I've had a few extended cable outages caused by power failures. The most recent one was maybe close to two years back when a driver drifted off to sleep and took out a power pole up the street knocking out power and the cable signal for several hours. Took a while for the power and cable guys to replace the pole and put the lines back in place. I have a fairly stout UPS for my cable modem and firewall and neither went down during the outage. I verified by looking at the logs when things came back. My firewall just kept cycling the WAN interface with DHCP trying to get an IP. Since I had the modem's private IP blocked, and the modem couldn't see the CMTS to get synced and obtain a proper IP to present to pfSense via the CMTS, pfSense just kept issuing DHCP requests over and over. Eventually, when the cable signal returned, the modem synced, pfSense got my public IP and things automatically returned to normal.
I realize I may not be offering much help, but that setting appears to work for me now. My modem is an Arris one, in case that matters.
It's possible the
unboundDNS daemon on pfSense might get confused if the WAN interface were to drop out and the daemon is listening on all interfaces. I use a DNS server from Active Directory on my LAN and so don't useunboundfor anything. -
@guardian said in pfSense not Reconnecting Automatically:
@bmeeks said in pfSense not Reconnecting Automatically:
I had a flaky cable modem connection a few years ago right after I switched over from DSL. During that time putting the cable modem's 192.168.100.1 IP address in the "Reject Leases From" box worked well enough. But there were still times when a physical "up/down" or forced Renew cycle was needed on the pfSense side.
This one I have done, and I think it improved the matters somewhat. I think the issue may be either unbound being confused as you suggest or too long a period of time (for pfSense to understand) between the ethernet port on the cable modem becoming active and the DNS responding. (This is a guess, but I think it's an accurate one.)
@bmeeks said in pfSense not Reconnecting Automatically:
It's possible the
unboundDNS daemon on pfSense might get confused if the WAN interface were to drop out and the daemon is listening on all interfaces. I use a DNS server from Active Directory on my LAN and so don't useunboundfor anything.Unfortunately I use unbound for DNS on my entire network. I'm wondering if there is a way to restart it from the shell?
Does ifconfig ifdown/ifup clear things up with unbound? It's really disruptive having to reboot pfSense as that can require reboot of some client computers. -
