On Thu, Sep 18, 2014 at 11:04:42AM +0100, Martin Townsend wrote: > Hi Alex, > > If I'm following correctly you need to add a monitor interface as well as a node/coord interface to the PHY. so we would see wpan0 and wpanmon0 and then I could do a > tcpdump -i wpanmon0? > mhhh, no. It's a question of design to have NODE, COORD and MONITOR parallel. But when we have phy mac handling for a iftype we should not have this parallel. We have multiple interfaces support, BUT only ONE phy. The phy have also mac handling, like addressfilter XOR promiscousmode. The addressfilter doesn't interrupt the phy on ANY frame, only on frames which belongs to us (the phy). That's why addressfilter makes sense on NODE and COORD. After an interrupt the LINUX mac802154 stack also run a addressfilter to be sure. (BUT only on NODE and COORD types). The MONITOR type bypass the mac802154 filters and send any frame to the interface, then you can see it on wireshark. But this required to disable the addressfilter of mac phy handling -> promiscousmode. Now having NODE and MONITOR parallel, you can't have promiscousmode and addressfilter at the same time. promiscousmode disabled the addressfilter. But then the LINUX mac802154 have a very workload because it need to check any frame which is received on promiscousmode. This isn't pracitcal, also promiscousmode isn't only addressfiltering also CRC... When you enable the promiscousmode on WPAN/NODE interface you only enable that your cpu load increases because you don't have any phy addressfilter anymore, then mac802154 do the job for you and remember a MONITOR device bypass the mac802154 filtering, then you see ONLY on a MONITOR interface every frame. Also frames which not in your pan or doesn' belong to you. That's what's the monitor interface does. More understandable? :/ - 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
