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.
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.
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.
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?
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.
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.
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?
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).
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.)
Allow me to pitch in a bit… 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.