Re: [PATCH v2 0/1] ieee802154: cc2520: Check CRC & add promiscuous

[Alexander Aring <alex.aring@gmail.com>]

On Wed, Dec 23, 2015 at 03:17:57AM -0500, Brad Campbell wrote:
> I've updated the patch to provide monitors a method for determining if
> the incoming packet had a valid CRC or not. This required adding promiscuous
> mode, which is no longer the default.
> 
> Also, am I correct in noting that configuring a node interface to be in
> promiscuous mode with something like:
> 
> ioctl(sockfd, SIOCGIFFLAGS, &ifopts);
> ifopts.ifr_flags |= IFF_PROMISC;
> ioctl(sockfd, SIOCSIFFLAGS, &ifopts);
> 
> is not currently supported? That's how I was testing at first and it
> didn't seem to work.... Also, if a user does set an interface to
> promiscuous using an ioctl, it seems like they would still want CRC
> checking, which is not what would currently happen.
> 

These flags does nothing, like in wireless we need to create a special
interface type for starting in promiscuous mode. Try [0].

The receiving path and the reason that monitors has no addresses is why
we handle it in that way.

All "NODE" types need to be parsed again on 802.15.4 conform header and
doing address filtering/etc stuff again. This is different on "MONITOR"
types, we parse nothing and this goes directly into userspace, the PHR
header (the len field) is the only thing which we should filter and
mostly in-driver because after frame[len] there is much moslty some
data (lqi/rssi/etc).


When you sniff on normal "NODE" type, then you will sniff with transceiver
filtering stuff enabled (address filtering/frame/etc.) what the
transceiver does AND what mac802154 does.

- Alex

[0] http://wpan.cakelab.org/#_sniffing