[wireguard] fixing #323

[jonahweissman]

I've made some progress on #323, and I'm putting it here to make it easier for other people to track.

Fortunately, it seems like there is a way to avoid building all of systemd just to get the resolvectl binary. There's a patch in the wireguard-tools repo for "dns-hatchet", a workaround for systems that don't have resolvconf. Based on Jason's explanation on the WireGuard mailing list, I think using it on reMarkable would be appropriate, but I'm open to other opinions.

Currently, I can set up a connection with wg-quick for a config that contains a DNS= key, but I get an error mount: /dev/shm: mount point is busy when I do the same thing using systemd. If anyone who knows more about systemd could take a look, I would really appreciate it.

As for the wildcard IP handling, I think the two /1 routes with tungate is still the way to go. I'm planning on spending some time over the next week figuring out it used to be implemented so that I can adapt it for IPv6.

[Eeems]

@jonahweissman have you had a chance to look into this further?

[jonahweissman]

@Eeems yes! Very sorry about the delay, I got busy and then forgot to come back to this when I had time. I decided to just display a message indicating that wildcard IP addresses are not supported, suggesting a workaround to the user.

It seems like the build is failing because the script is trying to set the modification time on the broken symlink that comes in the wg-tools repo (as in https://github.com/toltec-dev/toltec/issues/291). If we make it ignore FileNotFoundError, it seems to build okay.

I'm also just noticing that none of the files in this package are stored in the /opt partition. I'm assuming I set that up wrong and I should probably change that, right?

Finally, it looks like (at least on my remarkable 2) that the kernel version is now 5.4.70. Should I add the latest commit from the zero-sugar branch as a third version of the kernel to build against or should that replace one or both of the other versions? I haven't been paying much attention to remarkable updates, so I don't what's still being supported.

[Eeems]

@Eeems yes! Very sorry about the delay, I got busy and then forgot to come back to this when I had time. I decided to just display a message indicating that wildcard IP addresses are not supported, suggesting a workaround to the user.

No worries, just thought I should ping the PR just in case you had forgotten :P

It seems like the build is failing because the script is trying to set the modification time on the broken symlink that comes in the wg-tools repo (as in #291). If we make it ignore FileNotFoundError, it seems to build okay.

@matteodelabre looks like #291 is resolved, but this is still failing to build?

I'm also just noticing that none of the files in this package are stored in the /opt partition. I'm assuming I set that up wrong and I should probably change that, right?

Yes we should prefer storing in /opt or /home to survive upgrades and to avoid filling up the root partition. That said, I believe kernel modules need to be on the root partition. Not sure if symlinks would work.

Finally, it looks like (at least on my remarkable 2) that the kernel version is now 5.4.70. Should I add the latest commit from the zero-sugar branch as a third version of the kernel to build against or should that replace one or both of the other versions? I haven't been paying much attention to remarkable updates, so I don't what's still being supported.

I'm not sure, others will likely have to chime in. I believe zero-colors will eventually replace the kernel builds on both rM1/2 with a single kernel. Not sure when that will be happening though.

[jonahweissman]

Yes we should prefer storing in /opt or /home to survive upgrades and to avoid filling up the root partition. That said, I believe kernel modules need to be on the root partition. Not sure if symlinks would work.

Sounds good! At the very least, I'm sure we could have the config folder /etc/wireguard in /opt.

I'm not sure, others will likely have to chime in. I believe zero-colors will eventually replace the kernel builds on both rM1/2 with a single kernel. Not sure when that will be happening though.

Okay, I can just keep all three until we can figure out what the long term plan is. Unfortunately, I'm having some trouble getting the kernel module to build for zero-colors (and for the most recent commit of zero-sugar). They made a lot of changes, and I don't really understand the kernel build process very well. I'm getting this error:

In file included from allowedips.c:6:
 allowedips.h:9:10: fatal error: linux/mutex.h: No such file or directory
 9 | #include <linux/mutex.h>

however the file include/linux/mutex.h seems to still be present. I can probably get it to build if I spend enough time, but I'd be really curious if anyone has looked into the changes they made to the kernel or has any other insights that might be useful.

[Etn40ff]

~~I can probably help with kernel compilation, which options do you require?~~

I built a 5.4.70 kernel with all the required symbols and the out of tree kenel module for wireguard. I have no experience with wireguard itself nor a testing setup I could try them on but I can provide them to you and/or guide you through the compilation.

[Eeems]

@jonahweissman Do you still want to keep this open? We have dropped wg and wg-quick from the wireguard package, as entware provides packages for both now. As for the kernel module part of this, we will be dropping it from 3.x support, and only maintaining it for 2.x support (#759).

[jonahweissman]

I'm fine with closing this PR, since I'm unlikely to pick it back up. Thanks for the update on the status of the package. I'm still a user and a fan of Toltec even though I haven't had time to contribute in a while.