Re: [riot-devel] At86rf2xx ACK frame

[Alexander Aring]

Hi,

On Fri, Jun 16, 2017 at 09:45:25PM +0200, Oleg Hahm wrote:
> Hi Alex!
> 
> On Fri, Jun 16, 2017 at 09:21:18PM +0200, Alexander Aring wrote:
> > On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote:
> > > On 2017-06-16 11:27, Baptiste Clenet wrote:
> > > > Yes Thomas I haven't tried yet but I don't think transceiver stores it.
> > > > Joakim, OpenThread requires it as explained here:
> > > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978
> > > 
> > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer 
> > > to
> > > the ACK frame?
> > > 
> > 
> > Some IEEE 802.15.4 MLME-ops requires if the ack was received or not.
> > This need be handled by upper layers e.g. a SoftMAC layer of IEEE
> > 802.15.4. So actually if ARET is supported by hardware and it's an
> > SoftMAC transceiver it should have the possibility to read out some
> > status register of handled ARET algorithm on hardware side if ACK was
> > there or not (because MLME-ops requires this information). If hardware
> > can't report and is a SoftMAC transceiver with ARET support and can't
> > handle MLME-ops on hardware side: you have a problem.
> 
> Using at86rf2xx's extended operating mode allows you to figure out if an ACK
> was received or not, but not all models allows you to read if and how many
> retransmissions were necessary.
> 

Question here is:

Is "how many retransmissions were necessary" is a required information
for IEEE 802.15.4 MLME-ops? If so, then the transceiver hardware has a
lack of support to implement IEEE 802.15.4, if not then this is some
"extra" feature. Not sure if this information is required. Required
information for some MLME-ops is if finally there was an ACK or NOT, no
matter how many retransmissions was involved.

Such "extra" feature could only be useful to check how reliable a peer
is, maybe?.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] At86rf2xx ACK frame

[Alexander Aring]

Hi,

On Fri, Jun 16, 2017 at 07:07:17PM +0200, Baptiste Clenet wrote:
> OpenThread asks all new platform to use new function:
> otPlatRadioTxDone that requires ACK frame.
> 
> If you get deeper, I think they use it to get the power of the
> transmission and may be something else that I missed:
> https://github.com/openthread/openthread/blob/master/src/core/mac/mac.cpp#L993
> 

yes, but the power is not part of ack frame payload. It's just the
receive power measured when ARET was done "or something like that", or?

And they do it to collect some per peer statistics about how reliable/link
quality a neighbor is (I suppose). E.g. doing routing decisions
afterwards.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] At86rf2xx ACK frame

[Alexander Aring]

Hi,

On Fri, Jun 16, 2017 at 09:21:18PM +0200, Alexander Aring wrote:
> Hi Oleg,
> 
> On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote:
> > Hi Baptiste!
> > 
> > On 2017-06-16 11:27, Baptiste Clenet wrote:
> > > Yes Thomas I haven't tried yet but I don't think transceiver stores it.
> > > Joakim, OpenThread requires it as explained here:
> > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978
> > 
> > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to
> > the ACK frame?
> > 
> 

doh! Thought about why they need ackframe there or not, but it's about
payload... sorry.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] At86rf2xx ACK frame

[Alexander Aring]

Hi Oleg,

On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote:
> Hi Baptiste!
> 
> On 2017-06-16 11:27, Baptiste Clenet wrote:
> > Yes Thomas I haven't tried yet but I don't think transceiver stores it.
> > Joakim, OpenThread requires it as explained here:
> > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978
> 
> Sorry, I don't get the explanation. Why does OpenThread needs the pointer to
> the ACK frame?
> 

Some IEEE 802.15.4 MLME-ops requires if the ack was received or not.
This need be handled by upper layers e.g. a SoftMAC layer of IEEE
802.15.4. So actually if ARET is supported by hardware and it's an
SoftMAC transceiver it should have the possibility to read out some
status register of handled ARET algorithm on hardware side if ACK was
there or not (because MLME-ops requires this information). If hardware
can't report and is a SoftMAC transceiver with ARET support and can't
handle MLME-ops on hardware side: you have a problem.

For my Linux experiments I tried to implement to make an upper layer
report if ACK was there or not, see [0]. I didn't implement MLME-ops it
was to keep per peer stats about link quality. Further this information
for upper layer (mac802154) it's necessary for some IEEE 802.15.4 MLME-ops
handled by this layer.

I think OpenThread needs also this information for some of "future or
already?" handled MLME-ops.

---

What I have also in plans is... I need that also on an user space POSIX
socket on linux. This requires obviously a synced transmit handling in
user space for e.g. IEEE 802.15.4 sockets or even IPv6 Sockets. I want to
handle such information over the "socket error queue" [1] which allows a
synced xmit on user space level and even request if the transmitted
frame/ipv6 packet got an acked frame back. Okay for IPv6 lot of more
stuff need to be handled e.g. ACK handling report with fragmentation.
But for IEEE 802.15.4 sockets I need this handling for running user space
stacks e.g. RIOT in user space on a registered Linux 802.15.4 PHY. Which
is actually a necessary use-case which I found, same can be adapted for
IPv6/6LoWPAN (maybe somebody will specified protocols to check on L2 ack
handling, I don't know if such thing exists).

Note: the above idea was stolen from wireless (802.11) Linux subsystem,
see [3].

- Alex

[0] 
https://github.com/linux-wpan/linux-wpan-next/blob/for-mcr/drivers/net/ieee802154/at86rf230.c#L658
[1] https://linux.die.net/man/2/recv - MSG_ERRQUEUE
[3] http://www.spinics.net/lists/netdev/msg176415.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Alexander Aring]

Hi,

On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:
> 2017-05-17 17:47 GMT+02:00 Thomas Eichinger :
> > Hi Baptiste,
> >
> > On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:
> >
> >> According to their example:
> >> Example:
> >> A frame transmission of length five with TX_AUTO_CRC_ON set, is
> >> started with a Frame Buffer write access of five bytes (the last two
> >> bytes can be omitted). The first three bytes are used for FCS
> >> generation; the last two bytes are replaced by the internally
> >> calculated FCS.
> >>
> >> Even a five bytes frame would have its last two bytes overwritten. Is
> >> my understanding correct?
> >> So I don't understand why the driver limits the frame length to 127-2?
> >
> >
> > The at86rf2xx driver doesn't limit the *frame length* to 127-2 octets
> > because the
> > FCS is part of the frame sent out. The driver just makes sure that no
> > payload
> > data is overwritten by the FCS.
> >
> > Every 802.15.4 frame has two bytes of FCS. So if we didn't use
> > TX_AUTO_CRC_ON
> > we would have to calculate the checksum in software and write it into the
> > frame buffer, appended to the header, sequence number, addresses and payload
> > we
> > want to send. All together (FCF + seq_num + addrs + payload + FCS) this can
> > be 127 bytes max.
> >
> > Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have to
> > calculate
> > the FCS, it's appended to the rest of the frame.
> 
> I don't think it is appended to the frame but it really replace the
> last two bytes of the frame
> Example:
> at86rf2xx_tx_load(dev, ptr->iov_base, 5, 0);
> FCS is calculated on bytes 1, 2 and 3 and bytes 4 and 5 are replaced by FCS
> 

starting here at 0 or 1? :S

Replaced by FCS? I suppose this function loads frame into framebuffer,
the FCS isn't calculated there. See below.

> at86rf2xx_tx_load(dev, ptr->iov_base, 126, 0);
> FCS is calculated on bytes 1, to 124 and bytes 125 and 126 are replaced by FCS
> 
> So the stack which give the frame should give a frame  2bytes longer
> to let the transceiver calculate the FCS.
> This is why IMO this check is useless.
> 
> After reading more the datasheet, it's not clear because it is written:
> On transmission the radio transceiver generates and appends the FCS
> bytes during the frame transmission. This
> behavior can be disabled by setting register bit TX_AUTO_CRC_ON = 0
> (register 0x04, TRX_CTRL_1).
> 

I think when the transmitter starts sending the FRAME -> going into
BUSY. The transceiver will make some:

init_fcs();
for (b:each_bytes_to_tx) { <--- 127 - 2
send(b);
calc_fcs(b);
}
send_fcs(); <--- 2 bytes

then you need to be sure you send 127 - 2 bytes out. If you disable 

---

now if you disable AUTO_CRC then you can load 127 bytes into framebuffer
and hopefully last 2 bytes are FCS (or doesn't need to be, but then you
running out-of-spec).

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth

[Alexander Aring]

Hi,

On 02/26/2017 07:05 AM, Alexander Aring wrote:
> 
> Hi,
> 
> On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote:
>> From: Luiz Augusto von Dentz <luiz.von.de...@intel.com>
>>
>> Accourding to RFC 7668 U/L bit shall not be used:
>>
>> https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
>>
>>In the figure, letter 'b' represents a bit from the
>>Bluetooth device address, copied as is without any changes on any
>>bit.  This means that no bit in the IID indicates whether the
>>underlying Bluetooth device address is public or random.
>>
>>|0  1|1  3|3  4|4  6|
>>|0  5|6  1|2  7|8  3|
>>+++++
>>|||1110||
>>+++++
>>
>> Because of this the code cannot figure out the address type from the IP
>> address anymore thus it makes no sense to use peer_lookup_ba as it needs
>> the peer address type.
>>
> 
> I am still not quite 100% of this and want to leave my opinion about this
> handling which can be interpreted in a different way.
> 
> The RFC says here:
> 
> Following the guidance of [RFC7136], a 64-bit
> Interface Identifier (IID) is formed from the 48-bit Bluetooth device
> address by inserting two octets, with hexadecimal values of 0xFF and
> 0xFE in the middle of the 48-bit Bluetooth device address as shown in
> Figure 6. 

Okay, they said from IID from the 48-bit address. 

And IID is what you need here and what [RFC7136] describes as result,
so I think you are right.

There is no need for special u/l bitflip or link-layer multicast handling.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Stacksize optimization

[Alexander Aring]

Hi,

On 01/09/2017 02:01 PM, Baptiste Clenet wrote:
> Hi,
> 
> In order to optimize the statcksize of a thread, I would like to know
> when the thread uses the maximum of its stack (maximum can be 3/4 of
> the stack for instance)
> How can I find this "time"?
> 

In my opinion:

Welcome to the embedded world problems...

I thought about to have some coverage compiler and check always the
maximum stacksize... That's my idea to get such value... but then you
need to reach 100% coverage of the thread -> good luck with that. :-)

It would maybe nice to have such feature in RIOT to coverage his "little
tiny thread application" where you could reach your 100% coverage...

Maybe also possible on other stacks for testing in native application...
and also check ISR stack size. It think it's a good research topic for
somebody who looking for academic work. :-)

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [RFC 6719] MRHOF - Objective Function for RPL

[Alexander Aring]

Hi,

On 01/05/2017 02:15 PM, Rafał Rzatkiewicz wrote:
> Dear Developers of RIOT OS,
> 
> I am a fourth-year student of Telecomunications at Warsaw University of
> Technology. I am amost finishing my studies and my Engineering Thesis is
> about routing in wireless sensor networks. Together with my supervisor, we
> decided to choose RIOT OS as our operating system for developing the
> Minimum Rank with Hysteresis Objective Function (RFC 6719) algorithm
> implementation.
> 
> After hours of studying  RFC's related to the topic I started reviewing
> google results about what is done already about this topic around the
> internet. Unfortunately I noticed this:
> 
> https://github.com/RIOT-OS/RIOT/issues/2493
> 
> Of course this checklist is related to the previous implementation of RIOT
> OS and long before the gnrc network stack which is included in recent
> releases.
> 
> However, it sounds to me like there are couple issues which are not trivial
> in terms of MRHOF, ETX-metric and DAG Metrc Container implementation within
> RIOT OS.
> 

You could also thought about to use MLE [0] for provide ETX information.
MLE solves the issue with frame counter sync in mac device table, if
RIOT would have 802.15.4 security one day...

If you using MLE you don't need Metric Containers... simple provide some
IPC to dump current neighbor information.

Also MLE MAY do periodic transmission of Messages, with that you will
get better LQI average over a time...

I currently work on a POSIX compatible mle library, I can show you some
of my work if you like... but there need much things to do that you can
access lower OSI layers below UDP...

- Alex

[0] https://tools.ietf.org/html/draft-ietf-6lo-mesh-link-establishment-00
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Fwd: Re: RIOT MRF24J40 Driver

[Alexander Aring]

Hi,

On 11/03/2016 11:01 PM, Neo wrote:
> Hello Alexander,
> I have sometimes the situation that TXNSTAT = 1 / TXNRETRY1=1 / TXNRETRY0 = 1 
> /CCAFIL =1  -> Transmission failed (in the TXSTAT register). This register is 
> readonly and I have no idea how to
> reset those bits.
> Actually I make a real worse workaround -> I reset the chip.
> Have you any idea how these bits could be reset - so that the chip can go on 
> working...
> 

These bits are always set because you talk with an transceiver which
doesn't send an ack back! If you have a transceiver which sends an ack
back it should be zero.

If the first retry was failed TXNRETRY1 is 1.
If the second retry was failed TXNRETRY1 is 2.


up to max frame retries 3.

I cc now riot-devel this is an usual 802.15.4 handling.
"Normally" at tx complete irq -> you need to read out the TXNSTAT stat
and report the upper-layer if ACK was there or not. At least you 100%
need such information for some part of MLME-ops. 

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] L2 Netstats

[Alexander Aring]

Hi,

On 11/01/2016 04:22 PM, Oleg Hahm wrote:
> Hi Carsten!
> 
> On Tue, Nov 01, 2016 at 04:10:01PM +0100, Carsten Bormann wrote:
>> Please have a look at RFC7388 when doing this:
>>
>>  Definition of Managed Objects for IPv6 over Low-Power Wireless
>>  Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T.
>>  Tsou, C. Zhou. October 2014. (Format: TXT=53451 bytes) (Status:
>>  PROPOSED STANDARD) (DOI: 10.17487/RFC7388) 
>>
>> The writing on the package says its SNMP, but the important thing is the
>> definition of the counters, which have wider applicability.
> 
> That makes a lot of sense. Should have thought of this myself...
> 

and thanks also from my side, I had also the question what to count for
linux side _6LoWPAN_ interfaces.

But this is 6LoWPAN only? What about L2 stats. E.g. L2 stats are for me
802.15.4 values. For example if transmission with ack request got an ack
or not. Also last LQI value from peer.

I currently think heavily about that because I need it. I also need to
solve the short address vs extended address mapping, because I want to
count only one peer for an extended address. I maybe use the MAC device
table to do some lookup from short to extended. :-/

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] openthread and riot - license issues?

[Alexander Aring]

Hi,

I currently detect that openthread will be use internally some mbedtls
as some library for crypto stuff. This license is apache [0].

Will this not clash with RIOT's LGPL? Or does there exists some
replacement for such functionality under another license?

- Alex

[0] 
https://github.com/openthread/openthread/blob/master/third_party/mbedtls/repo/LICENSE
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Netdev2 State changes

[Alexander Aring]

Hi,

On 09/13/2016 10:50 PM, Alexander Aring wrote:
...
> 
> I think for "auto-acknowledgement" you can't _exactly_ track the states
> which the hardware does. E.g. transmit a frame and wait for a received ack.
> True, this would be a state change from "TX to RX", but you can't track
> it because it's done by hardware. The at86rf2xx will handle that also as
> TX_ARET_BUSY only, there is no change to get the "very small" receiving
> state after transmission.
> 

s/change/chance/

And the same is for "RX to TX", when receiving a frame and sends an ACK
frame back. This will also occur no netdev2 statechange in at86rf2xx.
It's not possible to detect this statechange on hardware (so far I
know). It will handled as RX state completely.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Netdev2 State changes

[Alexander Aring]

Hi,

On 09/13/2016 09:23 AM, Peter Kietzmann wrote:
> Hi Neo,
> 
> there might be code snippets that actively wait for a state transition, but 
> AFAIK not in the netdev part any more. Then there is interrupt handling which 
> signals tx/rx start/end points to the upper layer. Of course you can't 
> implement anything once it's not available on the device. The great thing 
> about netdev is that it's pretty generic and you don't *need* to implement 
> every function/message/interrupt/state change/whatsoever to get the device 
> running.
> 
> But looking at the data sheet I stumbled upon the RFSTATE register which 
> signals the following (useful) sates:
> 
> 111 = RTSEL2
> 110 = RTSEL1
> 101 = RX
> 100 = TX
> 011 = CALVCO
> 010 = SLEEP
> 001 = CALFIL
> 000 = RESET
> 
> In addition there is the INTSTAT register which seems somehow similar to the 
> Atmel radio. Where exactly did you stuck? Could you be a more precise?
> 

as the linux maintainer of 802.15.4 and I worked with at86rf2xx and
mrf24j40 transceiver I think I know what Neo means.

The main difference between both transceiver is that:

 - at86rf2xx has ONE framebuffer for transmit and receive
 - mrf24j40 has two (also even more for GTS, etc) framebuffers one for
   transmit and one for receive.

The main "performance?" advantage is that the mrf24j40 can _fill_ the tx
framebuffer while it's _actual_ receiving a frame.

That doesn't mean that it can transmit and receive at the same time.
It's about filling framebuffer over SPI connection.

For me it's important to know what does the state parameter exactly
means. Does a TX state means including "filling tx framebuffer" or
excluding "filling tx framebuffer". :-/ In at86rf2xx I think it would be
including, because you acutally stop receiving of frames to going into
TX state.

This would be end in some different meaning depends on transceiver what
acutally the TX state means.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] mqtt-sn, multicast and riot

[Alexander Aring]

Hi Michael,

On 09/07/2016 01:46 PM, Michael Frey wrote:
> Hi,
> 
> as probably some of you are aware, I'm working in my spare time on a
> mqtt-sn client for RIOT. The mqtt-sn specification [1] doesn't make any
> assumptions about the network stack, which is good and bad at the same
> time.
> 
> The "problem" is that MQTT-SN has "broadcast messages" such as the
> SEARCHGW message for example and also defines for some message types a
> "broadcast radius". While the latter is probably easy to "fix" using the
> hop limit field in IPv6, I'm not entirely sure how to tackle the broadcast
> issue.
> 
> The first thing which comes to mind is "simply" to use multicast, but the
> question is which scope? Something like "ff0n::1" (all nodes) seems a bit
> aggressive. Also RIOT doesn't seem to have a MLD implementation. Maybe it
> would be better to create a designated multicast group for MQTT-SN?
> 

don't know if I can help you with this information. OpenThread which use
some kind of forked MLE protocol [0]. MLE itself use a lot of multicast
messages, quoting:

"This requires some form of multi-hop multicast forwarding; these messages are
 sent infrequently, so forwarding with simple flooding is sufficient."

Is this the same what you are looking for? If yes then MLE has similar
issues like you.

So far I know the OpenThread people use MPL for that [1], so no MLD.
But for constrained networks, so far I know there is also no implementation
for MPL in RIOT. :-/

> I'm wondering if somebody was stumbling upon a similar issue? There seems
> to be a proposal within the MQTT-SN community [2] which is probably
> worthwhile to consider? Thanks in advance!
> 
> Best,
>  Michael
> 
> [1] http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf
> [2] https://github.com/mqtt/mqtt.github.io/wiki/MQTT-SN-Multicast-Addresses
> 

- Alex

[0] https://tools.ietf.org/html/draft-ietf-6lo-mesh-link-establishment-00
[1] https://tools.ietf.org/html/rfc7731
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] MRF24J40 radio module driver

[Alexander Aring]

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

Re: [riot-devel] MRF24J40 radio module driver

[Alexander Aring]

Hi,

not sure if I should open this discussion in this thread. :-/

On 09/05/2016 11:45 PM, Peter Kietzmann wrote:
> Hi Neo,
> 
> if I see it correctly, the procedure is as follows:
> 
> gnrc_networking uses the the gnrc_ipv6 module which automatically pulls in 
> it's dependencies. This is, among others, gnrc_ipv6_netif.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/Makefile.dep#L280
> 
> Once this was defined, auto_init will call the "init by netif device" 
> function.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/sys/auto_init/auto_init.c#L227
> 
> This function will set the net option "NETOPT_SRC_LEN" to 8 Byte, which is 
> the length for long hardware addresses.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L833
> 
> The at86rf2xx driver does not implement this option itself and passes it to 
> the netdev2_ieee802154 module.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L580
> 
> 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.

This is the way what I have in my mind to do in Linux.

side note:
interessting is that, in 6LoWPAN it depends on L3 address and
fragmentation if you use short or long address to produce the smallest
payload.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

[Alexander Aring]

Hi,

On 08/30/2016 05:50 PM, Baptiste Clenet wrote:
> Oleg, you were looking for that: https://github.com/openthread/openthread
> 
> Martine, Kaspar, AFAIK, OpenThread follow RFC standard and they added
> their part on top of it, but I don't know if it will be fully
> compatible.
> 

OpenThread doesn't use IPv6 neighbour discovery, they use a forked MLE
protocol which is maybe ~80% of that what IETF MLE is. They use MLE for
neighbour discovery, means filling neighbour entries with that. Also I
saw that they broadcast a stateful compression CID over MLE. The rest I
currently try to detect by using the force, ehm source.

Also you cannot be sure that OpenThread really follow any IETF standard
and do they own forks. Please see my question [0].

So OpenThread 6LoWPAN is _maybe_ not IETF 6LoWPAN.

- Alex

[0] https://groups.google.com/forum/#!topic/openthread-users/l2hozmMfE2M
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Raw communication between native nodes

[Alexander Aring]

Hi,

On 06/22/2016 09:19 PM, Alexander Aring wrote:
> 
> Hi,
> 
> On 06/22/2016 05:28 PM, Jose Alamos wrote:
>> Hi,
>>
>> I was wondering if there's a way to send raw data between nodes running on
>> native. I need to send OpenThread packets between nodes (through a radio
>> abstraction), and I'm having problems with TAP interface since they only
>> process ethernet frames.
>>
>> I tried to hack a little bit (put these OT packets in ethernet frames) but
>> is not working well. Basically, I need to emulate a radio device.
>>
>> Is there an easy way to achieve this?
>>
> 
> some of you maybe knowing that I am working on a RIOT native 802154raw
> transceiver driver which works with AF_PACKET RAW linux-wpan interfaces.
> 
> At the end it should work like the following:
> 
> First I need to describe a special virtual 802.15.4 driver, it's named
> fakelb (maybe such idea can also be implemented in RIOT).
> 
> It works similar like the hwsim80211 driver in linux (but less
> functionality, I also was thinking to make a better implementation of
> fakelb and name it hwsim802154).
> 
> With such driver you can create "virtual phy's" in Linux.
> 
> E.g. 2 phy's,
> 
> 
>   6LoWPAN/etc   6LoWPAN/etc
>| |
>   wpan node interface  wpan node interface
>| |
>mac802154 mac802154
>| |
>wpan-phy0 <--L1(memcpy)--> wpan-phy1
> 
> Descrption:
>   - mac820154: Our 802154 SoftMAC stack
>   - 6LoWPAN/etc: upper layer IPv6, foo stack
>   - wpan node interface: a wpan node interface which does filtering
> 
> Now with a 802154raw native RIOT driver the following would be possible:
> 
> 
>RIOT native (Userspace)
>  AF_PACKET RAW
>|6LoWPAN/etc   6LoWPAN/etc
>|| |
>   wpan monitor interface  wpan node interface  wpan node interface
>|| |
>|mac802154 mac802154
>|| |
>wpan-phy2 <-L1(memcpy)-> wpan-phy0 <--L1(memcpy)--> wpan-phy1
> 

I implemented it [0]. You need 1-2 patches which currently pending on
linux-wpan mailinglist, but then it should be possible.

Next days I need to figure out how to send github pull requests again.

- Alex

[0] https://github.com/linux-wpan/RIOT/commits/802154_raw
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Raw communication between native nodes

[Alexander Aring]

Hi,

On 06/22/2016 05:28 PM, Jose Alamos wrote:
> Hi,
> 
> I was wondering if there's a way to send raw data between nodes running on
> native. I need to send OpenThread packets between nodes (through a radio
> abstraction), and I'm having problems with TAP interface since they only
> process ethernet frames.
> 
> I tried to hack a little bit (put these OT packets in ethernet frames) but
> is not working well. Basically, I need to emulate a radio device.
> 
> Is there an easy way to achieve this?
> 

some of you maybe knowing that I am working on a RIOT native 802154raw
transceiver driver which works with AF_PACKET RAW linux-wpan interfaces.

At the end it should work like the following:

First I need to describe a special virtual 802.15.4 driver, it's named
fakelb (maybe such idea can also be implemented in RIOT).

It works similar like the hwsim80211 driver in linux (but less
functionality, I also was thinking to make a better implementation of
fakelb and name it hwsim802154).

With such driver you can create "virtual phy's" in Linux.

E.g. 2 phy's,


  6LoWPAN/etc   6LoWPAN/etc
   | |
  wpan node interface  wpan node interface
   | |
   mac802154 mac802154
   | |
   wpan-phy0 <--L1(memcpy)--> wpan-phy1

Descrption:
  - mac820154: Our 802154 SoftMAC stack
  - 6LoWPAN/etc: upper layer IPv6, foo stack
  - wpan node interface: a wpan node interface which does filtering

Now with a 802154raw native RIOT driver the following would be possible:


   RIOT native (Userspace)
 AF_PACKET RAW
   |6LoWPAN/etc   6LoWPAN/etc
   || |
  wpan monitor interface  wpan node interface  wpan node interface
   || |
   |mac802154 mac802154
   || |
   wpan-phy2 <-L1(memcpy)-> wpan-phy0 <--L1(memcpy)--> wpan-phy1

In this setup you can ping from Linux IPv6 stack the RIOT Stack which
running in userspace.

I think your use case would be look like the following which is also
be possible:

   RIOT native (Userspace)   OpenThread native (Userspace)
 AF_PACKET RAW  AF_PACKET RAW
   | |
   | |
  wpan monitor interface wpan monitor interface
   | |
   | |
   | |
   wpan-phy0  wpan-phy1

Then you could connect RIOT native with openthread native over the
fakelb driver (maybe also add Linux nodes or more RIOT/OpenThread
nodes).

I know somebody is working for adding such virtual driver in OpenThread,
but I think they want to use real hardware for that (which I don't
recommend). This is just for stack testing, there exists unsolved issues
with ACK handling etc and you really don't want to bypass the great
Linux IPv6 Stack :-).

I cc the guy/girl which wants to add this stuff to OpenThread.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Raspberry Pi 3 and packet sniffing

[Alexander Aring]

Hi,

On Fri, Jun 03, 2016 at 09:30:16PM +1200, Aaron Sowry wrote:
> Hi,
> 
> Yeah I tried a few different speeds with no luck - according to the
> docs the default is now 3 MHz anyway. If I could at least get garbled
> packets *consistently* this would be a step in the right direction,
> but the fact that it's sporadic makes debugging things rather
> difficult...
> 

there was one guy @#linux-wpan channel which had similar issues on
RPi2 or RPi3? and he fixed it by using the mainline kernel _NOT_ rpi
kernel.

I never used myself the rpi kernel for RPi2 so I can't say if this is
broken or not.

Maybe you have the chance to build a recent mainline kernel from
kernel.org. I don't know the RPi3 support, fast googling result into
[0], which seems to be available at "git://git.kraxel.org/linux
bcm2837".

- Alex

[0] http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-June/003916.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Raspberry Pi 3 and packet sniffing

[Alexander Aring]

Hi,

On Fri, Jun 03, 2016 at 11:42:47AM +1200, Aaron Sowry wrote:
> Hi,
> 
> I know this doesn't have anything to do with RIOT in particular, but
> since I know some of you are using the radio in question I thought I'd
> ask here.
> 
> For testing I've been using a RPi 2 with Openlabs' 802.15.4 radio[1],
> which was relatively easy to get working with Wireshark. The Pi
> recently destroyed my SD card however, including all the config I'd
> done to set it up, so I figured I'd start from scratch with an RPi 3.
> I can't seem to get it working this time though, and I was just
> wondering if anyone else had managed to use the RPi 3 with this radio
> for packet sniffing? I can't think of any reason why it shouldn't
> work, but although the radio is detected properly and is able to be
> manipulated using 'iwpan', it never sees any packets (although I know
> the packets are being sent correctly, because I can sniff them with
> another RIOT node).
> 

Sounds like issue [0]. This patch was not sent back to stable since we
don't have any stable strategy, sorry.

Anyway the most workaround for this issue is to change the channel/page
when the wpan/monitor on the phy is "up" - then the phy doesn't go into
sleep state.

On RPi1 I never had such issue, but the RPi2/RPi3 seems to be faster and
then such race occur (Setting registers while sleeping - which does not
work on at86rf2xx). :-(

- Alex

[0] 
http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/drivers/net/ieee802154/at86rf230.c?id=60f5f5d3a106dc5385b39348d13b20b15ac9cbf9
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Border-router and multicast

[Alexander Aring]

Hi,

On Mon, May 09, 2016 at 06:20:48PM +0200, Baptiste Clenet wrote:
> 2016-05-09 16:44 GMT+02:00 Alexander Aring <alex.ar...@gmail.com>:
> > On Mon, May 09, 2016 at 04:24:34PM +0200, Baptiste Clenet wrote:
> >> Hi Martine,
> >> Thank you for the answer.
> >> Ok ff04::1 is also a multicast address so I add it to every board with
> >> gnrc_networking and I should be able to ping them with this multicast
> >> address.
> >> Shouldn't I use:
> >> ifconfig 7 add multicast ff04::1
> >> ?
> >>
> >> I'm missing something here, could give me an explanation please:
> >> Before, I had a transceiver plugged on my linux so I was able to ping
> >> my board directly using fe80::address so I was able to use the local
> >> multicast address ff02::1, now that I use border router, I'm using a
> >> prefix 2001::db8 (why? and why documentation prefix?) Why can't I use
> >> fe80 as before?
> >
> > because link-local ff80::/10 will not be routed, between lowpan and
> > ethernet interface, so far I know.
> 
> ff80? You meant fe80? I was able to do ping with fe80 and lowpan0.

Sorry, I think I misunderstood here something completely.

Your setup what is it?

Linux (802.15.4/6LoWPAN) <-> RIOT

or

Linux -> TAP (ethernet) <-> RIOT BORDER ROUTER <-> RIOT

You say something with lowpan0 then I think it's the first one, but I am
not sure now and confused. :-)

It's a important information, if it's the second one then better
completely ignore what I said before, because I don't know how this
works exactly.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Border-router and multicast

[Alexander Aring]

On Mon, May 09, 2016 at 06:20:48PM +0200, Baptiste Clenet wrote:
> 2016-05-09 16:44 GMT+02:00 Alexander Aring <alex.ar...@gmail.com>:
> > On Mon, May 09, 2016 at 04:24:34PM +0200, Baptiste Clenet wrote:
> >> Hi Martine,
> >> Thank you for the answer.
> >> Ok ff04::1 is also a multicast address so I add it to every board with
> >> gnrc_networking and I should be able to ping them with this multicast
> >> address.
> >> Shouldn't I use:
> >> ifconfig 7 add multicast ff04::1
> >> ?
> >>
> >> I'm missing something here, could give me an explanation please:
> >> Before, I had a transceiver plugged on my linux so I was able to ping
> >> my board directly using fe80::address so I was able to use the local
> >> multicast address ff02::1, now that I use border router, I'm using a
> >> prefix 2001::db8 (why? and why documentation prefix?) Why can't I use
> >> fe80 as before?
> >
> > because link-local ff80::/10 will not be routed, between lowpan and
> > ethernet interface, so far I know.
> 
> ff80? You meant fe80? I was able to do ping with fe80 and lowpan0.

yep.

> >
> > I think what you want to have is the npd proxy magic stuff. See [0].
> > Just plugin the ethernet cable and your network will be extended with
> > the 6LoWPAN nodes.
> 
> What I want is to understand a bit better how my network works.
> Each node is inside the same PAN (let's say 0x23 by default on RIOT,
> any reason why you choose 0x23?)
> RIOT starts and we affect an link-local address fe80 so every RIOT
> node can ping another one with its link-local address.
> Then comes border-router, border router will tell every node to add a
> new ip with prefix 2001:db8::, is this right?

For this you need radvd [0] which sends RA with PIO (prefix information
option).

> How often does border router send a message to other node to say to
> add this new ip address?

depends on setting. Normally RA is a responds according to RS. RA can
also be transmitted periodically.

> Why 2001:db8 has been chosen? and how should I choose this prefix if I
> want to use my product for commercial use?
> 
> Why can't I ping a link-local address from Linux with the border router?

Because fe80::/10 address scope will not be routed, you could do that I
think with the ndp proxy stuff. If you simple want to extend your
ethernet IPv6 network with the 6LoWPAN nodes, then I suppose ndp proxy
can do that.

> I've got ten nodes and one linux with a border router, what I want is
> to be able to send messages to each of them (or all of them by
> multicast) at any moment, here I don't understand why I should use
> global address 2001:db8 instead of fe80::
> 

Because global addresses will be routed and are global? :-)

local is local in your network and global can be accessed from
"outside" and with "outside" I mean the internet, that's maybe the
reason why link-local will not be routed.

With a border router, you need to route from one IPv6 interface to
another IPv6 interface and link-local will not be routed over that.

NDP proxy is so far I know something where you can extend the network
from one IPv6 interface to another IPv6 interface but it's more some
tricky stuff to do this and maybe not everything is implemented what you
need.

> Thanks for your time,
> 

I hope I could help you.

- Alex

[0] https://github.com/linux-wpan/radvd/tree/6lowpan
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Border-router and multicast

[Alexander Aring]

On Mon, May 09, 2016 at 04:24:34PM +0200, Baptiste Clenet wrote:
> Hi Martine,
> Thank you for the answer.
> Ok ff04::1 is also a multicast address so I add it to every board with
> gnrc_networking and I should be able to ping them with this multicast
> address.
> Shouldn't I use:
> ifconfig 7 add multicast ff04::1
> ?
> 
> I'm missing something here, could give me an explanation please:
> Before, I had a transceiver plugged on my linux so I was able to ping
> my board directly using fe80::address so I was able to use the local
> multicast address ff02::1, now that I use border router, I'm using a
> prefix 2001::db8 (why? and why documentation prefix?) Why can't I use
> fe80 as before?

because link-local ff80::/10 will not be routed, between lowpan and
ethernet interface, so far I know.

I think what you want to have is the npd proxy magic stuff. See [0].
Just plugin the ethernet cable and your network will be extended with
the 6LoWPAN nodes.

I need to admit, I tested the manual stuff "ip -6 neigh add proxy ..."
only and never the ndppd (btw, there exists some offers to move this
handling into kernelspace to make it more easier for users).

If you want to test it, please share your expierence.

- Alex

[0] https://github.com/DanielAdolfsson/ndppd
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

On Fri, Apr 29, 2016 at 04:58:04PM +0200, smlng wrote:
> Hi Alex,
> hi all,
> 
> over the last days I did some more extensive tests and enabled/added some 
> debug output in RIOT, and I got close to the root cause of the problem. 
> 
> TL;DR: 
> - Linux does not set the router flag in its NAs
> - but it should when `radvd` is running (or `radvd` should enable it). 
> - RIOT behaves correctly, according to RFC-4861 7.2.4.
> 
> 
> 
> Now the slightly longer version; I quickly recap my setup:
> 
> - a RasPi with OpenLabs transceiver, and `radvd` (linux-wpan version from 
> github)
> - Atmel samr21-xpro running RIOT with `gnrc_networking` example 
> (2016.04-branch)
> - `radvd` announces a ULA-prefix (though ULA doesn't matter, could global as 
> well)
> 
> I observed the following behavior:
> 
> - RIOT send RS on boot, `radvd` on RasPi replies with RA (incl. PIO, ABRO, 
> SLLAO)
> - RIOT parse RA, generates IP from prefix, adds NCE for router with router 
> flag set
> - RIOT send NS for RasPi/routers link-local address -> RasPi replies with NA
> - RIOT parses NA, but router flag not set -> unset router flag in NCE of 
> router
> - hence no more router in cache -> no ping or data transfer via 
> non-link-local (e.g. ULA) IPs 
> 
> so my question @alex and @linux-wpan: can I manually set/enable the routers 
> flag for NAs in Linux Kernel? Or somehow _convince_ `radvd` to do so on 
> startup?

Routers are indicated by the "forwarding" setting. radvd silent warns
about that if this isn't set for interfaces with RA advert is on, so far I
know you need to increase the debug level for that.

I simple set:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

this will set forwarding for all interfaces.

Some code explaining:

See http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L838

this is at function when NS is received, the routeri flag will be set when
forwarding is enabled.

Maybe this solves all your current issues. :-)

> I'm running latest Raspbian with Kernel 'Linux raspberrypi 4.1.19+' and 
> wpan-tools from github on the RasPi.
> 

I would better use bluetooth-next, if possible. With all recent patches
you could also try to use 6CO in radvd.

btw: the radvd wants to accept my patches for 6lowpan 6CO stuff, but
basic 6LoWPAN-ND (first short address support for NA/NS) will be added
and short-address handling will not work with RIOT, but that's another
issue...

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

Hi,

On Sun, Apr 24, 2016 at 10:05:28PM +0200, Alexander Aring wrote:
> Hi,
> 
> On Fri, Apr 22, 2016 at 02:28:16PM +0200, Alexander Aring wrote:
> > On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
> ...
> > > 
> > > @Alex as you joined the discussion: I also have a question regarding the 
> > > Linux side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I 
> > > observed that Linux still does NS for link-local address via the nodes 
> > > scoped multicast address, instead of using 6lo 'shortcut' by extracting 
> > > LL/MAC-address from the link-local IP. Is this fixed in some recent 
> > > version?
> > > 
> > 
> > There are currently pending patches for introducing neigh_ops, which is
> > a callback strucuture for send/recv NS/NA. After this is mainline it
> > should be easily to change this behaviour, or? What do you think?
> > See [3] - function "lowpan_ndisc_send_ns".
> > 
> 
> I think, I know what you mean. There is some NS with src as unspecified
> addr "::" and dest is some "multicast node scope".
> 
> RFC 6775 says [0]:
> 
> An unspecified source address MUST NOT be used in NS messages.
> 
> Additional to the pending patches I added:
> 
> diff --git a/net/6lowpan/ndisc.c b/net/6lowpan/ndisc.c
> index d088295..c6207cd 100644
> --- a/net/6lowpan/ndisc.c
> +++ b/net/6lowpan/ndisc.c
> @@ -386,8 +386,11 @@ static void lowpan_ndisc_send_ns(struct net_device *dev,
> saddr = _buf;
> }
>  
> +   /* RFC6775:
> +* An unspecified source address MUST NOT be used in NS messages.
> +*/
> if (ipv6_addr_any(saddr))
> -   inc_opt = false;
> +   return;

Question would here also, if we really wants to drop it or use ?link-local?
saddr then.

> if (inc_opt) {
> optlen += ndisc_opt_addr_space(dev, dev->addr_len);
> optlen += lowpan_ndisc_802154_short_addr_space(dev);
> 
> 
> This will not sending NS with "::" addresses as source address.
> 
> However, it's a little bit ugly we should prevent to calling this
> callback when source address is "::".
> 
> This patch should be fine at first but can maybe optimized in future.
> 

I think what you ask is the complete ARO stuff support and I can't
follow the:

"by extracting LL/MAC-address from the link-local IP." in case of
destination address and sending NS. What I found is the "Sending NS"
section of rfc6775 [0], which doesn't say anything about different
destination address.

Also I found a bootstrapping example in case of 6LN -> 6LR, [1]. But they
meant there the GP64 and link-local is defined as LL64.

...

I think I need to look deeper into that to say something related to
6LoWPAN-ND. :-)

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-5.5.1
[1] https://tools.ietf.org/html/rfc6775#section-10.2.1
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

Hi,

On Fri, Apr 22, 2016 at 02:28:16PM +0200, Alexander Aring wrote:
> On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
...
> > 
> > @Alex as you joined the discussion: I also have a question regarding the 
> > Linux side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I 
> > observed that Linux still does NS for link-local address via the nodes 
> > scoped multicast address, instead of using 6lo 'shortcut' by extracting 
> > LL/MAC-address from the link-local IP. Is this fixed in some recent version?
> > 
> 
> There are currently pending patches for introducing neigh_ops, which is
> a callback strucuture for send/recv NS/NA. After this is mainline it
> should be easily to change this behaviour, or? What do you think?
> See [3] - function "lowpan_ndisc_send_ns".
> 

I think, I know what you mean. There is some NS with src as unspecified
addr "::" and dest is some "multicast node scope".

RFC 6775 says [0]:

An unspecified source address MUST NOT be used in NS messages.

Additional to the pending patches I added:

diff --git a/net/6lowpan/ndisc.c b/net/6lowpan/ndisc.c
index d088295..c6207cd 100644
--- a/net/6lowpan/ndisc.c
+++ b/net/6lowpan/ndisc.c
@@ -386,8 +386,11 @@ static void lowpan_ndisc_send_ns(struct net_device *dev,
saddr = _buf;
}
 
+   /* RFC6775:
+* An unspecified source address MUST NOT be used in NS messages.
+*/
if (ipv6_addr_any(saddr))
-   inc_opt = false;
+   return;
if (inc_opt) {
optlen += ndisc_opt_addr_space(dev, dev->addr_len);
optlen += lowpan_ndisc_802154_short_addr_space(dev);


This will not sending NS with "::" addresses as source address.

However, it's a little bit ugly we should prevent to calling this
callback when source address is "::".

This patch should be fine at first but can maybe optimized in future.

---

Also for processing NS the "::" seems to be different [1], "::" seems to
valid (ARO will be ignored than but we don't support it so it's default
ignored). :-)

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-5.5.1
[1] https://tools.ietf.org/html/rfc6775#section-6.5
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

Hi,

On Fri, Apr 22, 2016 at 01:31:04PM +0200, smlng wrote:
> Hi all,
> 
> I stripped down my 'radvd.conf' to a minimal of:
> 
> ---snip---
> interface lowpan0
> {
> AdvSendAdvert on;
> MinRtrAdvInterval 3;
> MaxRtrAdvInterval 10;
> AdvDefaultPreference low;
> 
> prefix fd4b:c597:5df5:0::/64
> {
> AdvOnLink off;
> AdvAutonomous on;
> AdvRouterAddr on;
> };
> };
> ---snap---
> 
> same behavior with RIOT. It still consistently configures an (ULA) IP with 
> provided prefix, but the routers entry is missing most of the time - 
> sometimes it's there for a couple of seconds -> until the next RS/RA round. 
> 

so far I know ABRO MUST BE there. radvd/6lowpan doesn't do anything with
that option it's a dummy only, but otherwise 6LoWPAN stacks will drop
it, see [0].

But it's "when RAs are used to propagate information between routers" only.
Not sure right now. :-)

- Alex

[0] https://tools.ietf.org/html/rfc6775#section-4.3
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT+ULAs: no router entry

[Alexander Aring]

On Fri, Apr 22, 2016 at 01:13:29PM +0200, smlng wrote:
> Hi Alex, and all,
> 
> my radvd.conf is the following:
> 
> ---snip---
> 
> interface lowpan0
> {
> AdvSendAdvert on;
> UnicastOnly on;
> AdvCurHopLimit 255;
> AdvSourceLLAddress on;
> 
> MinRtrAdvInterval 3;
> MaxRtrAdvInterval 10;

mhhh,

With MaxRtrAdvInterval 10 then the:

AdvDefaultLifetime

will be 3 * 10 = 30 seconds. Don't know if this is anything related to
it. It should be send another RA messages in the interval of 3-10, so
far I know. In this interval the route (on RIOT side) should be updated,
or?

I think in my setup I used a high value (9000) for this to make anything
working. :-) I can imagine this parameter will not fix this issue, so it
happens later only.

"Must be either zero or between MaxRtrAdvInterval and 9000 seconds."
see [0].

---

Also sending periodic RA messages is some optional feature [1], but if I
remember correctly I used also a periodic transmit, because my RIOT node
never send another RS messages after booting and after lifetime ends it
didn't work anymore and that was the reason for high lifetime. :-) 

So far my expierence. And newbie question: When it's needed to send RS
messages? Maybe it's [2], so far 6775 doesn't update it.

> 
> AdvDefaultPreference low;
> 
> prefix fd4b:c597:5df5:0::/64
> {
> AdvOnLink off;
> AdvAutonomous on;
> AdvRouterAddr on;
> };
> 
> abro fe80::1ac0:ffee:1ac0:ffee
> {
> AdvVersionLow 10;
> AdvVersionHigh 2;
> AdvValidLifeTime 2;
> };
> };
> 
> ---snap---

thanks, maybe I can reproduce it now.

btw: with recent kernel and linux-wpan/radvd -> 6lowpan branch you can
also use 6CO to add your prefix for stateful compression.

> 
> btw. I use your/linux-wpan fork of radvd. Again: RIOT does receive the RA 
> from radvd AND configures an IP with the provided prefix. Thus, the 
> processing of RS+RA up this point seems to be correct, what's missing is the 
> routers entry in RIOT. Further, RIOT does receive the COAP requests but it 
> cannot send any reply, as it does not know the LLaddr for the destination 
> (ULA) IP. As far as I remember my last digging into RIOTs NDP processing, 
> RIOT does the following:
> 
> 1. if DST_IP is link-local: extract LLaddr 
> 2. else if neighbor cache entry exist, use it
> 3. if no ncache: query (default) router for LLaddr
> 4. if no router: abort
> 
> I think I'm running into case 4, where no entry exists what so ever and thus 
> no COAP reply is send.
> 
> @Alex as you joined the discussion: I also have a question regarding the 
> Linux side. I currently use Raspbian with shipped Linux-Kernel 4.1.19. I 
> observed that Linux still does NS for link-local address via the nodes scoped 
> multicast address, instead of using 6lo 'shortcut' by extracting 
> LL/MAC-address from the link-local IP. Is this fixed in some recent version?
> 

There are currently pending patches for introducing neigh_ops, which is
a callback strucuture for send/recv NS/NA. After this is mainline it
should be easily to change this behaviour, or? What do you think?
See [3] - function "lowpan_ndisc_send_ns".

Can you show me the part in rfc6775 which describe that behaviour?
Also I need to admit that I am not an expert in 6LoWPAN-ND. :-)

- Alex

[0] http://linux.die.net/man/5/radvd.conf
[1] https://tools.ietf.org/html/rfc6775#section-6.4
[2] https://tools.ietf.org/html/rfc4861#section-6.3.7
[3] http://www.spinics.net/lists/linux-wpan/msg03716.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx and PHR filtering

[Alexander Aring]

On Fri, Apr 01, 2016 at 10:04:40AM +, Wachtler, Axel wrote:
> What I did mean, there are various reasons, why a frame can be invalid. 
> The reserved PHR bit is one thing, invalid CRC another. The CRC calculation 
> inside the transceivers is done without the reserved PHR bit, the PHR value
> is not part of the CRC itself.
> 
> 

ok.

> 
> For RX_AACK: I would suggest not trying to be a software nanny for  the 
> hardware,
> e.g. not trying to track the *_BUSY states. (this is just an 
> temporary/transient information 
> and when you receive this information in SW, it might already be outdated)
> 
> The state change commands in RF23x are queued commands (except FORCE_TRX_OFF, 
> FORCE_PLL_ON)
> That means any ongoing transaction is completed before the next command is 
> effective
> (transaction = receiving or tranmistting a frame). 
> 
> E.g. if you are in BUSY_RX and you write CMD_PLL_ON, at first the entire 
> frame received and after it,
> the TRX switches to PLL_ON.
> 
> In all basic RX and TX states, including TX_ARET_ON, a transaction ends with 
> a TRX_END IRQ.
> 
> This is not true for RX_AACK, reasons for this are: either a CRC error or 
> address match error 
> (see address filtering in DS). This means that in case of a max length 
> frame the TRX stays in BUSY_RX_AACK for 4.xms before it switches back to 
> RX_AACK_ON. 
> 
> To end RX_AACK use either CMD_TRX_OFF or CMD_PLL_ON and wait until the 
> desired state is reached
> or one of the FORCE_commands if you need the transceiver immediately to stop 
> the ongoing transaction 
> (e.g. when a Beacon needs to be sent)
> 

I looked now in RIOT code [0].

So they will call at86rf2xx_set_state(at86rf2xx_t *dev, uint8_t state)
with state as RX_AACK_ON, but at the end they call:

_set_state(at86rf2xx_t *dev, uint8_t state)

with RX_AACK_ON, so it could be that RIOT has this behaviour:

MCU   -> at86rf2xx_set_state(foo, RX_AACK_ON)
at86rf2xx -> going into RX_AACK_ON
at86rf2xx -> detected SFD, going into RX_AACK_BUSY
  MCU   -> _set_state(foo, RX_AACK_ON)
MCU   ->  while (at86rf2xx_get_status(dev) != state) -> stucks inside 
this loop
at86rf2xx -> receiving done, going into RX_AACK_ON
MCU   ->  while (at86rf2xx_get_status(dev) != state) -> loop ends


The stucking inside the loop for assertion is here a possible case which
is bad. But okay it's unlikely I also get such issues only when I make
really big traffic.

- Alex

[0] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_getset.c#L420
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx and PHR filtering

[Alexander Aring]

Hi,

On Fri, Apr 01, 2016 at 09:17:02AM +, Wachtler, Axel wrote:
> Hi Alex,
> 
> weird things on air result mostly in a damaged CRC. However malicious frames 
> can always
> generated by any SDR. My vote would be, because RIOT targets to 15.4 to drop 
> any 
> invalid length frame early on PHY level and don't bother the upper layers to 
> handle the junk. 
> (part of the junk handling is already done in RF23x HW, e.g. when RX_AACK 
> drops invalid CRC 
> frames, or if the framefilter rejects frames with none matching addresses.)
> 

I think the PHR will not be part of CRC, also you cannot be sure that
CRC guarantees that the frame is correct received when the CRC is
correct.

I agree when the CRC is invalid then the PHR is maybe also broken,
that's why this issue is likely when going into promiscuous mode
(then crc in RX_AACK_ON will be ignored).

Let me imagine the following device which is build by a very bad
guy/girl:

Looking for preamble, then let length field in some reserved area and let
the mac frame looking okay, correct CRC, etc.

Then walk with such device on the next embedded world and have fun. ;-)
Reminds me about the TV-B-Gone remote control.

But I think when the len is above 127, then I don't know which field
will be used by at86rf2xx for the CRC (?maybe the last two ones?).
I would need to check that at first. :-)


btw: when I talking right now with an atmel expert. Aother issue would
be the state-change assertion which is recommended by:

"AVR2022: AT86RF231 - Software Programming Model"

or some other Software Programming Model of at86rf2xx on site:

"Transitions to State RX_AACK_ON"

all state changes should be have an assertion to be sure if you are inside
the state which you wanted to change in before.

This doesn't work for RX_AACK_ON, because it could be that the assertion
will be done in the time between "change into RX_AACK_ON" and "received
SFD", then the transceiver will go into BUSY state and the assertion
will fail.

It's not a failure, I am happy that I am so fast in my implementation
that this race can occur. :-) But everybody should ignore the state
RX_BUSY while assertion when going into RX_AACK_ON. That's what we do
inside the Linux driver, see [0].

- Alex

[0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L413
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx and PHR filtering

[Alexander Aring]

On Fri, Apr 01, 2016 at 08:45:48AM +, Wachtler, Axel wrote:
> > Most datasheets doesn't say anything what they filter on PHR or not.
> 
> 
> 
> The MSB in the PHR field is reserved, see at86rf230 DS:
> 
> 
> 
> [cid:image001.png@01D18C02.AB62FEF0]
> 
> 
> 
> At and after RF231 this Bit could be sent by the transceiver and can then be 
> seen at the receiver site as well.
> 
> 
> 
> Also the standard tells that this bit is reserved, so proper implementations 
> needs to mask this out in order
> 
> to get the correct frame length at the receiving site.
> 

Okay, then all transceivers need to do that and mostly at driver layer
because at the tail are mostly LQI/RSSI information.

But it's not just the MSB bit, there are also some other "len" values
which are reserved:

256  *  0-4 Reserved
257  *  5   MPDU (Acknowledgment)
258  *  6-8 Reserved
259  *  9-127   MPDU


If you received one which is reserved then you know:

"It's an invalid 802.15.4 frame".

Question is how to react on that, already drop then on driver layer ->
because it's part of phy layer and not mac layer. Or simple do what we
do with deliver the full 127 byte frame to mac layer.

We assume then something weird happend on the air. :-)

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] at86rf2xx and PHR filtering

[Alexander Aring]

Hi,

I recentely talked with another 6lowpan linux developer about an ugly
behaviour of at86rf2xx transceivers and I told him I could break many of
nodes which use them because nobody really care about that while
programming.

The issue is that the len byte inside the PHR will not filtered by the
at86rf2xx transceivers, so the length could be above 127. Also remember
this can happen when the CRC is still correct. So I can mostly overwrite
some stack space, when the buffer is allocated on stack at first.

Most datasheets doesn't say anything what they filter on PHR or not.

In conclusion we introduce inside the Linux kernel [0] and all drivers
will check the length field when receiving at first.

In case of at86rf230 driver we check the len field at first, if invalid
then we read out the full frame buffer (interesting for monitor
interfaces and mac802154/etc should filter them correctly anyway if it's
invalid), just avoid copying above 127 because array boundaries. See [1].

btw: We read also the full framebuffer always because the RX_SAFE_MODE
functionality from at86rf2xx transceivers. But then we check on a valid
length field.

The developer told me to tell that RIOT, so I just want to leave a note
here and I don't know if RIOT does filtering on that or not.

- Alex

[0] http://lxr.free-electrons.com/source/include/linux/ieee802154.h#L263
[1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L704
___
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

[Alexander Aring]

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] address option fields inside of NA/NS

[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).
> 
> General proceeding is (in my opinion), copy 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

[riot-devel] address option fields inside of NA/NS

[Alexander Aring]

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 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.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] UDP travic between RIOT device and Raspberry PI 6LoWPAN seems not to work

[Alexander Aring]

Hi,

On Sun, Mar 13, 2016 at 08:36:21AM +0100, Martine Lenders wrote:
> Hi,
> 
> Bernhard Nägele  writes:
> > thank you for that hint. Is it sufficient to enable that modul in the
> > Makefile.dep file in the main-folder, or should I add this to the Makefile
> > in my example//Makefiles? Are there any changes needed elsewhere?
> 
> it is pretty insignificant where you enable it. You can even set
> USEMODULE=gnrc_sixlowpan_iphc_nhc as a local environment variable to
> make with the same effect (which IMHO is the cleanest approach since
> it does not change any files, so in case you forget about that it
> isn't hurting you afterwards ;-)):
> 

btw:

I want to change the default handling here inside the Linux kernel.

Compression for nhc at transmit side is turned off and can be turned on
by a debugfs UAPI which doesn't exist right now.
Same handling like the "compression flag" for rfc6775 stateful
compression, just adapted for nhc.

Receive handling is default on for nhc de-compression.

This is a small open task inside the linux-kernel, everybody is welcome
to send-patches, see [0].

I currently have other priorities e.g. short address handling.

- Alex

[0] http://wpan.cakelab.org/#_developing
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] wrong checksum

[Alexander Aring]

Hi,

On Mon, Mar 07, 2016 at 09:08:01PM +0100, Martine Lenders wrote:
> Hi Malo,
> did you check if everything is coming out right out of 6LoWPAN IPHC
> and/or fragmentation (check with a sniffer)? Sometimes older 6LoWPAN
> implementations have wrong datagram sizes and do weird stuff in the
> IPHC header (don't want to discredit your work though Alexander; up
> until now it seemed fine ^^").
>

this wasn't me. The not working parts was copy from contiki from
the old maintainers.

btw: We don't have currently a stable strategy, that means we don't fix
things into stable. It's just too difficult, because the most patches
are "rework xy".

So please use the lastest greatest kernel, the RPi has meanwhile a good
mainline support, so you could use [0] which I recommend.

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] wrong checksum

[Alexander Aring]

Hi,

On Mon, Mar 07, 2016 at 10:54:13AM +0100, smlng wrote:
> Hi Malo,
> 
> First, as you referred to my question on the list: I eventually got my setup 
> working, so your's should work as well. Second, for debugging you should 
> definitely get a 3 third node to work as a sniffer and monitor connection 
> between the other 2. 
> 
> How did you enable the rf233 transceiver on the rapsi? For starters I would 
> suggest you simply use latest Raspian and activate the device-tree overlay. I 
> wrote some guides that might be helpful, see [1]. NOTE: I had some trouble 
> with the SPI freq, you should set it to 3MHz, default is/was 6MHz. But in my 
> case this was to high and all packets were corrupted -> may be that causes 
> your checksum fail? You should see those corrupted packets on the sniffer ...
> 

I thought you had different experience with RPi Kernel and mainline
kernel, see [0].

On mainline kernel it works with 6 Mhz (like in my case), but RPi kernel
has issues at 6 Mhz.

The speedup here doesn't matter much, 3 Mhz should be fine in both
cases. :-)

- Alex

[0] https://github.com/raspberrypi/linux/issues/1294#issuecomment-185448044
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] TI CC1310 and CC2650

[Alexander Aring]

Hi,

On Sat, Nov 14, 2015 at 02:33:47PM +, Adam Hunt wrote:
> Has anyone taken a look at TI's CC2560 or  C1310 processors? They're both
> based on an a Cortex-M3 processor clocked up to 48 MHz and work in the 2.4
> GHz and sub-1 GHz bands respectively. I haven't had a chance to read all
> the documentation yet but they appear similar to the CC2538, aside from one
> part, they both have a Cortex-M0 based "RF Core" softMAC supporting
> 802.15.4, 6lowpan, BLE, and ZigBee stacks..
> 

For BLE and small stack implementation, I sumble over this the last days
[0].

Maybe the RIOT people can grab some stuff from there, just for leave a
notice about some small ble stack implementation, if RIOT doesn't has
already such implementation.

- Alex

[0] https://github.com/bluekitchen/btstack/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication

[Alexander Aring]

Hi,

On Thu, Oct 15, 2015 at 02:38:29PM +0200, Andreas Weigel wrote:
> Hi again,
> 
> indeed this should solve the issue -- I have to admit, that I hadn't
> considered this possibility for our driver, because I adapted the TinyOS MAC
> layer (using the basic operating mode) and had everything there already,
> including a handling of the ACKs in software, which works reasonably well.
> 

Sorry, this sounds awful. Ack handling in software is a mess because you
have very timing ciritcal things there. That's why at86rf2xx supports
the RX_AACK states which do AACK handling -> ACK handling on the
transceiver side.

> You will obviously still have to implement the CSMA-CA mechanism then if you
> need it. Is there already usable (for the at86rf2xx) code available for a
> CSMA-CA in Riot? Then probably combining it with the existing driver (with
> deactivated CSMA-CA) would be a good solution.
> 

CSMA-CA handling is the same like above, in my opinion you can not do
this in software. Okay you working in a little mcu world and yes you
maybe can do this by calculate all factors, spi-bus speed, max interrupt
latency, etc. inside the mcu world. If you don't do that and see if it's
fit, then don't do that.

CSMA-CA handling is also done by on transceiver side (no software mac
implementation required) in TX_ARET mode (except you disable it by
change csma retries to 7).

I need to admit, I don't know how RIOT handle timing critical 802.15.4
mac things. On linux, we don't support it in the MAC implementation and
we never will do that, because we can't.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel