[Sderby] ADSL Problems - gah!

[David Jolley]

* Kris and Laura Adcock (krisandlaura@danceswithferrets.org) wrote:
> (I've posted this on ADSL-related newsgroups, but not had any replies. 
> Thinking about it, though, I reckon I'd probably get more 
> technically-minded answers here.)
> 
In all seriousness, have you tried www.adslguide.org.uk ?  Usually
quite a good place for this sort of thing...

> Right,
> 
> I am trying to set up Broadband access for the office of a small 
> church/charity. The exchange has been switched over, the Zoom x3 
> Ethernet modem is up and running, and I have my laptop connected to it. 
> The modem's log shows that things are positive - IP address assigned, 
> netmask, DNS and gateway settings are all fine.
> 
Does the modem offer any sort of line analysis, such as bit error
rates and the like?

> If I leave Linux pinging an arbitrary address and then stop after a 
> minute or so, it informs me that 5-10% of packets have been lost. 
> Webpages refuse to transfer - the browser informs me that it has found 
> the site, then just stops. I can telnet to an NTP server and get the 
> time fine. If I ftp over to an ftp site, things go fine until I actually 
> try and transfer a file, or if text of a substantial quantity needs to 
> be transferred (so 'ls' tends to work, but 'ls -al' screws up). 
> Basically, any transfer of any real quantity tends to grind to a halt.
> 
ping, while a useful bit of kit, is not really a be-all-and-end-all
indication that something's wrong.  A busy router will, in all
probability drop all ICMP ping requests to reduce it's CPU load.  How
sure are you that it's not a busy router at your ISP?
However, in all likelyhood, it's a fair indication that something is
wrong - an overloaded router will, probably, be dropping other packets
*anyway* :(

I don't know what your level of experience with networking is, but as
you've managed to get linux up and running and doing NAT for a
network, I'm assuming you're reasonably competent - can you possibly
run tcpdump on your ethernet interface whilst having an http session,
and seeing what sequence of packets is generated? It'll tell you
*exactly* the sequence of events happening on the wire, and give you a
vague ide of what's *really* wrong.  i.e. an un-acked packet will
stick out like a sore thumb :)

> Now, this is the second modem. I took the first one back to the shop 
> because I believed the modem had a 'dodgy-buffer', or something. But as 
> the new one has exactly the same symptoms, I'm thinking that the fault 
> is elsewhere.
> 
Modems are of the same type presumably?  Having worked in the
electronics testing industry for a bit, I have virtually zero faith in
the test procedures for assembled printed circuit boards.  If the
modems are of different types, and both have the same symptoms, I'd be
more inclined to agree wth you.  Overly cynical?  Probably...

If you trust the modem manufacturer's batch testing procedures, then
your conclusion is a good one, and not one that I'd really seriously
dispute.

> So, has anyone else had this problem? How did you fix it? It could be 
> possible that there's a setting in the modem which limits bandwidth, but 
> I don't think that's where the fault lies. Who should I be talking to to 
> faultfind this situation?
> 
Unlikely to be a bandwidth throttler in a consumer grade modem, I'd go
with your conclusion that the line is a bit dicey.  My problem with my
ADSL line was an MTU related issue, not dropped packets (fortunately)

> Now, I've had some very unproductive telephone calls with freenetname's 
> supposed 'technical support', who basically charged me 50p per minute to 
> be put on hold and then refused to help me. To confuse matters further, 
> freenetname's ADSL access is provided by a company called Bulldog DSL. 
> But it turns out that Bulldog are really only the admin side, and 
> actually the service is being provided by BT. So I just KNOW that 
> whoever I ring will blame one of the other parties ... and so on, until 
> the end of time.
> 
The whole ADSL provisioning is set up to make customer's lives a
bloody nightmare.  You are a customer of your ISP who are, in turn,
customers of BT.  So you're actually a layer of beaurocracy away from
the people that can actually fix a problem.  For example, when I had
my "MTU" speed issues with my line, it took me a whole week to
convince my ISP that there was a fault, then it took them a week to
get a BT engineer out.  Fortunately, the BT engineer was able enough
to figure out that it was an exchange fault, and it took about a week
thereafter to get it fixed - it eventually turned out to be an
intermittently faulty card at the exchange.  But my point is that
*you* don't get to talk to BT directly, you have to go through your
ISP, who will require you to exhaust their support bod script before
they'll escalate. 

> Originally I was using a Windows ME laptop, but after the tech-support 
> tried to fob me of with "blah blah MTU sizes blah blah" I've installed 
> Smoothwall 'twixt the two. No difference, but then I didn't think there 
> would be.
> 
The MTU thing is to do with the interaction of the IP packets and the
ATM backbone (which supplies the IP packets from you to your ISP).  If
you have this set to (IIRC) > 1458 then your connection speed will be
drastically cut.  I've not yet heard of the MTU affecting whether a
packet makes it to it's final destination.

Have you told Bulldog that you've tried 2 different modems, and that
they both exhibit the same fault?  You'd be advised to use DrTCP
(http://www.dslreports.com/front/drtcp.html) to do the MTU tweak
before ringing your ISP, as it is used as a catchall solution.  I
don't think it'll make any difference, but it shuts them up a bit
quicker, and they then tend to assume a level of knowledge.

To make the process quicker through your ISP, I really think you ought
to put a Windows box on the ADSL line, as they won't have a clue about
what to do when confronted by an operating system desinged to do
networking.  Unless of course, you feel comfortable sitting in front
of the smoothwall box and translating their Windows-speak into the
relevant Linux commands (and vice-versa).

Cheers,

Dave.

-- 
  Imagination abandoned by reason produces impossible monsters;
  united with her, she is the mother of the arts.
     -- Goya.