Frequent internet loss - need help figuring out where and why? Maybe pfSense, Modem, ISP, or all 3?
-
I'm not sure where to begin with this, it's been an increasingly frequent reoccurring problem for me the last couple months. It gets worse under load (e.g. uploading files to "the cloud" or streaming video). I have not changed the config for the better part of a year and it was rock solid stable.
Scenario (repeats every 1-10 days):
- internet starts having high latency (~60-100mS compared to ~10mS to anything)
- After unknown period of time, I lose all internet connectivity
- I find the web-GUI unresponsive
- I log in via SSH and see it has no WAN IP and in the logs lots of re0 up/down/up/down and watchdog alerts
- if I restart PHP-FPM I can get back to the web-GUI for a brief period of time but I still can't get it to pull a DHCP IP on the WAN
- I reboot the whole router
- it comes up and appears to work fine, internet fully restored
- I look at the modem (192.168.100.1) and see high numbers of uncorrectable frames on all channels
- I observe pfsense now has a WAN IP and works fine.
What I've tried:
- rebooting cable modem only - no difference, still no WAN IP in pfSense
- used different NIC for WAN interface (Amazon Basics USB3.0 NIC) speculating it was the Realtek chipset, this made no difference but maybe that makes sense because the LAN (also Realtek) works fine to SSH into the router and restart it
- I clean installed both pfSense 2.4.3 (what I'd been on for a long time) and then tried 2.4.4 now that it is out. No difference.
- I have painfully rebuilt my configuration from scratch (vs backup/restore) after a clean install. Again, no difference.
- I have powered down all my ham radio gear (thinking RFI was causing an issue) again, no difference it still dies after a few days.
- I have moved my MoCA LAN bridge to a totally separate run of coax thinking it was interfering with the modem. Again, no change.
- I bought a key tool so I could open up the demarc box on the side of my house and remove/reseat the cable from the cable-co feed. I only have internet so its a straight shot off their pole into the demarc and up to my modem with only a couple barrel connectors (no splits). No difference.
- I have replaced all the cables that I can both coax and ethernet - only ones I have not changed out are in the walls (I rent, not my house) and up the telephone pole (cable-co side). Again, no change.
- I have tried replacing and removing my coax surge protector. No difference either way.
Here's my hardware:
ZOTAC ZBOX C Series CI323 Nano Passive Cooling Mini PC with Intel Celeron N3150 Quad-Core CPU Intel HD Graphics Barebones System with 4GB RAM and 16GB SSD (about 21 months old)
Arris Surfboard SB6193 modem (probably about 18-24 months old)My ISP is Metrocast/Atlantic Broadband and I have 200x15Mbps service (when its working right it achieves about 195x16Mbps)
I saved off /var/log folder as a tar-gzip before rebooting pfSense so I can pull files out but I don't know what to look for at this point - nothing is jumping out at me.
Here are screenshots from my modem:
I'm at my witts end, I have people suggesting I should "just buy a normal router" and I'm at the point I am considering just replacing hardware at random hoping it does something. I'm not sure I want to call my ISP because they will tell me to reboot my modem and plug a computer in "it works what is your problem" and blame my computer/router.
PLEASE help with any ideas?
-
On a hunch, what is the MTU of your WAN connection, and are you seeing any arpresolve errors?
I ran into a problem with a small MTU of 576 being handed out by my friend's ISP's cable modem termination system. In prior versions of pfSense the interface-mtu field passed with the lease was ignored by dhclient. The new dhclient code respects the interface-mtu field, and forces tiny packets, which can break things.
I posted about my experience and the fix here:
https://forum.netgate.com/topic/136089/solved-and-revised-2-4-4-release-arpresolve-can-t-allocate-llinfo-for-gateway-on-interface0-dhcp-mtu-576 -
According to Interfaces > Status my WAN MTU is 1500 currently. I have not modified it so I assume it's using whatever it got from DHCP or default.
I do get some lines like that (which look like it has the IP of either the ISP's gateway or ISP's DHCP server, unsure which) as well as my modem IP at times. I didn't think much of it because sometimes I see that and its still working fine until it starts getting the interface up-down.
Here's a snip from dmesg from when it finished booting until when it died one of the times if that helps.
re0 = WAN
re1 = LAN
Others = VLANS or OpenVPNOrigin="GenuineIntel" Id=0x406c3 Family=0x6 Model=0x4c Stepping=3 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> AMD Features2=0x101<LAHF,Prefetch> Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics padlock0: No ACE support. aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard re1: link state changed to DOWN vlan0: changing name to 're1.2' vlan1: changing name to 're1.3' re0: link state changed to DOWN re1: link state changed to UP re1.2: link state changed to UP re1.3: link state changed to UP re0: link state changed to UP tun1: changing name to 'ovpns1' ovpns1: link state changed to UP tun2: changing name to 'ovpns2' ovpns2: link state changed to UP pflog0: promiscuous mode enabled re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 192.168.100.1 on re0 arpresolve: can't allocate llinfo for 192.168.100.1 on re0 arpresolve: can't allocate llinfo for 192.168.100.1 on re0 arpresolve: can't allocate llinfo for 192.168.100.1 on re0 arpresolve: can't allocate llinfo for 192.168.100.1 on re0 arpresolve: can't allocate llinfo for 192.168.100.1 on re0 ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP -
Also possibly relevant (as I read your thread) I found tips about Realtek issues and I have disabled "Hardware Checksum Offloading" though I saw no difference doing that.
-
Could you take a look at your actual DHCP lease? It will be found in /var/db/dhclient.leases.re0 Does it contain an interface-mtu field?
You might want to anonymize your WAN IP rather than posting it here.
-
@bfeitell said in Frequent internet loss - need help figuring out where and why? Maybe pfSense, Modem, ISP, or all 3?:
var/db/dhclient.leases.re0
Yes - It does look like it contains that field
lease { interface "re0"; fixed-address 74.214.49.x; option subnet-mask 255.255.255.0; option routers 74.214.49.1; option domain-name-servers 173.44.120.56,173.44.120.57; option host-name "pfSense"; option interface-mtu 576; option broadcast-address 255.255.255.255; option dhcp-lease-time 86400; option dhcp-message-type 5; option dhcp-server-identifier 65.175.141.7; renew 2 2018/10/2 14:23:45; rebind 2 2018/10/2 23:23:45; expire 3 2018/10/3 02:23:45; } lease { interface "re0"; fixed-address 74.214.49.x; option subnet-mask 255.255.255.0; option routers 74.214.49.1; option domain-name-servers 173.44.120.56,173.44.120.57; option host-name "pfSense"; option interface-mtu 576; option broadcast-address 255.255.255.255; option dhcp-lease-time 86400; option dhcp-message-type 5; option dhcp-server-identifier 65.175.141.7; renew 2 2018/10/2 15:05:05; rebind 3 2018/10/3 00:05:05; expire 3 2018/10/3 03:05:05; } [2.4.4-RELEASE][root@pfSense.apt]/root:WAN IP...eh, it changes often enough anonymizing the last bit is probably fine.
-
EDITED TO CORRECT POINTER TO CORRECT FIELD IN "Lease Requirements and Requests"
Try the fix I discussed in the prior post I referenced. You are probably hitting the same issue I saw.
"In the "Lease Requirements and Requests" section for WAN DHCP in the field "Option modifiers" add the text without quotes: "supersede interface-mtu 0""
-
I shall give that a shot! Do I need a reboot/reload after that change is made?
Probably be at least 2 weeks until I declare "fixed" but I may know sooner if it dies. Interesting that they would set such a small MTU, I've never really seen anything under 1500 used "in the wild"
-
Please report back your results, especially with regard to whether the 'arpresolve can't allocate llinfo for $GATEWAY' errors go away with the fix in place. The granted lease details won't change, but the default pfSense MTU of 1500 should be in effect after the fix.
-
Maybe I'm still missing something. I don't see that field listed where I expected it to be under Interfaces > WAN
Am I missing something? This is 2.4.4
-
Yes, scroll down a bit more. "Option modifiers" appears below in the "Lease Requirements and Requests" section.
I would reboot, but saving and applying the fix should resolve things. You can check the MTU before and after the fix at the command prompt with 'ifconfig re0'.
-
Ah, I found it as you said under the "Lease Requirements and Requests" heading. I was looking for a keyword heading "Advanced" or checkbox "Advanced". I'll do a reboot for good measure, it seems reasonable enough.
I will certainly report back either way - if it is still having problems or showing those lines or if I think it's fixed after a while.
Thanks!
-
I have edited the post above, and my prior post to reflect the correct location of "Option modifiers" in the "Lease Requirements and Requests" section.
I really think this fix needs to be documented, as the underlying problem causes all sorts of flakiness beyond DHCP renewal/ARP quirks, including the failure of certain web sites, like newyorker.com, to load.
-
Interesting note - prior to the reboot after applying that I had intermittent connectivity and odd entries in my dmesg output.
I think after a reboot it settled out but in case you are interested here is what it showed:
arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to DOWN re0: link state changed to UP nd6_setmtu0: new link MTU on re0 (576) is too small for IPv6 re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0AFAIK my ISP does not support IPv6 and I don't appear to have any IPv6 connectivity. I'm assuming it just got confused with changing things until it was rebooted.
-
Yes, I think this pretty clearly shows you hit this 576 MTU oddity. For my friend it broke The New Yorker website, and iHeart Radio. I was more concerned with the firewall unpredictably falling off the net. It turned out that the two problems had the same root cause of a too small MTU.
-
Not sure why the forum thinks I'm spamming posting the output of ifconfig but it does.
After a reboot its still showing ifconfig re0 with mtu 576.
Any thoughts? Maybe I need to manually enter 1500 in the WAN settings?
-
Please post a screen shot of the "Lease Requirements and Requests" as you have it filled out. If you have the supersede statement in there correctly, it may be a quirk of the (re) driver interacting with dhclient. Setting 1500 explicitly for the MTU might fix it, but I would try a cold boot after confirming you have the incantation entered correctly. In the meanwhile, I will double check how I have it set on my friend's machine...
-
Just re-re-re read your post and you said without quotes. Maybe I should have gone to bed while it was still yesterday. :)
Took out my " " from the option modifiers, rebooted AGAIN and now I see mtu 1500 in ifconfig re0!
Seems like a good sign that its at least now doing what you (and I) was expecting.
-
Excellent! Please follow up on this if it is fixed. I think that Netgate needs to put this in the formal documentation. It is a sneaky little quirk from upstream. pfSense, and dhclient are doing the right thing following the DHCP lease parameters issued, but the cable modem hardware from the ISP is giving out bad settings for setting up the connection.
-
Negative success, just had total outage tonight. Had to reboot pfsense to get it to come back online.
Origin="GenuineIntel" Id=0x406c3 Family=0x6 Model=0x4c Stepping=3 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> AMD Features2=0x101<LAHF,Prefetch> Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics padlock0: No ACE support. aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard re1: link state changed to DOWN vlan0: changing name to 're1.2' vlan1: changing name to 're1.3' re0: link state changed to DOWN re1: link state changed to UP re1.2: link state changed to UP re1.3: link state changed to UP re0: link state changed to UP tun1: changing name to 'ovpns1' ovpns1: link state changed to UP tun2: changing name to 'ovpns2' ovpns2: link state changed to UP pflog0: promiscuous mode enabled ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 re0: link state changed to DOWN re0: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 ugen0.2: <American Power Conversion Back-UPS ES 750 FW841.I3 .D USB FWI3> at usbus0 (disconnected) ugen0.2: <American Power Conversion Back-UPS ES 750 FW841.I3 .D USB FWI3> at usbus0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 (disconnected) ugen0.5: <vendor 0x8087 product 0x07dc> at usbus0 re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP ovpns1: link state changed to DOWN ovpns1: link state changed to UP ovpns2: link state changed to DOWN ovpns2: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP arpresolve: can't allocate llinfo for 74.214.49.1 on re0 re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP re0: watchdog timeout re0: link state changed to DOWN
Any other thoughts? I see my modem errors are creeping up again (tho only in the few-hundreds this time, not up to 1000 yet)
