RIOT 6LoWPAN to Ethernet Bridge (Border Router) - Example or Documentation

[saurabh984]

Is there any implementation / example / documentation to get a border router working? I'd like to use an ethernet module connected via SPI.

Thanks S

[LudwigKnuepfer]

not yet.

[saurabh984]

Thanks @LudwigOrtmann Any pointers to get something like 6lbr for Contiki working / where to start etc? I'm happy to implement but very new to RIOT.

[OlegHahm]

I guess @authmillenon is the best person to ask. We're currently refactoring the network stack, enabling mulit-transceiver support.

Do you have any concrete hardware in mind?

[saurabh984]

Hi @OlegHahm Yes I do. Trying to run MQTT on end devices (SAM R21 Xplained Pro Boards) and Coordinator / Router / Bridge with Atmel's Ethernet1 Xplained Pro Expansion Board.

Kinda achieve ThingSquare Mist on SAM R21 with RIOT but running MQTT Stack with MQTT Broker running on a Raspberry Pi connected to the Bridge via ethernet.

Thanks

[OlegHahm]

I guess this should be achievable within Q1 2015. One of the first things we would need for that is a ethernet driver for the Atmel board. @haukepetersen, is this the same you're already working on?

[miri64]

Hello @saurabh984, as @OlegHahm pointed out already: the network stack will face some heavy rework early next year and enable multi-transceiver transport. If a driver according to the netdev API exists a border router for the device would automatically exist, as soon as the new network stack is in place. Our network stack however currently only supports CoAP on the application layer, so we would need an implementation for that, too.

[LudwigKnuepfer]

@saurabh984 do you know of an existing mqtt implementation with a compatible license?

[saurabh984]

@LudwigOrtmann Mosquitto is BSD so compatible. Source here. Eclipse Paho is Eclipse Public License which I'm not certain but think isn't compatible.

[LudwigKnuepfer]

The Eclipse license is incompatible with LGPL which we currently use. (If I remember this right..)

[saurabh984]

@LudwigOrtmann MQTT is quite simple to implement to be honest. Probably a day or 2 max I think (Famous last words ha). There's libemqtt which is LGPL but needs some work.

[LudwigKnuepfer]

Sorry, I was imprecise. LGPL 3 is problematic too, at least we thought so when we went for LGPL 2.1 back then. I guess writing or own MQTT library is the way to go.

[LudwigKnuepfer]

@saurabh984 did you by any chance start implementing something?

[cgundogan]

FYI: I implemented a very simple mqtt client some months ago with basic functionality and only QoS leve 0 and 1, if I can remember correctly. I did this on posix/linux not on riot itself, because there was no chance to speak to the outer world (excluding hackish ways). If there is still some interest I could try to port this on riot and, with my extended experience of riot now, I would retouch the software to use the vtimer/msg-api instead of threads

[LudwigKnuepfer]

@cgundogan I'd highly appreciate it, the question is when you'd have time for it ;) I guess we could also collaborate if you're interested.

[OlegHahm]

:+1:

[saurabh984]

@LudwigOrtmann No I'm afraid. Will update if I do get some time.

[LudwigKnuepfer]

@saurabh984 thanks for the update - @cgundogan and me started working on the implementation of MQTT-SN in the meantime.

[saurabh984]

@LudwigOrtmann MQTT-SN is not really needed tbh. You can implement the full MQTT protocol which can talk to the Broker directly without the need for something like the border router running a Gateway. MQTT-SN was designed way before IBM thought that something IPv6 was possible on embedded.

MQTT-SN Flow below. Sample implementation here - https://github.com/ty4tw/MQTT-SN

             Client              Gateway               Broker
                |                   |                    |      
   PUBLISH() -->| --- SERCHGW ----> |                    |  
                | <-- GWINFO  ----- |                    |  
                | --- CONNECT ----> |                    |  
                | <--WILLTOPICREQ-- |                    |  
                | --- WILLTOPIC --> |                    |  
                | <-- WILLMSGREQ -- |                    |  
                | --- WILLMSG ----> | ---- CONNECT ----> |(accepted)     
                | <-- CONNACK ----- | <--- CONNACK ----- |   
                | --- PUBLISH ----> |                    |  
                | <-- PUBACK  ----- | (invalid TopicId)  |  
                | --- REGISTER ---> |                    |  
                | <-- REGACK  ----- |                    |  
                | --- PUBLISH ----> | ---- PUBLISH ----> |(accepted)  
                | <-- PUBACK  ----- | <---- PUBACK ----- |    
                |                   |                    |    
                //                  //                   //      
                |                   |                    |          
 SUBSCRIBE() -->| --- SUBSCRIBE --> | ---- SUBSCRIBE --> |     
 [set Callback] | <-- SUBACK ------ | <--- SUBACK ------ |    
                |                   |                    |    
                //                  //                   //    
                |                   |                    |    
                | <-- REGISTER ---- | <--- PUBLISH ----- |<-- PUBLISH  
[exec Callback] | <-- PUBLISH  ---- |                    |  
                | --- PUBACK   ---> | ---- PUBACK  ----> |--> PUBACK  
                |                   |                    |  

[LudwigKnuepfer]

Why do you say mqtt-sn not needed? The possibility to have topic ids instead of topic strings appears very attractive to me.

[LudwigKnuepfer]

As for your comparison - sixlowpan appears to do for ipv6 what mqtt-sn does for mqtt... we have sixlowpan too ;)

[LudwigKnuepfer]

Oh, and the will is optional .. connection establishment can be drastically reduced.

[saurabh984]

Need for Gateway as MQTT-SN can not talk to a Broker directly. Haha I know and I meant having sixlowpan means no need for MQTT-SN except for the constrained resources it uses.

Again we'll need a Gateway Implementation too for MQTT-SN to work. Even IBM don't provide one :disappointed:

[cgundogan]

Thats true, we need a gateway to talk to the broker. I can imagine that in the long run we also might implement one to have this ability within RIOT. But for now, we can use mosquitto as it is readily equipped with a mqtt-sn gateway and broker. http://www.eclipse.org/proposals/technology.mosquitto/

[saurabh984]

Sounds good. Didn't realise IBM had released RSMB source. Let me know if I can help @LudwigOrtmann @cgundogan

[LudwigKnuepfer]

https://github.com/LudwigOrtmann/RIOT/tree/mqtt-sn << @saurabh984 the work is happening here

[saurabh984]

:+1:

[OlegHahm]

Hey @saurabh984, the border router is ready. You just need some Ethernet hardware.

[msolters]

@OlegHahm can you elaborate a little on what you mean by "the border router is ready" when using ethernet hardware?

My error was using the encx24j600 driver when the ATMEL Ethernet1 Xplained-Pro requires the KSZ8851SNL driver. Pulling and building against that driver makes everything run just fine.

I am building the border router example https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_border_router on an ATMEL SAMR21 Xplained-Pro, but rather than SLIP I am using the encx24j600 module and an Ethernet1 Xplained-Pro that is connecting directly to a router dishing out IPV6 by DHCP.

The ethernet hardware shows up successfully under ifconfig from the RIOT node.

I can't seem to wrap my head around how the IP assignment should work here, nor can I get the border router to communicate or successfully ping any other v6 IPs on the subnet.

I think it is worth mentioning as well, that the example fails to build when simply replacing the SLIP module with encx24j600. I had to actually add the encx24j600 module, and still keep SLIP. Which was solved with a simple make clean.