Subject: Re: Conditionalize expensive BPF operation
To: None <email@example.com>
From: Martin Husemann <firstname.lastname@example.org>
Date: 05/01/2001 14:53:11
> for bpf on pppoe interface, i guess we should not prepend ethernet
> header. my understanding is that:
> - pppoe interface should prepend ppp header and pass it to bpf
> - if you want to look at ether header, run tcpdump on ethernet
> am i wrong?
That's similar to what is done now (see syssrc/net/if_pppoe.c): on input,
if the device is already connected (i.e. in "session" state): strip ether
header and pass packet to bpf_mtap (still containing the PPPoE header).
On output, add PPPoE header, call bpf_mtap, pass to underlying ethernet
interface output routine (aka ether_output).
This is using the DLT_PPP_ETHER encapsulation type.
Jason suggested to better do a unified PPP encapsulation (for serial PPP,
isdn PPP, ethernet PPP, ...) by creating something like
<encapsulation type><encapsulation specific headers>
<protocol discriminator><PPP data>
where "encapsulation specific headers" would be the PPPoE header for this
case or 0xff 0x03 (PPP_ALLSTATIONS PPP_UI) for serial or ISDN PPP.
The problem with the current approach is: you can not trace the discovery
phase via the pppoe interface (and tcpdump currently has not enough smarts
to dig out that information from the raw ethernet trace). Not a big deal,
I actually do not care very much wich way it is done - I needed tcpdump working
to track down other problems, and this was a simple approach to do it. As
you surely noticed, this is far away from usual playfield and I do not pretend
to be a bpf expert.