NAT64 Installation for Contiki-NG
Closed this issue · 51 comments
Hi,
Since I have an application using IPv4 sockets and addresses, I need to install a NAT64 to connect to my Contiki IPv6 nodes from this application.
Here is the information about NAT64: https://github.com/contiki-ng/contiki-ng/wiki/NAT64-for-Contiki%E2%80%90NG
However, it requires to install Jool kernel modules and user-space tools (https://www.jool.mx/en/install.html). Unfortunately, I don't understand how to build those packages in Yocto.
Can anyone help me on this?
Also, I would like to ask whether M3 nodes have (local) IPv4 connectivity across the testbed so that I can use their IPv4 addresses instead of IPv6? Otherwise, I need this NAT64 to be set up in the A8 nodes running together with the border router.
Hi @fkerem
I'll take a look and get back to you.
You would save my life. Really appreciate your help!
not sure if it's good news ...
Hi @fkerem
You said that you use an application with IPV4 sockets and adresses. Are you sure that your application cannot bind on IPv6 sockets. Thus M3 nodes or A8-M3 nodes can communicate directly with it. You just need to install your application on a host with an IPV6 address. Am I wrong ?
@fkerem Is it a proprietary software ?
From our side, actually the Linux kernel for A8 nodes (Kernel 3.19 version) don't support Linux modules. So to install Jool NAT64 we need to enable this support in kernel and write a Yocto bitbake recipe to install the Jool kernel module out-of-tree and another one to install Jool user-tools. In summary it's not an easy task...
Another concern is the support of Jool in Contiki-NG. If I have a good understanding only Jool version <4 are supported. See the following issue: contiki-ng/contiki-ng#852 and the note in the NAT64 documentation (Note: this script works for Jool before version 4.0). This link also: https://gitter.im/contiki-ng/Developers?at=5f7392bf5a56b467a5fabdbe
The last Jool release before 4.x is 3.5.8 and it works with kernel 4.x version. We have as roadmap to update our IoT-LAB Yocto version to Dunfell with Linux kernel version 5.4.x. So if I do this port it won't be a lasting solution.
I feel like we don't have a good solution
Maybe you can ask to Contiki-NG what is the status on NAT64 support and Jool version 4 ?
They also talk about Python script (not for production) and it may be enough for you ?
Thanks for your detailed explanation @fsaintma .
I got your point. Where did you see this Python script conversation? Maybe, it can help.
I will also ask about the status on NAT64 and Jool version 4.
Oh, I got it @fsaintma .
This Python script is to be used with Jool v4.
Actually I don't need this NAT64 to be a lasting solution.
I need to do some experiments in two weeks and then I'm done.
My only concern is that enabling the support for Jool is not easy at your side.
Hi @fkerem ,
When I was talking about a NAT64 Python script I was referring to @joakimeriksson Gitter discussion. (I did a quick attempt at a NAT64 python-based solution some time ago. It is good for "demos" and short lived tests - but not really a robust/reliable long term solution. I can try digging it out - if someone is interested?)
Maybe this would be a good starting point ?
After today I will try to install Jool (3.5.8 version) in our Linux embedded images for A8 nodes. I hope that Contiki-NG will update their NAT64 support in the future with Jool 4.x versions and I could update my side.
I will test and update the Linux image only on one IoT-LAB site. Is the Saclay site suitable ? I'll let you know if I succeed :)
Hi @fsaintma ,
Thank you very much.
I really appreciate your support.
Yes, Saclay would be just suitable.
Hope it doesn't cause a lot of work, let's see.
Best,
Dear @fsaintma ,
Before you get to the work, I'm not sure whether this NAT64 is the thing that I'm looking for.
In my case, I would like to connect from IPv4 application to IPv6 nodes.
NAT64 allows to convert IPv6 addresses to IPv4 so that it is suitable to use when the connection is initiated by an IPv6 host.
In my case, the connection is initiated by an IPv4 host. Do you think NAT64 would still be useful?
My concern is that the address space for IPv6 is higher than IPv4 and 1-to-1 (symmetric) mapping is impossible.
If I connect from IPv4, do you think it will be able to connect to the respective IPv6?
Best,
I forwarded this question to Contiki gitter channel as well.
Hi, so you need a NAT46 :) But the A8 nodes are not joignable from outside with public IPV4 address. The only way to access them from outside is directly with public IPV6 connectivity and a SSH gateway hop (SSH frontend) with IPV4 connectivity. So the first question is where is your application code which establish an IPV4 connection to an IPV6 host ?
I run it on the A8 nodes, cross-compiled for ARM.
It's not outside the testbed @fsaintma .
what do you think about that NICMx/Jool#323
Yes, based on the documentation, it is the most suitable one to our case @fsaintma .
Hi @fkerem,
I have done the job in the repository with the jool_nat64 branch.
It seems to work on development Grenoble site
root@node-a8-1:~# modprobe jool pool6=64:ff9b::/96
root@node-a8-1:~# dmesg
....
[ 258.486633] NAT64 Jool: NAT64 Jool v3.5.8.0 module inserted.
root@node-a8-1:~# lsmod
Module Size Used by
jool 124328 -2
nf_defrag_ipv6 9979 -2
ipv6 268961 -2
root@node-a8-1:~# jool
jool jool_siit joold
root@node-a8-1:~# jool -V
3.5.8.0
I release it on Saclay site and you can test it. I hope that it helps you
You can find Jool documentation (3.5.8) with this link
Hi @fsaintma ,
Thank you very very much! I'll test it tonight and let you know about the situation.
This will surely help us to elevate our research.
Does this support NAT46 as well? Just asking because the command line prints out NAT64. :)
Best,
Sorry for inconvenience, I think it supports it.
I can see the siit module :) @fsaintma
Hi @fsaintma ,
I think I'm having issues with the configuration.
Here is what I do:
root@node-a8-97:~# sysctl -w net.ipv4.conf.all.forwarding=1
root@node-a8-97:~# sysctl -w net.ipv6.conf.all.forwarding=1
root@node-a8-97:~# modprobe jool_siit pool6=64:ff9b::/96
root@node-a8-97:~# jool_siit --eamt --add 192.0.2.1 2001:0660:3207:0400::61
After I do this, I'm not able to get a ping response from 192.0.2.1 or 2001:0660:3207:0400::61.
What do you think can be wrong?
root@node-a8-97:~# printenv
INET6_PREFIX_LEN=64
TERM=xterm
SHELL=/bin/sh
SSH_CLIENT=10.0.47.251 34822 22
SSH_TTY=/dev/pts/0
LC_ALL=en_US.UTF-8
USER=root
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
MAIL=/var/mail/root
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
PWD=/home/root
JAVA_HOME=/usr/lib/jvm/openjdk-8
INET6_PREFIX=2001:0660:3207:461
EDITOR=vi
LANG=en_US.UTF-8
GATEWAY6_ADDR=2001:0660:3207:0400:ff::
PS1=\u@\h:\w\$
SHLVL=1
HOME=/home/root
LANGUAGE=en_US.UTF-8
LS_OPTIONS=--color=auto
LOGNAME=root
SSH_CONNECTION=10.0.47.251 34822 10.0.44.97 22
INET6_ADDR=2001:0660:3207:0400::61/64
_=/usr/bin/printenv
Also tested it on a node to connect to another one but the situation did not change.
The issue has been resolved thanks to the suggestion here NICMx/Jool#361
Thank you very much for all your support @fsaintma , you are a true hero :)
Hi @fsaintma I cannot run the module on Saclay site nodes, were they updated?
I was able to run them previously.
Hi @fkerem,
Yes it's not a good news :( All the Linux images have been updated with a new Distro (Yocto Krogoth 2.1 to Dunfell TLS 3.1) and we mostly have released a new Kernel version (3.19 to 5.4). So all the installation of Jool (3.5.8) with Kernel module and tool are completely obsolete and not ported in this new version. I'm also afraid that the Jool 3.5.8 version is not compatible with Kernel 5.x.
Moreover actually I don't have so much time to test a new Jool installation. To summarize I don't have a quick answer for you... Are you in a hurry to use nat64 again on IoT-LAB ?
@fkerem I don't have many solutions. I just started a new build (several hours) of the old Linux image with the 3.19 kernel and the Jool kernel module. I'm crossing my fingers that it succeeds because I'm not sure if it still works. After that, I can try to install it only on one site for a certain time. I'll let you know if the build works. For me, do you need it only on the Saclay site ?
@fkerem Some news :) I managed to build an image with Jool support. As I thought, I encountered some errors during the build and had to disable two packages (i.e. jemalloc and Java). I hope you don't need it. I just installed the Linux kernel and image with Jool support on the Saclay site. It seems to work
root@node-a8-1:~# modprobe jool pool6=64:ff9b::/96
root@node-a8-1:~# lsmod
Size of the module used by
jool 124328 -2
nf_defrag_ipv6 9979 -2
ipv6 268961 -2
root@node-a8-1:~# jool -V
3.5.8.0
I hope you understand that this is not the official IoT-LAB image support and we need to enable this support for the shortest possible time and revert to the original deployment. Let me know when you have finished your experiments.
Perfect, thank you so much @fsaintma!
Sure, I don't need those packages and I will let you know as soon as we are done with the experiments!
Hi @fsaintma,
When I want to use flash_a8_m3, I get the error: ImportError: No module named 'gateway_code'.
What can I use instead of flash_a8_m3 (iotlab_flash)?
Command: root@node-a8-33:~# flash_a8_m3 ~/shared/firmwares/udp-client.iotlab
Full error:
Traceback (most recent call last): File "/usr/bin/iotlab_flash", line 22, in <module> from gateway_code.utils.cli import programmer ImportError: No module named 'gateway_code'
I think, we could update it by using the command iotlab-ssh flash in ssh-cli.
@fkerem no easy solution as it's a problem of incompatibility with gateway code Python package build in the Linux image :(
Moreover ssh-cli-tools use also gateway code package binaries.
So for me the best solution is to flash manually with a script install in the shared directory of the frontend SSH
Hope that it helps you ...
Create an executable script iotlab_flash with this content
root@node-a8-1:~/shared# cat iotlab_flash
#!/bin/bash
FILE=$(readlink -f "$0")
CFG_FOLDER="/usr/lib/python2.7/site-packages/gateway_code/static/"
if [ $# != 1 ]
then
echo "Usage: $0 <firmware_path>" >&2
exit 1
fi
openocd -f "${CFG_FOLDER}/iot-lab.cfg" \
-f "${CFG_FOLDER}/iot-lab-a8-m3.cfg" \
-c "init" \
-c "targets" \
-c "reset halt" \
-c "reset init" \
-c "flash write_image erase $1" \
-c "verify_image $1" \
-c "reset run"\
-c "shutdown"
ret=$?
echo "Return Value: $ret"
exit $ret
And after call this script like this with your binary firmware
root@node-a8-1:~/shared# ./iotlab_flash tutorial_a8_m3.elf
Open On-Chip Debugger 0.10.0-dirty (2022-11-07-18:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
trst_and_srst separate srst_nogate trst_push_pull srst_open_drain connect_assert_srst
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020 (STMicroelectronics), part: 0x6414, ver: 0x0)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f1x.cpu cortex_m little stm32f1x.cpu reset
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020 (STMicroelectronics), part: 0x6414, ver: 0x0)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002430 msp: 0x20010000
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020 (STMicroelectronics), part: 0x6414, ver: 0x0)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002430 msp: 0x20010000
auto erase enabled
Info : device id = 0x10016414
Info : flash size = 512kbytes
wrote 47104 bytes from file tutorial_a8_m3.elf in 2.133563s (21.560 KiB/s)
verified 46332 bytes in 0.752529s (60.125 KiB/s)
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020 (STMicroelectronics), part: 0x6414, ver: 0x0)
shutdown command invoked
Return Value: 0
root@node-a8-1:~/shared# miniterm.py /dev/ttyA8_M3 500000
--- Miniterm on /dev/ttyA8_M3 500000,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
IoT-LAB Simple Demo program
Type command
h: print this help
u: print node uid
d: read current date using control_node
s: send a radio packet
b: send a big radio packet
e: toggle leds blinking
cmd >
@fkerem
I remember that we have a regression bug with the Dunfell deployment and sniffer aggregator but for Krogoth it should be work. Can you use my script to be sure that you flash a firmware on the co-microcontroller. For me it's impossible that ss-cli-tools works because it uses the Python package gateway-code
@fkerem I can confirm that sniffer aggregator works on saclay site with M3 nodes and there is no reason that it doesn't work with A8 nodes
saintmar@saclay:~$ sniffer_aggregator -r -d -o - | tshark -V -i -
1668069836.631758;Aggregator started
Capturing on 'Standard input'
1668069841.231376;m3-3;Packet received len: 54
1668069841.232060;m3-1;Packet received len: 54
1668069841.232277;m3-2;Packet received len: 54
1668069841.239344;m3-4;Packet received len: 54
1668069841.242328;m3-5;Packet received len: 54
Frame 1: 22 bytes on wire (176 bits), 22 bytes captured (176 bits) on interface 0
Interface id: 0 (-)
Interface name: -
Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
Arrival Time: Nov 10, 2022 09:44:01.202547000 CET
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1668069841.202547000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 22 bytes (176 bits)
Capture Length: 22 bytes (176 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: wpan]
IEEE 802.15.4 Beacon
Frame Control Field: 0x5320, Frame Type: Beacon, Acknowledge Request, Sequence Number Suppression, Information Elements Present, Destination Addressing Mode: None, Frame Version: IEEE Std 802.15.4-2006, Source Addressing Mode: Reserved
.... .... .... .000 = Frame Type: Beacon (0x0)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..1. .... = Acknowledge Request: True
.... .... .0.. .... = PAN ID Compression: False
.... ...1 .... .... = Sequence Number Suppression: True
.... ..1. .... .... = Information Elements Present: True
.... 00.. .... .... = Destination Addressing Mode: None (0x0)
..01 .... .... .... = Frame Version: IEEE Std 802.15.4-2006 (1)
01.. .... .... .... = Source Addressing Mode: Reserved (0x1)
[Expert Info (Warning/Malformed): Sequence Number Suppression invalid for 802.15.4-2003 and 2006]
[Sequence Number Suppression invalid for 802.15.4-2003 and 2006]
[Severity level: Warning]
[Group: Malformed]
[Expert Info (Error/Malformed): Invalid Source Address Mode]
[Invalid Source Address Mode]
[Severity level: Error]
[Group: Malformed]
Thank you so much @fsaintma, I think the problem is with flashing the firmware but I could not check it thoroughly.
I'll try that with your script today and let you know the result.
Really appreciate your support!
Hi @fsaintma,
Currently I can flash the firmware manually using your code, thank you so much!
However, when I automate that through SSH, it says:
/home/root/shared/iotlab_flash: line 12: openocd: command not found
Trying to fix that now.
Dear @fsaintma,
I resolved the previous issue, we don't need Wireshark.
Unfortunately, we have a major issue right now.
Most of the nodes that I'd like to reserve give errors:
Here is the list:
a8-21.saclay.iot-lab.info
a8-27.saclay.iot-lab.info
a8-28.saclay.iot-lab.info
a8-29.saclay.iot-lab.info
a8-32.saclay.iot-lab.info
a8-33.saclay.iot-lab.info
a8-37.saclay.iot-lab.info
a8-38.saclay.iot-lab.info
a8-42.saclay.iot-lab.info
a8-43.saclay.iot-lab.info
a8-44.saclay.iot-lab.info
a8-47.saclay.iot-lab.info
a8-48.saclay.iot-lab.info
a8-49.saclay.iot-lab.info
a8-50.saclay.iot-lab.info
a8-53.saclay.iot-lab.info
a8-54.saclay.iot-lab.info
This is a bit urgent, it would be great if you could help us on this! :)
@fkerem Ok I see it's another issue with a full filesystem on IoT-LAB gateways. I will restart all A8 Saclay nodes and it will be good.
Can I stop your experiment 345246 ?
I keep you informed.
Dear @fsaintma,
I am unable to connect to the testbed and the website right now.
Do you think my IP address is blocked? :)
Appreciate your help,
Dear @fsaintma,
We submitted the revised paper today.
Without your support, it wouldn't be possible to make it real.
Thank you very very much for your help.
Still, we are not done I think, it would be great for us if you could have a plan B for us for the next time :)
After we get the acceptance, no more headaches though, I'll let you know.
Thank you so much again and again! Feel free to contact me anytime!