Re: Headroom for bridging and wireless

On Saturday 06 December 2003 01:08, Tom Marshall wrote:
> 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)?

net/bridge/br_device.c::br_dev_setup() calls 
drivers/net/net_init.c::ether_setup() when a new bridge device is created.

> 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?

No.
For routed IP traffic, the check is always done in 
net/ipv4/ip_output.c::ip_finish_output2().

> 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?

Yes, I was thinking about packets originating from the bridge box itself.
The vlan code does this when creating a new vlan device 
(net/8021q/vlan.c::register_vlan_device()):
	new_dev->hard_header_len = real_dev->hard_header_len;
	if (!(real_dev->features & NETIF_F_HW_VLAN_TX)) {
		/* Regular ethernet + 4 bytes (18 total). */
		new_dev->hard_header_len += VLAN_HLEN;
	}

To deal with bridge packets, the madwifi code will need a test like this in 
the tx code:
if (skb_headroom(skb) < VLAN_HLEN) {
	struct sk_buff *sk_tmp = skb;
	skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN);
}

This is also done in the vlan code, see 
net/8021q/vlan_dev.c::vlan_dev_hard_start_xmit().

> 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.

Yes.

> 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?

You can change it, but you will probably need the call_rcu mechanism to be 
sure this size isn't changed at the wrong time. Note that changing this value 
would mean the hard_header_len of the bridge device will possibly need to be 
changed too.
You'd better consult with Stephen Hemminger if he would accept the changes to 
be made to the bridge code.

cheers,
Bart



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click