Hi
I want to user arm cortex-m3 as main cpu , and then I want to use RIOT as host system , so is it possible to custom RIOP as a router system which like openwrt ?
Hi Edwin!
I want to user arm cortex-m3 as main cpu , and then I want to use RIOT as host system , so is it possible to custom RIOP as a router system which like openwrt ?
I guess it depends on what you want to connect to the Internet. If you want to connect your full-featured PCs, laptops, or tablets to the Internet, neither RIOT nor a Cortex-M3 would be a good choice, I guess. RIOT doesn't support important features for a home gateway like NAT, IPv4, Firewall rules, or port forwarding and the Cortex is probably not powerful enough to deal with the bandwidth requirements.
If you want to connect your embedded devices for home automation, sensing, or metering over 6LoWPAN to the Internet, RIOT on a Cortex-M3 could be a good choice. Although this approach has (at least) two open todos: - the border router implementation needs some love and - a driver for NIC to connect the Cortex to a traditional network (like Wifi or Ethernet) needs to be written.
Both, todos are quite feasible, but would require some programming efforts.
Hope that answers your question, Oleg
Hi Oleg
Thanks for your quick reply
I do want to custom a router connect to internet , so is it possible to custom NAT protocol or custom IPV4 protocol?
Hi Edwin,
I don't understand your question.
But like Oleg said: RIOT has no IPv4 or NAT.
Cheers, Ludwig
Hi Edwin,
You may have seen me on the Riot-OS list - Nice to meet you.
It's possible that Riot-OS doesn't do what you are asking but I think my Open-Source project clixx.io might.
I'm mixing Python and C++, and working on using MQTT as a communication protocol to allow small devices to talk over Internet.
Here's my project:
https://github.com/clixx-io/clixx.io
If you have any requests for particular things that you would like to do then please let me know.
Regards
David
I'm just quoting https://github.com/RIOT-OS/RIOT/wiki/Introduction
"The transceiver module
The transceiver module is an abstraction layer and multiplexer between the network stack and the radio driver. It runs in a single thread with the PID transceiver_pid. It provides an IPC interface that enables to configure and use available radio drivers, e.g. setting the radio channel or sending a packet. A thread may also register at the transceiver module, in order to get notified whenever a packet for a particular radio transceiver is received. The notification message contains a pointer to the packet struct. After processing the packet, the registered thread needs to decrease this struct's member processing which acts as a semaphore for the packet's memory buffer. "
I'm going to look into creating a tcp/ip socket client with the existing transceiver module. Mainly just to satisfy my own curiosity. I had fun with the TAP example, and next I'd like my packets to go a little further off to other machines.
Regards
David
I just located this module: https://github.com/RIOT-OS/RIOT/tree/master/sys/transceiver
That looks like a pretty good starting point for a TCP/IP client.
As the "Radio-Channel" parameter is specified as void*, it means that it could be adapted to specify an IPv4 address/port combination as it's essentially just an end-point address.
Of course I can see how what I'm mentioning this doesn't align with traditional stack based networking idea's but the Riot definition of a transceiver is quite powerful.
I wonder what others think?
Regards
David
Hi David,
I just located this module: https://github.com/RIOT-OS/RIOT/tree/master/sys/transceiver
That looks like a pretty good starting point for a TCP/IP client.
as a side project I'm working on new code for an HTTP client and a DNS client to showcase RIOT's true IPv6 end-to-end connectivity.
My showcase is, to do a bing search (google is forwarding to https, which is not implemented in RIOT, jet)
As the "Radio-Channel" parameter is specified as void*, it means that it could be adapted to specify an IPv4 address/port combination as it's essentially just an end-point address.
Of course I can see how what I'm mentioning this doesn't align with traditional stack based networking idea's but the Riot definition of a transceiver is quite powerful.
I wonder what others think?
what we have in RIOT is a IPv6-only stack up to UDP and TCP.
@cgundogan can you point to your application code using TCP?
@david, you can simply use POSIX sockets in your code, 1-to-1 Linux code.
in the IPv4 direction: when I'm getting my hands on an network controller with embedded IPv4 stack, I'll try to make it work in RIOT, too...I ordered Ethernet, GSM and Wifi 
IMHO: RIOT should support embedded IP stacks as well.
Best Christian
Hi David Great , I will study your project , but at the begining , I will buy a dev board , then I will contact with you again.
Thanks.
as a side project I'm working on new code for an HTTP client and a DNS client to showcase RIOT's true IPv6 end-to-end connectivity.
My showcase is, to do a bing search (google is forwarding to https, which is not implemented in RIOT, jet)
Cool.
@david, you can simply use POSIX sockets in your code, 1-to-1 Linux code.
That's good to know and I will go look for that example.
I'm personally more dedicated to using the style of MQTT messaging (short stateless packets) than socket programming in C/C++ which I've done enough of in the past.
The transfer may only be 5-30 bytes of data, but it's usually like sensor/control data being as little as Temp=24 or 24 or "Warm".
My showcase project that I'm working on at the moment is a Qt based GUI that allows you to make/edit small network programs for devices that's runs from the system-bar. In addition, lets you send + receive control messages to and from those devices over bluetooth to monitor sensor data/turn things on/off.
When it's all a bit more ready I'd like to try controlling Riot-based devices.
IMHO: RIOT should support embedded IP stacks as well.
Yes, well that's pretty much what I'm suggesting by using the existing radio interface to do that. But all these things take time and even though the potential is there to be able to knock up an IoT device for something in an evening, we're not quite there yet.
Regards
David
Hi David,
I have the feeling you still misunderstand the purpose of the transceiver. It is an abstraction layer for radio divers, not internet protocols. Example: Air -> radio -> radio driver -> transceiver -> [optional MAC] -> IP -> UDP -> application protocol -> application -> application protocol -> UDP -> IP -> [optional MAC] -> transceiver -> radio driver -> radio -> air.
What you suggested (using the channel as a port indicator) would mean that the radio driver also implements [optional MAC,] IP and UDP. I don’t know on which layer mqtt resides, but I assume it’s also anywhere between MAC and application. If you implement the logic for those layers below the transceiver, it does not make sense to use the transceiver abstraction layer anymore.
You might want to read up on the “msg” API which is used for IPC in RIOT.
Cheers, Ludwig
I have the feeling you still misunderstand the purpose of the transceiver. It is an abstraction layer for radio divers, not internet protocols.
To be more clear, I'm probably more suggesting a rethink of the model. I'm just pointing out the demarcation between radio-drivers and internet protocols is getting increasingly blurry. For example, wifi is like that.. is it radio or Internet?
If Riot just needs to be a teaching aid for students then it's fine to keep the dividing lines. If it's an operating system to live in the IoT world then that makes the priorities a little different.
What you suggested (using the channel as a port indicator) would mean that the radio driver also implements [optional MAC,] IP and UDP.
Not really. Because the TCP/IP protocol is just too complex to 'emulate' like that.
I don't know on which layer mqtt resides, but I assume it's also anywhere between MAC and application.
It's technically an application protocol for M2M communications. It's sits over TCP/IP sockets currently.
If you implement the logic for those layers below the transceiver, it does not make sense to use the transceiver abstraction layer anymore.
You might want to read up on the "msg" API which is used for IPC in RIOT.
Ok I will do that, but IPC's usually aren't inter-machine.
I guess the point I'm trying to communicate is that typical home/industrial users might not want a seperate API for every type of radio/network device which is the way things have mostly been done in the computer world for the last 30 years.
To me, a data-packet is a data-packet whether it's sent by fibre-optic, morse-code, zmodem or SMS.
So I'm putting out for discussion, if Riot can to make it simpler for sending out the packets and dealing with them no matter on what physical device is used to transport them.
Regards
David
Hi David!
To be more clear, I'm probably more suggesting a rethink of the model. I'm just pointing out the demarcation between radio-drivers and internet protocols is getting increasingly blurry. For example, wifi is like that.. is it radio or Internet?
Pretty easy, Wi-Fi as a synonym for IEEE 802.11 specifies MAC and physical layer, hence it's radio.
If Riot just needs to be a teaching aid for students then it's fine to keep the dividing lines. If it's an operating system to live in the IoT world then that makes the priorities a little different.
Well, while I agree that sometimes cross-layer concepts are useful for a more efficient implementation, I would highly recommend not to discard a model that has proven to be very helpful for the last 40 years so fast.
> What you suggested (using the channel as a port indicator) would mean >that the radio driver also implements [optional MAC,] IP and UDP.
Not really. Because the TCP/IP protocol is just too complex to 'emulate' like that.
> I don't know on which layer mqtt resides, but I assume it's also >anywhere between MAC and application.
It's technically an application protocol for M2M communications. It's sits over TCP/IP sockets currently.
So, you're saying that TCP/IP is too complex on the one hand, and suggesting
another protocol on top of it on the other hand? 
> If you implement the logic for those layers below the transceiver, it >does not make sense to use the transceiver abstraction layer anymore. > > You might want to read up on the "msg" API which is used for IPC in >RIOT.
Ok I will do that, but IPC's usually aren't inter-machine.
Not yet, but we're working on it:
I guess the point I'm trying to communicate is that typical home/industrial users might not want a seperate API for every type of radio/network device which is the way things have mostly been done in the computer world for the last 30 years.
To me, a data-packet is a data-packet whether it's sent by fibre-optic, morse-code, zmodem or SMS.
So I'm putting out for discussion, if Riot can to make it simpler for sending out the packets and dealing with them no matter on what physical device is used to transport them.
Agreed, that's definitely one goal.
Cheers, Oleg
Hi David!
> To be more clear, I'm probably more suggesting a rethink of the model. I'm > just pointing out the demarcation between radio-drivers and internet > protocols is getting increasingly blurry. For example, wifi is like that.. > is it radio or Internet?
Pretty easy, Wi-Fi as a synonym for IEEE 802.11 specifies MAC and physical layer, hence it's radio.
> If Riot just needs to be a teaching aid for students then it's fine to keep > the dividing lines. If it's an operating system to live in the IoT world > then that makes the priorities a little different.
Well, while I agree that sometimes cross-layer concepts are useful for a more efficient implementation, I would highly recommend not to discard a model that has proven to be very helpful for the last 40 years so fast.
I couldn't agree more with this. Especially since you're talking about students, and, I'm going go out on a limb here and assume that you're talking about undergrads. In that case, if you're looking for a teaching aid then I would stay as close to layered model that used in the "real world" as possible. Though, if you're talking about grad students, sure, throw the model out, experiment, and have fun.
> > What you suggested (using the channel as a port indicator) would mean > >that the radio driver also implements [optional MAC,] IP and UDP. > > Not really. Because the TCP/IP protocol is just too complex to 'emulate' > like that. > > > I don't know on which layer mqtt resides, but I assume it's also > >anywhere between MAC and application. > > It's technically an application protocol for M2M communications. It's sits > over TCP/IP sockets currently.
I missed the previous message in this thread so I'll just stick my head in here and say that while the MQTT specification *does* specify TCP as the transport it's not a huge part of the design. As long as there's a connection oriented transport layer that supports retransmission and can guarantee delivery of packets/frames/messages exists as QOS 0 assumes that some sort of effort beyond fire-and-forget is going to made, you'd probably be okay. That being said, if TCP is too complex, and in the world of low bandwidth lossy networks it often is, you should take a look at MQTT-SN. MQTT-SN nodes can be connected using almost any bidirectional communications method (fibre-optic, morse-code, zmodem, SMS, RS/EIA-232/422/485, I²C, SPI, IrDA, CAN, raw ethernet, EtherCAT, HP-IP, IRC, ISDN, PSK31, X.25, telex, MIDI, semaphore telegraph, heliograph, carrier pigeon, smoke signals, UUCP, NNTP, FidoNet...). SN devices are able to communicate with a "full fat" MQTT broker with the aid of a gateway so there's really no downside.
So, you're saying that TCP/IP is too complex on the one hand, and suggesting another protocol on top of it on the other hand?
> > If you implement the logic for those layers below the transceiver, it > >does not make sense to use the transceiver abstraction layer anymore. > > > > You might want to read up on the "msg" API which is used for IPC in > >RIOT. > > Ok I will do that, but IPC's usually aren't inter-machine.
Not yet, but we're working on it: core: Improve core IPC by kaspar030 · Pull Request #1270 · RIOT-OS/RIOT · GitHub
Interesting, I hadn't seen that PR until now. Hey, I have an idea, why not port 9P from Plan 9 to RIOT? Okay, that's probably not a viable idea.
Well, while I agree that sometimes cross-layer concepts are useful for a more efficient implementation, I would highly recommend not to discard a model that has proven to be very helpful for the last 40 years so fast.
I don't see the 40 years spent on network-stack-building as being negative. Those years were for 'growing' the codebases.
Now that we know what is needed and what is possible, we should be in a position where we can rationalise. Rationalise to make programming IoT devices easier and faster.
In the early days of my career, a company where I worked spent $6000 on a RISC Unix machine. Not sure what the specifications were, but I doubt now that it would be better than a raspberry-pi.
Since Riot is meant to be an OS for small machines with small memory, my suggestion of making an efficient operating-system for communication/networking purposes makes sense.
So, you're saying that TCP/IP is too complex on the one hand, and suggesting another protocol on top of it on the other hand?
Actually not that.
But here's the dilemma. A TCP/IP stack is too big for many small MCU's. Should we give up? or just add a dedicated IC to the hardware design that implement's TCP/IP directly?
Here's an example of current hardware that might better explain what I mean:
Good Day,
Please have a look at https://github.com/RIOT-OS/RIOT/pull/1448 especially https://raw.githubusercontent.com/authmillenon/RIOT/network-layer-interface/sys/include/basic_net.h
By specifying a network architecture based on the trusty layers, you can attach a driver for your high-level device into its proper place while also supporting really dumb interfaces.
E.g.:
+-------+ +------+ +-------+
> MQTT | | COAP | | funny |
+-------+ +------+ | App |
^ ^ +-------+
basic_net basic_net
v v
+-------+ +--------+ ^
> TCP | | UDP | basic_net
+-------+ +--------+ v
> high | ^
> level | basic_net
> net | v
> IF | +-----------------+
> with | | Network layer |
> TCP | +-----------------+
> inside> ^ ^
> > basic_net basic_net
> > v v
> > +-------+ +-------+
> > > MAC | | MAC |
> > +-------+ +-------+
> > > Radio | | Radio |
+-------+ +-------+ +-------+
Everyone wins.
Cheers, Ludwig
Hi Ludwig,
Putting all network traffic through a basic_net driver looks pretty good.
I read through basic_net.h as best as I could and it seemed pretty straightforward. I'm assuming that you just parameterise that or use different modules.
With the diagram, I'm not sure why mqtt and COAP are at the top. I would have thought that 'Application Program' would have been at the top and MQTT and COAP would have been at the bottom under Network Layer.
It's nice to see the good work that's gone in though.
Regards
David
Hi David,
When referring to the “Application Layer” in the OSI model it’s important to remember that we’re talking about application protocols, not end user applications. HTTP, Atom, DHCP, and smb/CIFS are all application layer protocols while Firefox, Google Reader, dhcpd, and Samba would be examples of applications that use the respective protocols.
Hi,