[PATCH,RFC] bridge: call eth_type_trans() in br_pass_frame_up()
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.0 +0200 +++ linux-2.6.19-rc2/net/bridge/br_input.c 2006-10-18 11:10:08.0 +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); } - 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
Re: [PATCH,RFC] bridge: call eth_type_trans() in br_pass_frame_up()
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.0 +0200 > +++ linux-2.6.19-rc2/net/bridge/br_input.c2006-10-18 11:10:08.0 > +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
Re: [PATCH,RFC] bridge: call eth_type_trans() in br_pass_frame_up()
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.0 +0200 > +++ linux-2.6.19-rc2/net/bridge/br_input.c2006-10-18 11:10:08.0 > +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, this will cause packets coming in from other interfaces to be incorrectly marked as OTHERHOST. Think of the following: eth0: 00:11:11:0:1:2 eth1: 00:11:11:0:1:3 br0: 00:11:11:0:1:2 If packet arrives with Destination Address (DA) of 00:11:11:0:1:3 on eth1 then your change will mark it as OTHERHOST. The case you are trying to fix is an ARP packet arriving on eth1 with the DA of eth0. That implies some sort of mismatch or cycle in your topology, it is not clear if the packet should just be dropped. -- 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
