Max, Dave, Jeff,
I get what was bothering me now - it took me a while to formulate it:
TUN_TUN_DEV dev->type is ARPHRD_PPP
dev->type is really related to link layer header, perhaps at the low
level if neighbor discovery works well then we have a link-headerless
packet which gets manipulated with the correct header by some generic
code. The combination of dev->type and dev->hard_header_len works
together to achieve this.
In the case of TUN_TUN_DEV, the header_len is 0 ;->
To be of type ARPHRD_PPP, tun needs to have a header_len which is the
size of the l2 ppp header.
As an example, TUN_TAP_DEV is fine as type ARPHRD_ETHER and header_len
of ETH_HLEN.
A lot of devices are abusing this system, tun is not the only one.
My suggestion is to change dev->type to ARPHRD_VOID for TUN_TUN_DEV or
we introduce something like ARPHDR_NONE for devices with link layer
headers of size 0.
thoughts?
cheers,
jamal
On Mon, 2004-04-26 at 15:31, Max Krasnyansky wrote:
> On Sat, 2004-04-24 at 07:14, jamal wrote:
> > Maxim,
> >
> > When TUN_TUN_DEV is used, before the packet is injected into
> > the netif_rx() only skb->mac.raw = skb->data is set; the other headers
> > are not adjusted. Typically netdevs would do a
> > skb_pull(skb,dev->hard_header_len) to make the adjustment.
> > I have a feeling this is design intent thats why i didnt send you a
> > patch.
> Well TUN does not have any hw headers so there is nothing to pull :).
> Basically it does what ever PPP driver does. Which is
>
> skb_pull(skb, 2); /* chop off protocol */
> skb->dev = ppp->dev;
> skb->protocol = htons(npindex_to_ethertype[npi]);
> skb->mac.raw = skb->data;
> netif_rx(skb);
>
> Max
>
>
>
|