Ethos in Mac OS

Hi,

I have a question about the ethos tool in the RIOT repository. There only seems to be a linux port of this. The file ethos.c includes linux/if.h and linux/if_tun.h which do not exist in Mac OS.

Is there a way to run ethos in Mac OS?

Regards,

Adeel

Hi,

I have a question about the ethos tool in the RIOT repository. There only seems to be a linux port of this. The file ethos.c includes linux/if.h and linux/if_tun.h which do not exist in Mac OS.

Is there a way to run ethos in Mac OS?

Regards,

Adeel

Thanks for your response Francisco. I just quickly browsed through the Pull Request. Its seems like I have to run the IP stack between the border router and the end device, which is something I do not want. The code we are running runs CCN-lite directly over Ethernet towards the border router and CCN-lite directly over 802.15.4 between the border router and the end device. I have managed to run CCN-lite in RIOT on a border router with Ethernet as the underlying layer on the north bound interface and CCN on 802.15.4 on the southbound interface. Running it on IP would require more work. Maybe porting ethos.c for Mac OS would be a quicker solution, but it might turn out to be harder than one would expect.

/Adeel

Hi Adeel!

I'm trying to understand your question:

I have managed to run CCN-lite in RIOT on a border router with Ethernet as the underlying layer on the north bound interface and CCN on 802.15.4 on the southbound interface.

Do I understand this correctly: you've already achieved this, right?

              ccn-lite ccn-lite Internet <--- Ethernet ---> RIOT <--- 802.15.4 ---> Lowpan

Now you want to change this to:

              ccn-lite ccn-lite               Ethernet Internet <--- Serial ---> RIOT <--- 802.15.4 ---> Lowpan

Is this correct?

Cheers, Oleg

Hi Oleg,

What I have already achieved is the latter of the two you state. What I want to do now is also the latter of the two you state, except that now I am trying to run Ethos in Mac OS. Earlier I was running Ethos in Ubuntu Linux which worked fine.

/Adeel

Hi Adeel!

I see. Thanks for the explanation. I assume there is no Ethernet adapter available on your hardware so that you could simply use a real Ethernet connection?

That's right. I use the STM32F4Discovery platform.

/Adeel

There we are again :slight_smile:

https://tools.ietf.org/html/draft-bormann-t2trg-slipmux-00

(We have that on the agenda for the Friday Bremen/Berlin meeting.)

Grüße, Carsten

He Carsten,

No, I wasn’t aware that it proposes to replace the unstructured “shell” interface with CoAP.

But maybe adding an Ethernet frame encapsulation to slipmux would be a good thing. Beyond ICN, what are the applications for Ethernet frame encapsulation over serial?

Grüße, Carsten

Hey,

Are you aware that ethos basically does the same as slipmux?

No, I wasn’t aware that it proposes to replace the unstructured “shell” interface with CoAP.

Well, actually it doesn't. It just allows to multiplex different channels over one serial interface, currently ethernet and a serial stream.

But maybe adding an Ethernet frame encapsulation to slipmux would be a good thing. Beyond ICN, what are the applications for Ethernet frame encapsulation over serial?

It provides a simple method to get networking between a node connected via serial and the host box. CoAP can then be done on top (with probably IPv6 in between).

Kaspar

Hey,

Are you aware that ethos basically does the same as slipmux?

No, I wasn’t aware that it proposes to replace the unstructured “shell” interface with CoAP.

Well, actually it doesn't. It just allows to multiplex different channels over one serial interface, currently ethernet and a serial stream.

Right, in that sense it is similar to slipmux )except that we focused on IP packets instead of Ethernet packets — not yet sure why you’d want to do the latter).

But maybe adding an Ethernet frame encapsulation to slipmux would be a good thing. Beyond ICN, what are the applications for Ethernet frame encapsulation over serial?

It provides a simple method to get networking between a node connected via serial and the host box. CoAP can then be done on top (with probably IPv6 in between).

The point of doing CoAP over serial, with no IP in between, is that you can use it to configure the node, including IP. (There is nothing in slipmux that would stop you from also doing CoAP over IP, of course, but the latter is not useful for initial basic node configuration, and IP may also get in the way of certain management and diagnostic operations that CoAP over serial would do well.)

Grüße, Carsten

Hi

Allow me to pitch in a bit… :slight_smile: This post contains zero content related to Ethos and some opinions related to CoAP.

Well, actually it doesn’t. It just allows to multiplex different channels over one serial interface, currently ethernet and a serial stream.

Right, in that sense it is similar to slipmux )except that we focused on IP packets instead of Ethernet packets — not yet sure why you’d want to do the latter).

There are numerous research projects focusing on replacing everything between L2 and pure information theory. I’m sure this is not unique. I’m personally involved in http://point-h2020.eu/ in which the aim is to produce a better routing for IP than “traditional IP routing + CDN + content aware caching + wibbly wobbly” does.

So yes, being able to tunnel anything over X instead of tunneling IP over X is definitely a good thing.

Basically all over the world people are realizing that while Metcalfe hit very close to something pure, the upper layers are just axioms that may indeed be placed wrongly. So definitely there is a reason to tunnel L2 instead of L3. Of course this does not render L3 tunneling as unnecessary.

The point of doing CoAP over serial, with no IP in between, is that you can use it to configure the node, including IP. (There is nothing in slipmux that would stop you from also doing CoAP over IP, of course, but the latter is not useful for initial basic node configuration, and IP may also get in the way of certain management and diagnostic operations that CoAP over serial would do well.)

I think being able to CoAP over anything is good for agnosticism. Not only of protocol but that our familiar layering is by no means the only possible one. CoAP over serial is not that much different to CoAP over SMS or CoAP over avian carrier (we need an rfc though). I also think that CoAP over X with no IP in sight is perfectly valid for actual use instead of just covering the system bootstrapping phase.

  • t

P.S. CoAP over Modbus anyone?