Setting lost after reboot

[JohnsonWang1222]

I found a solution to solve the problem.

In control panel -> schedule task, add a task:

user account: root
event: boot

and put your synonet related command in the task setting page -> user defined script

Done. After NAS reboot, the ASUSTOR 2.5G USB network adapter is automatically working.

[bb-qq]

Thank you for sharing the solution. I will try this.

I will keep on investigating a straight solution that behaves like built-in interfaces.

[johannol]

I supose theses user scheduled task, defined by build-in interfaces, persist the config somewhere on disk. If the package install script can do the same, to auto define the "user scheduled task" at the install stage, it's possible to fix the issue.

[bb-qq]

Thanks to @iwanovich, the driver supported setting persistence. Please download the latest version and let me know whether it works.

[ChloeMarieTaylor76]

@bb-qq Can confirm with the latest driver and on the 1815+ there is no persistence between restarts

[ChloeMarieTaylor76]

Had a further look into it. The config file at /etc/sysconfig/network-scripts/ is wiped empty after a restart even if I save a config to it. Looking at the code in start-stop-status at lines 25 (and perhaps 12) you conditionals are not correct if my memories of bash are correct? Shouldn't they be '=='. This is right before this would save the config location. Apologies if I am wrong, bash is not even my third language and it quite an oddity :)

[iwanovich]

You might be right, I'll take a look tomorrow. Tnx for noticing.Op 31 mrt. 2020 23:46 schreef ChloeMarieTaylor76 <notifications@github.com>: Had a further look into it. The config file at /etc/sysconfig/network-scripts/ is wiped empty after a restart even if I save a config to it. Looking at the code in start-stop-status at lines 25 (and perhaps 12) you conditionals are not correct if my memories of bash are correct? Shouldn't they be '=='. This is right before this would save the config location. Apologies if I am wrong, bash is not even my third language and it quite an oddity :) —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. Op 31 mrt. 2020 23:46 schreef ChloeMarieTaylor76 <notifications@github.com>: Had a further look into it. The config file at /etc/sysconfig/network-scripts/ is wiped empty after a restart even if I save a config to it. Looking at the code in start-stop-status at lines 25 (and perhaps 12) you conditionals are not correct if my memories of bash are correct? Shouldn't they be '=='. This is right before this would save the config location. Apologies if I am wrong, bash is not even my third language and it quite an oddity :) —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. Op 31 mrt. 2020 23:46 schreef ChloeMarieTaylor76 <notifications@github.com>: Had a further look into it. The config file at /etc/sysconfig/network-scripts/ is wiped empty after a restart even if I save a config to it. Looking at the code in start-stop-status at lines 25 (and perhaps 12) you conditionals are not correct if my memories of bash are correct? Shouldn't they be '=='. This is right before this would save the config location. Apologies if I am wrong, bash is not even my third language and it quite an oddity :) —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[davidgirard]

Hello there - First of all, nice job, the driver works really well with my DS620slim and my CableCreation USB 3.0 to 2.5 Gigabit LAN Ethernet Cable Adapter. I just wanted to let you know that just like others, the NIC disappears after reboot and a re-installation of the package fixes the issue (using the latest version).

Cheers,
David

[bb-qq]

Persistence seems to work correctly in my environment(DS918+). What DSM version are you using?

[ChloeMarieTaylor76]

Hi, was a ds1815+, DSM 6.2.2-24922 update 6. I have given up with the usb adapter, too much buffering problems of 4k streams, not sure the cpu could cope consistently enough with the usb overhead. :( bought a 1819+ with an official 10gb card

…

On Tue, 7 Apr 2020, 10:17 bb-qq, ***@***.***> wrote: Persistence seems to work correctly in my environment(DS918+). What DSM version are you using? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKB74HED77HXYS2DD3GECF3RLLVTDANCNFSM4IYSGYLQ> .

[iwanovich]

Hi, was a ds1815+, DSM 6.2.2-24922 update 6. I have given up with the usb adapter, too much buffering problems of 4k streams, not sure the cpu could cope consistently enough with the usb overhead. :( bought a 1819+ with an official 10gb card
…
On Tue, 7 Apr 2020, 10:17 bb-qq, @.***> wrote: Persistence seems to work correctly in my environment(DS918+). What DSM version are you using? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKB74HED77HXYS2DD3GECF3RLLVTDANCNFSM4IYSGYLQ .

Dear Chloe, I took a look but am unable to reproduce the problem. The patch that was created by me was for the AQC111 driver and I don't have the hardware to reproduce your scenario. I understand you resolved your problem by changing hardware.

[davidgirard]

Hi,

I use DSM 6.2.2-24922 Update 4, which seems to be the latest version for the DS620slim.

After a reboot, I need to stop the driver package, then run it again, to get the NIC to re-appear.

Not the end of the world as I hardly ever reboot my NAS, but just letting you know there is an issue with the slim.

Cheers,
David

[bb-qq]

Hi @ChloeMarieTaylor76 , could you confirm whether reproduce the issue with the new 1819+?
(Just FYI: enabling jumbo-frame may help performance)

[bb-qq]

After a reboot, I need to stop the driver package, then run it again, to get the NIC to re-appear

Hi @davidgirard, does setting persistence to work correctly after stop/run operation?
It may be a timing issue between device detection and running the script. If you attach the output of dmesg, I will look into it.

[davidgirard]

Hi @bb-qq,

Thanks for offering to look into it!

Loading sequence during boot:
[ 47.360270] r8152: module verification failed: signature and/or required key missing - tainting kernel
[ 47.402919] usbcore: registered new interface driver r8152
[ 47.534198] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[ 47.665067] r8152 2-1:1.0 eth2: v2.12.0 (2019/04/29)
[ 47.671029] r8152 2-1:1.0 eth2: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.

Then nothing (the next set of dmesg is unrelated).

If I stop then start it again, note the different sequence:
[ 178.447495] usbcore: deregistering interface driver r8152
[ 203.346986] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[ 203.458804] r8152 2-1:1.0 eth2: v2.12.0 (2019/04/29)
[ 203.464369] r8152 2-1:1.0 eth2: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.
[ 203.481906] usbcore: registered new interface driver r8152
[ 203.531498] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 207.618509] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 207.625673] r8152 2-1:1.0 eth2: carrier on

Cheers,
David

[bb-qq]

Could you please try to add a sleep command to the driver's script directly by editing /var/packages/r8152/scripts/start-stop-status like this:

		/sbin/insmod $SYNOPKG_PKGDEST/r8152/r8152.ko
		sleep 5
		set_interfaces up

[davidgirard]

@bb-qq That did the trick!

[ 44.939292] r8152: module verification failed: signature and/or required key missing - tainting kernel
[ 44.968659] usbcore: registered new interface driver r8152
[ 45.099294] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[ 45.218141] r8152 2-1:1.0 eth2: v2.12.0 (2019/04/29)
[ 45.223837] r8152 2-1:1.0 eth2: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.
[ 50.042944] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 50.215815] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 50.222966] r8152 2-1:1.0 eth2: carrier on

Easy fix for your next release.

Thank you,
David

[bb-qq]

Thank you for the report. This fix was applied to this version: https://github.com/bb-qq/r8152/releases/tag/2.12.0-3

[davidgirard]

Just installed 2.12.0-3, all good.

Thanks!

[bb-qq]

Closing. Please feel free to re-open the issue if you still encounter this problem.

[nuil]

I'm having the same issue on my DS216j. Driver Version is 2.14.0-2. The device is detected, but the link is not automatically started. I need to manually start the link on eth1. After that, i always need to set the mode to dhcp.

Any ideas how to solve it?

[bb-qq]

I'm having the same issue on my DS216j. Driver Version is 2.14.0-2. The device is detected, but the link is not automatically started. I need to manually start the link on eth1. After that, i always need to set the mode to dhcp.

Any ideas how to solve it?

Could you try to increase the delay in the above comment? If it does not help, please create another issue with logs.