Problem receiving UDP broadcast packets.
invalid at invalid.invalid
Thu Apr 21 16:22:01 CEST 2011
On 2011-04-21, Dan Stromberg <drsalists at gmail.com> wrote:
> On Wed, Apr 20, 2011 at 7:21 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>> On 2011-04-20, Dan Stromberg <drsalists at gmail.com> wrote:
>>> On Tue, Apr 19, 2011 at 8:12 PM, Dan Stromberg <drsalists at 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
* 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!
More information about the Python-list