All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benoit PAPILLAULT <benoit.papillault@free.fr>
To: linux-kernel@vger.kernel.org
Subject: UDP broadcast packets not looped back
Date: Mon, 13 Aug 2007 23:32:47 +0200	[thread overview]
Message-ID: <46C0CDFF.6080409@free.fr> (raw)

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

Hi there,

I wrote a small C program using the BSD socket API to send a UDP 
broadcast packet to all interfaces of my machine. To do so, i sendto() 
it to 255.255.255.255 after using setsockopt(SO_BINDTODEVICE) on the 
correct interface. It works perfectly.

However, in the same program, either using the same socket or another on 
the same UDP, I found out that I just received the packet i'm sending as 
well. And do not want it. I perfectly understand that some program might 
be interested in broadcast packets they sent, but i don't.

I have seen that in the multicast world, every program can choose this 
behaviour throught the setsockopt IP_MULTICAST_LOOP. I do not want to 
use multicast since I don't want my packets to be routed (if there was 
ever a multicast router on the link). But I admit I could use a TTL=1 
packet in this case.

Anyway, I dig five minutes into the kernel source code I have at hand 
and wrote a small patch to add IP_MULTICAST_LOOP to broadcast packets. 
Since it might be interesting to other people, I just submit it here. It 
has been testing on Ubuntu and kernel 2.6.23-rc1 from the wireless.git 
repository. It should be very easy to adapt to other kernel version.

I have not seen this feature as being standard throught the OpenGroup 
specification 
(http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html), 
but it might be usefull anyway.

Comments welcome,
Benoit


[-- Attachment #2: wireless-dev-udp-broadcast.diff --]
[-- Type: text/x-patch, Size: 804 bytes --]

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index c9e2b5e..1052a6e 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -232,6 +232,9 @@ int ip_mc_output(struct sk_buff *skb)
 	skb->dev = dev;
 	skb->protocol = htons(ETH_P_IP);
 
+	printk("rt->rt_flags = %x mc_loop=%d\n",
+		rt->rt_flags, sk ? inet_sk(sk)->mc_loop : 0);
+
 	/*
 	 *	Multicasts are looped back for other local users
 	 */
@@ -266,10 +269,12 @@ int ip_mc_output(struct sk_buff *skb)
 	}
 
 	if (rt->rt_flags&RTCF_BROADCAST) {
+		if (!sk || inet_sk(sk)->mc_loop) {
 		struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
 		if (newskb)
 			NF_HOOK(PF_INET, NF_IP_POST_ROUTING, newskb, NULL,
 				newskb->dev, ip_dev_loopback_xmit);
+		}
 	}
 
 	return NF_HOOK_COND(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dev,

             reply	other threads:[~2007-08-13 21:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-13 21:32 Benoit PAPILLAULT [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-09-01 14:30 UDP broadcast packets not looped back Benoit PAPILLAULT

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=46C0CDFF.6080409@free.fr \
    --to=benoit.papillault@free.fr \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.