Skip to content
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

Make jool client backward compatible (with old Jool kernel modules) #347

Closed
boleifu opened this issue Dec 9, 2020 · 3 comments
Closed
Milestone

Comments

@boleifu
Copy link

boleifu commented Dec 9, 2020

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.

Error: The kernel module returned error 22: Version mismatch. The userspace client's version is 4.1.4.0,\nbut the kernel module is 4.1.2.0.\nPlease update the kernel module.\n
@ydahhrk
Copy link
Member

ydahhrk commented Dec 9, 2020

Ok.
But since Jool 4.2 is almost complete, I'd like to make this a 4.2 feature.
Also, I don't want to mix 4.1 and 4.2, so backwards compatibility will only extend back up to 4.2.0.

@ydahhrk ydahhrk added this to the 4.2.1 milestone Dec 9, 2020
ydahhrk added a commit that referenced this issue Jan 23, 2023
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.
@ydahhrk ydahhrk modified the milestones: 4.2.1, 4.1.9 Jan 25, 2023
@ydahhrk
Copy link
Member

ydahhrk commented Jan 26, 2023

(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.

@ydahhrk ydahhrk modified the milestones: 4.1.9, 4.1.10 Jan 26, 2023
@ydahhrk
Copy link
Member

ydahhrk commented Jan 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants