Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #3597 > unrolled thread

Problem receiving UDP broadcast packets.

Back to article view | Back to comp.lang.python

Contents

  Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-19 22:21 +0000
    Re: Problem receiving UDP broadcast packets. Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2011-04-20 01:13 +0200
      Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-19 23:21 +0000
        Re: Problem receiving UDP broadcast packets. Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2011-04-20 01:40 +0200
          Re: Problem receiving UDP broadcast packets. Dan Stromberg <drsalists@gmail.com> - 2011-04-19 16:52 -0700
            Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 00:09 +0000
              Re: Problem receiving UDP broadcast packets. Chris Angelico <rosuav@gmail.com> - 2011-04-20 10:53 +1000
                Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 01:15 +0000
                  Re: Problem receiving UDP broadcast packets. Chris Angelico <rosuav@gmail.com> - 2011-04-20 11:24 +1000
                    Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 03:05 +0000
                  Re: Problem receiving UDP broadcast packets. Dan Stromberg <drsalists@gmail.com> - 2011-04-19 20:12 -0700
                    Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 14:31 +0000
                    Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 15:42 +0000
                  Re: Problem receiving UDP broadcast packets. Dan Stromberg <drsalists@gmail.com> - 2011-04-19 20:16 -0700
                    Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 14:21 +0000
                      Re: Problem receiving UDP broadcast packets. Dan Stromberg <drsalists@gmail.com> - 2011-04-20 18:35 -0700
                        Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-21 14:22 +0000
                      Re: Problem receiving UDP broadcast packets. Heiko Wundram <modelnine@modelnine.org> - 2011-04-21 08:22 +0200
              Re: Problem receiving UDP broadcast packets. Roy Smith <roy@panix.com> - 2011-04-19 23:35 -0400
                Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 14:23 +0000
              Re: Problem receiving UDP broadcast packets. Sherm Pendley <sherm.pendley@gmail.com> - 2011-04-20 06:07 -0400
                Re: Problem receiving UDP broadcast packets. Adam Tauno Williams <awilliam@whitemice.org> - 2011-04-20 06:20 -0400
                  Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 15:37 +0000
          Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-19 23:54 +0000
            Re: Problem receiving UDP broadcast packets. Heiko Wundram <modelnine@modelnine.org> - 2011-04-20 08:45 +0200
              Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 14:30 +0000
                Re: Problem receiving UDP broadcast packets. Heiko Wundram <modelnine@modelnine.org> - 2011-04-20 16:53 +0200
                  Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 15:24 +0000
                    Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 15:32 +0000
                Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 15:50 +0000
    Re: Problem receiving UDP broadcast packets. Dan Stromberg <drsalists@gmail.com> - 2011-04-19 16:40 -0700
      Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 00:00 +0000
        Re: Problem receiving UDP broadcast packets. Chris Angelico <rosuav@gmail.com> - 2011-04-20 10:32 +1000
    Re: Problem receiving UDP broadcast packets. Thomas Heller <theller@ctypes.org> - 2011-04-20 12:18 +0200
      Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 14:35 +0000
    Re: Problem receiving UDP broadcast packets. Grant Edwards <invalid@invalid.invalid> - 2011-04-20 22:25 +0000

Page 2 of 2 — ← Prev page 1 [2]

#3675

Grant Edwards <invalid@invalid.invalid> writes:

> I'm trying to implement a device discovery/configuration protocol that
> uses UDP broadcast packets to discover specific types of devices on
> the local Ethernet segment.  The management program broadcasts a
> discovery command to a particular UDP port.  All devices who get that
> packet are expected to answer regardless of thier current IP address.

Have you looked at the source for Apple's Bonjour?

  <http://developer.apple.com/opensource/>
  <http://opensource.apple.com/source/mDNSResponder/mDNSResponder-258.18/>

Might be interesting to see how it does announcement/discovery. Or maybe
just use it directly, if this happens to be a case of "gee, I didn't
know that wheel had already been invented." :-)

sherm--

-- 
Sherm Pendley
                                   <http://camelbones.sourceforge.net>
Cocoa Developer

[toc] | [prev] | [next] | [standalone]

#3680

On Wed, 2011-04-20 at 06:07 -0400, Sherm Pendley wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
> > I'm trying to implement a device discovery/configuration protocol that
> > uses UDP broadcast packets to discover specific types of devices on
> > the local Ethernet segment.  The management program broadcasts a
> > discovery command to a particular UDP port.  All devices who get that
> > packet are expected to answer regardless of thier current IP address.
> Have you looked at the source for Apple's Bonjour?

On LINUX this is called "avahi", which has Python bindings.  Avahi
auto-configuration / discovery works very well.

<http://avahi.org/>
<http://freshmeat.net/projects/avahi>
<http://pypi.python.org/pypi/pybonjour/1.1.1>
<http://avahi.org/wiki/PythonBrowseExample>

See also:
<http://pypi.python.org/pypi/pybonjour/1.1.1>
at least you may be able to lift code from them (License is non-viral
MIT)

> Might be interesting to see how it does announcement/discovery. Or maybe
> just use it directly, if this happens to be a case of "gee, I didn't
> know that wheel had already been invented." :-)

-- 
Adam Tauno Williams <awilliam@whitemice.org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

[toc] | [prev] | [next] | [standalone]

#3723

On 2011-04-20, Adam Tauno Williams <awilliam@whitemice.org> wrote:
> On Wed, 2011-04-20 at 06:07 -0400, Sherm Pendley wrote:
>> Grant Edwards <invalid@invalid.invalid> writes:
>> > I'm trying to implement a device discovery/configuration protocol that
>> > uses UDP broadcast packets to discover specific types of devices on
>> > the local Ethernet segment.  The management program broadcasts a
>> > discovery command to a particular UDP port.  All devices who get that
>> > packet are expected to answer regardless of thier current IP address.
>> Have you looked at the source for Apple's Bonjour?
>
> On LINUX this is called "avahi", which has Python bindings.  Avahi
> auto-configuration / discovery works very well.
>
><http://avahi.org/>
><http://freshmeat.net/projects/avahi>
><http://pypi.python.org/pypi/pybonjour/1.1.1>
><http://avahi.org/wiki/PythonBrowseExample>
>
> See also:
><http://pypi.python.org/pypi/pybonjour/1.1.1>
> at least you may be able to lift code from them (License is non-viral
> MIT)

I've looked at those protocols and they aren't particularly suited to
what we want to do.  One of our requirements is to be able to discover
a device with a static IP address (or no IP address?) that isn't on
the same subnet -- and I don't see how those protocols can do that. 

Since the management program already has to implement the UDP based
protocol I'm working on, it would be a big win if I didn't have to
make the management program add support for a second protocol.

-- 
Grant Edwards               grant.b.edwards        Yow! Are we THERE yet?
                                  at               My MIND is a SUBMARINE!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#3611

On 2011-04-19, Irmen de Jong <irmen.NOSPAM@xs4all.nl> wrote:
> On 20-4-2011 1:21, Grant Edwards wrote:
>> 
>> If I don't call bind(), then the broadcast packets go out the wrong
>> interface on the sending machine.
>
> Fair enough.
>
> Next issue then: as far as I know, broadcast packets are by default
> not routed across subnets by gateways. Which is a good thing.
>
> That would explain why your receiver doesn't see the packets unless
> its interface IP address is in the same subnet as the sender's.
>
> However it doesn't explain (for me) why the tcpdump program running
> on that same receiver machine still happily spits out received
> packets.

The two machines are on the same Ethernet segment (they're connected
via a dumb Ethernet switch).

Tcpdump shows the packets because the packets are being received by
the receiving machine's Ethernet interface.  They have a destination
MAC of ff:ff:ff:ff:ff:ff, so everybody on the logical Ethernet segment
receives them.

I guess the problem is that I expected to receive a packet on an
interface anytime a packet was received with a destination IP address
that matched that of the the interface.  Apprently there's some
filtering in the network stack based on the _source_ address as well
(that seems very counter-intuitive to me).

-- 
Grant Edwards               grant.b.edwards        Yow! I'm not an Iranian!!
                                  at               I voted for Dianne
                              gmail.com            Feinstein!!

[toc] | [prev] | [next] | [standalone]

#3658

Am 20.04.2011 01:54, schrieb Grant Edwards:
> I guess the problem is that I expected to receive a packet on an
> interface anytime a packet was received with a destination IP address
> that matched that of the the interface.  Apprently there's some
> filtering in the network stack based on the _source_ address as well
> (that seems very counter-intuitive to me).

Just to pitch in here (because nobody's mentioned it yet AFAICT): yes,
there's a filtering done (at least under Linux, and I'd guess something
similar on xBSD too) to packets based on the source address coming in on
an interface, and it's called the reverse path filter and is on by
default (the tunable on Linux is /proc/sys/net/ipv4/conf/*/rp_filter).

The idea behind the reverse path filter is that your machine won't
accept packets coming in over an interface when a return packet (i.e.,
the presumed response) won't be routed over the same interface, and from
what I gather, this is what makes the TCP/IP stack drop the packets
because your machine will not route packets to 192.168.x.x over the same
interface it sees the packet coming in. This is a _security_ feature,
because it makes address spoofing harder.

If you need to see the packets regardless, either use a promiscuous mode
sniffer (i.e., tcpdump, but that's relatively easy to mirror in Python
using SOCK_RAW, capturing packets at the ethernet level), or add a route
on your system for the 192.168.x.x network on the same interface.

HTH!

-- 
--- Heiko.

[toc] | [prev] | [next] | [standalone]

#3711

On 2011-04-20, Heiko Wundram <modelnine@modelnine.org> wrote:
> Am 20.04.2011 01:54, schrieb Grant Edwards:
>> I guess the problem is that I expected to receive a packet on an
>> interface anytime a packet was received with a destination IP address
>> that matched that of the the interface.  Apprently there's some
>> filtering in the network stack based on the _source_ address as well
>> (that seems very counter-intuitive to me).
>
> Just to pitch in here (because nobody's mentioned it yet AFAICT): yes,
> there's a filtering done (at least under Linux, and I'd guess something
> similar on xBSD too) to packets based on the source address coming in on
> an interface, and it's called the reverse path filter and is on by
> default (the tunable on Linux is /proc/sys/net/ipv4/conf/*/rp_filter).

Brilliant!  While I had determined that such filtering took place, I'd
been unable to figure out if it was configurable.

> The idea behind the reverse path filter is that your machine won't
> accept packets coming in over an interface when a return packet (i.e.,
> the presumed response) won't be routed over the same interface, and from
> what I gather, this is what makes the TCP/IP stack drop the packets
> because your machine will not route packets to 192.168.x.x over the same
> interface it sees the packet coming in. This is a _security_ feature,
> because it makes address spoofing harder.

And it's an eminently sensible feature.

> If you need to see the packets regardless, either use a promiscuous mode
> sniffer (i.e., tcpdump, but that's relatively easy to mirror in Python
> using SOCK_RAW, capturing packets at the ethernet level), or add a route
> on your system for the 192.168.x.x network on the same interface.

I've thought about the SOCK_RAW option, but the CPU load of looking
all received Ethernet packets in user-space would be a big down-side.

Adding the route isn't an option since 1) the device doesn't know what
route to add, and 2) adding such a route could  break the normal
networking operation.

-- 
Grant Edwards               grant.b.edwards        Yow! My haircut is totally
                                  at               traditional!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#3715

Am 20.04.2011 16:30, schrieb Grant Edwards:
>> If you need to see the packets regardless, either use a promiscuous mode
>> sniffer (i.e., tcpdump, but that's relatively easy to mirror in Python
>> using SOCK_RAW, capturing packets at the ethernet level), or add a route
>> on your system for the 192.168.x.x network on the same interface.
> 
> I've thought about the SOCK_RAW option, but the CPU load of looking
> all received Ethernet packets in user-space would be a big down-side.

Not necessarily: instead of using UDP datagrams to send the data, use
ethernet datagrams (without any IP/UDP header) with your own
ethernet-type (there is a range of "local" types that you can use for
your own local use-case), and then simply create a RAW socket that only
listens on packets that have the specified ethernet types. We use
something similar at work for a high-availability application.

The server-side looks something like:

"""
PKT_TYPE = 0x1234 # My very own ethertype.

sock = socket(AF_PACKET,SOCK_DGRAM,htons(PKT_TYPE))
sock.bind(("ethxyz",PKT_TYPE))

while True:
    data, (_, _, _, _, addr) = sock.recvfrom(1500)
    print "I got:", repr(data), "from etheraddr:", addr
"""

The client-side looks similar.

Because you're using UDP broacast, you have unreliable transport anyway,
and if the client-side supports sending ethernet datagrams (with a
broadcast address), I'd rather advise to use that for your use case.
This makes you independent of IP configuration (and as I can see, you're
actually not interested in the "routing" that IP gives you, but rather
interested in contacting all nodes on a local ethernet; why not use
ethernet directly?).

-- 
--- Heiko.

[toc] | [prev] | [next] | [standalone]

#3719

On 2011-04-20, Heiko Wundram <modelnine@modelnine.org> wrote:
> Am 20.04.2011 16:30, schrieb Grant Edwards:
>>> If you need to see the packets regardless, either use a promiscuous mode
>>> sniffer (i.e., tcpdump, but that's relatively easy to mirror in Python
>>> using SOCK_RAW, capturing packets at the ethernet level), or add a route
>>> on your system for the 192.168.x.x network on the same interface.
>> 
>> I've thought about the SOCK_RAW option, but the CPU load of looking
>> all received Ethernet packets in user-space would be a big down-side.
>
> Not necessarily: instead of using UDP datagrams to send the data,

There's the rub.  The requirement is to use UDP.

> use ethernet datagrams (without any IP/UDP header) with your own
> ethernet-type (there is a range of "local" types that you can use for
> your own local use-case), and then simply create a RAW socket that
> only listens on packets that have the specified ethernet types. We
> use something similar at work for a high-availability application.

Same here.  What I'm working on is a replacement for just such a
protocol.  The problem is that this whole scheme has to work easily
with the management program running on Windows. While doing a custom
Ethernet protocol on Linux is dead-simple (it does require either
UID==0 or CAP_NET_RAW), doing it on Windows is painful in the extreme.

Thus the requirement to use something that works using "normal UDP" on
the manager end of things (even if it requires jumping through some
hoops on the device end).  

[Insert standard whinge about how once again, Microsoft royally
botches something and we non-Windows people have to suffer.]

-- 
Grant Edwards               grant.b.edwards        Yow! ... I want to perform
                                  at               cranial activities with
                              gmail.com            Tuesday Weld!!

[toc] | [prev] | [next] | [standalone]

#3720

On 2011-04-20, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2011-04-20, Heiko Wundram <modelnine@modelnine.org> wrote:

>>> I've thought about the SOCK_RAW option, but the CPU load of looking
>>> all received Ethernet packets in user-space would be a big down-side.
>>
>> Not necessarily: instead of using UDP datagrams to send the data,
>> use ethernet datagrams (without any IP/UDP header) with your own
>> ethernet-type (there is a range of "local" types that you can use for
>> your own local use-case), and then simply create a RAW socket that
>> only listens on packets that have the specified ethernet types. We
>> use something similar at work for a high-availability application.
>
> Same here. What I'm working on is a replacement for just such a
> protocol.

Now that I think of it, I added raw socket support to Python just so I
could implement that protocol in Python!

[A rather vain attempt to inject some Python content back into the
thread.]

-- 
Grant Edwards               grant.b.edwards        Yow! Awright, which one of
                                  at               you hid my PENIS ENVY?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#3726

On 2011-04-20, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2011-04-20, Heiko Wundram <modelnine@modelnine.org> wrote:
>> Am 20.04.2011 01:54, schrieb Grant Edwards:
>>> I guess the problem is that I expected to receive a packet on an
>>> interface anytime a packet was received with a destination IP address
>>> that matched that of the the interface.  Apprently there's some
>>> filtering in the network stack based on the _source_ address as well
>>> (that seems very counter-intuitive to me).
>>
>> Just to pitch in here (because nobody's mentioned it yet AFAICT): yes,
>> there's a filtering done (at least under Linux, and I'd guess something
>> similar on xBSD too) to packets based on the source address coming in on
>> an interface, and it's called the reverse path filter and is on by
>> default (the tunable on Linux is /proc/sys/net/ipv4/conf/*/rp_filter).
>
> Brilliant!  While I had determined that such filtering took place, I'd
> been unable to figure out if it was configurable.

Bingo!

Turning off reverse-path filtering solved my original problem (not
receiving broadcasts sent to 255.255.255.255 because the source IP
wasn't reachable via the receiving interface).

It doesn't help with the "new" requirement of receiving subnet
broadcasts that don't match the interface on which they're received,
since it's destination IP filtering that's dropping those.

Apparently that requirement is due to the fact that on some OSes (some
flavors of BSD and Windows) applications can't broadcast to
255.255.255.255, they can only do subnet broadcasts.

-- 
Grant Edwards               grant.b.edwards        Yow! I wish I was a
                                  at               sex-starved manicurist
                              gmail.com            found dead in the Bronx!!

[toc] | [prev] | [next] | [standalone]

#3607

On Tue, Apr 19, 2011 at 3:21 PM, Grant Edwards <invalid@invalid.invalid> wrote:
> I'm have problems figuring out how to receive UDP broadcast packets on
> Linux.
>
> Here's the receiving code:
>
> ------------------------------receive.py-------------------------------

> But, the receiving Python program never sees any packets unless the
> _source_ IP address in the packets is on the same subnet as the
> receiving machine.

This is just how broadcasts work.

Normally, you take your subnet mask and "bitwise and" it with the IP
addresses of the sending and receiving machines.  If the results match
for two such pairs on two different machines, then the broadcast
should be visible, given appropriate code.

However, some routers have the ability to pass packets from one subnet
to another.  I believe this is called a "helper", at least in the
Cisco world, and must be configured specially.

[toc] | [prev] | [next] | [standalone]

#3614

On 2011-04-19, Dan Stromberg <drsalists@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 3:21 PM, Grant Edwards <invalid@invalid.invalid> wrote:
>> I'm have problems figuring out how to receive UDP broadcast packets on
>> Linux.
>>
>> Here's the receiving code:
>>
>> ------------------------------receive.py-------------------------------
>
>> But, the receiving Python program never sees any packets unless the
>> _source_ IP address in the packets is on the same subnet as the
>> receiving machine.
>
> This is just how broadcasts work.
>
> Normally, you take your subnet mask and "bitwise and" it with the IP
> addresses of the sending and receiving machines.  If the results match
> for two such pairs on two different machines, then the broadcast
> should be visible, given appropriate code.

That certainly looks like what's hapenning, but it seems very
counter-productive to me.

If I send a packet to ff:ff:ff:ff:ff:ff--255.255.255.255, it's because
I want everybody on the Ethernet segment to receive it.  If I wanted
only people on a particular subnet (e.g. 10.0.0.0/8) to receive it, I
would have sent it to the subnet broadcast address (e.g. 10.255.255.255).

> However, some routers have the ability to pass packets from one subnet
> to another.  I believe this is called a "helper", at least in the
> Cisco world, and must be configured specially.

There are no routers or firewalls involved -- just a dumb Ethernet
switch.

It seems I'm going to have to use raw sockets to do what I need to do.
That's exactly what I was trying to avoid by using UDP: I'm replacing
a proprietary (non IP) MAC-level protocol that was implemented using
raw sockets.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm young ... I'm
                                  at               HEALTHY ... I can HIKE
                              gmail.com            THRU CAPT GROGAN'S LUMBAR
                                                   REGIONS!

[toc] | [prev] | [next] | [standalone]

#3619

On Wed, Apr 20, 2011 at 10:00 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> If I send a packet to ff:ff:ff:ff:ff:ff--255.255.255.255, it's because
> I want everybody on the Ethernet segment to receive it.  If I wanted
> only people on a particular subnet (e.g. 10.0.0.0/8) to receive it, I
> would have sent it to the subnet broadcast address (e.g. 10.255.255.255).

> It seems I'm going to have to use raw sockets to do what I need to do.
> That's exactly what I was trying to avoid by using UDP: I'm replacing
> a proprietary (non IP) MAC-level protocol that was implemented using
> raw sockets.

I have to ask:

1) Why do you have two subnets on the same switch? Isn't that going to
be an eternal maintenance headache? Not that it _can't_ be done -
obviously it can - but it's likely to confuse the humans involved.

2) Can you replace that protocol at a higher level? Presumably there's
a full protocol stack with application data getting wrapped up inside
(ultimately) ethernet frames; can you cut it somewhere else and make,
say, a TCP/IP connection to the remote system?

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#3679

Am 20.04.2011 00:21, schrieb Grant Edwards:
> I'm have problems figuring out how to receive UDP broadcast packets on
> Linux.
[...]
>
> On the receiving machine, I've used tcpdump to verify that broadcast
> packets are being seen and have a destination IP of 255.255.255.255 and
> destination MAC of ff:ff:ff:ff:ff:ff
[...]
> But, the receiving Python program never sees any packets unless the
> _source_ IP address in the packets is on the same subnet as the
> receiving machine.  In this test case, the receiving machine has an IP
> address of 172.16.12.34/16.  If I change the receiving machine's IP
> address to 10.0.0.123, then the receiving program sees the packets.
>
> Even though the destination address is 255.255.255.255, the receiving
> machine appears to discard the packets based on the _source_ IP.  Can
> anybody provide example Python code for Linux that receives UDP
> broadcast packets regardless of their source IP address?
>
> This probably is more of a Linux networking question than a Python
> question, but I'm hoping somebody has solved this problem in Python.
>

You must set the network interface to promiscous mode on the receiving side:

os.system("ifconfig eth0 promisc")

Thomas

[toc] | [prev] | [next] | [standalone]

#3713

On 2011-04-20, Thomas Heller <theller@ctypes.org> wrote:
> Am 20.04.2011 00:21, schrieb Grant Edwards:
>> I'm have problems figuring out how to receive UDP broadcast packets on
>> Linux.
> [...]
>>
>> On the receiving machine, I've used tcpdump to verify that broadcast
>> packets are being seen and have a destination IP of 255.255.255.255 and
>> destination MAC of ff:ff:ff:ff:ff:ff
> [...]
>> But, the receiving Python program never sees any packets unless the
>> _source_ IP address in the packets is on the same subnet as the
>> receiving machine.  In this test case, the receiving machine has an IP
>> address of 172.16.12.34/16.  If I change the receiving machine's IP
>> address to 10.0.0.123, then the receiving program sees the packets.
>>
>> Even though the destination address is 255.255.255.255, the receiving
>> machine appears to discard the packets based on the _source_ IP.  Can
>> anybody provide example Python code for Linux that receives UDP
>> broadcast packets regardless of their source IP address?
>>
>> This probably is more of a Linux networking question than a Python
>> question, but I'm hoping somebody has solved this problem in Python.
>>
>
> You must set the network interface to promiscous mode on the
> receiving side:
>
> os.system("ifconfig eth0 promisc")

Why?

The network interface is already receiving the packets I want, since
they're beign sent with a destination MAC of ff:ff:ff:ff:ff:ff.

-- 
Grant Edwards               grant.b.edwards        Yow! Spreading peanut
                                  at               butter reminds me of
                              gmail.com            opera!!  I wonder why?

[toc] | [prev] | [next] | [standalone]

#3755

On 2011-04-19, Grant Edwards <invalid@invalid.invalid> wrote:

> I'm have problems figuring out how to receive UDP broadcast packets on
> Linux.

Thanks to everybody for their help with what turned out to have little
or nothing to do with Python itself.

The main problem was reverse-path filtering (which is enabled by
default on Linux). Disabling it allowed me to receive packets sent to
255.255.255.255 regardless of the sender's IP address.

Another minor issue that cropped up was that I ended up having to use
two sockets: an Rx socket bound to ('',port) and a Tx socket bound to
(myip,port).

Even though the protocol spec said that subnet broadcasts were used,
tracing a few transactions between existing implementations showed
that only global broadcasts were used. More testing showed that
existing implementations won't respond to subnet broadcasts unless
they're already configured to be on the proper subnet.  So, receiving
subnet broadcasts that don't match an interface turned out to be a
wild goose chase.

It's all working now...

-- 
Grant Edwards               grant.b.edwards        Yow! Everywhere I look I
                                  at               see NEGATIVITY and ASPHALT
                              gmail.com            ...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web