Wireshark-users: Re: [Wireshark-users] Using Wireshark for a DSL "link no surf" problem [UPDATE]
And since my ISP, MegaPutz/MegaPath uses 0/40 (which isn't listed
there), that "auto-detect" would never have found it. It's really not
an auto-detect if it just cycles through "the most common values" but
more of a brute force/trial-and-error approach.
On 7/11/14 09:59, Frank Bulk (iname.com) wrote:
The most common values are 0/35 and 8/35 and 0/100
(http://www.dslreports.com/faq/1149). I'm sure there are a few more
variations. That auto-detect would quickly detect the most common ones.
Frank
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Kok-Yong Tan
Sent: Monday, July 07, 2014 7:06 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Using Wireshark for a DSL "link no surf"
problem [UPDATE]
Yes, well, the ZyXEL P660R-F1 and the Broadxent/Innoband Briteport
don't. If they did, I wouldn't have had any problems connecting up in
the first place. That's why I'm looking for a method/software/hardware
that would detect what the existing VPI/VCI is on the wire besides just
knowing what it was set to.
From what I gathered in reading "End-to-End DSL Architectures" by Wayne
C. Vermillion, VPI is the Virtual Path Identifier and VCI is the Virtual
Circuit Identifier. Also, for each ATM physical link, there are 256
possible VPIs and within each VP are 65,536 possible VCIs (less
identifier numbers 0-31 which are reserved). This means that there are
a humongous number of possible valid values of VPI/VCI (256 * 65,504 by
my calculation) to cycle through if one takes the brute force approach.
And even if one were to chance upon the correct set of values, how
does one verify that it's the intended one?
On 7/6/14 23:42, Frank Bulk (iname.com) wrote:
Some DSL modems do have an auto-detect where they cycle through the most
common VPI/VCI values.
Frank
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Kok-Yong Tan
Sent: Wednesday, July 02, 2014 7:09 PM
To: Guy Harris; Community support list for Wireshark
Subject: Re: [Wireshark-users] Using Wireshark for a DSL "link no surf"
problem [UPDATE]
On 7/2/14 19:31, Guy Harris wrote:
On Jul 2, 2014, at 3:46 PM, Kok-Yong Tan <ktan@xxxxxxxxxxxxxxxxxxx>
wrote:
This segues to my next question: Is there any way to use Wireshark
to ascertain the VPI/VCI of the ATM circuit from the Layer 2
packets that were said to have been flowing? Or must I have
specialized software or hardware to do this?
If you're capturing on the Ethernet into the modem, I wouldn't expect
to see any ATM information from the capture - if, for example, the
modem has an HTTP-based configuration interface for use on the local
user side, Ethernet traffic to and from its Web server won't even
necessarily go out over the DSL circuit.
To capture traffic on the ATM side of the modem, you'd need
specialized hardware, and probably some level of specialized software
to talk to that hardware.
I noticed that the rep had nothing more than his laptop connected
via ethernet cable to the DSL modem when he noticed the different
VPI/VCI settings on a possibly in-house-only software running on
it.
According to the manual for your modem at the URL you sent in an
earlier message, there's an HTTP-based configuration interface.
That's probably what the rep was using.
Okay, noted on the ATM info. Thanks.
Unfortunately, he wasn't using that HTTP-based interface (I looked at
what he was looking at and it's not the Broadxent Briteport's
interface). The Broadxent Briteport's web-based interface is just a
status interface. There's nothing that can be set on it except for the
PPPoE settings and there's also a reset-to-defaults button. All through
the case when I was offline, it just displayed a VPI/VCI of 0/35. I
suspect that there is another port which allows an admin user to login
and manipulate the settings, just like on the replacement ZyXEL P660R-F1
the onsite tech provided me with.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
