DSM 7.0 support?

[bitedxh]

Hello bb-qq, the new dsm7.0 rc has been released. Is there any planned maintenance driver?

[patrick-87]

Hard to say. In September 2020 it was said by bb-qq here "Quote: Thank you for the report. I will update my drivers after toolchains for DSM7 will be released."

14 days ago, however, came the following words here: "Quote: Sorry, currently I do not have any plans to support DSM7. And I know installation via the Package Center is no longer supported in DSM 7 due to policy change of Synology. I will investigate this issue when I move to DSM7"

So at the moment it looks rather bad, but DSM 7 is not final yet. I think it will take a while. Some things have probably changed significantly in the system.

[eemanuelsson]

Synology seem to be locking down the system in many areas in DSM7 compared to DSM6.
Just taking a quick look at the release notes for "DSM 7.0-41882 (release candidate)" over at Synology the line below stick out as problematic for wired network adapters.

"USB devices (Wi-Fi dongle, Bluetooth dongle, 3G/4G dongle, USB DAC/speaker, and DTV dongle) are no longer supported. If your Synology NAS is currently connected via a wireless dongle, it will be disconnected after the update."

It may of course be possible to work around problems with some command line trickery, but at this time I think it is a pretty safe bet that USB network adapters will not be working in DSM7 at launch.

[ihvar]

It is easy to understand Synology - they want to promote their newer models with its own brand hardware.
But! NAS is not CPU or GPU card to buy it every 1-2 years and most user won't like the idea that they will have to buy new devices instead of upgrading with fewer investments. And Synology even doesn't have any USB dongles with 2x price to upgrade older models. I bought my 418play last year and now I'm not planning to buy another Synology NAS

[kylehoo]

I am also waiting for it!

[wolfyportal]

quick update
DSM 7.0 Official Toolchain is release
there are no issue to build driver (kernel module)
just like on DSM 6
but there has a permission problem on DSM 7
so you can build spk to install but may not work
here the thread you can follow...

just prove it work...

[sshimko]

Confirmed. No SPK to share but I built and insmod'd the kernel modules. iperf3 (native) results for a DS920+ and a DS218+ connected to each other via a pair of QNA-UC5G1T w/ MTU 9000:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  4.07 GBytes  3.50 Gbits/sec   59             sender
[  5]   0.00-10.03  sec  4.07 GBytes  3.49 Gbits/sec                  receiver

As a rule don't load random .ko files from random people on the Internet or random people you meet at a bar but...
AQC111 DSM 7.0-41890.zip

[Benniphx]

@sshimko thanks works like a charm on my 1019+ (around 400 MB/s with 9000 MTU on DSM 7)

[ihvar]

Guys, how to make AQC111 to autoload?

cp /volume1/homes/xxx/mii.ko /lib/modules/
cp /volume1/homes/xxx/usbnet.ko /lib/modules/
cp /volume1/homes/xxx/aqc111.ko /lib/modules/

insmod /lib/modules/mii.ko
insmod /lib/modules/usbnet.ko
insmod /lib/modules/aqc111.ko

ifconfig eth2 up

[sshimko]

There are a few short steps involved to get them to autoload on boot.

They removed depmod, which was really a multi-call binary like busybox, so create a symlink to /bin/kmod. You'll need that to update the mod dep files:

ln -s /bin/kmod /usr/sbin/depmod

After a closer look I don't think you need the usbnet.ko from here, one is already shipped by Synology and works. The mii mod wasn't present so while usbnet was there it couldn't load successfully. Drop the files in /lib/modules/:

cp mii.ko aqc111.ko /lib/modules/

Update the module deps:

/usr/sbin/depmod -a

Add the files to a list loaded at boot, might not be necessary with the module deps re-generated but I had already done this before I hit the depmod issue:

echo -e 'mii\nusbnet\naqc111\n' > /lib/modules-load.d/99-aqc111.conf

That is a rough pass at what I did to make them load on boot. There was trial and error involved but I think those were the key pieces to make it work.

[ihvar]

I tried to use you guide - device is loaded but I have to start eth2 every time I boot my NAS

I use Synology Scheduler to do

ifconfig eth2 up

But it always starts with static IP and cannot obtain it from DHCP. If I change interface options to DHSP in Network manager, they stay until next restart. And after restart eth2 is down until I up it with Scheduler or command line....
Strange thing that MTU 9000 stays on (maybe Network Manager saves them to another config file?)

How can I autoup this interface (eth2) with DHCP options on?

[bb-qq]

Thanks for all the information you provide. I have created and uploaded drivers for DSM 7.0 based on that information.
But it is still loaded from the Package Manager and it needs additional steps with the root shell.

[sshimko]

Not knowing the DHCP stack in Synology I would just create a systemd service unit, bring up the NIC in the ExecStartPre and manually configure the address in ExecStart, and enable the unit, then sort out DHCP later. You could do it in rc.local but they already muck around there and in a systemd world you might as well do it via a proper unit.

There are downsides to that like it possibly getting clobbered on updates, but I'm not sure what they would do with a custom unit in /etc/systemd.

[bb-qq]

I think the method modifying /lib/modules/ is more preferable because the loading process will be started earlier in the boot stages. So if you find a good way to persist the settings over the update of DSM, I would like to refer to it.

[sshimko]

For the modules /lib/modules that makes complete sense, but bringing up the interface early enough that you can manipulate it via the DSM UI might require something else.

Looking in /etc/systemd some community packages include unit files. Assuming an unmodified systemd and the content of the units they are likely run as root. They are dropped in /usr/local/lib/systemd/system and are WantedBy=syno-low-priority-packages.target. Dropping a unit there that brings up the NIC(s) based on the NIC(s) that contain "driver: acq111" in the output of ethtool -i should work. You might be able to make it pretty flexible and handle all USB NICs by default. For people using unsupported PCIe NICs that might be more difficult.

syno-low-priority-packages.target might be too late to make it appear in the UI, but there are a bunch of targets one will probably work :)

sh-4.4# ethtool -i eth1|grep -E '(driver:|bus-info: usb)'
driver: aqc111
bus-info: usb-0000:00:15.0-3

[sshimko]

OK stepping back for a sec to rethink this...

1. Something somewhere creates the ifcfg file and simply sets BRIDGE=ovs_. I don't think this is a contributing issue though because rc.networfk should fix that if the NIC is up.

2. /etc/rc.network is still called via the rc-network.service unit. It looks like it should create ifcfg entries for any NIC in the "up" state that isn't already tracked by Synology by the time it runs. It specifically mentions external NICs in a comment. It looks in /proc/sys/net for NICs that are up, looks for that NIC's entry in a Syno conf file, and if it doesn't exist creates the NIC and vswitch ifcfg files for you setting it to DHCP.

Since it looks like rc.network will fix the ifcfg files for us, we just need to make sure the kmods are loaded (the /lib/modules and depmod stuff above), bring up the interface, and then we get DHCP by default thanks to rc.network and then we go from there.

We need a service unit to bring up the interface and some combination of dep declarations in the unit like Before=rc-network.service and Requires=rc-network.service (I always have to screw with deps to get them right).

Summary: kmods loaded, NIC up, then rc.network gets us to DHCP with ifcfg files for the NIC. Maybe... ;)

[ihvar]

Althougth AQC111 is working, when I'm using

/usr/sbin/depmod -a

i'm getting

depmod: WARNING: could not open /lib/modules//modules.order: No such file or directory
depmod: WARNING: could not open /lib/modules//modules.builtin: No such file or directory

[sshimko]

Those files would come from the kernel build itself. We could probably reconstruct modules.builtin with some work but not modules.order without the kernel tree including config and proprietary module errata.

A quick look indicates there aren't going to be alias conflicts with these three introduced (the modules.order warning), e.g. via duplicate symbols from different modules, and we already know they're not builtin so modprobe won't fail trying to load them due to that issue (the modules.builtin warning).

Also, they are just warnings. Nothing ever goes wrong when you ignore those.

[ihvar]

made
ifcfg-eth2 files in

etc/sysconfig/network-scripts/
etc/sysconfig/networking/
etc.defaults/sysconfig/network-scripts/
etc.defaults/sysconfig/network-scripts/

DEVICE=eth2
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
NAME=eth2
NM_CONTROLLED=no

But no results. Still some script loads defaults

BOOTPROTO=static

to ifcfg-eth2

[sshimko]

Looks like they remove extra ifcfg files based on the number of expected NICs for the device.

/var/log/synobootup.log:Jul 10 20:28:13 NAS synochecknetworkcfg[5581]: synochecknetworkcfg.c:59 unlink [/etc/sysconfig/network-scripts/ifcfg-eth2], max LAN id is [1]

This seemed to do the trick. Bring up your NIC once, configure it like you want in the UI. Then increment this conf value based on the number of extra NICs you're trying to add, e.g. if you have two built-in and you're adding one more NIC you set the value to 3. You can probably just bump it way high but I didn't try that.

synosetkeyvalue /etc.defaults/synoinfo.conf maxlanport 3
synosetkeyvalue /etc/synoinfo.conf maxlanport 3

An update will probably revert this.

[ihvar]

Thank you, Spencer! That's exactly what I needed. Now the settings stay stable during reboots!

[bb-qq]

I'm closing this issue since DSM 7.0 support is complete. If there are still problems, please create a new issue.

[ffries]

it seems that these settings do not apply for DS420J. I am getting the same problem on reboot.