Subject: Re: Conditionalize expensive BPF operation
To: None <itojun@iijlab.net>
From: Martin Husemann <martin@duskware.de>
List: tech-net
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
> 	  interface
> 	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,
though.

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.


Martin