On Wed, 18 Oct 2006 11:14:45 +0200 Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> > Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]> > > --- 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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
