Hello, On Sat, Mar 3, 2012 at 10:10 PM, Felix Varghese <felixv1...@gmail.com> wrote: > On 3 March 2012 02:48, Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote: >> On Fri, Mar 2, 2012 at 3:52 PM, Felix Varghese <felixv1...@gmail.com> wrote: >>> Guys, I'd like to join the foray too :) >>> >>>> I'm sorry but your suggestions make nearly no sense. The current design >>>> is targeted different applications and different types of interfaces which >>>> can be bound to each radio. >>> Ability to bind different types of interfaces to the same radio is >>> desirable. However, is there any scenario where multiple interfaces >>> would be simultaneously bound to the same radio at the same time? Or >>> did I misunderstand the purpose of storing a list of slaves in >>> mac802154_priv? Also, wouldn't this cause some confusion as to which >>> specific interface should handle packets received over a particular >>> radio? >> >> Yes. I want to have ability to bind monitor together with _any_ other >> interface. >> We do not have that implemented, but most probably being a retransmitter >> (coordinator in one segment and a child node in another) would require two >> interfaces bound to single node. I like the ability to control SMAC and >> 802.15.4 >> from single radio. Or another sample - participating in two different >> 802.15.4 >> networks at the same time. This reqires two subinterfaces. So, this should >> stay as it is, unless I see strong arguments to do it another way. >> >> And no, this won't cause any confusion: all interfaces bound to radio >> receive all >> packets (by design). It is a part of the interface to understand if it >> should receive >> this packet and handle it accordingly (drop). Consider two PANs on single >> radio. >> Each subinterface will receive all packets and drop all packets which belong >> to >> other PAN. > > Most 802.15.4 transceivers in the market today provide a lot of > hardware acceleration, such as support for address filtering, auto > acknowledgement, CRC checking, retries and CSMA, etc. To use this kind > of features, the transceiver needs to 'know' its own short address, > MAC address, PAN ID etc. Such a transceiver is either in promiscuous > mode, sniffing all packets, ACKing none, or it is part of a network, > only ACKing and accepting packets addressed to it and maybe even > keeping its receiver off (sleepy devices, beaconed networks, etc.) to > save power when possible. A monitor attached to such a radio would > only catch packets addressed to itself.
AFAIR the major part of that acceleration that can not be done in kernel space is sending ACK. So, it is a matter of setup. If user asks for accelerated iface from driver, he then can not ask for monitor, SMAC or any other subiface. But it is perfectly legal to have unaccelerated 802.15.4 together with monitor or SMAC interfaces (I had such setup for a while on my stand). It is for the driver to decide. In 802.11 world it is a driver who decides if the user can allocate any interface, not core layer. BTW: I remember rf231/rf212 chips having ACK/filter MAC acceleration. Does Atmel have a chip with support for beaconing or beaconed networks? > As far as a single radio joining two PANs is concerned, in case the > aforementioned hardware acceleration is used, it cannot be done, > unless the radio itself supports dual addresses, pan ids, etc. If such > a radio does arrive in the market, can we not have two instances of > wpan phy itself, one bound to each such 'logical' radio? 76.164.216.197:8181 No, because it would be still a single radio with single channel settings. > >> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >> because MAC implementation is far from being complete. > > We were hoping to help you guys rectify that problem :) We really appreciate your efforts. Maybe we should meet on IRC or on ML to discuss your intentions, your goals and your plan. What do you think? -- With best wishes Dmitry ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
