Invalid DSL modem configs (VPI needs to be 0 for Bell territory)
JF Mezei
unplugged the telephone wire to pass it through a different location in
a cabinet and plugged it back in before the modem appeared to lose sync.
But moments later, even though the green light was still on the modem,
the router started to complain about trying to establish connection.
Tracing at the router level showed the routyer sending discovery
packets, but not getting anything back (he should normally get a few
packets from Bell announcing the BAS server etc.
As soon as Teksavvy's offices opened, I called in. It is pretty cool
they can now check my line stats from their end. From his end, he was
seeing no activity but a good sync.
I read to him one display from my modem which showed packets going out
but 0 packets coming in as well as some other "obscure" paremeters. He
picked up on one parameter "VPI" and said it should be at 0. Mine seemed
to be set to 8.
In another display, it showed VPI at 0, so we both figured the modem was OK.
While he was on the phone with Bell to open a ticket, I found the
commands to set the VPI to 0, and almost instantly, the router was able
to establish the PPPoE session.
This modem had been sold preconfigured by ISTOP and had never really
been a problem. My guess is that sometime in the last 6 months (when I
last had lost PPPoE session, Bell must have changed something in their
systems to no longer tolerate erroneous parameters and this is only seen
the next time you get sync.
So, if you got a 3COM Home Connect modem from ISTOP, you may wish to
access it through the serial port and:
3-COM> LIST PORTS
It will list the configured ports. You need to have VPI=0 and VCI=35 for
Bell Canada territory. (I think the batch ISTOP sold had come from
Sprint and had "sprint" as port names).
You can also SHOW PORT portname COUNTER to confirm that VPI is set to 0
If it isn't set to 0:
3Com-DSL> DISABLE PORT portname
3Com-DSL> SET PORT portname VPI 0
3Com-DSL> ENABLE PORT portname
3Com-DSL> SAVE ALL (to make it permanent)
Maybe it was just a glitch for me that resulted in this VPI set to 8,
maybe not. But if you lose ability to connect, you'll know to check the
VPI in your modem and save you a lot of hours of fiddling around.
(this info may be handy if you buy a vanilla modem and need to configure it).
Thanks to a very sharp Tech guy at Teksavvy who spotted that obscure
parameter !!!!!!!
Gillian Stokesbluff
must be bell.
"JF Mezei" <jfmezei...@teksavvy.com> wrote in message
news:43DF6DFB...@teksavvy.com...
JF Mezei
>
> Yes, blame bell for changing something.
>
> must be bell.
I don't "blame" bell. If I had a wrong config that was tolerated by Bell
for a long time and is no longer tolerated, it isn't Bell fault for no
longer tolerating it.
I posted this just in case someone else would have an improper config on
those modems. I have been told that Telcos have various settings for
VPI/VCI.
http://www.dslmodemsdirect.com/DSL%20Configuration/VPI_VCI%20configuration%20Page.htm
Geoffrey Welsh
> I don't "blame" bell. If I had a wrong config that was tolerated by
> Bell for a long time and is no longer tolerated, it isn't Bell fault
> for no longer tolerating it.
Based on my very meagre knowledge of ATM, I don't think that any incorrect
value could have been tolerated.
> I posted this just in case someone else would have an improper config
> on those modems. I have been told that Telcos have various settings
> for VPI/VCI.
Yes, I recovered a Westell modem from an office in BellSouth territory (we
had bought the modem, so why not keep it?) and I discovered that they used a
different value than Bell Canada. Maybe it had to do with the fact that it
was a business DSL circuit, and maybe it was just how BellSouth operates.
Fortunately, I had the ATM settings on my GNet to compare to.
TekSavvy does deserve some credit... lord knows the script readers at
Sympatico wouldn't have figured it out!
On the other hand, just today I filed an abuse report with TekSavvy... it
would seem that one of their customer's machines was hacked and used to host
a phishing web site. Sad, but all too common these days.
--
Geoffrey Welsh <Geoffrey [dot] Welsh [at] bigfoot [dot] com>
Never leave until tomorrow what can wait until next week.
JF Mezei
> Based on my very meagre knowledge of ATM, I don't think that any incorrect
> value could have been tolerated.
Yeah, that is puzzling. Looking at the web, it seems that some modems
will "auto negotiate", and what the teksavvy expert told me is that they
try different variations until they see a connection.
> TekSavvy does deserve some credit... lord knows the script readers at
> Sympatico wouldn't have figured it out!
Yep a big kudos to stev to have picked up. I was merely reading a
display that showed data going out but not coming in along with obscure parameters.
> On the other hand, just today I filed an abuse report with TekSavvy... it
> would seem that one of their customer's machines was hacked and used to host
> a phishing web site. Sad, but all too common these days.
You shouldn't have mentioned it here and waited to see how they handled
a normal complaint. Now that you've mentioned it, they're probably going
to put more priority on the issue :-)
Geoffrey Welsh
>> On the other hand, just today I filed an abuse report with
>> TekSavvy... it would seem that one of their customer's machines was
>> hacked and used to host a phishing web site. Sad, but all too
>> common these days.
>
> You shouldn't have mentioned it here and waited to see how they
> handled
> a normal complaint. Now that you've mentioned it, they're probably
> going
> to put more priority on the issue :-)
It's one of many complaints that I file daily as a result of both my
personal spam at home and at work, and the stuff reported to me by
coworkers. Any reply would be lost in the pile, and I don't usually follow
up on reports I file also because of volume.