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. 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? > 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 :) Regards, Felix. ------------------------------------------------------------------------------ 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
