Ethereal-dev: Re: [Ethereal-dev] PPPoE over ATM

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Guy Harris" <gharris@xxxxxxxxx>
Date: Fri, 27 May 2005 14:59:05 -0700 (PDT)
Schuler, Dr. Christian said:

> I have installed and compiled Ethereal 0.10.11 on a Sun/Solaris Machine
> with a Marconi ATM adapter card. I'm trying to capture packets from
> PPPoE over ATM connections.

On what network interface device are you capturing that traffic?  The one
for the ATM adapter?

If so, it appears that...

> My problem is that this protocol stack is obviously not supported in
Ethereal, which results in wrong decoding.

...the problem is that the people at Fore/Marconi who wrote the driver for
that adapter didn't actually follow the rules of DLPI when they did so,
which results in capture files that any application trying to decode it
will decode incorrectly unless it knows about that problem.  (Perhaps
those rules didn't let them do what they wanted to, but it might have been
better had they gotten Sun to at least let them specify DL_ATM as the
link-layer type in DLPI and have that mean "LLC-encapsulated ATM".)

> I found out that I have 6 additional Bytes in front of the IP-Paket:
>
>  | fe fe 03  | cf 00 21  | 45 00 .......
>    LLC Head    PPP Header  IP ->

Actually, 0xcf is the OSI NLPID for PPP, and the 00 21 is the PPP header.

So this looks like PPPoA, as per RFC 2364, not any form of PPPoE (I would
think PPPoE over ATM would be PPPoE carried on top of bridged Ethernet
over ATM).

RFC 2364 PPPoA should be supported by Ethereal, *if* the packet is in a
form that can be recognized by Ethereal as LLC-encapsulated ATM.  It'd see
the fe fe 03 as an LLC header, call the "OSI network layer" dissector
because the DSAP is 0xfe, and the OSI dissector should then call the PPP
dissector because the NLPID is 0xcf.

The problem is that the Fore/Marconi card is claiming to users of DLPI,
such as libpcap on Solaris, that it's an *Ethernet* card, and putting a
bogus Ethernet header on the packet.  Equally unfortunately, there's no
good way to detect that form of bogosity, as far as I know, except
*perhaps* treating a source and destination MAC address of all zeroes as a
sign that the capture came from a Fore/Marconi card that puts a bogus
Ethernet header onto the packet.

Do you have any programming documentation for the Fore/Marconi card?  If
so, perhaps it discusses how to read raw packets using DLPI and indicates
how to figure out that it's lying when it says it's an Ethernet card, in
which case libpcap could be modified to work around that.

If that's not possible, I've attached the source to a small libpcap-based
program that will read one of those bogus Fore/Marconi captures and write
it out with

    1) a link-layer header type of DLT_ATM_RFC1483, so Ethereal will think
it's LLC-encapsulated ATM;

    2) the first 14 bytes of each packet stripped off, so the fake
Ethernet link-layer header is missing.

It seemed to do the right thing on the capture you sent.

Attachment: debogify.c
Description: Binary data