Frequent drops (Dialup)

Hi there!

I’m running IPFire (2.25 / CU 150) on an APU2 behind some modem set in bridge mode. I configured IPFire with the PPP settings provided by my ISP.

Over the past months, I’ve been experiencing random 5 to 30 second drops and they’ve became more frequent over the past days. I called my ISP asking if they can see any issues on their side, everything is clear but they’ve noticed a high error rate coming from me. I’m not sure how to troubleshoot this and where to find relevant logs in IPFire. I checked some of the stats (load, traffic, etc…) and there’s nothing out of the ordinary or that I could corroborate with the drops.

Any ideas what I should look at?

Cheers,
Raf

Hi Raf,

Its most likely due to your line.
Depending on the modem, it may not be able to hold onto the line well.
Some models allow access via telnet or monitoring that you can query.
The fact the ISP are saying they are seeing errors would tend to indicate that you are getting FEC errors most likely.

On your telephone connection, or at least in the UK we have a faceplate on the BT socket.
nte5-test-web

Plug your modem into test socket, and see if you still get errors. If not the problem is with your internal wiring.
Try using a separate filter if you have one.
If you still get an error, its upto your provider to fix the issue.

The provider can put a tester on the line to see if there any issues further up the line.
A bad joint, water in pods etc. Aluminum cabling. etc

HTH
Joe.

1 Like

Hi Joe,

Thanks a lot of the reply.

I assumed it was because of my IPFire configuration, being the first time I use it in a Dialup type setup. But after taking my APU2 off the network and resetting the modem, the same drops persist. Tried also swapping out all my cables as a sanity check but no luck either. We can rule out configuration issues on my end I guess.

So it might either be my ISP’s modem that is crap or an issue on the line as you pointed out. The socket is brand new (installed by the ISP) and has the filter built-in. In any case, I think the only option left is to pester them until they get it fixed :slightly_smiling_face:

Thanks again for replying so quickly, really appreciate the help!

Cheers,
Raf

Hi Raf,

Some modems you can access via telnet or SSH and can check what the modem is doing and/or monitor the line stats. If you can, it gives you a good stick to beat the ISP with.
There are various programs out there than can monitor the data too like DSLstats etc.
But the most important parameter is your SNR or signal to noise ratio. Sometimes routers don’t show this but show a SNR Margin, which is different.

Its complicated to go into, but generally you want a higher SNR or decent SNR margin above 6db. Any lower an SNR Margin and the line will start to drop. Too low an SNR and you would get enough signal. A way to think of it, is SNR is same as being in a room full of people who are all making background noise/buzz and you are trying to communicate with a person over the other side of the room. The noise starts to get to a level where you cant communicate. The other important factor is attenuation. its an inverse figure, you want a lower DB on your attenuation, Around 20db is excellent, over or around 50db is bad.

I started to explain a bit better but have found this link which explains it easier.

So, haha if you have made it this far well done!!
Next bit if you can get those figures out of your modem, you can use them with your ISP to get something done to improve the signal. Sometimes the ISP can tweak the DSLAM to attempt negotiation at a lower rate. But if you are experiencing drops you may have noise, or high attenuation, depending on how far from the exchange you are. Personally if I am paying for it, I push the provider.

HTH
Joe.

1 Like

Hi Joe,

Thanks a lot for the additional info and explanation. I checked the modem info and found some stats:
graph - stats

I see the SNR moving between 9 and 11db on the info page. But looking at the graph I can also see some random dips. Not sure what’s causing it but I guess it’s going to be the ISP’s job to find out. I sent them all the info and asked them to send someone over.

Cheers,
Raf

Hi Raf,

Not sure how correct the first graph is, but second image shows an ok SNR margin. Also your FEC errors are very low, so not sure why ISP said they saw errors. On the SNR margin as long as it stays above 6Db. The DSLAM will attempt to adapt the profile down to this margin. Have you tried a quiet line test to see if there is any noise on the line? if you are on BT in uk… dial 17070 select quiet line test. hold the line open and listen for a while, especially around the times of a suspected drop.
If you get crackling, hissing you could have an issue or REIN, which is radio interference. I have seen air conditioning units for example cause a problem with lines and disconnects when they spun up.

BR
Joe.

1 Like

Hi Joe,

Thanks for the reply!

I’m not sure I can do the quite line test. I don’t have a telephone (or number assigned to me that I know of) and the socket has a single RJ11 port used by the modem.

But I suspect some sort of interference but I’m not really sure what could cause it and where. The distance from where they attached the cable (entrance door) to the modem is relatively short and there isn’t much in the way or near except a Wifi camera (2.4 GHz) at the entrance.

That’s the only device I can think of that could cause some sort of radio interference. The issues happened before I put the camera but I have the feeling that they are more frequent since. I’ll disconnect it for a while and see if it helps. I’ll keep you posted!

There’s also something else I’ve just realised. I’m behind a shared IPv4 (having a public IPv4 costs extra). Looking at Google Reviews, some customers complained about that mentioning disconnections. Maybe my ISP is just terrible and I should leave them for another one :slight_smile:

Cheers,
Raf

No blaming or shaming intended.

Openable ferrite clamps on the phone cable may help reduce the EMI coming from surroundings. That won’t surely transform the cable into a shielded one, but… if you can find some spare ones even from old VGA Cables… who knows?
If you can’t access to the xDSL page of your xDSL router you cannot find the attenuation value and the SNR value, which can help you understand better if the connection between your CPE/xDSL router to the DSLAM (the ISP counterpart) is wonderful, nice, not that bad or crappy.

Also… in 30 years sometimes ethernet devices are not that compatible as they should be. Beefy corporate-grade switches can more or less eat/connect everything as negotiation (sometimes with some settings on ports) and can manage quite well crappy 8pin Ethernet cables. But consumer grade devices and network cards sometimes cannot keep a stable relation between the two sides. So try with another network cable between IPFire and the CPE/xDSL router might be something cheap and easy to test for change something.
Also… If the connection is not that fast (less than 100Mbps down or up) you can think to downgrade the network negotiation between CPE and IPFire box, if changing cables don’t work.

I’m bored, so i’m willing to share these simple tests for trying to troubleshoot your issue… but it’s quite annoying to read for the… maybe 1Mth time than “culprit is the new toy” only because the previous one (software, device, consumer device, whatever) was not refined enough to show the problem. Few months ago i were quite pixxed off with my smartphone because at one customer site the WLAN was wobbling up and down as connection, while the crappy old laptop did not. Long story short, the WLAN adapter of the Access Point was really unstable. The old 802.11N wireless card of the laptop didn’t budge, the 802.11AC adapter of the smartphone showed the db level graph shaking like and earthquake chart.
Shame on me once to don’t investigate before cursing my device, shame on me twice for assuming that the problem was “the new toy”. It only showed better the truth (after the AP replacement, also all the WLAN connected AC units started to work flawlessly).

A little hint for the next IT/net shipwreck: when something’s not working as expected, don’t blame the new thing, do some homework and verifications before :slight_smile: