Problem receiving UDP broadcast packets.

[Grant Edwards]

On 2011-04-20, Heiko Wundram <modelnine at 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!!