Re: Headroom for bridging and wireless

On Fri, Dec 05, 2003 at 10:54:05PM +0100, Bart De Schuymer wrote:
> On Friday 05 December 2003 07:44, Tom Marshall wrote:
> > The madwifi driver (for Atheros cards) uses sk_buff's directly in its xmit
> > code.  When using WEP, a 4 byte header is prepended to the data using
> > skb_push().  Since normal ethernet drivers don't anticipate the need for
> > this, a call to skb_realloc_headroom() is needed for all packets crossing
> > the bridge from ethernet to wireless.
> >
> > How hard would it be to add some logic in the bridge code to supply extra
> > headroom in the sk_buff allocator?  I'm thinking it could query each
> > network device in the system for its headroom requirements and use the max.
> >  Or it could recognize which interfaces are in bridging mode and only ask
> > them.  Or something even more intelligent.
> 
> That shouldn't be too difficult, just put the hard_header_len of the bridge 
> device to the max of the hard_header_len of the bridge ports, each time a 
> port is added or deleted.

Thanks for the answer.  I've been thinking about this problem some more, and
it seems the more I think, the more questions I have.

[I apologize in advance if these are dumb questions or off-topic.  I'm not
really a kernel developer and I'm not a network coding expert...]

I've been looking through both the bridge and netfilter code.  I notice that
net/core/netfilter.c has this:

        /* Change in oif may mean change in hh_len. */
        hh_len = (*pskb)->dst->dev->hard_header_len;
        if (skb_headroom(*pskb) < hh_len) {
                struct sk_buff *nskb;

                nskb = skb_realloc_headroom(*pskb, hh_len);
                if (!nskb) 
                        return -1;
                if ((*pskb)->sk)
                        skb_set_owner_w(nskb, (*pskb)->sk);
                kfree_skb(*pskb);
                *pskb = nskb;
        }

Note I haven't tried routing with WEP myself, and even if I had, the current
madwifi code leaves hard_header_len == ETH_HLEN anyway (surely a bug).  But
it brings up an interesting question...

I don't see anything like this in the bridge code.  Is that because
netfilter has to work across different media types but the bridge must use
ethernet devices?  If that is the case, is it valid to have an ethernet
device with hard_header_len != ETH_HLEN (eg. is this just a special case
that the bridge should not need to worry about)?

Suppose we did set the bridge device's hard_header_len to the max of all its
interfaces as you suggested.  How would the headroom get set?  Does the
packet always go through the above netfilter code?

Suppose the bridge code does check the headroom and the madwifi driver does
set hard_header_len == ETH_HLEN+4.  The original sk_buff is allocated by the
incoming ethernet driver, correct?  So it won't have enough headroom and we
still wind up doing a realloc/copy (just in a different place) right?

Wandering further away from bridge questions...

When a packet hits the device tx routine, can the device change the skb? 
More specifically, is it valid to call skb_push() for the WEP header and
change the skb->data pointer?  I'm thinking the answer is yes, this is a
valid thing to do, because the netfilter code does it.  But I would like to
know for sure -- maybe netfilter makes a copy and the bridge code doesn't.

And finally, the wireless device can change its WEP setting at any time. 
Is it valid to change hard_header_len anytime, or do we need to set it to
ETH_HLEN+4 when opening the device and leave it there?

-- 
It is by the fortune of God that, in this country, we have three benefits:
freedom of speech, freedom of thought, and the wisdom never to use either.
        -- Mark Twain

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj/RHegACgkQFMm9uvwPXW4oLwCePLdATsFex2ZyL/uvDCpvRCDe
GHwAn3c/+3PFmfHMT6HkwDG0cFqJvRrF
=+lOF
-----END PGP SIGNATURE-----