Re: [riot-devel] At86rf2xx ACK frame

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

Re: [riot-devel] At86rf2xx ACK frame

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

Re: [riot-devel] At86rf2xx ACK frame

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

Re: [riot-devel] At86rf2xx ACK frame

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

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

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

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

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:

Re: [riot-devel] Stacksize optimization

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

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

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

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

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

Re: [riot-devel] L2 Netstats

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

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

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]

Re: [riot-devel] Netdev2 State changes

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",

Re: [riot-devel] Netdev2 State changes

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

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

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

Re: [riot-devel] MRF24J40 radio module driver

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&q

Re: [riot-devel] MRF24J40 radio module driver

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,

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

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

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

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 (thro

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 discussi

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

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 L

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

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

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

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

Re: [riot-devel] at86rf2xx and PHR filtering

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 >

Re: [riot-devel] at86rf2xx and PHR filtering

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

Re: [riot-devel] at86rf2xx and PHR filtering

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

[riot-devel] at86rf2xx and PHR filtering

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

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

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_

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

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

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

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

Re: [riot-devel] wrong checksum

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

Re: [riot-devel] wrong checksum

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

Re: [riot-devel] TI CC1310 and CC2650

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

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

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