Hi Husarnet guys.
I was doing some tests with Zenoh Bridge for ROS2, trying to launch Zenoh automatically on a client device pointing to a master device where Zenoh was running, like this:
zenoh-bridge-ros2dds --connect tcp/$public_ipv6:7447
Turns out that the $public_ip was being retrieved from Husarnet using API call to /network/ID, and the IP of the device was like this):
1111:111:909:1111:1111:1111:1111:6333
But on the /etc/hosts file of the devices, it was like this:
1111:1111:0909:1111:1111:1111:1111:6333
The difference is that on /etc/hosts the 3rd section of the IP is 0909 but on https://app.husarnet.com/network/ID the value is 909. The 1111 values above are just examples; the the 909 is a correct value present on the device-id.
This reminds me of the “npm left-pad incident” where a “11 line npm package called left-pad broke the internet”.
I’m aware that you call this field device-id and not device-ip when we call the API, but I just used it as the IPv6 because it is ‘definitely’ the device IPv6; but feel free to correct me if I’m mistakenly misusing the field or making wrong assumptions.
I can and will definitely solve this on my side by manually adding ‘zeroes’ if the values returned from Husarnet have less than 4 digits, but I’m letting you know because this may someday cause another left-pad incident on millions of robots.
[update]
Oh, I just realized that if I right_justify the IPv6 sections by adding zeroes to the left, when I try to get the device status using the API it doesn’t find the device. Just take that into consideration if you decide to right_justify the device-id.