DSM Uses this interface as its default about r8152 HOT 9 CLOSED

Every time a package like Directory server is re/started the interface in /etc/resolve.conf gets replaced with the IP on this adapter. In the example below, the adapter replaces the correct interface and the NAS fails to make any DNS queries.

root@syno:/# cat /etc/resolv.conf
nameserver	169.254.119.186
domain	example.local

from r8152.

I found the source of the issue. It looks like some packages like Directory Server run the command below to choose an interface. The interface from the r8152 package is always listed first. So far I don't have any way around this. I can override the interface to use or override /etc/resolv.conf but it will get set back every time the NAS reboots or a package gets restarted.

How Synology sets the interface

synonet --set_dns $(synonet --show_ha | awk '/^IP/{ print $2 }' | head -1)

from r8152.

Hallo, i have here two 1019+ with 4 club3D ethernet adapters. No Problem here. But i start my Diskstations with the startup script:
/etc/rc.network restart
sleep 10
All adapters on the Diskstations disable dhcp and set ip manuel.
4 Ethernet Adapter (2 onboard, 2 usb Ethernet Adapter) set too 1Bond with 4Gbit.
Works here without any problems....
Bond works only with all Adapters disable dhcp.

Test your config without dhcp.

from r8152.

So after a lot of digging it looks like Synology does not pull interfaces in the system order and how they would be displayed in the ifconfig or ip addr outputs. DSM uses a lot of scripts that pull interface groups such as ethx, vpnx, tunx, ovsx and then order them from 1 to 9. The adapter that occupies position number 1 will be the adapter used by other services including the Surveillance System Application.

To make matters worse, the synonet command cannot be used to add more than 1 nameserver to the /etc/resolv.conf file. I tried to add multiple servers separated by a comma and the binary returns an error. It is possible to overwrite/edit the /etc/resolv.conf file to include more than one nameserver. This change does update the "Preferred DNS Server" field under Network > General but I am unsure if that has any effect on the Active Directory Package. Restarting the package will, of course, undo the change and revert it back to only one. I could create a script that runs on a schedule to overwrite /etc/resolv.conf but applications like Active Directory probably parse this file only on startup. I would have to modify the package scripts to change this behavior which would only persist till the next update.

In this particular case, I was running Virtual Machine Manager which requires the interfaced to be added to an ovs group using open vSwitch. Their network scripts sort the interfaces by ethx followed by ovsx. This caused eth5 to effectively be ordered before eth1-4.

I believe I have solved this issue by performing the following steps:

Preference Locations:
Package Center > Installed > Virtual Machine Manager
Control Panel > Network > Network Interface > Manage > Open vSwitch

Steps:

1. Package Manager: Remove the Virtual Machine Manager package
2. Open vSwitch: Disable by unchecking Enable (Bounces Network)
3. Wait for network to become available
4. Open vSwitch: Enable by checking Enable (Bounces Network)
5. Wait for network to become available
6. Package Manager: Reinstall Virtual Machine Manager package
7. Verify interface ordering is changed in synonet --show_ha output

The take away here is the new interface needs to be in the same group as all the other ethx interfaces. They need to be all eth or ovs but having the r8152 interface outside the ovs group will result in the r8152 interface being the primary DSM interface. Synology picks the first interface for DNS and does not allow choosing the adapter that's actually exposing the DNS service. This is an indication to me that Synology DSM is a consumer-minded OS and not reliable for a business environment. DSM's default configurations, inability to change defaults, lack of vLan Trunking, multiple DNS servers, and Interface Isolation are just indications that they are best designed for a single interface, single site consumer setup. The choice to just "pick the first interface" is such an oversight.

I think the documentation should be updated to include installation on a system running ovs and Virtual Machine Manager. Users should be aware that plugging in an adapter and not rebuilding ovs can result in the NAS breaking DNS, Directory Server, Mail Plus, and many other services. Users not utilizing ovs and Virtual Machine Manager should not see any interruptions.

from r8152.

Ok i have some bad news. I installed a DSM update and it removed the interface from open vSwitch. This is something end users can’t do without removing the virtual machine manager package. The original problem came back where eth gets listed before ovs and DNS broke. I guess it’s not going to be possible to run virtual machines on the same NAS with an adapter.

What a shame. Perhaps there’s a way to add the interface to ovs on startup without uninstalling and reinstalling virtual machine manager.

from r8152.

"synonet" seems to show interfaces in alphabetical order of its name. I guess your other interfaces are enabled Open vSwitch and its names are ovs_eth0/1. So priorities of those names are lower than eth2.

Under this assumption, I only come up with these solutions:

• Edit the script directly every time on updating the package.
• Configure a Job to execute command on every startup as follows:
  ifconfig eth2 down && synoservice –restart DirectoryServerForWindowsDomain && ifconfig eth2 up

The other way is enabling Open vSwitch on eth2, but I don't know how to that.

from r8152.

Any thoughts?

from r8152.

I think the cause of the issue is on the system side, and I don't think the issue can be resolved by the driver, so I'll close this issue if there is no particular opinion.

from r8152.

I added the OpenvSwitch support to the startup script of the driver. Hopefully, the changes will be a workaround for this problem.

I'm closing this issue because there has been no update for a long time. Please feel free to reopen the issue if you have any problems.

from r8152.