On Tue, May 28, 2002 at 10:01:03PM +1000, Darren Reed wrote:
> I noticed that neither -X or -x work with PPPoE and tcpdump.  This
> patch fixes this for me.  I don't understand why PPPOE_HDRLEN+2 is
> needed, as logic would seem to say that the +2 shoudln't be required?

Note that there are two types of PPPoE packets:

        discovery packets, which have a 6-byte PPPoE header followed by
        a bunch of TLVs;

        session packets, which have a 6-byte PPPoE header followed by a
        PPP packet.

It looks as if the NetBSD "sys/net/if_pppoe.c" (at least as of version
1.18), which is the driver that provides a DLT_ type of DLT_PPP_ETHER
(and thus that provides packets printed by "pppoe_if_print()") only
hands session packets to the BPF code.  (I guess if you want all the
PPPoE packets you would snoop on the Ethernet interface, and that the
PPPoE interface is an interface for use if you want to snoop the PPP
traffic.)  So discovery packets aren't going to be printed by
"pppoe_if_print()", and we don't have to worry about the "link layer
header" for them.

So the only PPPoE packets that should be printed by "pppoe_if_print()"
are session packets.  If what happens when you don't put the +2 in is
that the PPP header is printed, the reason why the +2 is needed is that
the PPP header is 2 bytes long.  :-)

However, it's not *necessarily* 2 bytes long - the protocol field in the
PPP header can be 8 or 16 bits long.

I've checked in code, based on your code, that gets the PPP header
length from "ppp_print()".
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe

Reply via email to