Re: Promiscuous patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alex,

I noticed the 802.15.4 spec mentions that when promiscuous mode is set it zeroes out the source and destination addressing mode of received packets which seems to suggest that the packet should not be handled by the stack also implying this is a monitor mode. Carry on with your design which I've had a chance to look through and it looks great. I can implement whatever I need in a separate debug branch.

- Martin.

On 19/09/14 11:11, Alexander Aring wrote:
On Thu, Sep 18, 2014 at 10:34:45PM +0200, Alexander Aring wrote:
On Thu, Sep 18, 2014 at 08:53:48PM +0200, Alexander Aring wrote:
On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
...
and I hope we clarified now that promiscuous mode with NODE/WPAN type
doesn't make any sense than increasing cpu load. You don't get more
frames into userspace.
We are implementing 802.15.4 on powerline.  If we had say a peer to peer
network involving 4 different PANs and because we aren't restricted by
distance as much as wireless we could potentially put one of the Coordinator
nodes into promiscuous mode and then capture traffic from all 4 PAN's
whereas if we are filtering we only see the traffic for the PAN(s) we are
involved in.  Wouldn't this be more frames that just the filter?

I can't follow, with monitor interface you will get any frame from pans,
also all frame types like ACK's etc... you can also send some frames
(okay the 802.15.4 standard doesn't say that) but at86rf231 seems to
allow this.

I need to show you moooore implementation details, then you know what a
WPAN/NODE type does on receiving and MONITOR will do on receiving.

WPAN/NODE/COORD -> have hardwware filtering, addresses, FCS etc..

MONITOR -> Doesn't filter anything, okay it filters when a SFD was
            receivied but nothing more.

Now LINUX the "mac802154" does also do filtering stuff, but only on
WPAN/NODE/COORD because these are to interact practical in a network,
not just sniffing.

On WPAN/NODE/COORD we have filter in mac802154, see [0]. This shows
frame parsing of data frames. You can more look into this how this works.
Now if you have address filter on PHY you will decreasing the load of
mac802154, because most of these frames are already filtered by the phy.

NOW if you set promiscuous mode on WPAN/NODE you increasing workload but
the most frames will dropped at [0]. You don't get more frames into the
interface (userspace). You only increasing the workload of the cpu.


On Monitor interface the PHY doesn't filter anything and the filtering
of [0] is disabled. It's directly send it to the interface so you can
see all frames, also frames which doesn't belong to you.
What a monitor interface does on receiving is [1]. Don't check anything
directly send it to the MONITOR interface. That's why I said "the
monitor interface is a big userspace playground - no filtering on PHY
and kernel is involved".

Is there maybe some practical use for being in promiscuous mode and
operate as coordinator/node? Is that what you want?

I see this could make also big trouble because ACK handling is disabled
in promiscuous mode. So in ARET networks this could really make trouble.
On at86rf231 there is a switch to enable/disable ack handling, datasheet
describes always to disable ACK handling there, need to look what
802.15.4-2011 says for this.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux