netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart De Schuymer <bdschuym@pandora.be>
To: "David S.Miller" <davem@redhat.com>
Cc: Stephen Hemminger <shemminger@osdl.org>, netdev <netdev@oss.sgi.com>
Subject: [PATCH] Fix loopback over bridge port
Date: Sat, 27 Dec 2003 15:36:46 +0100	[thread overview]
Message-ID: <200312271536.46940.bdschuym@pandora.be> (raw)

Hi Dave,

When sending a broadcast from a Linux bridge over a bridge port,
net/ipv4/ip_output.c::ip_dev_loopback_xmit() will send the packet back
to the bridge port. Currently, the bridge code will intercept this
loopback packet and try to bridge it. This is not right, the loopback
packet doesn't even have an Ethernet header. This loopback packet is
intended for the bridge port and should not be stolen by the bridge code.
The patch below fixes this by adding a check in __handle_bridge().
It also changes br_netfilter.c by only doing the paranoid checks of
br_nf_post_routing() when CONFIG_NETFILTER_DEBUG is set. I think the
loopback fix will get rid of any skbuffs matching those paranoid checks.

The patch also introduces/removes some whitespace in br_netfilter.c.

I think the code (in net/ipv4/ip_output.c::ip_dev_loopback_xmit())
__skb_pull(newskb, newskb->nh.raw - newskb->data);
is useless, as data always points to the network header at that moment. But
that's not really my territory...

cheers,
Bart

PS: I see I forgot a decent subject in my previous mail, it should have
read something like "[PATCH] Always copy and save the vlan header in
bridge-nf"


--- linux-2.6.0/net/core/dev.c.old	2003-12-25 17:03:41.000000000 +0100
+++ linux-2.6.0/net/core/dev.c	2003-12-25 17:04:29.000000000 +0100
@@ -1543,7 +1543,7 @@ static inline int __handle_bridge(struct
 			struct packet_type **pt_prev, int *ret)
 {
 #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
-	if (skb->dev->br_port) {
+	if (skb->dev->br_port && skb->pkt_type != PACKET_LOOPBACK) {
 		*ret = handle_bridge(skb, *pt_prev);
 		if (br_handle_frame_hook(skb) == 0)
 			return 1;
--- linux-2.6.0/net/bridge/br_netfilter.c.earlier2	2003-12-25 17:31:49.000000000 +0100
+++ linux-2.6.0/net/bridge/br_netfilter.c	2003-12-25 17:59:28.000000000 +0100
@@ -352,6 +352,7 @@ static unsigned int br_nf_local_in(unsig
 	return NF_ACCEPT;
 }
 
+
 /* PF_BRIDGE/FORWARD *************************************************/
 static int br_nf_forward_finish(struct sk_buff *skb)
 {
@@ -462,6 +463,7 @@ static unsigned int br_nf_forward_arp(un
 	return NF_STOLEN;
 }
 
+
 /* PF_BRIDGE/LOCAL_OUT ***********************************************/
 static int br_nf_local_out_finish(struct sk_buff *skb)
 {
@@ -527,9 +529,7 @@ static unsigned int br_nf_local_out(unsi
 		return NF_ACCEPT;
 
 	nf_bridge = skb->nf_bridge;
-
 	nf_bridge->physoutdev = skb->dev;
-
 	realindev = nf_bridge->physindev;
 
 	/* Bridged, take PF_BRIDGE/FORWARD.
@@ -597,18 +597,15 @@ static unsigned int br_nf_post_routing(u
 	struct vlan_ethhdr *hdr = (struct vlan_ethhdr *)(skb->mac.ethernet);
 	struct net_device *realoutdev = bridge_parent(skb->dev);
 
-	/* Be very paranoid. Must be a device driver bug. */
+#ifdef CONFIG_NETFILTER_DEBUG
+	/* Be very paranoid. This probably won't happen anymore, but let's
+	 * keep the check just to be sure... */
 	if (skb->mac.raw < skb->head || skb->mac.raw + ETH_HLEN > skb->data) {
 		printk(KERN_CRIT "br_netfilter: Argh!! br_nf_post_routing: "
 				 "bad mac.raw pointer.");
-		if (skb->dev != NULL) {
-			printk("[%s]", skb->dev->name);
-			if (has_bridge_parent(skb->dev))
-				printk("[%s]", bridge_parent(skb->dev)->name);
-		}
-		printk(" head:%p, raw:%p\n", skb->head, skb->mac.raw);
-		return NF_ACCEPT;
+		goto print_error;
 	}
+#endif
 
 #ifdef CONFIG_SYSCTL
 	if (!nf_bridge)
@@ -618,13 +615,16 @@ static unsigned int br_nf_post_routing(u
 	if (skb->protocol != __constant_htons(ETH_P_IP) && !IS_VLAN_IP)
 		return NF_ACCEPT;
 
+#ifdef CONFIG_NETFILTER_DEBUG
 	/* Sometimes we get packets with NULL ->dst here (for example,
-	 * running a dhcp client daemon triggers this).
+	 * running a dhcp client daemon triggers this). This should now
+	 * be fixed, but let's keep the check around.
 	 */
-	if (skb->dst == NULL)
-		return NF_ACCEPT;
+	if (skb->dst == NULL) {
+		printk(KERN_CRIT "br_netfilter: skb->dst == NULL.");
+		goto print_error;
+	}
 
-#ifdef CONFIG_NETFILTER_DEBUG
 	skb->nf_debug ^= (1 << NF_IP_POST_ROUTING);
 #endif
 
@@ -651,6 +651,18 @@ static unsigned int br_nf_post_routing(u
 		realoutdev, br_dev_queue_push_xmit);
 
 	return NF_STOLEN;
+
+#ifdef CONFIG_NETFILTER_DEBUG
+print_error:
+	if (skb->dev != NULL) {
+		printk("[%s]", skb->dev->name);
+		if (has_bridge_parent(skb->dev))
+			printk("[%s]", bridge_parent(skb->dev)->name);
+	}
+	printk(" head:%p, raw:%p, data:%p\n", skb->head, skb->mac.raw,
+					      skb->data);
+	return NF_ACCEPT;
+#endif
 }
 
 

             reply	other threads:[~2003-12-27 14:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-27 14:36 Bart De Schuymer [this message]
2003-12-30  1:43 ` [PATCH] Fix loopback over bridge port David S. Miller
2004-01-01 20:38 ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200312271536.46940.bdschuym@pandora.be \
    --to=bdschuym@pandora.be \
    --cc=davem@redhat.com \
    --cc=netdev@oss.sgi.com \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).