Re: [PATCH,RFC] bridge: call eth_type_trans() in br_pass_frame_up()
From: Stephen Hemminger <hidden>
Date: 2007-02-26 18:40:34
On Wed, 18 Oct 2006 11:14:45 +0200 Lennert Buytenhek [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Hi, I've been seeing a failure to reply to incoming ARP packets on a bridge interface until after the first few packets have been transmitted over that interface, and the patch below seems to fix the issue, the 'issue' being that the incoming ARP packets are marked with PACKET_OTHERHOST, and there not being anything to set that back to PACKET_HOST even if the destination MAC address matches the bridge interface's MAC address. If this looks good, I'll prepare a proper commit message. cheers, Lennert Signed-off-by: Tom Billman <redacted> Signed-off-by: Lennert Buytenhek <redacted>--- linux-2.6.19-rc2.orig/net/bridge/br_input.c 2006-10-18 11:11:08.000000000 +0200 +++ linux-2.6.19-rc2/net/bridge/br_input.c 2006-10-18 11:10:08.000000000 +0200@@ -32,6 +32,9 @@ indev = skb->dev; skb->dev = br->dev; + skb_push(skb, ETH_HLEN); + skb->protocol = eth_type_trans(skb, skb->dev); + NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, indev, NULL, netif_receive_skb); }
No, eth_type_trans already be called by the device in the receive path. Looks like a device driver bug, not a bridge issue. If you add this, the code ends up doing eth_type_trans twice. -- Stephen Hemminger [off-list ref]