Ok, trivial patch attached. Applies to both latest 2.6 and 2.4
I will go hunting for more drivers that do this; for now, a good start
here.

cheers,
jamal


On Mon, 2004-05-10 at 13:18, Max Krasnyansky wrote:

On Sat, 2004-05-08 at 04:55, jamal wrote:

quoted

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?

I have no problem with that. I mean introducing new ARPHDR_ type.
ARPHDR_PPP was simply most appropriate for TUN that's why I picked it.
I vote for ARPHDR_NONE.

Thanks
Max