-
Notifications
You must be signed in to change notification settings - Fork 67
Make jool client backward compatible (with old Jool kernel modules) #347
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
Comments
Ok. |
New implementation: Major and Minor version numbers must match, but Revision and Development can be anything. Rationale: - Because it pretty much by definition involves new tables, Major changes involve tweaks that pretty much guarantee communication incompatibility. Therefore, binaries that do not share Major should refuse to talk to each other. - Minor is a gray area, and should probably be evaluated on a case-by-case basis. But that's outside the scope of this commit, and the default behavior should be conservative. - Revision only signals bugfixes that rarely tweak the Netlink code, so it's probably safe to ignore it. - Development doesn't matter because I'm the only one who uses it. Proposed fix for #347.
(Context: Jool 4.2.0's release has taken so long, in the end I decided to patch this bug already. Jool 4.1.9 should be backwards compatible with other 4.1.x's.) Uhhh... crap. I just noticed that the kernel module and userspace clients have separate version validation codes. When patching this, I tweaked the kernelspace validation, but not the userspace validation. So... the patch shouldn't work. However I test it though, it runs fine: $ jool --version # userspace version
4.1.8.0
$ sudo modprobe jool
$ dmesg | tail -1 # kernelspace version
NAT64 Jool v4.1.9.0 module inserted.
$ sudo jool instance add --iptables -6 64:ff9b::/96
$ echo $?
0 I'm going to have to postpone this bug's closure until 4.1.10, because it needs a review, and 4.1.9 is already released. |
Ok, review done. The kernel module copies the version number from the request to the response, so the client is actually looking at its own version, not the kernel module's. It's one benign bug and one actual bug, cancelling each other out. So, happily, the backwards compatibility is working as intended in the 4.1.9 release. I'm going to patch the userspace version validation code shortly, but it's not going to change anything in practice. |
Please support some levels of backward compatibility between Jool client and the kernel module. Otherwise, we have to reboot the machine or reload the module for every Jool upgrade, which may not be necessary. Thanks.
The text was updated successfully, but these errors were encountered: