Re: [riot-devel] address option fields inside of NA/NS
On Tue, Mar 15, 2016 at 10:56:19AM +0100, Alexander Aring wrote: ... > > The most important question for me is MUST there always an extended > address option field inside NA/NS, because this address is unique and > always available. For short address handling address option field should > be appended if they are unicast valid. > Some example where extended addr as destination l2 address would be "?good?" when using stateless compression: In case of two RIOT nodes which has a "extended based" SLAAC address, the one which is fe80::$EXTENDED_ADDR with U/E bit flip. These two RIOT nodes has also a short address and addr_src is set to 2. IPHC scenario would be: If one node sends an IPv6 packet with _destination_ address of the other node (fe80::$EXTENDED_ADDR with U/E bit) it can't use the SAM/DAM bit compression method "11", because the neighbor cache only knows the short address it will not compressed with method "11". I think "01" will be used then to handle such compression, "64 bit's inline". If an extended address and short would be available, then using the extended address would give here a small benefit (saved two bytes). This doesn't mean that it doesn't work if extended address will not be part of address option fields, it's just that extended address has a little benefit here. I am still unsure if extended address in option field is a MUST, because this address always exists. :-/ - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Anyone going to IPSN?
Hi Michael, none from our side (some of us go to the IETF in Argentina the week before, so it's a near collision, unfortunately). If you're going to IPSN and you see anything interesting / relevant for this forum, please do let us know! Cheers, Emmanuel On Tue, Mar 15, 2016 at 12:53 PM, Michael Andersen wrote: > Hi > > Are any RIOT devs going to IPSN in Vienna in April? > > Thanks > Michael > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Anyone going to IPSN?
Hi Are any RIOT devs going to IPSN in Vienna in April? Thanks Michael ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] address option fields inside of NA/NS
Hi, On Tue, Mar 15, 2016 at 10:34:19AM +0100, Martine Lenders wrote: > Hi, > > 2016-03-15 9:35 GMT+01:00 Alexander Aring : > > Hi, > > > > On Mon, Mar 14, 2016 at 07:43:17PM +0100, Alexander Aring wrote: > >> Hi, > >> > >> while hacking the short address handling for Linux, I _maybe_ stumble > >> over some issue. > >> _Maybe_, because I am not sure how it really should work. > >> > >> The issue is that when setting src_len to 2 then a short address will be > >> part of source/target link address option only. > >> > >> For my knowledge the setting of "src_len" is wrong, the interface can > >> really have two mac addresses at the same time. According to 802.15.4 > >> the short address is somewhat optional. If they is available then add > >> them to the address option fields. (Then you have two address option > >> fields). > > src_len primary purpose is to identify the address mode the interface > uses for its source address, so I don't see how this can be "wrong". > You can't put both addresses in the 802.15.4 header. > Ah, okay. Then this is the default behaviour to use short XOR extended as source address. > >> General proceeding is (in my opinion), copy&pasted from irc: > >> > >> 16:37 < eintopf> I think extended address address field for extended > >> address (length==2) need to be always there, then if the short address > >> is valid (not 0x or 0xfffe, for unicast neighbour) then add also a > >> second option for short address. > >> > >> 16:50 < eintopf> so in NS/NA source/target link address option fields: > >> extended address _always_ AND short address if link short address is > >> valid (not 0x or 0xfffe). > >> > >> This is how I did it for linux. > > You are right that it might be possible to add both link-layer > addresses into a seperate SLLAO to NS/NA, but I don't really see a > reason why to do that: The L2 address should be "changed" (as in > mode-switched) as little as possible, so a new SLLAO can also be send > out on mode-switch. Which values are you referring to by "0x or > 0xfffe"? The stuffing for the IID? > 0x and 0xfffe are invalid _unicast_ short addresses according to 802.15.4 and 0x is default value. > > Additional notes: > > > > I also can't see the autoconfiguration for a short address based > > link-local address [0], when using short address. > > Because we have no proper SLAAC yet ;-) > ok. > > I think you need to have both addresses then, one based on extended and one > > based on (panid +) short. > > > > The SLAAC address based on short (+panid) is not compressable with > > SAM/DAM = 11 in IPHC for stateless compression, (it's in case if panid > > is zero only). > > The RFCs are very unclear on the whole PAN ID thing. RFC 4944 is > specifying the translation from short address to IID by including the > PAN ID, while RFC 6282 specifies it without, while not even referring > to the previous specification. Since RFC 6282 is the more current I > decided to go for its approach, while keeping the conversion PAN ID + > short => IID optionally in there, by having them as a virtual 32-bit > address of the device. > I think these are two different things. - RFC 4944 describes SLAAC addresses. - RFC 6282 describes how to compress addresses which has some format which based on short address. This isn't how to generate the SLAAC address for short addresses. I agree it would make sense to compress addresses which follows the SLAAC format according to RFC 4944, but for me it doesn't look like that they specifies it in that way. --- The most important question for me is MUST there always an extended address option field inside NA/NS, because this address is unique and always available. For short address handling address option field should be appended if they are unicast valid. What do you mean with "mode switched"? - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] address option fields inside of NA/NS
Hi, 2016-03-15 9:35 GMT+01:00 Alexander Aring : > Hi, > > On Mon, Mar 14, 2016 at 07:43:17PM +0100, Alexander Aring wrote: >> Hi, >> >> while hacking the short address handling for Linux, I _maybe_ stumble >> over some issue. >> _Maybe_, because I am not sure how it really should work. >> >> The issue is that when setting src_len to 2 then a short address will be >> part of source/target link address option only. >> >> For my knowledge the setting of "src_len" is wrong, the interface can >> really have two mac addresses at the same time. According to 802.15.4 >> the short address is somewhat optional. If they is available then add >> them to the address option fields. (Then you have two address option >> fields). src_len primary purpose is to identify the address mode the interface uses for its source address, so I don't see how this can be "wrong". You can't put both addresses in the 802.15.4 header. >> General proceeding is (in my opinion), copy&pasted from irc: >> >> 16:37 < eintopf> I think extended address address field for extended >> address (length==2) need to be always there, then if the short address >> is valid (not 0x or 0xfffe, for unicast neighbour) then add also a >> second option for short address. >> >> 16:50 < eintopf> so in NS/NA source/target link address option fields: >> extended address _always_ AND short address if link short address is >> valid (not 0x or 0xfffe). >> >> This is how I did it for linux. You are right that it might be possible to add both link-layer addresses into a seperate SLLAO to NS/NA, but I don't really see a reason why to do that: The L2 address should be "changed" (as in mode-switched) as little as possible, so a new SLLAO can also be send out on mode-switch. Which values are you referring to by "0x or 0xfffe"? The stuffing for the IID? > Additional notes: > > I also can't see the autoconfiguration for a short address based > link-local address [0], when using short address. Because we have no proper SLAAC yet ;-) > I think you need to have both addresses then, one based on extended and one > based on (panid +) short. > > The SLAAC address based on short (+panid) is not compressable with > SAM/DAM = 11 in IPHC for stateless compression, (it's in case if panid > is zero only). The RFCs are very unclear on the whole PAN ID thing. RFC 4944 is specifying the translation from short address to IID by including the PAN ID, while RFC 6282 specifies it without, while not even referring to the previous specification. Since RFC 6282 is the more current I decided to go for its approach, while keeping the conversion PAN ID + short => IID optionally in there, by having them as a virtual 32-bit address of the device. > I think to have "good compression" results you need also to have some > best-matching algorithmn EXTENDED vs SHORT, which address will do the best > compression for on the air frames. That is if you want it completely automated, yes. But I'm not sure we want that for RIOT. Cheers, Martine ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] IoT technology survey
Hi everyone, our friends from Eclipse Foundation are conducting a survey about IoT technologies currently in use or aimed at in various contexts. Maybe you can consider filling it in (and maybe the results will be of some interest). https://www.surveymonkey.com/r/AGILEIoT Best, Emmanuel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] address option fields inside of NA/NS
Hi, On Mon, Mar 14, 2016 at 07:43:17PM +0100, Alexander Aring wrote: > Hi, > > while hacking the short address handling for Linux, I _maybe_ stumble > over some issue. > _Maybe_, because I am not sure how it really should work. > > The issue is that when setting src_len to 2 then a short address will be > part of source/target link address option only. > > For my knowledge the setting of "src_len" is wrong, the interface can > really have two mac addresses at the same time. According to 802.15.4 > the short address is somewhat optional. If they is available then add > them to the address option fields. (Then you have two address option > fields). > > General proceeding is (in my opinion), copy&pasted from irc: > > 16:37 < eintopf> I think extended address address field for extended > address (length==2) need to be always there, then if the short address > is valid (not 0x or 0xfffe, for unicast neighbour) then add also a > second option for short address. > > 16:50 < eintopf> so in NS/NA source/target link address option fields: > extended address _always_ AND short address if link short address is > valid (not 0x or 0xfffe). > > This is how I did it for linux. > Additional notes: I also can't see the autoconfiguration for a short address based link-local address [0], when using short address. I think you need to have both addresses then, one based on extended and one based on (panid +) short. The SLAAC address based on short (+panid) is not compressable with SAM/DAM = 11 in IPHC for stateless compression, (it's in case if panid is zero only). I think to have "good compression" results you need also to have some best-matching algorithmn EXTENDED vs SHORT, which address will do the best compression for on the air frames. - Alex [0] https://tools.ietf.org/html/rfc4944#section-6 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ReSupport for Microchip MRF24J40 Radio Module
Hi Adika, it is as usual: took longer than expected. A WIP pull request should be opened soon. I'll force @TobiasFredersdorf ;-) to open it. If you have some experience with that device you can speed up development by (reviewing and) testing then. Best Peter Am 14.03.2016 um 20:59 schrieb Adika Bintang Sulaeman: Hallo Bernhard, I'm trying to use STM32F4 Discovery with MRF24J40 transceiver, but I didn't find the driver for this transceiver. It's a relief to see in this mailing list that you and Tobias are working on this driver and I hope the code will be merged soon. By the way, can I see the code you are working on? Maybe if it is possible I can fork the code through Github. Thank you Hello Malo, thanks a lot for your hint about the atzb-a-233-xpro module. I guess RIOT should support this module out of the box (as a reference for debugging). Best regards, Bernhard --- Hello Peter, shure - you are right - Tobias is working on it and I stay in contact with him. Thanks also a lot for your help! Best regards Bernhard ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
