Packet loss and dropouts - can it be router?

[Simon]

I've been on this forum for nearly 10 years, and I still don't understand most of this stuff.  I'm getting seemingly random packet loss and dropouts, as can be seen in my TBB monitor below.  My initial question is, as this appears on the TBB monitor, is this happening outside of my network, or could it be my router which is at fault?

[zappaDPJ]

I'm no expert but I'd want to see more graphs because that doesn't look like a typical pattern of PL, it looks more like a one off event. Does this happen regularly?

[Simon]

Quite regularly, yes.  At least once a day, on average.  Initially, I thought it was an issue with my wifi, but that wouldn't follow as it happens when I'm connected via a cable as well.

[Lance]

The TBB monitor works by pinging your router so regardless of how (or even if) you are connected the router should respond given that it is in theory connected all the time.

Could it be your router? Well, possibly given if the router doesn't respond or sends an unrecognisable response that would be recorded as a dropped package. However, I would suggest that outside interference would be a more likely cause. Given you're on ADSL still, a burst of noise on the line is more likely to have a greater affect on the connection with the result being either the connection dropping or at least being right on the verge of dropping.

Easiest way of course is to try a different router. 

[Simon]

Well, this actually is a different router.  I had a Billion 7800DXL, but there were two things with that.  Firstly, the WiFi coverage wasn't great, and secondly, I had problems a while back with complete loss of connection on several occasions.  IDNet couldn't find a solution, although they did acknowledge at the time, that the problem looked to be with the exchange, or some other outside factor.  In the end, they suggested going on to PPPoE, rather than PPPoA, and that seemed to resolve the issue.

This was some time back, and recently, I came across an Asus N55U for a silly price on eBay, so thought I'd give it a try.   It virtually set itself up, and you could choose your ISP from a drop down list, in which IDNet was included, so I can only assume that all the settings are correct, but the settings look quite familiar.  It is, however, now back on PPPoA, but this issue isn't the same as before, in that I'm not totally losing DSL, at least, not for more than a minute or two.  So, I don't really know if this is the same issue as before, only presenting differently due to the different router, or it's something else.

[Simon]

Having Googled a bit, it seems there are several pointers to a firmware issue with the Asus N55U, so I have reset the Billion to factory settings, and am now using that again, so we will see if that improves things, or whether the old problem with the Billion will resurface.

[zappaDPJ]

That's interesting, about four hours after the swap you appear to have had a re-sync resulting in a noticeable drop in latency.

[Simon]

Well, although I didn't notice it at the time, it appears there's been another dropout this evening:

Code Select Expand

Apr 10 19:58:17 daemon crit kernel: Line 0: ADSL link down
Apr 10 19:58:18 daemon warn kernel: bcmxtmcfg: XTM Link Information, port = 0, State = DOWN, Service Support = ATM
Apr 10 19:58:18 daemon warn kernel: bcmxtmrt: DSD(8cfed45c) - 128
Apr 10 19:58:18 daemon warn kernel: HOST XTM tx ch 0 disabled.
Apr 10 19:58:18 daemon warn kernel: bcmxtmcfg: Connection DOWN, LinkActiveStatus=0x0
Apr 10 19:58:21 daemon notice syslog: pppd:Terminating on signal 20.
Apr 10 19:58:21 daemon crit syslog: Clear IP addresses.  PPP connection DOWN.
Apr 10 19:58:21 daemon crit syslog: Clear IP addresses.  Connection DOWN.
Apr 10 19:58:35 daemon crit kernel: Line 0: ADSL G.992 started
Apr 10 19:58:39 daemon crit kernel: Line 0: ADSL G.992 channel analysis
Apr 10 19:58:45 daemon crit kernel: Line 0: ADSL G.992 message exchange
Apr 10 19:58:46 daemon crit kernel: Line 0: ADSL link down
Apr 10 19:59:03 daemon crit kernel: Line 0: ADSL G.992 started
Apr 10 19:59:07 daemon crit kernel: Line 0: ADSL G.992 channel analysis
Apr 10 19:59:14 daemon crit kernel: Line 0: ADSL G.992 message exchange
Apr 10 19:59:15 daemon crit kernel: Line 0: ADSL link up, Bearer 0, us=1256, ds=9091
Apr 10 19:59:15 daemon warn kernel: bcmxtmcfg: XTM Link Information, port = 0, State = UP, Service Support = ATM
Apr 10 19:59:15 daemon warn kernel: bcmxtmrt: MAC address: 00 04 ed f4 75 90
Apr 10 19:59:15 daemon warn kernel: [DoCreateDeviceReq.3269]: register_netdev
Apr 10 19:59:15 daemon warn kernel: [DoCreateDeviceReq.3271]: register_netdev done
Apr 10 19:59:15 daemon warn kernel: [FAP0] xtmCreateDevice : devId 0, encapType 1, headerLen 0
Apr 10 19:59:15 daemon warn kernel: bcmxtmrt: DSD(8a54a4bc) - 128
Apr 10 19:59:15 daemon warn kernel: XTM Init: 400 tx BDs at 0xaf908000
Apr 10 19:59:15 daemon warn kernel: bcmxtmcfg: Connection UP, LinkActiveStatus=0x1, US=1256000, DS=9091000
Apr 10 19:59:15 daemon warn kernel: [FAP0] xtmLinkUp : devId 0, matchId 0
Apr 10 19:59:16 daemon notice syslog: pppd:cms logging initialized.
Apr 10 19:59:16 daemon notice syslog: pppd:PPPoATM setdevname_pppoatm
Apr 10 19:59:16 daemon notice syslog: pppd:PPPoATM setdevname_pppoatm - SUCCESS
Apr 10 19:59:16 daemon notice syslog: pppd 2.4.1 started by admin, uid 0
Apr 10 19:59:16 daemon notice syslog: PPP: Start to connect ...
Apr 10 19:59:16 daemon warn kernel: netdev path : pppoa0
Apr 10 19:59:16 daemon info kernel:  -> atm0
Apr 10 19:59:16 daemon notice syslog: pppd:Using interface pppoa0
Apr 10 19:59:16 daemon notice syslog: pppd:Connect: pppoa0 <-->
Apr 10 19:59:25 daemon notice syslog: pppd:LCP: timeout sending Config-Requests
Apr 10 19:59:25 daemon notice syslog: pppd:Connection terminated.
Apr 10 19:59:28 daemon notice syslog: PPP: Start to connect ...
Apr 10 19:59:28 daemon warn kernel: netdev path : pppoa0
Apr 10 19:59:28 daemon info kernel:  -> atm0
Apr 10 19:59:28 daemon notice syslog: pppd:Using interface pppoa0
Apr 10 19:59:28 daemon notice syslog: pppd:Connect: pppoa0 <-->
Apr 10 19:59:31 daemon crit syslog: PPP LCP UP.
Apr 10 19:59:32 daemon crit syslog: PPP LCP UP.
Apr 10 19:59:35 daemon crit syslog: PPP LCP UP.
Apr 10 19:59:38 daemon notice syslog: pppd:local  IP address 91.***.*.**
Apr 10 19:59:38 daemon notice syslog: pppd:remote IP address 212.69.63.39
Apr 10 19:59:38 daemon notice syslog: pppd:primary   DNS address 212.69.40.13
Apr 10 19:59:38 daemon notice syslog: pppd:secondary DNS address 212.69.36.13
Apr 10 19:59:38 daemon crit syslog: Received valid IP address from server.  Connection UP.
Apr 10 19:59:43 daemon warn kernel: ^[[0;36;44mBroadcom Packet Flow Cache flushing the flows^[[0m
Apr 10 19:59:50 daemon crit syslog: Clear IP addresses.  PPP connection DOWN.
Apr 10 19:59:50 daemon crit syslog: Clear IP addresses.  Connection DOWN.
Apr 10 19:59:50 daemon notice syslog: pppd:local  IP address 91.***.*.**
Apr 10 19:59:50 daemon notice syslog: pppd:remote IP address 212.69.63.39
Apr 10 19:59:50 daemon notice syslog: pppd:primary   DNS address 212.69.40.13
Apr 10 19:59:50 daemon notice syslog: pppd:secondary DNS address 212.69.36.13
Apr 10 19:59:50 daemon crit syslog: Received valid IP address from server.  Connection UP.
Apr 10 20:00:00 daemon warn kernel: ^[[0;36;44mBroadcom Packet Flow Cache flushing the flows^[[0m

[Simon]

That's interesting, about four hours after the swap you appear to have had a re-sync resulting in a noticeable drop in latency.

So, what does that mean?  Is that good or bad?  I'm not getting the same sync speed as I was with the Asus router.  I'm now getting 9091Kbps, which is a drop of around 1000Kbps.

[zappaDPJ]

So, what does that mean?  Is that good or bad?  I'm not getting the same sync speed as I was with the Asus router.  I'm now getting 9091Kbps, which is a drop of around 1000Kbps.

I'm not sure that I'm qualified to say but if it was a re-sync that lowered your latency it suggests to me that BT's adaptive technology has determined your line is more stable than it was. That's my best guess.

[Lance]

And the line could be more stable as you have synced at a lower speed thus there is more headroom on the noise margin.

[Simon]

The noise margin has gone up from ~8.2 to 9.9, but I put that down to fiddling about with the connection.  I know I can modify that with this router, but I may just leave it for a while, and see if it remains stable.

[Simon]

Here we go again.  Same problem as before with the Billion router.  Connected to DSL but no PPP.   

[Steve]

My gut feeling is it's not your router/modem but as your trying another one it's the only way to rule them out.

[Simon]

As before with the Billion router, I've switched to PPPoE and the connection seems to be stable.  Not really sure what that indicates, but presumably there's a problem somewhere, and the different routers present it in different ways?  With the Asus, I was getting the packet loss, but the connection always came back.  With the Billion, it seems to drop PPP completely.

[nowster]

I wonder if PPPoA and PPPoE have different routings within the OpenReach network.

[Simon]

Strangely, when I tried the Asus router on PPPoE, it wouldn't connect at all, but maybe there was something else I didn't do at the time.  I was getting a higher sync speed with the Asus, so I might try it again at some point when I have the time and inclination.

[Simon]

Another bloody disconnection!  Having rebooted the router, now I've got all the correct lights up but still no internet.   

[Simon]

And now it's back. 

[Adrian]

From your original BQM, if you look very carefully at the red bit, it is actually tapered on the left and it looks to me as though you are getting a rapid rise in packet loss over a short period of time leading to a resync, the whole event taking several minutes. To me that doesn't look like a router fault, and the fact that you seem to get it with both routers would support that theory.

The Billion routers have a reputation for being very tenacious at keeping sync and when I was on ADSL my Billion 7800DXL performed very well, but I can't speak for your particular Asus router. Even so, I am as certain as I can be that the problem lies somewhere between your router and the exchange. Have you tried running from the master socket? Is there anything electrical happening in your home when the dropout happens?

[Simon]

Nothing electrical happening as far as I can tell, and it seems a bit too random to be something like that.  This is the first time it's happened since the 11th, when I changed back to the Billion and set it to PPPoE, which I thought may have cured the problem, as the connection had been stable since then.

I haven't tried in the test socket, because that is downstairs in the electric and gas meter cupboard, so it would mean I'd not be able to connect my main PC (no WiFi), and having tried that once before, the WiFi signal is patchy from there to other devices.  Besides, it could be fine for days, and then it would be Sod's Law that as soon as I moved the router back upstairs, I'd get a dropout. 

[Adrian]

Looking at your BQM again there is also a strange peak in packet loss after the drop out just as you re-acquire sync. It all seems very odd, and I have never seen anything like that before.

Presumably you are running a cable from the master socket to the router, so does this cable run close to mains wiring and how close is your master socket and associated wiring to the electricity feed to your meter. I am just thinking aloud here as a noisy electricity supply could play havoc. It could even be something as simple as a neighbour on the same phase turning on an appliance that makes a large sudden demand on the mains supply, especially a motor.

[Simon]

There is nothing connected to the master socket.  The router is connected to a splitter type faceplate, which was fitted by a BT engineer some years ago.  Obviously there is also a phone connected to that, but it is a DECT phone, so there are no other phones connected as all the other phones run from the one base station.  I have to admit, the DECT phone base is quite near to the router (about 2ft away), but again, this is just so random, I can't see how it could be that, especially given that the two devices have been in the same place for about 10 years and haven't caused issues. 

When this happened yesterday, I did power off the router for a couple of minutes, so that may have extended the downtime slightly.  Would that explain the anomaly you are seeing on my graph?

I live on a fairly new estate, which is still in development, so there is constant building works going on in the vicinity.  I'm just wondering if BT are fiddling about, connecting new homes, and this could be what is causing the problems?  There are always BTOR vans here at the local green box, so I might try and catch an engineer next time I see one, and have a chat with him.

[Simon]

Actually, you know when things has been there for so long, you forget that they're there sometimes?  Well, I've just realised that I do have another phone connected to the phone line, and that is a wired phone.  I could try disconnecting that for a while, but these dropouts do not seem to coincide with phone calls coming in or going out, so I'm not convinced that it could be anything to do with that.

[Adrian]

It might be worth having a chat with BTOR engineers, I have always found them very helpful. There are always BTOR engineers poking around in the cabinets here but I have never noticed any issues on my connection that I could attribute to them.

Sorry, when I referred to your master socket, I meant the splitter faceplate. The wired phone could be a problem I suppose and given the difficulty you are having resolving this I think it pays to go right back to first principles and methodically try and eliminate  everything one at a time. The difficulty you have of course is that it is often along time between incidents, but if you can manage without the wired phone then it is worth a try. Is there any correlation with the weather, I have heard of people having issues which turned out to be due to a leaking roof in the exchange allowing water to drip into the electronics!

You might also try a quiet line test when a dropout occurs, if you haven't already.