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 1 of 2  [1] 2  Next page →

#3597 — Problem receiving UDP broadcast packets.

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

Here's the receiving code:

------------------------------receive.py-------------------------------
#!/usr/bin/python
import socket

host = ''
port = 5010

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.bind((host, port))

while 1:
    try:
        message = s.recv(8192)
        print "Got data: %s" % repr(message)
    except KeyboardInterrupt:
        break
----------------------------------------------------------------------

Here's the sending code:

--------------------------------send.py-------------------------------
#!/usr/bin/python
import sys,socket,time

host = sys.argv[1]
port = 5010

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.bind((host,port))

s.sendto(str(time.time()), ('255.255.255.255', port))
----------------------------------------------------------------------


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

03:05:09.187327 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
        0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
        0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
        0x0020:  ffff 1392 1392 0015 6e6e 3133 3033 3235
        0x0030:  3131 3830 2e34 3500 0000
03:05:09.407508 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
        0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
        0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
        0x0020:  ffff 1392 1392 0015 6c6c 3133 3033 3235
        0x0030:  3131 3830 2e36 3700 0000
03:05:09.615962 IP 10.0.0.1.5010 > 255.255.255.255.5010: UDP, length 13
        0x0000:  ffff ffff ffff 0018 e708 2033 0800 4500
        0x0010:  0029 0000 4000 4011 30c4 0a00 0001 ffff
        0x0020:  ffff 1392 1392 0015 6b6a 3133 3033 3235
        0x0030:  3131 3830 2e38 3800 0000

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.

-- 
Grant Edwards               grant.b.edwards        Yow! I want my nose in
                                  at               lights!
                              gmail.com            

[toc] | [next] | [standalone]

#3601

On 20-4-2011 0:21, Grant Edwards wrote:
> I'm have problems figuring out how to receive UDP broadcast packets on
> Linux.
> 
[...]

> Here's the sending code:
> 
> --------------------------------send.py-------------------------------
> #!/usr/bin/python
> import sys,socket,time
> 
> host = sys.argv[1]
> port = 5010
> 
> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
> s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
> s.bind((host,port))

I don't think you should use s.bind() at all in the sending code.
Could that be at least part of the problem?


-Irmen

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

#3602

On 2011-04-19, Irmen de Jong <irmen.NOSPAM@xs4all.nl> wrote:
> On 20-4-2011 0:21, Grant Edwards wrote:
>> I'm have problems figuring out how to receive UDP broadcast packets on
>> Linux.
>> 
> [...]
>
>> Here's the sending code:
>> 
>> --------------------------------send.py-------------------------------
>> #!/usr/bin/python
>> import sys,socket,time
>> 
>> host = sys.argv[1]
>> port = 5010
>> 
>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>> s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
>> s.bind((host,port))
>
> I don't think you should use s.bind() at all in the sending code.
> Could that be at least part of the problem?

If I don't call bind(), then the broadcast packets go out the wrong
interface on the sending machine.

-- 
Grant Edwards               grant.b.edwards        Yow! Vote for ME -- I'm
                                  at               well-tapered, half-cocked,
                              gmail.com            ill-conceived and
                                                   TAX-DEFERRED!

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

#3608

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. Unless the routing between
the subnets is somehow done on the receiving machine itself? My knowledge of networks
and TCP/IP ends here I'm afraid.

Cheers
Irmen.

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

#3609

On Tue, Apr 19, 2011 at 4:40 PM, 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. Unless the routing between
> the subnets is somehow done on the receiving machine itself? My knowledge of networks
> and TCP/IP ends here I'm afraid.
>
> Cheers
> Irmen.

I'm guessing there are two different subnets on the same physical
cable - which is a little unusual, but not impossible.

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

#3617

On 2011-04-19, Dan Stromberg <drsalists@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 4:40 PM, 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. Unless the routing between
>> the subnets is somehow done on the receiving machine itself? My knowledge of networks
>> and TCP/IP ends here I'm afraid.
>
> I'm guessing there are two different subnets on the same physical
> cable

Yes -- though technically they're on the same Ethernet segment rather
than physical cable, since there's an intervening Ethernet switch.

> - which is a little unusual, but not impossible.

OK, here's some background...

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.

The management program can then send another broadcast packet to
configure the IP address of a device. After that, the management
program switches over to normal unicast TCP and UDP protocols (HTTP,
TFTP, etc.) to set up the device.

I had ignorantly assumed that an UDP broadcast sent to IP address
255.255.255.255 would be received by everybody who could hear it.

Apparently I'm going to have to use RAW packets and implement UDP
myself. :/

-- 
Grant Edwards               grant.b.edwards        Yow! BELA LUGOSI is my
                                  at               co-pilot ...
                              gmail.com            

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

#3622

On Wed, Apr 20, 2011 at 10:09 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> The management program can then send another broadcast packet to
> configure the IP address of a device. After that, the management
> program switches over to normal unicast TCP and UDP protocols (HTTP,
> TFTP, etc.) to set up the device.
>

Wonder if it would be possible to (ab)use DHCP for this. If every
device registers itself with a central DHCP server, you could query
that to find out what's around, and configuring of IP addresses would
then be out of your hands.

Or can you simply use a stupid netmask like /1 that picks up all the
IP ranges? That way, the source-IP check wouldn't fail.

Chris Angelico

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

#3624

On 2011-04-20, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Apr 20, 2011 at 10:09 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> The management program can then send another broadcast packet to
>> configure the IP address of a device. After that, the management
>> program switches over to normal unicast TCP and UDP protocols (HTTP,
>> TFTP, etc.) to set up the device.
>>
>
> Wonder if it would be possible to (ab)use DHCP for this. If every
> device registers itself with a central DHCP server, you could query
> that to find out what's around, and configuring of IP addresses would
> then be out of your hands.

I can't require the presense of a DHCP server, and many installations
won't have one.

> Or can you simply use a stupid netmask like /1 that picks up all the
> IP ranges? That way, the source-IP check wouldn't fail.

That would require that the device somehow knows that it's not
configured correctly and should change the netmask to /1.  The device
doesn't have any way to know that, and it must respond to the
discovery commands both before and after it's properly configured.

I've reread the protocol documentation and noticed that the device has
to respond not only to broadcasts to 255.255.255.255 but also to
subnet broadcasts send to subnets it's not on.  That pretty much
clinches the requirement to use a raw socket. :/

-- 
Grant

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

#3626

On Wed, Apr 20, 2011 at 11:15 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> Or can you simply use a stupid netmask like /1 that picks up all the
>> IP ranges? That way, the source-IP check wouldn't fail.
>
> That would require that the device somehow knows that it's not
> configured correctly and should change the netmask to /1.  The device
> doesn't have any way to know that, and it must respond to the
> discovery commands both before and after it's properly configured.

Was hoping that you could make such a change _only_ on the computer
that's receiving the data - that way it's only one change, the devices
don't need any tweaking. But if it can't be, it can't be.

> I've reread the protocol documentation and noticed that the device has
> to respond not only to broadcasts to 255.255.255.255 but also to
> subnet broadcasts send to subnets it's not on.  That pretty much
> clinches the requirement to use a raw socket. :/

Sounds to me like someone majorly abused IP to do weird things. Looks
like you're stuck doing the same weirdness, in whatever way you can
manage :| Sorry.

Chris Angelico

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

#3632

On 2011-04-20, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Apr 20, 2011 at 11:15 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>>> Or can you simply use a stupid netmask like /1 that picks up all the
>>> IP ranges? That way, the source-IP check wouldn't fail.
>>
>> That would require that the device somehow knows that it's not
>> configured correctly and should change the netmask to /1. ?The device
>> doesn't have any way to know that, and it must respond to the
>> discovery commands both before and after it's properly configured.
>
> Was hoping that you could make such a change _only_ on the computer
> that's receiving the data - that way it's only one change, the devices
> don't need any tweaking. But if it can't be, it can't be.

There can by any number of devices that have to receive the broadcast
packet, and any of them can be on different subnets (or have no IP
address at all).

>> I've reread the protocol documentation and noticed that the device
>> has to respond not only to broadcasts to 255.255.255.255 but also to
>> subnet broadcasts send to subnets it's not on.

It turns out that some OSes (BSD and some flavors of Windows) can't
broadcast to 255.255.255.255, only to the subnet broadcast address.
Hence the requirement for the devices to be able to receive a subnet
broadcast regardless of their IP address.

>> That pretty much clinches the requirement to use a raw socket. :/
>
> Sounds to me like someone majorly abused IP to do weird things.

Indeed.  The other option is to do something that's not based on IP
but done completely at the Ethernet layer.  Implementing management
programs that can do that can be very nasty on Windows, which
unfortunately matters to most customers.

So you bite the bullet on the device end and implement all sorts of
weirdness in order to allow the management program to use standard
UDP.

> Looks like you're stuck doing the same weirdness, in whatever way you
> can manage

Yup.  It doesn't even appear that it can be done with a raw UDP
socket. According to all of the documentation I can find, such a
socket is supposed to receive copies of all UDP packets seen by the
kernel, but it doesn't.  Even if I use a raw UDP socket, the kernel is
still dropping broadcast packets whose source address don't match any
interface's subnet.

AFAICT, I'm going to have to go completely raw and process in
user-space every single IP packet recieved.  That's going to be
brutal on the CPU...

-- 
Grant

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

#3634

On Tue, Apr 19, 2011 at 6:15 PM, Grant Edwards <invalid@invalid.invalid> wrote:

>> Or can you simply use a stupid netmask like /1 that picks up all the
>> IP ranges? That way, the source-IP check wouldn't fail.
>
> That would require that the device somehow knows that it's not
> configured correctly and should change the netmask to /1.  The device
> doesn't have any way to know that, and it must respond to the
> discovery commands both before and after it's properly configured.

- Actually, you Might be able to configure your device to have a
netmask of 0.0.0.0, IP address of 255.255.255.255 and broadcast of
255.255.255.255.
- I've seen something a bit similar used for detecting IP address
conflicts automatically.
- A network guru I used to work with told me that you could configure
a machine with a broadcast of 255.255.255.255 more simply than messing
around with the netmask, while still achieving the same result for
general purpose networking.

> I've reread the protocol documentation and noticed that the device has
> to respond not only to broadcasts to 255.255.255.255 but also to
> subnet broadcasts send to subnets it's not on.  That pretty much
> clinches the requirement to use a raw socket. :/

With a netmask of 0.0.0.0, I suspect you will receive all broadcasts
on the wire, given appropriate listening code.

You could probably also modify a copy of tshark or tcpdump to flush
after every line of output (or run an unmodified one on a pty to avoid
maintaining your own copy of the binary), and parse that output in
Python.  That should make the Python code pretty simple.

There's an old program called "pty" that makes it easy to run
something on a pty, to get unbuffered output - it's in
comp.sources.unix volumes 22, 23 and 25; it's written in C.  You'd
just open a subprocess with no buffering on the python side, that runs
tcpdump or tshark under pty.  Beware though - the pty program predates
GNU autoconf, so might be a little involved to compile.

I agree though that you're kind of pushing IP in a direction it wasn't
intended to go.

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

#3712

On 2011-04-20, Dan Stromberg <drsalists@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 6:15 PM, Grant Edwards <invalid@invalid.invalid> wrote:
>
>>> Or can you simply use a stupid netmask like /1 that picks up all the
>>> IP ranges? That way, the source-IP check wouldn't fail.
>>
>> That would require that the device somehow knows that it's not
>> configured correctly and should change the netmask to /1. ?The device
>> doesn't have any way to know that, and it must respond to the
>> discovery commands both before and after it's properly configured.
>
> - Actually, you Might be able to configure your device to have a
> netmask of 0.0.0.0, IP address of 255.255.255.255 and broadcast of
> 255.255.255.255.
> - I've seen something a bit similar used for detecting IP address
> conflicts automatically.
> - A network guru I used to work with told me that you could configure
> a machine with a broadcast of 255.255.255.255 more simply than messing
> around with the netmask, while still achieving the same result for
> general purpose networking.

I'll look into that.

>> I've reread the protocol documentation and noticed that the device has
>> to respond not only to broadcasts to 255.255.255.255 but also to
>> subnet broadcasts send to subnets it's not on. ?That pretty much
>> clinches the requirement to use a raw socket. :/
>
> With a netmask of 0.0.0.0, I suspect you will receive all broadcasts
> on the wire, given appropriate listening code.

That might be an option as well, as long as it doesn't disrupt normal
operation of the interface.

-- 
Grant Edwards               grant.b.edwards        Yow! Remember, in 2039,
                                  at               MOUSSE & PASTA will
                              gmail.com            be available ONLY by
                                                   prescription!!

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

#3724

On 2011-04-20, Dan Stromberg <drsalists@gmail.com> wrote:

> - Actually, you Might be able to configure your device to have a
>   netmask of 0.0.0.0, IP address of 255.255.255.255 and broadcast of
>   255.255.255.255.

255.255.255.255 isn't allowed as an IP address.

I tried a netmask of 0.0.0.0, and it didn't make any differnce.

-- 
Grant Edwards               grant.b.edwards        Yow! My EARS are GONE!!
                                  at               
                              gmail.com            

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

#3635

On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg <drsalists@gmail.com> wrote:
> I agree though that you're kind of pushing IP in a direction it wasn't
> intended to go.

It just occurred to me: You might get some additional mileage out of
popping the network adapter into promiscuous mode.  In fact, it Might
be necessary irrespective of the rest of your approach.

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

#3706

On 2011-04-20, Dan Stromberg <drsalists@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg <drsalists@gmail.com> wrote:
>> I agree though that you're kind of pushing IP in a direction it wasn't
>> intended to go.
>
> It just occurred to me: You might get some additional mileage out of
> popping the network adapter into promiscuous mode.  In fact, it Might
> be necessary irrespective of the rest of your approach.

The network adapter is already receiving all the packets I want to
receive, so putting it into promiscuous mode would only increase the
number of unwanted packets.

-- 
Grant Edwards               grant.b.edwards        Yow! Send your questions to
                                  at               ``ASK ZIPPY'', Box 40474,
                              gmail.com            San Francisco, CA 94140,
                                                   USA

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

#3758

On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2011-04-20, Dan Stromberg <drsalists@gmail.com> wrote:
>> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg <drsalists@gmail.com> wrote:
>>> I agree though that you're kind of pushing IP in a direction it wasn't
>>> intended to go.
>>
>> It just occurred to me: You might get some additional mileage out of
>> popping the network adapter into promiscuous mode.  In fact, it Might
>> be necessary irrespective of the rest of your approach.
>
> The network adapter is already receiving all the packets I want to
> receive, so putting it into promiscuous mode would only increase the
> number of unwanted packets.

I think tcpdump and tshark (was tethereal) will put the interface into
promiscuous mode so it can see more traffic; on OSF/1 (Tru64), we had
to do this manually for said programs to see all that was possible
(barring the presence of a switch not repeating packets the way
routers and hubs would).

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

#3802

On 2011-04-21, Dan Stromberg <drsalists@gmail.com> wrote:
> On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2011-04-20, Dan Stromberg <drsalists@gmail.com> wrote:
>>> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg <drsalists@gmail.com> wrote:
>>>> I agree though that you're kind of pushing IP in a direction it wasn't
>>>> intended to go.
>>>
>>> It just occurred to me: You might get some additional mileage out of
>>> popping the network adapter into promiscuous mode. ?In fact, it Might
>>> be necessary irrespective of the rest of your approach.
>>
>> The network adapter is already receiving all the packets I want to
>> receive, so putting it into promiscuous mode would only increase the
>> number of unwanted packets.
>
> I think tcpdump and tshark (was tethereal) will put the interface into
> promiscuous mode so it can see more traffic;

It can (and by default does).  I was using "-p" so it didn't.

> on OSF/1 (Tru64), we had
> to do this manually for said programs to see all that was possible
> (barring the presence of a switch not repeating packets the way
> routers and hubs would).

 * The packets were being sent to MAC address ff:ff:ff:ff:ff:ff, so the
   NIC does not have to be in promiscuous mode to receive them.

 * tcpdump saw them even when it doesn't put the NIC in promiscuous
   mode.

 * The kernel was seeing the packets because it was logging them as
   martians and discarding them (something I didn't notice until later).

 * Turning off reverse-path filtering in the TCP stack allowed the
   packets to be received as expected.

-- 
Grant Edwards               grant.b.edwards        Yow! I was making donuts
                                  at               and now I'm on a bus!
                              gmail.com            

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

#3765

Am 21.04.2011 03:35, schrieb Dan Stromberg:
> I think tcpdump and tshark (was tethereal) will put the interface into
> promiscuous mode so it can see more traffic; on OSF/1 (Tru64), we had
> to do this manually for said programs to see all that was possible
> (barring the presence of a switch not repeating packets the way
> routers and hubs would).

It actually depends on the network adapter/card that's in use: many
modern cards (especially those in the lower price segment, i.e. Realtek)
don't (properly) implement "MAC"-filtering at the hardware level, and in
this case, there's no difference for the operating system between
promiscuous mode and non-promiscuous mode (because the card will forward
all packets that it sees coming in over the ethernet bus to the
operating system, which will then discard those at the ethernet level it
doesn't deem necessary to process at a higher level, for example because
the destination MAC is unicast, but not the cards own, so the
destination wasn't the system itself).

For pricier cards/chips, this filtering (which also includes restricting
the multicast-destinations that are forwarded to the operating system,
think IPv6-multicast which uses quite a range of multicast MAC addresses
for its neighbour discovery) is implemented at the hardware level, and
the ethernet adapter throws away uninteresting packets and doesn't
signal the operating system (think of the cost of interrupts you save;
on high throughput links, this makes perfect sense). Putting the card
into promiscuous mode basically disables this filtering, so that the
card will again forward all packets to the operating system.

This is why tcpdump for example puts the network adapter into
promiscuous mode, but normally (see above, depending on the network
adapter), that's not required because the operating system "sees all"
ethernet packets anyway.

-- 
--- Heiko.

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

#3640

In article <iol875$ah2$3@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> 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 considered what will happen if you have, say, 1000 such 
devices, and they all respond at the same time?

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

#3709

On 2011-04-20, Roy Smith <roy@panix.com> wrote:
> In article <iol875$ah2$3@reader1.panix.com>,
>  Grant Edwards <invalid@invalid.invalid> wrote:
>
>> 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 considered what will happen if you have, say, 1000 such 
> devices, and they all respond at the same time?

Yes.  Firstly, there will very rarely be more than a handful of such
devices.  Secondly, I plan on inserting a small, psuedo-random delay
before replying.  Thirdly, the management program typically repeats
the discovery process a few times in case any packets get dropped.



-- 
Grant Edwards               grant.b.edwards        Yow! Maybe we could paint
                                  at               GOLDIE HAWN a rich PRUSSIAN
                              gmail.com            BLUE --

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web