Raspberry Pi suport

[George Djabarov]

It is possible to run openthread cli example on raspberry pi? I was trying to follow the build instructions and ./bootstrap-configure fails

$ git clone https://github.com/openthread/openthread.git

$ cd openthread

$ ./bootstrap-configure

./bootstrap-configure

./bootstrap-configure: 42: ./bootstrap-configure: pushd: not found

./third_party/nlbuild-autotools/repo/scripts/bootstrap: 180: ./third_party/nlbuild-autotools/repo/scripts/bootstrap: cannot open /home/x/github/openthread/third_party/nlbuild-autotools/repo/tools/host/armv6l-unknown-linux-gnueabihf/bin/libtoolize: No such file

chmod: cannot access ‘/tmp/tmp.bootstrapwaZOEV/libtoolize’: No such file or directory

./third_party/nlbuild-autotools/repo/scripts/bootstrap: 239: ./third_party/nlbuild-autotools/repo/scripts/bootstrap: --automake-acdir=/home/x/github/openthread/third_party/nlbuild-autotools/repo/tools/host/share/aclocal-1.14: not found

./bootstrap-configure: 47: ./bootstrap-configure: popd: not found

./bootstrap-configure: 52: ./bootstrap-configure: ./configure: not found

I do have libtoolize installed:

$ which libtoolize

/usr/bin/libtoolize

Any idea what's wrong?

Cheers,

G

[Jonathan Beri]

Hey George! Mind filing an Issue on Github? Might be related to autotools. Please make sure to include the hardware version and OS you're using.

[jpbc...@gmail.com]

I found here some info as to why it doesn't work for you. You basically need to rebuild the tools needed on your new POSIX-compatible host system. 

On your Pi, go to openthread/third_party/nlbuild-autotools/repo/tools/packages and enter this command:

$ sudo /bin/bash build

You will also need to install the python module pexpect. You can use "$ sudo pip install pexpect" to do so. It's also possible that you have to upgrade ptyprocess with "$ pip install --upgrade ptyprocess" since I've had trouble with that.

Once that's done go to openthread/third_party/mbedtls/repo and do "$ sudo make" then "$ sudo make check".

Now go back to openthread/ and if everything works fine you should now be able to use the bootstrap-configure with:

$ sudo /bin/bash bootstrap-configure

$ sudo make

I've tested all of this on my raspberry pi 3 and I can successfully ping between the two nodes with the OpenThread CLI Example.

Regards,

JP

[Jonathan Hui]

On Tue, May 17, 2016 at 8:17 AM, <jpbc...@gmail.com> wrote:

I found here some info as to why it doesn't work for you. You basically need to rebuild the tools needed on your new POSIX-compatible host system. 

On your Pi, go to openthread/third_party/nlbuild-autotools/repo/tools/packages and enter this command:

$ sudo /bin/bash build

Thanks for pointing this out, JP.  The build system does not currently include pre-built versions of GNU autotools for RPi, and you will need to build those yourselves as JP noted out above.  I can add a note to the CLI example README.

You will also need to install the python module pexpect. You can use "$ pip install pexpect" to do so. It's also possible that you have to upgrade ptyprocess with "$ pip install --upgrade ptyprocess" since I've had trouble with that.

Once that's done go to openthread/third_party/mbedtls/repo and do "$ sudo make" then "$ sudo make check".

As FYI, pexpect should only be required if you want to run the test scripts (e.g. with 'make check').

Now go back to openthread/ and if everything works fine you should now be able to use the bootstrap-configure with:

$ sudo /bin/bash bootstrap-configure

$ sudo make

I've tested all of this on my raspberry pi 3 and I can successfully ping between the two nodes with the OpenThread CLI Example.

Let us know if this helps.  Thanks!

--

Jonathan Hui

[Andrei Emeltchenko]

Hi Jonathan,

I am trying to use openthread with Raspberry Pi3 with raspbian.

I can build openthread and run ot-cli binary. All commands returns Done but it seems to be not working

For examples after
> ifconfig up
Done

Should wpan0 be up? I also set some channel and see no activity there but scan command returns Done.

Regards,
Andrei

[Martin Turon]

Hi Andrei,

The ot-cli app is designed for SoC configurations that have an internal 802.15.4 radio such as the cc2538.

For RasPi, the best configuration to use would be to attach a 802.15.4 radio via some USB dongle, run ot-ncp firmware on that dongle, and control OpenThread running on the dongle via wpantund.

Martin

_____________________________
Martin Turon  |  Nest Labs

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe@googlegroups.com.
To post to this group, send email to openthread-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/853d37fa-8b59-4abc-9a35-99eaecbf8c23%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Martin Turon]

Hi Andrei,

Just for clarity, there is another path where ot-cli would make sense:

- OpenThread stack runs on the RasPi

- A 802.15.4 radio such as the rf233 is attached to the RasPi via SPI or UART

   * Example: http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio

- An otPlat radio driver is written to talk to such a 15.4 radio directly

I don't know if such a radio driver is available yet in master however, which is why I mentioned the ot-ncp configuration.  

What you have currently is likely ot-cli running as an emulation node on the RasPi.

Martin

_____________________________
Martin Turon  |  Nest Labs

[Jonathan Hui]

Hi Andrei,

The ot-cli app is actually a generic app that exposes a CLI interface to interact with OpenThread.  However, the posix platform currently implements a simulated IEEE 802.15.4 network, where each each ot-cli process is a simulated Thread device.  We use this platform to execute hardware-independent continuous integration checks.

--

Jonathan Hui

On Fri, Sep 30, 2016 at 7:54 AM, Martin Turon <mtu...@nestlabs.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CAOOu1%3DBLZRKXxS8vO5g9V8PfpPG2hrcJ1P4%3Dyqxm5HDonv9afA%40mail.gmail.com.

[Alexander Aring]

Hi,

Am Freitag, 30. September 2016 17:11:42 UTC+2 schrieb mturon:

Hi Andrei,

Just for clarity, there is another path where ot-cli would make sense:

- OpenThread stack runs on the RasPi

- A 802.15.4 radio such as the rf233 is attached to the RasPi via SPI or UART

   * Example: http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio

- An otPlat radio driver is written to talk to such a 15.4 radio directly

I don't know if such a radio driver is available yet in master however, which is why I mentioned the ot-ncp configuration.  

I currently work on that. It will use Linux specific AF_PACKET socket types with SOCK_RAW, see `man 7 packet`.

On a monitor interface it will directly connect to the PHY-Layer. However it works for my use-case to create

some virtual 802.15.4 network with Linux fakelb driver and Linux 802.15.4 interfaces.

It will not use a direct access to 802.15.4 transceiver hardware, it use the Linux kernel driver and AF_PACKET

via "posix" openthread platform. But there exists still some issues. Anyway I don't use it for real hardware, it's

for testing some stuff against openthread. It's working similar like [0].

Also possible to add a RIOT "native"  platform on another monitor interface, then you could have

Linux+openthread+riot which talking to each other, when you did the right MLE magic before. :-)

I will make some announce to the openthread-devel mailinglist the next days, but I am not able to send

pull-request to openthread upstream implementation. Sorry. :-(

- Alex

[0] https://github.com/RIOT-OS/RIOT/pull/5582

[Andrei Emeltchenko]

Hi all,

On Fri, Sep 30, 2016 at 09:32:18AM -0700, Alexander Aring wrote:
> Just for clarity, there is another path where ot-cli would make sense:
> - OpenThread stack runs on the RasPi
> - A 802.15.4 radio such as the rf233 is attached to the RasPi via SPI or
> UART

>    * Example: [1]http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio

I have exactly this setup and other similar to this (atusb - like
devices connected over USB creating normal linux wpan).

> - An otPlat radio driver is written to talk to such a 15.4 radio
> directly
> I don't know if such a radio driver is available yet in master however,
> which is why I mentioned the ot-ncp configuration.  
>
> I currently work on that. It will use Linux specific AF_PACKET socket
> types with SOCK_RAW, see `man 7 packet`.
> On a monitor interface it will directly connect to the PHY-Layer. However
> it works for my use-case to create

So this is because openthread and RIOT OS create the full 802.15.4
frame and it needs to be send AS IS?

So this in principle should work but never tested on real hardware?

> some virtual 802.15.4 network with Linux fakelb driver and Linux 802.15.4
> interfaces.
> It will not use a direct access to 802.15.4 transceiver hardware, it use
> the Linux kernel driver and AF_PACKET
> via "posix" openthread platform. But there exists still some issues.
> Anyway I don't use it for real hardware, it's
> for testing some stuff against openthread. It's working similar like [0].
> Also possible to add a RIOT "native"  platform on another monitor
> interface, then you could have
> Linux+openthread+riot which talking to each other, when you did the right
> MLE magic before. :-)
> I will make some announce to the openthread-devel mailinglist the next
> days, but I am not able to send
> pull-request to openthread upstream implementation. Sorry. :-(
> - Alex
> [0] https://github.com/RIOT-OS/RIOT/pull/5582

So what is the status with this pull request?

Best regards
Andrei Emeltchenko

[Alexander Aring]

Hi,

2016-10-03 9:43 GMT+02:00 Andrei Emeltchenko <andrei.em...@gmail.com>:
> Hi all,
>
> On Fri, Sep 30, 2016 at 09:32:18AM -0700, Alexander Aring wrote:
>> Just for clarity, there is another path where ot-cli would make sense:
>> - OpenThread stack runs on the RasPi
>> - A 802.15.4 radio such as the rf233 is attached to the RasPi via SPI or
>> UART
>> * Example: [1]http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio
>
> I have exactly this setup and other similar to this (atusb - like
> devices connected over USB creating normal linux wpan).
>

What he mean is to access the 802.15.4 rawly from userspace. This can
be done for the e.g. openlabs transceiver over linux spidev [0].
For the atusb you need libusb then or you port openthread to atusb mcu
and use wpantund stuff.

What I tell you now is another method to access a 802.15.4-layer on
the linux-kernel.

>> - An otPlat radio driver is written to talk to such a 15.4 radio
>> directly
>> I don't know if such a radio driver is available yet in master however,
>> which is why I mentioned the ot-ncp configuration.
>>
>> I currently work on that. It will use Linux specific AF_PACKET socket
>> types with SOCK_RAW, see `man 7 packet`.
>> On a monitor interface it will directly connect to the PHY-Layer. However
>> it works for my use-case to create
>
> So this is because openthread and RIOT OS create the full 802.15.4
> frame and it needs to be send AS IS?
>

Yes, but... normally you need more functionality than "send/receive my
frame out/in". E.g. you need channel switching, ED scan, LQI/RSSI etc.

> So this in principle should work but never tested on real hardware?
>

It works for my use-case, I highly not recommend it on real hardware
because there exists issues - but I think these issues can be handled
better. But I don't make it better because it fits into my use-case if
I need more features then I will try to make it possible.
I use it on some virtual setup with a 802.15.4 6lowpan linux interface
and programming some userspace MLE stuff.

You will get issues in:

- channel switching
- ACK handling (because this is not done at hardware side)
- LQI/RSSI stuff
- And lot of other things.... (Which I have not in my mind yet)

I already push the openthread changes to run it on a 802.15.4
interface at [1], you need to compile with AF_PACKET=1 as makevar.

I will explain how I use it now, I have some setup script for fakelb:

--- snip
#!/bin/sh
rmmod fakelb
modprobe fakelb numlbs=4

ip link add link wpan0 name lowpan0 type lowpan
iwpan dev wpan0 set pan_id 0x0000
ip link set wpan0 up
ip link set lowpan0 up

iwpan dev wpan1 del
iwpan phy1 interface add ot0 type monitor

iwpan dev wpan2 del
iwpan phy2 interface add ot1 type monitor

ip link set ot0 up
ip link set ot1 up

iwpan dev wpan3 del
iwpan phy3 interface add monitor0 type monitor

ip link set monitor0 up
--- snap

On "ot0" and "ot1" you can start for each an openthread instance via:

AF_PACKET_IFNAME="ot0" ./ot-cli 1

and another for ot1 and doing the normal setup-routine and it can talk
to each other.
I use the monitor0 interface to sniff traffic and the lowpan0/wpan0 is
the linux 802.15.4 6lowpan stuff.

The ot0/ot1 are monitor interfaces which doesn't do some kernel
filtering stuff and the "hardware" is in promiscuous mode.

Again, I don't want and don't support to run it on real hardware. What
I want is to talk on Linux UDP Socket-Layer and analyze some MLE stuff
- the current state of my hack is okay to do that.

Furthermore I can think about to add channel switch support which need
access to nl802154. Also running openthread on node interfaces which
supports AACK on hardware side, but this also needs access to nl802154
that the address filter is in sync with openthread instance. I think
there are more issues to get it running on node interfaces.

>> some virtual 802.15.4 network with Linux fakelb driver and Linux 802.15.4
>> interfaces.
>> It will not use a direct access to 802.15.4 transceiver hardware, it use
>> the Linux kernel driver and AF_PACKET
>> via "posix" openthread platform. But there exists still some issues.
>> Anyway I don't use it for real hardware, it's
>> for testing some stuff against openthread. It's working similar like [0].
>> Also possible to add a RIOT "native" platform on another monitor
>> interface, then you could have
>> Linux+openthread+riot which talking to each other, when you did the right
>> MLE magic before. :-)
>> I will make some announce to the openthread-devel mailinglist the next
>> days, but I am not able to send
>> pull-request to openthread upstream implementation. Sorry. :-(
>> - Alex
>> [0] https://github.com/RIOT-OS/RIOT/pull/5582
>
> So what is the status with this pull request?
>

I am waiting there for another pull request in RIOT which allows to
add more than one interface in native platform. I currently very busy
because another topics. And I don't have time to experiment more with
openthread posix platform and adding more support e.g. channel
switching.
If you want to experiment it, feel free... I also accept pull-request
for af802154 branch.

btw:
What I told there is, it should be possible to run another monitor
interface and create a RIOT instance there..., it's works on the same
mechanism.

- Alex

[0] http://lxr.free-electrons.com/source/Documentation/spi/spidev
[1] https://github.com/linux-wpan/openthread/tree/af802154