search

tinyos / tinyos-main

Main development repository for TinyOS (an OS for embedded, wireless devices).
1.39k stars 514 forks source link

063f787 breaks PppRouter and CoapBlip #300

Open thp-comnets opened 9 years ago

thp-comnets commented 9 years ago

As already mentioned in the comments of 063f787, this commit breaks both applications for telosb nodes.

PppRouter seems to have an ROM overflow, even when disabling neighbor discovery in the Makefile. Since this app is essential, I think it should work right away without letting the user disable anything (somewhere in the Makefile).

CoapBlip:

  1. ./configure --with-tinyos has to be done first as this command is not included in the build procedure of /tools/. Does it make sense to include in the build too?
  2. However, I get the following error message when executing make telosb blip coap: In component RPLRankP: ../../tos/lib/net/rpl/RPLRankP.nc: At top level: ../../tos/lib/net/rpl/RPLRankP.nc:112: divideRank undeclared here (not in a function) ../../tos/lib/net/rpl/RPLRankP.nc: In function exceedThreshold: ../../tos/lib/net/rpl/RPLRankP.nc:223: ETX_THRESHOLD undeclared (first use in this function) ../../tos/lib/net/rpl/RPLRankP.nc:223: (Each undeclared identifier is reported only once ../../tos/lib/net/rpl/RPLRankP.nc:223: for each function it appears in.) ../../tos/lib/net/rpl/RPLRankP.nc: In function insertParent: ../../tos/lib/net/rpl/RPLRankP.nc:320: INIT_ETX undeclared (first use in this function) ../../tos/lib/net/rpl/RPLRankP.nc:322: divideRank undeclared (first use in this function) ../../tos/lib/net/rpl/RPLRankP.nc: In function ForwardingEvents.linkResult: ../../tos/lib/net/rpl/RPLRankP.nc:521: divideRank undeclared (first use in this function) ../../tos/lib/net/rpl/RPLRankP.nc: In function parseDIO: ../../tos/lib/net/rpl/RPLRankP.nc:723: divideRank undeclared (first use in this function) ../../tos/lib/net/rpl/RPLRankP.nc:796: INIT_ETX undeclared (first use in this function) ../../tos/lib/net/rpl/RPLOFC.nc:19:2: error: #error "You must select a RPL objective function" In component `RPLOFC': ../../tos/lib/net/rpl/RPLOFC.nc: At top level: ../../tos/lib/net/rpl/RPLOFC.nc:27: cannot find RPL_OF ../../tos/lib/net/rpl/RPLOFC.nc:29: cannot find RPL_OF ../../tos/lib/net/rpl/RPLOFC.nc:30: cannot find RPL_OF ../../tos/lib/net/rpl/RPLOFC.nc:31: cannot find RPL_OF ../../tos/lib/net/rpl/RPLOFC.nc:32: cannot find RPL_OF ../../tos/lib/net/rpl/RPLOFC.nc:33: cannot find RPL_OF ../../support/make/Makerules:348: recipe for target 'exe' failed make: *\ [exe] Error 1
bradjc commented 9 years ago

I'm looking into this, but I'm not really sure what to do. The size issue is a problem because PppRouter was at the very limit of fitting in ROM before 063f787 and continuing to support PppRouter on the MSP430F1611 means basically not adding any new features to Blip/RPL. This is problematic because before 063f787 the addressing schemes supported by blip were rather awful and maintaining interoperability with nodes running contiki may mean adding to blip.

I don't personally use PppRouter or similar and instead use more capable Raspberry Pis/Beaglebone Blacks as border router/gateway nodes. But requiring a new node to bridge blip/ipv6 to a computer or internet makes blip much harder to use/get started with.

Any thoughts on how to proceed?

gnawali commented 9 years ago

What does Contiki solution look like if it has the equivalent of PppRouter?

Remember - we do have some non-mote tools in TinyOS...

cire831 commented 9 years ago

I'm of the opinion that we should not support BLIP on the really old 1611 processor. Sorry but at some point running out of space is running out of space.

On Fri, Aug 1, 2014 at 3:04 PM, gnawali notifications@github.com wrote:

How does Contiki solution look like if it has the equivalent of PppRouter?

Remember - we do have some non-mote tools in TinyOS...

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/300#issuecomment-50940047.

Eric B. Decker Senior (over 50 :-) Researcher

sanjugem commented 9 years ago

Just to add this is error popping during compile of CoapBlip for telosb /home/developer/Documents/rich/tinyos-main/tos/lib/net/coap/resources/CoapLedResourceP.nc:225: syntax error before " * " make: *\ [exe0] Error 1

any idea on this ? command : make telosb blip coap install,3 bsl,/dev/ttyUSB0

jdede commented 9 years ago

@gnawali: Contiki uses SLIP (Serial Line Internet Protocol) for the border router. It tunnels the IP traffic via a serial line. The protocol is much easier compared to PPP. As a tradeoff, you need a special application called tunslip respectively tunslip6 at the host computer.

This solution seems to be very efficient regarding memory consumption. The Contiki border router also comes with a small HTTP server which shows the current routing table. Everything fits into one sky / TelosB node.

If the memory usage is so critical and cannot be fixed easily, may it be reasonable to switch from PPP to tunslip in TinyOS?

cire831 commented 9 years ago

SLIP really isn't Serial Line IP but rather a packetzation mechanism that denotes the start and end of packets. It doesn't have a type field.

Is Contiki using it for IPv4 or is it using it with it's IPv6 implementation too?

On Wed, Aug 13, 2014 at 1:32 AM, JD notifications@github.com wrote:

@gnawali https://github.com/gnawali: Contiki uses SLIP (Serial Line Internet Protocol) for the border router. It tunnels the IP traffic via a serial line. The protocol is much easier compared to PPP. As a tradeoff, you need a special application called tunslip respectively tunslip6 at the host computer.

you need a special application for our PPP stuff too. equivilent to tunslip. but a more off the shelf ppp end point.

This solution seems to be very efficient regarding memory consumption. The Contiki border router also comes with a small HTTP server which shows the current routing table. Everything fits into one sky / TelosB node.

Indeed, PPP is much more complicated than SLIP.

If the memory usage is so critical and cannot be fixed easily, may it be reasonable to switch from PPP to tunslip in TinyOS?

Do we want to start simplifing, so that things fit into a really old mote? I'm fine with that, just asking the question.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/300#issuecomment-52022382.

Eric B. Decker Senior (over 50 :-) Researcher

jdede commented 9 years ago

There is a tunslip for IPv4 and tunslip6 for IPv6. So it works for both. I have tested it with IPv6 some month ago and it worked fine.

gnawali commented 9 years ago

Is there any disadvantage to providing this as one of the ways to do ipv6? At least there will be one documented pathway to get ipv6 up and running without struggling with code size on the border router.

cire831 commented 9 years ago

code size on the 1611 will probably continue to be an issue, especially with the ipv6 stack. I don't know if anyone has done an analysis of how much code lives where for the ipv6 stack.

the advantage of using SLIP is ostensibly a reduced complexity resulting in reduced code size.

The down side is as far as I know there isn't any standard for how to encapsulate ipv6 packets in SLIP. We would probably copy how ConTiki does it. But is ConTiki using SLIP for the IP stack and/or IPv6 stack.

So back to the original question? Do we really want to continue to support border router functionality on motes like the 1611 that have a small code space?

thp-comnets commented 9 years ago

In my opinion the MSP430F1611 (aka TelosB) is one of most widely used motes and I think it is essential to support the border router for these devices further.

jdede commented 9 years ago

Another interesting point is that Contiki supports the sky / telosb platform. They even test against this platform for the CI build using travis. No PR is accepted if the build on the sky platform fails.

As @thp-comnets mentioned: the platform is widely used. Dropping the support for it would lead to a large disadvantage compared to Contiki.

ppannuto commented 9 years ago

Wait.. I'm confused. I don't think anyone is suggesting that TinyOS stop supporting the TelosB or that border routers shouldn't continue to support networks that include TelosBs. The argument here is that the border router application, which by its nature is a heavyweight application, shouldn't be shoehorned into the tiny 1611 MCU on the TelosB (an argument I wholeheartedly agree with).

The TelosB can't act as a border router on its own without a support machine anyway, so this isn't really a huge change. It just means that a different, more capable mote will have to act as the gateway.

jdede commented 9 years ago

Okay, that is clear. I'm sure nobody has attached an ethernet port to the TelosB. Thus, a support machine is needed anyway. Assuming a RaspberryPi, a *WRT router or just a laptop, we still need an IEEE 802.15.4 interface. How to provide this in a generic way? Would it be possible to strip down the border router similar to the old BaseStation for this? Or the already mentioned tunslip? Then the node acts as a simple bridge. The main processing is done on the host PC. In my opinion, this solution has two advantages:

Or am I ignoring some essential points?

What kind of hardware are you using for your setups? Is it available for everyone and can be connected without any knowledge in soldering to standard devices (i.e. USB connector)?

cire831 commented 9 years ago

On Fri, Aug 22, 2014 at 1:40 AM, JD notifications@github.com wrote:

Okay, that is clear. I'm sure nobody has attached an ethernet port to the TelosB. Thus, a support machine is needed anyway. Assuming a RaspberryPi, a *WRT router or just a laptop, we still need an IEEE 802.15.4 interface. How to provide this in a generic way? Would it be possible to strip down the border router similar to the old BaseStation for this? Or the already mentioned tunslip? Then the node acts as a simple bridge. The main processing is done on the host PC. In my opinion, this solution has two advantages:

  • No further restrictions regarding CPU / RAM / ROM as main processing is done at the host computer
  • Homogeneous network hardware. No need of special hardware for the border router would lead to more flexibility when testing the sensor networks.

Or am I ignoring some essential points?

What kind of hardware are you using for your setups? Is it available for everyone and can be connected without any knowledge in soldering to standard devices (i.e. USB connector)?

No you are not missing anything. I think you have summed up this problem very succinctly.

The problem as Pat has reiterated is shoe horning the border function into the 1611. No one is suggesting dropping general support for the telosb.

A simple bridge function of some kind would be good. This however opens up the issue of what protocols are bridged. etc. You have to define what the translation looks like from the media on one side to the serial side.

Just saying its non-trivial and requires work and I don't know who is going to do the work.

Personally, I think it makes much more sense to run a light weight protocol on the mote side (like AM) but with an addressing scheme that easily maps into an IPv6 numbering scheme. AM generally can do this trivially.

Then the bridge is pretty simple.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/300#issuecomment-53036690.

Eric B. Decker Senior (over 50 :-) Researcher

thp-comnets commented 9 years ago

As I was just about to port CoapBlip to the latest CoAP version, I stumbled again over this issue. Essentially I agree on the idea to move the functionality of PppRouter to the host machine, but it seems there is no progress on this at the moment. Which means to me that using TinyOS with PppRouter and blip enabled applications does not work anymore. As far as I know, the PppRouter is the only way (and also the way described in the wiki) to connect a host to a WSN when using IPv6. If this is not working anymore, how can people use these applications? Or am I missing something here?

Instead of having a "broken" solution, my suggestion would be to create a lightweight version of PppRouter, as it was before ND was added, to get it back working while looking for a better solution.

andrasbiro commented 9 years ago

In theory, PppRouter should work on RFA1 based motes since 8a2e30a423afb2f1c254a486ae6879ac0a993f29, I just don't understand blip enough to test it in every aspect.

I heard most of the blip users use eighter some kind of commercial edge router or something like this: https://github.com/lab11/raspberrypi-cc2520/

But I agree, the current solution is basicly "If you want to use blip, buy some new hardware", and on top of that, it's undocumented.