Currently OT uses otPlatRadioIdle() to transition the radio between receive and transmit. It might be more natural and straightforward if OT were to instead remove the option for a radio Idle State and instead treat the radio as operating in one of the following States {Disabled, Sleep, Receive, Transmit}. To transmit a packet OT would then make a call to otPlatRadioTransmit() without a pre-requisite call to otPlatRadioIdle(). This also creates an assumption that if the radio is not Disabled, Transmitting or Sleeping then it must be Receiving. This should reduce opportunities for missing received packets and simplify the OT code.

We have good positive path test coverage of OpenThread now using make check and the CI test suite.

Perhaps the negative path test coverage of OpenThread could be built using "fuzzing" techniques, and some of the tools available in that space.

The GDS blog discusses the technique, good open source tools to implement it, and even have examples applying the method to an instrumented mbedtls:

"Fuzzing is a testing technique that feeds a program under inspection with random inputs and observes its behavior. The goal of fuzzing is to discover bugs in the inspected program."

We will need a Thread Sniffer for debugging and analyzing the OpenThread.
The Sniffer can also be used to debug and analyze any other thread traffic.

The wpantund and the ncp app both response to the echo request from the soc app, if the soc app uses the mesh local address as the destination address.
Could I know which side should response to this echo request? The laptop running wpantund or the end node running ncp app?

When the time is right, we should cut an initial release (maybe after I/O?) Items I think we could include in the release description can include:

• Supported Thread spec version
• Spec features added, enhanced or changed
• Device, library or framework support
• Docs and tools improvements

Anything else?

There is no functionality in which MAC layer would inform radio (implementation) layer about pending frames for a particular node. In this case implementation is forced to always set FRAME_PENDING bit in ACK frames. This is not ideal for sleepy devices, that will send DATA_REQUEST, receive an ACK with FRAME_PENDING bit set and wait for (probably) non-existent packet and waste battery life.

The CLI currently does not have an output FIFO, which can cause characters to be lost if subsequent output is generated before the serial driver can transmit the first request.

I noticed that we have both README and README.md files. We should get rid of one or the other, and I vote for getting rid of README.

I would have just filed a pull request for this, except that there is text in README that doesn't appear in README.md, so I'm not sure if/how the data from README should be merged into README.md.

This should be resolved before any initial first cut.

It is rather confusing that the name of the executable for the cli app is soc. I think we should consider renaming it to something more clear.

The route command appears to seg fault when called with no arguments:

$ ./soc --nodeid=1 -S
route
route
Segmentation fault: 11

Ability to capture raw IEEE 802.15.4 frames from the radio will enable packet sniffing capabilities. Ideally, this can be enabled whether or not the Thread stack is also operating.

Thanks for open-sourcing this implementation. What are the pre-requisites to 'make' and run openthread from source code? i.e. for testing and getting things to run exactly as in your documentation what board/platform/system is recommended?

I am trying out thread with android comissioning app, edison/brillo/weave, nxp and silabs and wondering how this works with these other implementations... Can you provide some pointers on getting started with this implementation and about the compatibility with other thread apps?

Maybe I'm misinterpreting the code, but having a look at ProcessReceiveSecurity() in src/core/mac/mac.cpp:

ThreadError Mac::ProcessReceiveSecurity(const Address &aSrcAddr, Neighbor *aNeighbor)
{
    ThreadError error = kThreadError_None;

    // ...

    if (mReceiveFrame.GetSecurityEnabled() == false)
    {
        ExitNow();
    }

    // ...

exit:
    return error;
}

I checked later on and I don't see any obvious indication that insecure packets are given any additional attention. Obviously the stack needs to be able to handle insecure traffic, but it must handle it with care to ensure that these sorts of packets aren't confused as legit network traffic and passed up the stack (except under very specific circumstances, and even then always handled differently).

The Timer logic fails to execute expired timers in order of earliest expired to last expired. Instead the logic executes the first expired timer in the list.

Currently, a subset of OT calls are designed to be called from interrupt context when another call to OT may be interrupted. It is preferable for all locking/concurrency handling to be handled outside of OT, as this is necessarily platform-specific. This would also greatly simplify the otPlat* driver APIs.

Remove any locking/concurrency handling from OT would mean:

1. Removing the Atomic platform abstraction and any use of Atomic within OT.
2. Removing all otPlat*Signal* calls into OT.
3. Updating the POSIX example to use a single thread of execution.

POSIX example platform radio implementation can return kThreadError_Busy in state change operations (otPlatRadioEnable, otPlatRadioSleep, otPlatRadioIdle, otPlatRadioReceive and otPlatRadioTransmit), however the documentation does not allow such return.

When running 'make pretty' under ubuntu, error would happen complaining as below

Invalid option file options:
style="allman"

the environment I am using is
Artistic Style Version 2.04
Ubuntu 14.04.4 LTS

the command could work when do some modification on the file .astyle-opts
--style="allman" ===> --style=allman

Expose LQI measurements on received frames from the radio up through the Thread stack.

Running the netdataregister doesn't return the expected 'Done' response:

./soc --nodeid=1 -S
netdataregister
netdataregister

After running the command, other commands still work. But if the command is run twice, the shell becomes unresponsive to all commands:

./soc --nodeid=1 -S
netdataregister
netdataregister
panid
panid
65535
Done
netdataregister
netdataregister
panid
panid

While we're targeting an OSS toolchain, folks use a bunch of different compilers @ work. IAR seems to be a common request and one that doesn't work out of the box. See this SO question as an example.

It's not feasible to target every toolchain, but we should at least be able to come up with a strategy to help people use their preferred (or required) toolchains.

In POSIX platform example FRAME_PENDING flag is set to true if the local device just sent MAC command frame (before commit b865607, it checked that it was DATA_REQUEST MAC command). This creates few issues:

1. The requester (local) device decides whether the responder (remote) device has pending data frame.
2. The requester (local) device ignores responders FRAME_PENDING bit.
3. FRAME_PENDING bit is set to true for all MAC commands (not just DATA_REQUEST).

In section 4 of app CLI readme, there is a link to more (core) CLI documentation. That link is dead (https://github.com/openthread/openthread/blob/master/examples/posix/src/cli/README.md) and [I think] it should point to https://github.com/openthread/openthread/blob/master/src/cli/README.md.

This probably happened after code rearrangement.

Please add official trademark policy incuding usage guidelines for logos, images, and the Thread (TM) name, etc.

Example:

http://kodi.wiki/view/Official:Trademark_Policy

Currently, the scan command does not work unless start is first called. In order to support commissioning and general network discovery, the scan should be possible without starting the network and attaching.

It would appear that currently all certification tests fail on OS X with errors similar to the following:

======================================================================
FAIL: test (__main__.Cert_5_1_01_RouterAttach)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./thread-cert/Cert_5_1_01_RouterAttach.py", line 66, in test
    self.assertEqual(self.nodes[ROUTER].get_state(), 'router')
AssertionError: 'leader' != 'router'

----------------------------------------------------------------------
Ran 1 test in 10.105s

Build success,but run /examples/posix/app/cli/soc 1 , nothing happen
OS is OS X
I tried sudo , and no effect yet

The platform api should be extended to provide a platform-specific means to store items that are required to be non-volatile.

Couple of ideas:

• Calculating the link margin based on running average of rssi
• Using a running average noise-floor for calculation of link margin
• Considering to add hysteresis for converting link margin to quality (per spec)

include found in openthread.cpp is not available on all platforms. A more portable way for initializing and assignment memory to the ThreadNetif needs to be provided to make Openthread more portable.

The sniffer that does not need the OT stack, but need the otPlatRadio interface, common scheduler, message queue, etc.
Then the sniffer needs to include libopenthread.a, which causes the multiple definitions error. The mac and sniffer both use otPlatRadioSignalReceiveDone.
Do we need to have a standalone library for the common functions that does not related with the thread stack? Then other app could do not always need to include the whole ot stack, while they do not need to use it, or only part of it.

This line of code is dangerous when compiled for an embedded platform:
https://github.com/openthread/openthread/blob/master/src/cli/cli_serial.cpp#L106

Accidentally pressing CTRL-C in your CLI terminal will halt execution and require a reset.
Perhaps it would be okay if a proper watchdog is implemented on the platform.

Add ability to capture received IEEE 802.15.4 frames for sniffing and debugging.

Capturing raw IEEE 802.15.4 frames should be possible when:

1. the Thread interface is enabled, capturing all IEEE 802.15.4 frames that are processed by OpenThread.
2. the Thread interface is disabled and capturing all IEEE 802.15.4 frames with IEEE 802.15.4 promiscuous mode enabled.

The prefix command with no arguments appears to seg fault:

/soc --nodeid=1 -S
prefix
prefix
Segmentation fault: 11

This occurs whether thread stack has been started or not.

In addition to the "SoC/CLI" implementation that is already included, OpenThread needs a Network Control Processor (NCP) implementation to facilitate applications where the Host Controller is logically separate from the controller that implements the Thread stack (Which is the NCP). This task also necessitates the definition of the protocol that the Host Controller and the NCP use to communicate with each other.

I have developed a starting point for both of these, which are currently living in the development branch feature/ncp-spinel. The initial name of the protocol is "Spinel", but the long-term goal is to standardize the protocol to be the official Thread Host Controller Interface (or THCI) line protocol.

A draft of the Spinel protocol document is included in this branch. Expect it to be updated regularly to improve readability and organization, as well as to incorporate received feedback and real-world experiences. At this point everything is subject to change, but as-is the protocol has been demonstrated to work fairly well.

The NCP implementation in the branch has been tested, and is working well enough for basic connectivity, but is far from complete. A Host implementation is not yet provided in the tree, but will likely eventually be included. A separate host implementation for Linux has been written and is anticipated to be released as a separate project over the next few weeks.

The feature/ncp-spinel branch will be under heavy development and rebases should be expected.

Thoughts and feedback are welcome and appreciated.

Given certain roles require far fewer resources to support, openthread should have a way to compile the stack such that only the necessary functionality to serve the desired product role is included.

Specifically, a targeted child-only or sleepy end device configuration would be useful and necessary for highly-constrained platforms.

Those platform radio API's which take no arguments, lack the requisite (void) declaration and instead appear as follows.

ThreadError otPlatRadioEnable();

The autotools build system can do a number of things. This task would be to improve the documentation so it is easy to determine what can be done and how to do it:

• unit tests: how to build them; how to run them?
• pretty: how to verify coding convention conformance; what prerequisite tools are needed?
• code coverage: how to run analysis; how to view html output?
• doxygen: how to regenerate the docs?
• check: how to run certification tests; how to configure to run against hardware vs. simulator?
• tags: how to generate and use tags to browse the code via emacs or other tool?
• cross-compilation: how to compile the library for a different target architecture?

Please consider letting non-profit open source projects, such as example Domoticz and OpenHAB, join the ThreadGroup for free.

In src/ncp.hpp, we are currently allocating two 1500 byte buffers: one for sending, and one for receiving. This is quite wasteful. There are also several cases where outbound frames might be dropped due to the fact that the device is in the process of sending a previous frame.

If radio supports ACK timeout, and radio reports that No ACK received, Mac::TransmitDoneTask may retransmit the same frame constantly.

The current default value of the PANID (as retrieved by otGetPanId()) is 0xFFFF. This itself isn't a bad default—it effectively implies that the PANID is undefined (because it is not a valid PANID for a network).

However, the current OpenThread stack seems to take this value and run with it anyway, happily creating a new partition with the PANID 0xFFFF instead of doing something more reasonable (like calculating a new PANID).

I propose that the behavior for having a PANID of 0xFFFF should be to:

• If a suitable already partition exists and has a legal PANID, use the PANID from that partition and join it. (maybe we would want to do this anyway)
• If no suitable partition is found nearby, allocate a new PANID and use that to start a new partition.

Thoughts?

Starting to work with this implementation it is quite complicated to find out, how the abstraction layer is realised and used.

Is it possible to add a more extensive explanation either in a separate file, or as inline comments for the example implementations, that the line becomes clearer where the example posix implementation ends and the common open thread core code starts?

Some radio chips have memory-mapped regions for transmit and receive buffers. Having the radio driver provide buffers directly helps avoid unnecessary copies.

This may be obvious, but when starting the example at https://github.com/openthread/openthread/tree/master/examples/cli the README shows:

$ ./soc --nodeid=1 -S
$ start
Done

However, when I actually ran this example, I thought soc had hung because there was no $ prompt printed. Here's what I actually get when running it:

$ ./soc --nodeid=1 -S
start
start
Done

Everything works, but just may be a bit confusing for people trying this for the first time.

1. prefix add [pvdcsr] [prf]
   here allowed prf value in implementation is [high, med, low], not an integer in the range [-1, 1]

2. route add [s] [prf]
   same as above, allowed prf in implementation is [high, med, low]
   here 'r:Default Route flag' should be removed

The default build options attempt to compile examples and cli. It is proposed that these sub-dirs only get compiled when explicitly configured to do so.

Embedded platforms may not have access to this header or the in6_addr structure included by spinel.h:

[spinel.h]

 #include <arpa/inet.h>
// ...
typedef struct in6_addr spinel_ipv6addr_t;

Perhaps moving over to using openthread-types.h would be more appropriate?

#include <openthread-types.h>
// ...
typedef otIp6Address spinel_ipv6addr_t;

I read the document saying that EC-JPAKE is used for key agreement but I can't find any use of JPAKE in the code. It would be great if the CLI could demonstrate the key agreement. (Also, it would be great if the symmetric key management that the CLI does implement was more clearly documented.)

Some examples of useful notifications:

• Device Role (e.g. detached, child, router, leader).
• IPv6 addresses added or removed.
• Partition ID
• etc.