Frequent but random lost carrier drops

Ejeckt

Well-Known Member
Joined
Oct 4, 2011
Messages
341
Hey. Can someone help me make heads or tails of what is going on? I've reported my issue with Axxess and Openserve is supposed to send out a technician, and I'd like to be able to actually know what the issue is and what I can expect from the technician - because I don't want to end up in a situation where the technician tells me there's nothing wrong because it's working when he comes over.

1) At random times, but mostly during the day between 11AM and 6PM I'm losing connection - my (new) ASUS router logs the following:

Nov 5 17:19:04 pppd[12229]: Serial link appears to be disconnected.
Nov 5 17:19:09 WAN Connection: Fail to connect with some issues.
Nov 5 17:19:09 stop_nat_rules: apply the redirect_rules!
Nov 5 17:19:10 pppd[12229]: Connection terminated.
Nov 5 17:19:10 pppd[12229]: Modem hangup
Nov 5 17:19:55 pppd[12229]: Timeout waiting for PADO packets
Nov 5 17:20:00 pppd[12229]: Connected to a0:f3:e4:bb:8d:96 via interface eth0
Nov 5 17:20:00 pppd[12229]: Connect: ppp0 <--> eth0
Nov 5 17:20:03 pppd[12229]: PAP authentication succeeded
Nov 5 17:20:03 pppd[12229]: peer from calling number A0:F3:E4:BB:8D:96 authorized
Nov 5 17:20:03 pppd[12229]: local IP address 197.245.87.xxx
Nov 5 17:20:03 pppd[12229]: remote IP address 197.245.9.xxx
Nov 5 17:20:03 rc_service: ip-up 15112:notify_rc start_firewall
Nov 5 17:20:04 miniupnpd[14971]: shutting down MiniUPnPd
Nov 5 17:20:05 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Nov 5 17:20:05 rc_service: ip-up 15112:notify_rc stop_upnp
Nov 5 17:20:05 rc_service: waitting "start_firewall" via ip-up ...
Nov 5 17:20:05 miniupnpd[15147]: version 1.9 started
Nov 5 17:20:05 miniupnpd[15147]: HTTP listening on port 40712
Nov 5 17:20:05 miniupnpd[15147]: Listening for NAT-PMP/PCP traffic on port 5351
Nov 5 17:20:06 rc_service: ip-up 15112:notify_rc start_upnp
Nov 5 17:20:06 rc_service: waitting "stop_upnp" via ip-up ...
Nov 5 17:20:06 miniupnpd[15147]: shutting down MiniUPnPd
Nov 5 17:20:07 ntp: start NTP update
Nov 5 17:20:07 miniupnpd[15151]: version 1.9 started
Nov 5 17:20:07 miniupnpd[15151]: HTTP listening on port 47025
Nov 5 17:20:07 miniupnpd[15151]: Listening for NAT-PMP/PCP traffic on port 5351

2) On my ONT the PON light blinks while this is happening. It then returns to steady.

3) My ISP access logs report the termination cause as Lost Carrier.

4) As mentioned, times are completely random and I've tested my whole local network to make sure every NIC is behaving. I can't reproduce the disconnect on demand and sometimes it happens every 2 minutes, sometimes I go 2 hours without a break. Don't know how to test if the ONT is faulty.

I suspect I've had this going on for a long time. It happened a few weeks ago but only persisted for 1 day. It's been dragging now for 5 days. Before I got the new ASUS router I had a cheap DLINK that wasn't meant for Fibre anyway, and when it happened there it would bomb the router and I'd have to restart it frequently (as it wouldn't auto-recover like the ASUS) - but ISP logs said termination cause was user-request (hence new router)

I took a video of the time and ONT behaviour and saved the logs (dunno if that will mean anything to the openserve tech). Is there anything you guys can think of that I can still try or what I tell the guy if he says there's nothing wrong because it's working at whichever moment he's checking it?

Hope I explained the issue - not really a networking guy.
 

Syphonx

Expert Member
Joined
Jun 25, 2008
Messages
3,864
Buy some data from another ISP and test account for a few days.
 

savage

Expert Member
Joined
Aug 11, 2003
Messages
2,922
2) On my ONT the PON light blinks while this is happening. It then returns to steady.

When it's flashing and not solid, it's more than likely a issue with the fiber. OS would need to solve this. They should be able to test the fiber and/or ONT device. The sad part is you seem to always just get someone that doesn't bother to check the history of the line, but rather is stuck at not seeing beyond the fact that the light flashed previously, before he arrived.
 
Top