-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LinuxEthernetTap improperly changing MAC while tap/tun device already up #1314
Comments
Just chiming in to report the same problem on CentOS/RHEL 6. Reverting back to ZeroTier 1.4.6 fixes it. |
Same problem on Ubuntu 16.04 LTS |
Same problem with router R7000 rt-ac68u Reverting to ZeroTier 1.4.6
|
I've been having issues on an OpenVZ VPS with anything newer than 1.4.6. For me, this alters the issue symptom from giving "destination unreachable" to 100% packet loss for an outgoing ping to another ZT host ( |
I've now done a proper I've opened a new PR to set the MAC address prior to bringing up the TAP device. It seems more reliable to set MTU after bringing up the device. |
please update source code, many users affected |
@jonathonf unfortunately, the PR breaks other Linux distros intermittently. |
Which distros? Which kernels? How/why is it intermittent? Without the PR ZeroTier is reliably broken on certain systems, which seems better than intermittently broken on others? |
Debian and red hat based distros. Basically anything not running openvz |
As I said in the PR, ZT with the patch (and therefore 1.8.1) works on all of the distros I tested, which includes Debian, Ubuntu, and Arch (on a variety of metal and virtualised systems). Can this be narrowed down to a more specific set of affected systems, or linked to an Issue? Edit: This only reported issue I can see with 1.8.1 is #1486 and that was "solved" by leaving and rejoining the network. |
hey thanks for reminding about this. The 1.8.2 code sets the MAC before and after ZeroTierOne/osdep/LinuxEthernetTap.cpp Line 202 in 3f4cd7f
It may have taken a couple commits to get there. Will look more later. |
A What system/config/etc. are you seeing the incorrect MAC issue on so I can try to replicate here? Testing on one of my Debian systems (metal, Bullseye, 4.19.0-18-amd64) with 1.8.1:
|
For me, a fresh debian 11 amd64 vm. |
I can replicate on a Bullseye system
using the ZeroTier 1.8.1 binary:
However, according to the apt sources list, the published Bullseye packages seem to be built against Buster libraries:
After compiling 01bf3b8 locally against Bullseye libraries,
the problem seems to be gone:
I note that there is a Bullseye package available under http://download.zerotier.com/debian/bullseye/pool/main/z/zerotier-one/, and yet after installing http://download.zerotier.com/debian/bullseye/pool/main/z/zerotier-one/zerotier-one_1.8.1_amd64.deb the issue also occurs:
This kind of implies the issue lies somewhere in your package build infrastructure? It might be worth checking that packages are being compiled against the correct library versions for the distro on systems where you're seeing this happen? |
We will need to update install.zerotier.com and have people having this issue reinstall to use the |
Actually, after building a 1.8.1 deb in a Bullseye
the "incorrect MAC" issue occurs. I've tried with a range of flags in Edit: I'm not convinced that the "incorrect MAC" issue is not a bug somewhere in Bullseye. I switched to the backport 5.14 kernel and used the above pbuilder-compiled 1.8.1 deb - no incorrect MAC issue. 1.8.1 from the ZT repo - incorrect MAC. |
hey @jonathonf, just to double check openvz is broken on 1.8.2 and .3? |
Confirm, broken on what I think is OpenVZ 6:
Although, maybe this means it's just time to retire these VPS... they also can't be updated to newer Debian because of the outdated host nodes - annnndddd I just noticed OpenVZ 6 was EoL in November 2019, so why the provider is still running this is beyond me. |
Confirming, 1.8.3 works fine on OpenVZ 7. I suspect this can be closed, supporting an EoL operating system isn't reasonable. |
ZeroTierOne/osdep/LinuxEthernetTap.cpp
Lines 210 to 215 in e440416
I have noticed that in debian Wheezy (tested using qemu with debian-live-7.8.0-amd64-standard.iso), this code will fail setting tun/tap device MAC, and subsequently unable to join zerotier network properly.
To my understanding (tried using iproute2 tools in debian wheezy) code-flow should be:
ip tuntap add dev tapx mode tap
) -> L205-L209ip link set dev tapx address 1:2:3:4:5:6
) -> L224-L229ip link set dev tapx mtu 1234
) -> L231-L236ip link set tapx up
) -> L210-L215Current improper code flow is
1
->4
->2
->3
, so to rectify L210-L215 shall be relocated to line L237, after setting MTU.IMHO changing MAC address shall not be done while device in up state.
I did tried modify code to correct its flow (tried in qemu wheezy: git clone, edit code, install gcc-4.9, make all), and the result is ok, vm can join zerotier network.
The text was updated successfully, but these errors were encountered: