On 2011-04-21, Dan Stromberg wrote:
> On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards
> wrote:
>> On 2011-04-20, Dan Stromberg wrote:
>>> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg wrote:
I agree though that you're kind of pushing IP in a direction it wasn't
intended to go.
>>>
>>
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 r
On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards wrote:
> On 2011-04-20, Dan Stromberg wrote:
>> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg 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 add
On 2011-04-19, Grant Edwards 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
defa
On 2011-04-20, Grant Edwards wrote:
> On 2011-04-20, Heiko Wundram 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
On 2011-04-20, Dan Stromberg 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
On 2011-04-20, Adam Tauno Williams wrote:
> On Wed, 2011-04-20 at 06:07 -0400, Sherm Pendley wrote:
>> Grant Edwards 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
On 2011-04-20, Grant Edwards wrote:
> On 2011-04-20, Heiko Wundram 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,
>> u
On 2011-04-20, Heiko Wundram 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
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
On 2011-04-20, Thomas Heller 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
On 2011-04-20, Dan Stromberg wrote:
> On Tue, Apr 19, 2011 at 6:15 PM, Grant Edwards
> 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 no
On 2011-04-20, Heiko Wundram 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
>> filte
On 2011-04-20, Roy Smith wrote:
> In article ,
> Grant Edwards 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
>> discover
On 2011-04-20, Dan Stromberg wrote:
> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg 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 prom
On Wed, 2011-04-20 at 06:07 -0400, Sherm Pendley wrote:
> Grant Edwards 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
>
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:
Grant Edwards 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 ge
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 _sou
In article ,
Grant Edwards 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 d
On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg 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
On Tue, Apr 19, 2011 at 6:15 PM, Grant Edwards 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
On 2011-04-20, Chris Angelico wrote:
> On Wed, Apr 20, 2011 at 11:15 AM, Grant Edwards
> 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 no
On Wed, Apr 20, 2011 at 11:15 AM, Grant Edwards 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
On 2011-04-20, Chris Angelico wrote:
> On Wed, Apr 20, 2011 at 10:09 AM, Grant Edwards
> 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
On Wed, Apr 20, 2011 at 10:09 AM, Grant Edwards 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.
>
On Wed, Apr 20, 2011 at 10:00 AM, Grant Edwards 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
On 2011-04-19, Dan Stromberg wrote:
> On Tue, Apr 19, 2011 at 4:40 PM, Irmen de Jong 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
On 2011-04-19, Dan Stromberg wrote:
> On Tue, Apr 19, 2011 at 3:21 PM, Grant Edwards
> wrote:
>> I'm have problems figuring out how to receive UDP broadcast packets on
>> Linux.
>>
>> Here's the receiving code:
>>
>> --receive.py---
>
>> Bu
On 2011-04-19, Irmen de Jong 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
On Tue, Apr 19, 2011 at 4:40 PM, Irmen de Jong 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
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 3:21 PM, Grant Edwards 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 pac
On 2011-04-19, Irmen de Jong 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/py
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.arg
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.setsockop
36 matches
Mail list logo
