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
On 2011-04-21, Dan Stromberg drsali...@gmail.com wrote:
On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards invalid@invalid.invalid
wrote:
On 2011-04-20, Dan Stromberg drsali...@gmail.com wrote:
On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg drsali...@gmail.com wrote:
I agree though that you're
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
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.
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
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
On 2011-04-20, Dan Stromberg drsali...@gmail.com wrote:
On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg drsali...@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
On 2011-04-20, Roy Smith r...@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
On 2011-04-20, Heiko Wundram modeln...@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
On 2011-04-20, Dan Stromberg drsali...@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
On 2011-04-20, Thomas Heller thel...@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
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
On 2011-04-20, Heiko Wundram modeln...@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
On 2011-04-20, Grant Edwards invalid@invalid.invalid wrote:
On 2011-04-20, Heiko Wundram modeln...@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
On 2011-04-20, Adam Tauno Williams awill...@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
On 2011-04-20, Dan Stromberg drsali...@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
On 2011-04-20, Grant Edwards invalid@invalid.invalid wrote:
On 2011-04-20, Heiko Wundram modeln...@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
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
On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards invalid@invalid.invalid wrote:
On 2011-04-20, Dan Stromberg drsali...@gmail.com wrote:
On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg drsali...@gmail.com wrote:
I agree though that you're kind of pushing IP in a direction it wasn't
intended to go.
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)
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]
On 2011-04-19, Irmen de Jong irmen.nos...@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---
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
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.
On Tue, Apr 19, 2011 at 4:40 PM, Irmen de Jong irmen.nos...@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
On 2011-04-19, Irmen de Jong irmen.nos...@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
On 2011-04-19, Dan Stromberg drsali...@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:
On 2011-04-19, Dan Stromberg drsali...@gmail.com wrote:
On Tue, Apr 19, 2011 at 4:40 PM, Irmen de Jong irmen.nos...@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.
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
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
On 2011-04-20, Chris Angelico ros...@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
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
On 2011-04-20, Chris Angelico ros...@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
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
On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg drsali...@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
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
36 matches
Mail list logo
