[DTAG] No Internet on reconnect after configuration change

Hey there,

I recently bought a Turris Omnia (2019 EU Edition) with a DrayTek Vigor165 Super Vectoring modem.

Every time I change something network related in foris I lose internet connection. I am unsure if this is a problem with PPPoE or some setting in my modem. My workaround is, to reboot after the Omnia restarted all the network interfaces.

Is there a way to debug this? The Interfaces page in LuCI just tells me “Unknown error: USER_REQUEST” for the WAN interface.

I suspect this could be some kind of rate-limit from DTAG.

I hope someone has a fix or at least a way to debug this issue.

Thanks in advance :smiley:

Is that with TOS3.x or TOS4.x?

There should be more verbose info than just what is printed on the LuCI network tab

in the system log.

The cited error code is being generated by the PPP module [1] and merely indicates/hints at an issue with PPPoE. However, PPP(oE) can only work with the physical link being in an active state.

Experiencing somewhat similar on a VDSL2 subscriber line with PPPoE on TOS 4.x | 5.x | 6.x [2], albeit with a different modem.

In my humble opinion there is some sort of a link-up signal mismatch (bug). However, the system log on your node may shed some light of what the culprit might be.

After having applied the changes via Foris you could check the physical link status for the WAN port, that is in TOS4.x, from the ssh cli with:

  • ip -d -s -h l sh eth2
  • devstatus eth2


  • ip -d -s -h l sh pppoe-wan
  • devstatus pppoe-wan

[1] [OpenWrt-Devel] [PATCH] ppp: Detailed last error support
[2] SFP module transmit fault (#14) · Issues · Turris / Turris OS / Turris Build · GitLab

TOS 4.0.1

Looks like I will need to do my testing in a few weeks when I am at home again.

Just had a look at the device (DrayTek) live demo [3] and it would appear that it is not just a modem but a fully fledged router with firewall, DHCP etc. which could lead to conflicts with the TO in its role as cascaded downstream router. The DrayTek should probably be configured best in a bridged mode for handling the modem part only and passing the traffic through to the TO.

[3] http://eu.draytek.com:10165/

It is configured in Full Bridge Mode. DHCP is off and it does not have any login information. So it can’t act on it’s own

I just found the time to debug this more.

Here is the relevant syslog:


Don’t know why kernel timestamps are different compared to syslog

It could be possible that some kind of handshake between the Omnia and the modem fails. Will send logs from modem, too when I get home.

According to the log the PPPoE authentication with the ISP succeeds and IPs/DNS are being furnished by the ISP.

The log capture seems been taken at the boot stage but not when


that is a known issue [3 | 4]

[3] Busybox logger - fix timezone (#100) · Issues · Turris / Turris OS / Turris OS packages · GitLab
[4] syslog-ng time is in UTC, not localtime (#471) · Issues · Turris / Turris OS / Turris OS packages · GitLab

This log is a few minutes after I approved an update from foris. The first part of the log was basically repeating itself for 8-10mins after the netifd hook of the updates was called.

Eventually it picks up a connection. This may be a result of the “automatic diagnosis” I initiated from the DTAG website. (It basically disconnects your DSL connection and basically forces the modem / router to reconnect)

It is not clear what that means - you changed something network related in Foris or you approved a software update in Foris? If the latter the node is likely to have rebooted (if it involved a kernel update) and which is different than changing something network related via Foris.

Perhaps you could expand what pertains to changing something network related in Foris?

  1. I approved an update in Foris
  2. A few minutes later the omnia lost connection to the internet
  3. ~10 minutes later the connection was established again

After examining the log I saw that the update triggered the “netifd” hook. That basically triggered a restart of all network interfaces.

Dec 16 19:14:34 yeeturris updater[25538]: src/lib/logging.c:204 (log_subproc_open): Running postinst of netifd

After this message all interfaces went down and were reenabled shortly after.

Similar things happen when you change something in Foris that would affect the network in any way. For example if you edit DHCP options or change OpenVPN settings. These kinds of things were the things I would call “network-related changes”. Basically everytime you get that small loading spinner on the webinterface telling you to wait for reconnect.

The router also didn’t reboot after the update (I have to do that manually). It has an uptime of 16 days (as of now), where as the update ran on 16th December.

Once I get home this weekend i will investigate this issue further, especially in regards to what the modem reports to me.

This is likely expected since netifd (network manager) got updated and subsquently restarted.

Likely that the Foris script is restarting netifd to apply/accomodate the changes. The syslog should then print related output/issues, that is prior undertaking any other steps such as

It is probably not the modem causing the issue but netifd reestablishing the physical link and/or recognising the physical link status on the WAN port.

I think I had the same or similar issue.
Enabling “Force link” in the “Advanced Settings” tab in the WAN interface solved the problem for me.
Without this option the WAN link is down after every network related change and didn’t come back or it take very long to come back.
Provider is Vodafone

Is your ISP subscriber line FTTH or VDSL?

Yes, VDSL2 Vectoring (250 MBit)

Since I switched to the Turris OS HBK branch, everything runs much better.