> 3. Why we have a list of slaves in the mac802154 implementation? To handle > one device with different channels? I don't know how this could work > with tx packets. I don't understand this point too. One point could be a device with more than one phy which is able to send on more than one channel. For tx packets the current stack implementation would set the channel of the hw device to the channel of the slave device. But for received frames, there is no information to get some information about the channel it was received on. So the most interesting option for such an device, sniffing on multiple channels, is missing some important information. I'm not aware of such an device existing anyhow...
The only point of the slave devices I'm aware of, is the monitor device, which can be used to sniff every received packet. Maybe implementing some support for promiscuous mode would do the same job here? Is anyone aware about what was the initial intention behind this multiple slave devices? Thanks, Sascha -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
