Problem receiving UDP broadcast packets.

Grant Edwards 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
   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            



More information about the Python-list mailing list