[PATCH] don't try to track broadcasts or multicasts (4/4)

[PATCH] don't try to track broadcasts or multicasts (4/4)

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

There exists code to disable tracking of broadcasts but it's insice a
#if 0 / #endif in ip_conntrack_core.c and looks like some old debugging
code as it has printk's and stuff.

this patch removes that chunk and replaces it with a check so if the
packet is a broadcast or multicast we just return NF_ACCEPT since
there's not much point in us trying to track it.

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

[-- Attachment #2: ip_conntrack_core.c-broadmulti-diff --]
[-- Type: text/plain, Size: 1053 bytes --]

--- linux-2.4.19-pre9/net/ipv4/netfilter/ip_conntrack_core.c.orig	Mon Jun  3 20:32:28 2002
+++ linux-2.4.19-pre9/net/ipv4/netfilter/ip_conntrack_core.c	Tue Jun  4 20:56:18 2002
@@ -737,20 +737,9 @@
 	/* FIXME: Do this right please. --RR */
 	(*pskb)->nfcache |= NFC_UNKNOWN;
 
-/* Doesn't cover locally-generated broadcast, so not worth it. */
-#if 0
-	/* Ignore broadcast: no `connection'. */
-	if ((*pskb)->pkt_type == PACKET_BROADCAST) {
-		printk("Broadcast packet!\n");
+	/* Don't try to track broadcasts or multicasts. */
+	if ((*pskb)->pkt_type == PACKET_BROADCAST || (*pskb)->pkt_type == PACKET_MULTICAST)
 		return NF_ACCEPT;
-	} else if (((*pskb)->nh.iph->daddr & htonl(0x000000FF)) 
-		   == htonl(0x000000FF)) {
-		printk("Should bcast: %u.%u.%u.%u->%u.%u.%u.%u (sk=%p, ptype=%u)\n",
-		       NIPQUAD((*pskb)->nh.iph->saddr),
-		       NIPQUAD((*pskb)->nh.iph->daddr),
-		       (*pskb)->sk, (*pskb)->pkt_type);
-	}
-#endif
 
 	/* Previously seen (loopback)?  Ignore.  Do this before
            fragment check. */

Re: [PATCH] don't try to track broadcasts or multicasts (4/4)

[Harald Welte]

On Thu, Jun 06, 2002 at 02:24:05PM +0200, Martin Josefsson wrote:
> There exists code to disable tracking of broadcasts but it's insice a
> #if 0 / #endif in ip_conntrack_core.c and looks like some old debugging
> code as it has printk's and stuff.
> 
> this patch removes that chunk and replaces it with a check so if the
> packet is a broadcast or multicast we just return NF_ACCEPT since
> there's not much point in us trying to track it.

hm.  I would generally agree with you, but there is one issue which
needs to be looked into before considering this patch:

What happens if some client sends an ip-unicast diagram as link layer
broadcast?  How does the linux stack react to this?

If the packet is processed/routed the same way like any other ip-unicast
link-layer unicast packet, we still need to do tracking of broadcast
packets.

Could you try to look into that and keep us posted?

Thanks.

> /Martin

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: [PATCH] don't try to track broadcasts or multicasts (4/4)

[Martin Josefsson]

On Sat, 2002-06-08 at 09:35, Harald Welte wrote:

> hm.  I would generally agree with you, but there is one issue which
> needs to be looked into before considering this patch:
> 
> What happens if some client sends an ip-unicast diagram as link layer
> broadcast?  How does the linux stack react to this?
> 
> If the packet is processed/routed the same way like any other ip-unicast
> link-layer unicast packet, we still need to do tracking of broadcast
> packets.
> 
> Could you try to look into that and keep us posted?

Hmm why didn't I think about that?

I've done some simple testing and the results are:

TCP:
send SYN to ll broadcast: ignored
send SYN,ACK to ll broadcast: ignored

UDP:
packet sent to ll broadcast: accepted

ICMP:
echo-request sent to ll broadcast: accepted
echo-reply sent to ll broadcast: accepted
port unreachable sent to ll broadcast: accepted

I havn't done any tests with multicast ll addresses.

Seeing these results there's not much need for a patch of this kind.
TCP ll broadcasts are extremely rare. almost all ll broadcasts here are
UDP.

It was a nice thought but doesn't work in the real world.

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

Re: [PATCH] don't try to track broadcasts or multicasts (4/4)

[Harald Welte]

On Sat, Jun 08, 2002 at 04:51:47PM +0200, Martin Josefsson wrote:
> Hmm why didn't I think about that?

it just came to my mind after reading your mail..

> I've done some simple testing and the results are:

the results are actually quite interesting - but maybe there's a
particular reason for TCP behaving different than other protocols...

> It was a nice thought but doesn't work in the real world.

yup, it would have been a nice optimization...

> /Martin

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: [PATCH] don't try to track broadcasts or multicasts (4/4)

[Henrik Nordstrom]

On Sunday 09 June 2002 19:18, Harald Welte wrote:

> the results are actually quite interesting - but maybe there's a
> particular reason for TCP behaving different than other
> protocols...

Broadcast or multicast does not apply to TCP. It does in the other 
protocols (ICMP / UDP). A broadcast or multicast packet received by 
TCP is with no doubt a martian as there is no aspect of TCP that can 
be safely used on other than unicast links.

Linux ICMP seems to have some provision to filter out broadcasts when 
they do not make sense, but it could do better I think..

But I think this aspect of the Linux IP stack can be ignored local 
traffic. If you receive a broadcast frame addressed to your unicast 
IP address then the processing should not be much different from 
receiving a broadcast frame addressed to your broadcast address. The 
likelyhood that there is TCP/IP implementations sending you broadcast 
link frames when unicast was intended is very low.

But the reverse cannot be assumed. There is special applications of 
TCP/IP where multicast is used as local transport. This can be seen 
in some odd active-active load balancing products where all servers 
must see all packets, so a Linux server/router can be required to 
receive unicast IP frames from a multicast link source address or to 
sent unicast IP to a multicast link address..

If this is considered in a bridge environment using the 
bridge-netfilter integration then obviously no optimization based on 
unicast/multicast link transport can be done on forwarded packets..

Regards
Henrik