On Wed, Dec 23, 2015 at 4:22 AM, Alexander Aring <alex.aring@xxxxxxxxx> wrote: > 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. > Is it possible to create two interfaces on a phy, one node and one monitor? Then the driver would be in promiscuous mode and not checking CRC, and the node interface would get packets with failed CRC with no way to check that they were wrong. > - Alex > > [0] http://wpan.cakelab.org/#_sniffing - Brad -- 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
