search

runfalk / synology-wireguard

WireGuard support for some Synology NAS drives
MIT License
956 stars 134 forks source link

Update to work with DSM 7.1 #154

Open darkphoenix opened 2 years ago

darkphoenix commented 2 years ago

So after a rather nasty surprise when keeping this module installed during the update to 7.1 caused the DiskStation to lock up about a minute after boot (existing SSH survived, new ones time out), I'm now trying to build a new module for the new kernel version they're seemingly shipping with that update. The scripts in this repo don't quite work, but my first issue was solving by changing the pkgscripts-ng branch from DSM7.0 to DSM7.1 (I did it manually, the proper way would probably be another branch in build.sh). I'll report back on any further issues and whether the result actually works.

darkphoenix commented 2 years ago

So update, that worked just fine. For some reason (error about "fallthrough" being undeclared) I can't be bothered to figure out it won't compile the latest version, but it will do 20210606; iirc this as already the case on 7.0.

fabiov64 commented 2 years ago

For which platform are you compiling ? For armada38x it compiles the last version without any issue.

f0rtung commented 2 years ago

I have tried to build for geminilake.

teffalump commented 2 years ago

The build script needs to be updated for DSM7+. Notably, to handle 7.1, currently https://github.com/runfalk/synology-wireguard/blob/19cd73c50babedb47387c6c53f94054b93d8321f/build.sh#L34-L42

should change to

clone_args="-b DSM7.0" ==> clone_args="-b DSM$DSM_VER"

I think another issue mentions this.

And add the /dev mount to the build https://github.com/runfalk/synology-wireguard/issues/88#issuecomment-1026355820

I think there are PRs for these changes. At least, these are the issues I ran into compiling for 7.1. I tested it on a DS218+.

589290 commented 2 years ago

So after a rather nasty surprise when keeping this module installed during the update to 7.1 caused the DiskStation to lock up about a minute after boot (existing SSH survived, new ones time out), I'm now trying to build a new module for the new kernel version they're seemingly shipping with that update. The scripts in this repo don't quite work, but my first issue was solving by changing the pkgscripts-ng branch from DSM7.0 to DSM7.1 (I did it manually, the proper way would probably be another branch in build.sh). I'll report back on any further issues and whether the result actually works.

@darkphoenix So, the wg kernel module must be unloaded before any/all DSM system upgrades?

darkphoenix commented 2 years ago

@darkphoenix So, the wg kernel module must be unloaded before any/all DSM system upgrades?

Patch level updates are usually fine in my experience, but point releases do appear to contain kernel updates sometimes. At the very least disable automatically loading it at boot before the update, so if something goes wrong worst case you can just reset the thing - save you the trouble I had getting back in.

589290 commented 2 years ago

@darkphoenix I've been poking around for how to disable autoloading at boot. However, documentation on Synology kernel modules is not easy to find. So, to be safe, I just uninstall the .spk package and re-install after boot. However, this doesn't protect against unintended system restarts. What is the preferred method to disabled the kernel module from loading at boot... and how would I manually load it on my own without uninstalling/reinstalling/starting the .spk package?

589290 commented 2 years ago

@darkphoenix or @all any help here would be greatly appreciated.

darkphoenix commented 2 years ago

@darkphoenix or @all any help here would be greatly appreciated.

I've no clue, and really this seems only tangentially related to this issue. I'm not entirely sure how the autoload works, but I have some vague recollection of this package including a script to do it, so maybe they should add some option to disable it or maybe even detect if the kernel has changed? Though I seem to recall the version didn't actually change after the update, it just appears to have different options or custom patches.

At any rate, most of this is speculation on my part, I'm just a user happy this exists because before I had to build the module myself and that was considerably more of a pain. I opened an issue to fix upstream what I'd already fixed for myself, and I really don't have the time to figure out the details myself and help you on this.

589290 commented 2 years ago

@darkphoenix appreciate your thoughts and insight that what I'm currently looking for, might not in fact be here. I'll dive deeper into the package on my own to see if I can discover how autostart works.

runfalk commented 2 years ago

The line that auto loads the kernel module is here https://github.com/runfalk/synology-wireguard/blob/master/scripts/start-stop-status#L26.

I don't really use my NAS anymore (hence why the project is essentially unmaintained).