@OlegHahm ping?

Sorry, will test ASAP.

I want to test this, but could I ask for clearer instructions on how to do it?

it should work with any ethernet enabled board (including native), by just including gnrc_sixlowpan_router_default to the modules

• I'm using native and have added USEMODULE += gnrc_sixlowpan_router_default to gnrc_networking's example Makefile from master. (I see USEMODULE += gnrc_ipv6_router_default there as well, should I remove this or any other thing?)

and setting the 6Lo flag with 6LoWPAN.

• Not sure I understood this.

Wireshark should be configurable by clicking right on a packet and setting for Ethertype 0x87dd the 6LoWPAN dissector with Decode As....

• If I right-click a package on Wireshark (before the change to the Makefile) I see 0x86dd (IPv6) on the "Link" tab of Decode As... menu. 6LoWPAN is not an option on neither "Link" nor "Network" tabs.

If I do change the Makefile, no packages are seen on Wireshark (and udp server + udp send doesn't work between RIOT nodes).

it should work with any ethernet enabled board (including native), by just including gnrc_sixlowpan_router_default to the modules

• I'm using native and have added USEMODULE += gnrc_sixlowpan_router_default to gnrc_networking's example Makefile from master. (I see USEMODULE += gnrc_ipv6_router_default there as well, should I remove this or any other thing?)

Doesn't hurt to leave it in there. It won't add any code ;-).

and setting the 6Lo flag with 6LoWPAN.

Not sure I understood this.

In the shell type ifconfig <if> set 6lo

Wireshark should be configurable by clicking right on a packet and setting for Ethertype 0x87dd the 6LoWPAN dissector with Decode As....

If I right-click a package on Wireshark (before the change to the Makefile) I see 0x86dd (IPv6) on the "Link" tab of Decode As... menu. 6LoWPAN is not an option on neither "Link" nor "Network" tabs.

Damn :( then we probably need to implement some kind of dissector for that :(.

In the shell type ifconfig set 6lo

It just gives me the usage information in response to this command (which is not documented within the usage information itself). Is this the correct command?

Args sorry, drop the set.

ifconfig <if> 6lo

while you're at it you can also activate IPHC this way:

ifconfig <if> iphc

I don't think it's working:

> ifconfig
ifconfig
Iface  7   HWaddr: ca:1f:1a:cd:d9:51 

           MTU:1500  HL:64  
           Source address length: 6
           Link type: wired
           inet6 addr: ff02::1/128  scope: local [multicast]
           inet6 addr: fe80::c81f:1aff:fecd:d951/64  scope: local
           inet6 addr: ff02::1:ffcd:d951/128  scope: local [multicast]

> ifconfig 7 6lo
ifconfig 7 6lo
usage: ifconfig <if_id> [-]{promisc|autoack|csma|autocca|cca_threshold|preload|iphc|rtr_adv}
> ifconfig 7 iphc
ifconfig 7 iphc
error: unable to (un)set IPHC
> ifconfig 7 -6lo
ifconfig 7 -6lo
usage: ifconfig <if_id> [-]{promisc|autoack|csma|autocca|cca_threshold|preload|iphc|rtr_adv}
> ifconfig 7 -iphc
ifconfig 7 -iphc
error: unable to (un)set IPHC

Okay, obviously this PR still needs some work ^^". Will do as soon as I find some time.

Okay, I've updated this PR a little bit, now at least sending is working, but reception still doesn't work and it needs some investigation to find out why (I suspect some unexpected behavior regarding neighbor discovery ;-)).

Changes I did:

• Rebase to current master,
• Update of draft URL, and
• I realized, that shell: ifconfig: fixes #4028 made 6lo for the ifconfig command read-only ⇒ The flag needs to be set on start-up. For that I introduced a set pseudo-modules gnrc_sixloenc% (to inform the build about the slightly different configuration) and a constant GNRC_SIXLOENC_IFACE to allow for that configuration.

I will provide a dissector in a separate PR as soon as I found a solution for the reception problem.

Feature freeze -> postponed.

Finally came around to do something for this PR. Rebased and fixed. Problem was the header compression and the neighbor discovery: they were not able to handle MAC-48 link-layer addresses. Now they are. Regarding the "Decode As..." problem in wireshark: I issued a question for that to wireshark.

In the meantime, here is a little lua hack you can put into your ~/.config/wireshark/plugins directory:

-- get 6LoWPAN dissector
sixlo = Dissector.get("6lowpan")
-- get Ethertype dissector table
eth_table = DissectorTable.get("ethertype")
-- add 6LoWPAN dissector for experimental ethertype
eth_table:add(0x88b6, sixlo)

Note that this generates output that has a little bit of a messed up IPHC, since wiresharks IPHC implementation seems to expect IEEE 802.15.4 frames ;-).

Postponed due to Feature Freeze.

@miri64, if you're okay we can try to merge this at the next H&A.

👍

You can test with gnrc_networking on native with the following patch

diff --git a/examples/gnrc_networking/Makefile b/examples/gnrc_networking/Makefile
index fb8bfe8..1ee9781 100644
--- a/examples/gnrc_networking/Makefile
+++ b/examples/gnrc_networking/Makefile
@@ -19,6 +19,7 @@ USEMODULE += gnrc_netdev_default
 USEMODULE += auto_init_gnrc_netif
 # Specify the mandatory networking modules for IPv6 and UDP
 USEMODULE += gnrc_ipv6_router_default
+USEMODULE += gnrc_sixloenc_router_default
 USEMODULE += gnrc_udp
 # Add a routing protocol
 USEMODULE += gnrc_rpl
@@ -38,7 +39,7 @@ USEMODULE += netstats_rpl
 # Comment this out to disable code in RIOT that does safety checking
 # which is not needed in a production environment but helps in the
 # development process:
-CFLAGS += -DDEVELHELP
+CFLAGS += -DDEVELHELP -DGNRC_SIXLOENC_IFACE=7
 
 # Comment this out to join RPL DODAGs even if DIOs do not contain
 # DODAG Configuration Options (see the doc for more info)

and by adding a small dissector (which will hopefully be fixed in wireshark upstream soonish):

mkdir ~/.config/wireshark/plugins/
echo "-- get 6LoWPAN dissector
sixlo = Dissector.get("6lowpan")
-- get Ethertype dissector table
eth_table = DissectorTable.get("ethertype")
-- add 6LoWPAN dissector for 6LoENC ethertype
eth_table:add(0xa0ed, sixlo)" > ~/.config/wireshark/plugins/6loenc.lua

Hm, while pinging I get wrong ICMP checksums in Wirshark.

Ah, no wonder the source and destination addresses are corrupted, both are fe80:: (I was pinging the link local address).

Hm, while pinging I get wrong ICMP checksums in Wirshark.

Ah, no wonder the source and destination addresses are corrupted, both are fe80:: (I was pinging the link local address).

On Oct 1, 2016 @miri64 wrote:

Note that this generates output that has a little bit of a messed up IPHC, since wiresharks IPHC implementation seems to expect IEEE 802.15.4 frames ;-).

Since the addresses are in different places in IEEE 802.15.4 and Ethernet the compression of course causes garbage output in Wireshark. If I find the time I will look into it in wireshark.

@miri64 would you rebase, if this PR is still on? Otherwise close as memo?!

Would be nice to have RFC 7973 working. However, at the moment this has low priority for me and I would rather see #6121 merged first that this PR.

All in all, let's keep it open at least until the next release.... After that I might give up. However, the number 4861 is kind of important to me ;-)

at the moment this has low priority

Remove milestone, until further development.

Will revive this maybe later-on, but for now I'm closing it as memo.