Guy,
thanks a lot for your reply. This explains a many of my problems. In particular now I know, why I see an Ethernet header when capturing on an ATM interface.
You are certainly right, it must be PPPoA (I'm planning to capture PPPoE on the ATM interface as well).
I only have the Marconi Adapter User manual, which gives no hints how to capture raw packets. So I will try to use your C-Program to convert the traces.
Regards,
Christian
------------------------------------------
Dr.-Ing. Christian Schuler
Datendienste - Netzdesign
QSC AG
Mathias-Brüggen-Str. 55
50829 Köln
Telefon: 0221 / 66 98 - 468
Telefax: 0221 / 66 98 - 609
mobil: 0179 / 2011175
E-Mail: Christian.Schuler@xxxxxx
Internet: www.qsc.de
>-----Ursprüngliche Nachricht-----
>Von: Guy Harris [mailto:gharris@xxxxxxxxx]
>Gesendet: Freitag, 27. Mai 2005 23:59
>An: Ethereal development
>Cc: Schuler, Dr. Christian
>Betreff: Re: [Ethereal-dev] PPPoE over ATM
>
>
>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.
>
