Hi, On 09/06/2016 10:00 AM, Oleg Hahm wrote: > Hey Alex! > > On Tue, Sep 06, 2016 at 08:48:13AM +0200, Alexander Aring wrote: >>> In case netopt is "NETOPT_SRC_LEN" and the value is >>> "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets >>> the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag. >>> >>> https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173 >>> >> >> I don't know why this goes down through the driver layer. The address >> filter doesn't need such information if you use as source address long >> or short. >> >> For me it's unclear for what this sourc_len really is made for. I would >> suggest to use the best address setting which do the most smallest >> payload. Sure, there exists situation to overwrite such setting - but >> this should be done not as an interface setting. > > Maybe I miss something, but how should the driver know which L2 address format > is expected at the receiver's side? >
Why the driver needs to know about that? The driver doesn't build mac frames. Well, there exists hardmac transceivers which do building mac frames on transceiver side. I never had some hardmac transceiver so I am unsure how they really work and which API they offer. I know that neighbour discovery knows if neighbour has short and extended address. For purely L2 solution you might need to have coordinator support etc. It's job of some upper-layer to provide such mapping, or you do some force setting like NETOPT_SRC_LEN which I suggest what it is. I can understand that this goes to the driver layer for some hardmac transceivers which accepts mac payload data only and builds the mac frame on transceivers side. - Alex _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
