dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
599
MrMazda86 (banned)
join:2013-01-29
Kitchener, ON

MrMazda86 (banned)

Member

[DSL] Hell Telecom (formerly Bell) + AOHell

I know this isn't a TekSavvy issue, but all DSL services essentially work in the same manner, so it would be interesting to see if anyone here may be able to help explain the situation I've got with a customer. I know there are a number of people here who are a lot more familiar with the workings of the infrastructure than I am, which will be an asset for understanding the situation.

I have a customer who has asked that I see about fixing their internet issues. On the most part, I've been able to hammer them all out. Her hardware configuration is as follows:

Modem: Simmens SpeedStream 4200 (Bridged)
Router: D-Link DIR-615 (Rev E3, FW 5.10)
Configuration: Router establishes PPPoE connection on WAN port, PC connects to router's LAN (as follows:)
PHONE LINE (Internet) ===> MODEM (Bridge) ===> ROUTER (PPPoE Dialer/LAN Host) ===> PC (End Device on LAN)

The first thing that I noticed that was out of place was that her internet seemed to be running really slow. It's supposed to be a 6Mbit/800Kbit line, however it only seems to be bringing in 3.25Mbit/650Kbit. My first initial thought was to do all the usual network resets within Windows, power down the computer, then power cycle the modem and router, powering on/connecting each device in the chain in the order that they come, but had no success. The result was a "PPPoE Authentication Error" that was coming up in the router's error log.

What seemed more interesting was that the modem still indicated that it had a link to the ATM network and that in theory, it should be able to allow the router to establish the PPPoE link. Confused by this, we decided to contact AOHell technical support directly to see if perhaps there may have been some sort of issue with their PPPoE authentication systems in the area, but after a long (and painful) 2 hours, they came up empty handed and unable to explain the reason for why she was unable to establish the PPPoE link. Since this was not satisfactory to me, I decided to run a few more tests for shits and giggles to see where the problem seemed to be, and that's when I started noticing some very interesting results.

The first test that I decided to run was by changing the PPPoE login to test@test to connect directly to the CO and run a few tests. It seemed that the modem wasn't the problem as I was assigned an IP of 10.3.212.18 and noted that when I tried this test from my Kitchener DSL line in the same general side of the city it had given me 10.3.212.16. My first question here is: Does this mean that her line and my line both run to the same CO or DSLAM? Just curious on that one.

The more interesting observation that I noted was when I opened up a command prompt and tried running "ping -n 100 10.3.212.1". The result it turned up was as follows:
quote:
Ping statistics for 10.3.212.1:
Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 248ms, Average = 51ms

The first question that comes to mind when I see this is does this mean that the distance from the CO or DSLAM may perhaps be too far?

Aside from that, there are many other things that come to mind, but I can't help but wonder... What does this mean? I know that normally, the ping statistics on this test should generally never be above 10ms, but in this case, it seems that there's a problem. The question here is what would this problem be, and would I need to get AOHell to file a ticket with Hell Telecom to be able to investigate this issue?

What was even more interesting was that when I went to reconnect to her DSL to run some further tests on the connection to see where the problem lied with her connection, but only found myself in a frustrating situation. According to AOHell, there should have been nothing preventing me from establishing the PPPoE link using her actual AOHell login, however no matter what I tried, it seemed that this was just not going to happen. Frustrated by this and trying to determine if the modem perhaps may have been faulty, I decided to give my good 'ole faithful TekSavvy login a whirl... It worked... Like a charm. I was back online and poking around on the internet without any issue, but noted that the speeds still seemed reduced.

My question here is: Is it possible that the problem with the ping on the test@test being so out of whack may be what is causing the link to AOHell's PPPoE authentication server to not be established? If not, would I likely need to have either AOHell or the Hell Telecom Test Centre run any kind of further testing on the line to try and determine the problem?

Any tips anyone could give me at this point would be greatly appreciated. I've already traced every last stitch of wiring, every jack, etc and I am unable to produce any kind of line issue anywhere in the line past the demarc point. I have even attempted to swap the Simmens SpeedStream 4200 with a newer Simmens SpeedStream 5200, a 2Wire 2701HG-G, a Thompson SpeedTouch 516, and a Comtrend CT-5072T, all of which produce the exact same result, so I'm fairly sure it's safe to rule the modem out as a possible problem.

I just hope I don't have to end up dealing with AOHell India or Hell Telcom (at least directly) to get this resolved for her. I'm just frustrated as can be with it and have come to the opinion that the expression "AOL Technical Support" is an oxymoron.

Inssomniak
The Glitch
Premium Member
join:2005-04-06
Cayuga, ON

Inssomniak

Premium Member


From what you typed, there is not "enough" wrong with the line to not allow the bell login to work. Did she pay her bill?

Your TSI login worked, so the issue is with bell, and not the line or modem, but something perhaps in the routing of the login, or her account is off? Try her login on your DSL line.

The slow speeds might be line related, post the stats, but this isnt why you cant establish your PPPoE session with Bell.
Expand your moderator at work
MrMazda86 (banned)
join:2013-01-29
Kitchener, ON

MrMazda86 (banned) to Inssomniak

Member

to Inssomniak

Re: [DSL] Hell Telecom (formerly Bell) + AOHell

said by Inssomniak:

From what you typed, there is not "enough" wrong with the line to not allow the bell login to work. Did she pay her bill?

Noted. Thank you
Yes. According to AOHell (formerly AOL), the account shows that it's all paid.
said by Inssomniak:

Your TSI login worked, so the issue is with bell, and not the line or modem, but something perhaps in the routing of the login, or her account is off? Try her login on your DSL line.

I think you may be on to something there. Her login doesn't seem to work on my line either, so it would seem there could be something wrong with the login. The only question here would be what and why.
said by Inssomniak:

The slow speeds might be line related, post the stats, but this isnt why you cant establish your PPPoE session with Bell.

I should be going back over there to work on it further tomorrow. I will grab the stats when I'm there. Hopefully, this will turn up something of an interesting value. AOHell (formerly AOL) can be quite frustrating to deal with sometimes. At least I can say though that I think the bulk of the frustration that comes with them though is nothing more than a lack of understanding caused by a language barrier, rather than just being unwilling to help.

Just out of curiosity, do you know if there's any way I'd be able to run further tests on the line, or would I need to consult with AOHell or Hell Telecom to be able to have such further testing done?

BACONATOR26
Premium Member
join:2000-11-25
Nepean, ON

1 edit

BACONATOR26 to MrMazda86

Premium Member

to MrMazda86
If you can authenticate with test@test then the line itself is fine in terms of making a connection to the DSL network and between the CO.

If her Bell (or AOL) login, however, doesn't work anywhere then there may be an issue with her account in Bell's RADIUS server. If you haven't already you might want to try her Bell login on your Tek line to test that it works at all.

Otherwise, the only thing I can think of is call them up and double check the PPPoE login and the password character by character to make sure it is correct. Sometimes it's a simple error.

Also I may just be a bit biased but her network is not quite optimal.

Modem: Simmens SpeedStream 4200 (Bridged)
Router: D-Link DIR-615 (Rev E3, FW 5.10)

She could swap for a newer modem like the 2wire which might give her a better line quality, the 4200 is a little out of a date and I simply do not trust the quality of those D-Link routers.

Sorry, didn't see it was an AOL provided line - but I think they just direct resell Bell if I recall correctly.
MrMazda86 (banned)
join:2013-01-29
Kitchener, ON

MrMazda86 (banned)

Member

Her actual internet service actually lies with AOHell (formerly AOL). The only thing that she has with Hell Telecom (formerly Bell) is her home phone.

What I'm wondering is if it would be beneficial to have Hell Telecom run some diagnostics and such on the line to see about correcting the issue, since the average ping tends to be a lot higher than it should be.

From what AOHell is telling me, there shouldn't be a problem with the login. It's kind of tempting to see about talking her into making the switch to TSI, given the price points and the difference in line speed. Literally only $1/mo more would get Canadian tech support (who actually speak English) and a faster line speed.

@mlerner: I wouldn't say your "biased" with respect to D-Link products. I too have had a number of frustrating issues with them, namely the DIR-615. It seems that the only two hardware revisions that seem to like a PPPoE connection are E3 and I3.... Any other hardware revision is really just a joke.

I will be bringing a 2Wire 2701HG-G over to swap it out and see what happens.

BACONATOR26
Premium Member
join:2000-11-25
Nepean, ON

BACONATOR26

Premium Member

If you can pull the line stats, post them here and we can check but 51-248 ms could mean her line is on interleave, maybe line quality or distance issues but interleave does help maintain a stable connection at the expense of latency. Then again it could also mean the server you're pinging has QoS applied with lower priority for ICMP response.

As far as diagnostics, Bell could probably fix up line quality but it won't make the login work as whatever endpoint it is Bell or AOL, it ain't taking that login on their end.
MrMazda86 (banned)
join:2013-01-29
Kitchener, ON

1 edit

MrMazda86 (banned)

Member

Here is a direct copy & paste of the command prompt when I ran the test. The result is even more frightening today. My next step is going to be to switch her out for the 2Wire 2701HG-G modem so that I can take a look at the actual physical line information and see if it will get her better speeds and/or get her a better ping response. The following was kinda frightening:
quote:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\eh>ping -n 100 10.3.212.1

Pinging 10.3.212.1 with 32 bytes of data:
Reply from 10.3.212.1: bytes=32 time=48ms TTL=248
Reply from 10.3.212.1: bytes=32 time=46ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=54ms TTL=248
Reply from 10.3.212.1: bytes=32 time=55ms TTL=248
Reply from 10.3.212.1: bytes=32 time=49ms TTL=248
Reply from 10.3.212.1: bytes=32 time=83ms TTL=248
Reply from 10.3.212.1: bytes=32 time=51ms TTL=248
Reply from 10.3.212.1: bytes=32 time=45ms TTL=248
Reply from 10.3.212.1: bytes=32 time=42ms TTL=248
Reply from 10.3.212.1: bytes=32 time=43ms TTL=248
Reply from 10.3.212.1: bytes=32 time=50ms TTL=248
Reply from 10.3.212.1: bytes=32 time=71ms TTL=248
Reply from 10.3.212.1: bytes=32 time=192ms TTL=248
Reply from 10.3.212.1: bytes=32 time=80ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=49ms TTL=248
Reply from 10.3.212.1: bytes=32 time=44ms TTL=248
Reply from 10.3.212.1: bytes=32 time=45ms TTL=248
Reply from 10.3.212.1: bytes=32 time=86ms TTL=248
Reply from 10.3.212.1: bytes=32 time=237ms TTL=248
Reply from 10.3.212.1: bytes=32 time=117ms TTL=248
Reply from 10.3.212.1: bytes=32 time=120ms TTL=248
Reply from 10.3.212.1: bytes=32 time=285ms TTL=248
Reply from 10.3.212.1: bytes=32 time=250ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=42ms TTL=248
Reply from 10.3.212.1: bytes=32 time=116ms TTL=248
Reply from 10.3.212.1: bytes=32 time=117ms TTL=248
Reply from 10.3.212.1: bytes=32 time=117ms TTL=248
Reply from 10.3.212.1: bytes=32 time=52ms TTL=248
Reply from 10.3.212.1: bytes=32 time=57ms TTL=248
Reply from 10.3.212.1: bytes=32 time=122ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=423ms TTL=248
Reply from 10.3.212.1: bytes=32 time=245ms TTL=248
Reply from 10.3.212.1: bytes=32 time=118ms TTL=248
Reply from 10.3.212.1: bytes=32 time=42ms TTL=248
Reply from 10.3.212.1: bytes=32 time=69ms TTL=248
Reply from 10.3.212.1: bytes=32 time=57ms TTL=248
Reply from 10.3.212.1: bytes=32 time=43ms TTL=248
Reply from 10.3.212.1: bytes=32 time=120ms TTL=248
Reply from 10.3.212.1: bytes=32 time=117ms TTL=248
Reply from 10.3.212.1: bytes=32 time=118ms TTL=248
Reply from 10.3.212.1: bytes=32 time=40ms TTL=248
Reply from 10.3.212.1: bytes=32 time=77ms TTL=248
Reply from 10.3.212.1: bytes=32 time=75ms TTL=248
Reply from 10.3.212.1: bytes=32 time=211ms TTL=248
Reply from 10.3.212.1: bytes=32 time=118ms TTL=248
Reply from 10.3.212.1: bytes=32 time=52ms TTL=248
Reply from 10.3.212.1: bytes=32 time=133ms TTL=248
Reply from 10.3.212.1: bytes=32 time=139ms TTL=248
Reply from 10.3.212.1: bytes=32 time=45ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=57ms TTL=248
Reply from 10.3.212.1: bytes=32 time=774ms TTL=248
Reply from 10.3.212.1: bytes=32 time=306ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=502ms TTL=248
Reply from 10.3.212.1: bytes=32 time=138ms TTL=248
Reply from 10.3.212.1: bytes=32 time=119ms TTL=248
Reply from 10.3.212.1: bytes=32 time=119ms TTL=248
Reply from 10.3.212.1: bytes=32 time=152ms TTL=248
Reply from 10.3.212.1: bytes=32 time=48ms TTL=248
Reply from 10.3.212.1: bytes=32 time=59ms TTL=248
Reply from 10.3.212.1: bytes=32 time=59ms TTL=248
Reply from 10.3.212.1: bytes=32 time=47ms TTL=248
Reply from 10.3.212.1: bytes=32 time=121ms TTL=248
Reply from 10.3.212.1: bytes=32 time=48ms TTL=248
Reply from 10.3.212.1: bytes=32 time=45ms TTL=248
Reply from 10.3.212.1: bytes=32 time=122ms TTL=248
Reply from 10.3.212.1: bytes=32 time=215ms TTL=248
Reply from 10.3.212.1: bytes=32 time=119ms TTL=248
Reply from 10.3.212.1: bytes=32 time=131ms TTL=248
Reply from 10.3.212.1: bytes=32 time=59ms TTL=248
Reply from 10.3.212.1: bytes=32 time=210ms TTL=248
Reply from 10.3.212.1: bytes=32 time=284ms TTL=248
Reply from 10.3.212.1: bytes=32 time=48ms TTL=248
Reply from 10.3.212.1: bytes=32 time=46ms TTL=248
Reply from 10.3.212.1: bytes=32 time=49ms TTL=248
Reply from 10.3.212.1: bytes=32 time=64ms TTL=248
Reply from 10.3.212.1: bytes=32 time=85ms TTL=248
Reply from 10.3.212.1: bytes=32 time=128ms TTL=248
Reply from 10.3.212.1: bytes=32 time=111ms TTL=248
Reply from 10.3.212.1: bytes=32 time=60ms TTL=248
Reply from 10.3.212.1: bytes=32 time=66ms TTL=248
Reply from 10.3.212.1: bytes=32 time=71ms TTL=248
Reply from 10.3.212.1: bytes=32 time=54ms TTL=248
Reply from 10.3.212.1: bytes=32 time=48ms TTL=248
Reply from 10.3.212.1: bytes=32 time=63ms TTL=248
Reply from 10.3.212.1: bytes=32 time=77ms TTL=248
Reply from 10.3.212.1: bytes=32 time=70ms TTL=248
Reply from 10.3.212.1: bytes=32 time=57ms TTL=248
Reply from 10.3.212.1: bytes=32 time=57ms TTL=248
Reply from 10.3.212.1: bytes=32 time=131ms TTL=248
Reply from 10.3.212.1: bytes=32 time=48ms TTL=248
Reply from 10.3.212.1: bytes=32 time=65ms TTL=248

Ping statistics for 10.3.212.1:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 774ms, Average = 105ms

C:\Users\eh>

Any ideas on what this means or where I should be thinking of taking things from this point? I already know that I'm going to have to get AOHell involved and rattle some cages there because she's currently having to use my TSI login to be able to do such things as send her rent money to her landlord.

@TSI: In a situation like this where this kind of issue exists (or even in general for that matter), is there a policy against using a TSI login from a non TSI connection? Also, would using a TSI login on a non TSI connection constitute a terms of service violation or anything else along those lines that wouldn't be desirable?

JenSuisUn
Premium Member
join:2006-02-23
Chatham, ON

JenSuisUn

Premium Member

Pinging a BAS & receiving these types of stats would indicate congestion at the BAS. This would require the ISP to open a slow speed ticket & see if Bell would return back with a Pattern issue.

This is not a normal response rate from the BAS.
MrMazda86 (banned)
join:2013-01-29
Kitchener, ON

MrMazda86 (banned)

Member

Thank you... I'm on it