Well, if i look at the first post of this thread, it sure looks like the trouble i had. So no worry’s, If the FTU<>WAN stays online for more then lets say 4 hours, this will work. I do wonder though if all this has some sort of consequences for speed, or anything else?
You mean deploying force_link? The only caveat is that media sensing is lost on the WAN port, least when it concerns netifd | ubus, probably not to the kernel though.
So, if this setting is the solution to the issue, what exactly is the problem then? ( me nOOb 
)
Difficult to debug. Out of curiosity - is your node impacted (without force_link) as well only when the ISP rolls over the IP every 24 hours, like the other two users reported, or as well when booting the node?
the IP there is fixed, so it has or had nothing to do on that part over here.The connection simply was made, and then some random time later ( within 2 min or 2 hours ) the connection was lost, and the MOX tried again without succes. I had to reboot or the FTU, or both. Just rebooting the MOX did sometimes solve it, but not always?
if this is what you mean?
I ask my ISP regarding force separation and confirm that they disconnect regarding the IP address the connection.
It’s state of the art acc. the answer from the ISP.
Yes, thank you for the info. It is a different case though and even more weird with those sporadic disconnects.
Do you set the static IP in the router settings somewhere or is the ISP assigning it, if latter through which method, DHCP or IPCP or a mix (IPv4|6)?
Is is this a dual-stack connectivity (IPv4|6)?
Is the FTU providing Gf-TAE or is there a converter in between the FTU and the MOX?
About fixed ip, i do not know. With PPPoE i just fill in some bogus usrname and pass, and then i get IP? nothing is set in the MOX on that part. The IP is fixed on or from the ISP part.
Yes, it is IPV4 and 6, where IP 6 is set on automatic, ‘’ Protocol: Virtual dynamic interface (DHCPv6 client)"’.
About the FTU, i do not know? It is a rather straightforward box with Fiber in, and 1 LAN ( 1 gb ) out?
Then there’s something wrong about this. pppd does exit when link is down, however other pppd processes are killed before they can make a connection. Maybe too short time given to pppd by netifd?
Normally in the past I get the disconnection between 17 - 19.00 o’ clock German time.
The same like yesterday is today: I didn’t get the disconnection. Maybe I have it but I don’t observe it.
For me works fine in the moment and I can’t observe any disadvantages.
In addition I don’t understood the explanation from before what will be the disadvantages with the option force_link.
Sure this is related to my missing knowledge.
Maybe the issue is much more deeper and I didn’t catch the problem.
What I said before: The force separation from the ISP is state of the art and normally the router will connect automatically the connection by self.
I will come back if I’ve news or when it’s stable.
1 Like
seems that this helped for two days in a row.
well this might be a bit unfortunate if something happens with WAN port…
There might be two issues at play,
- one a bug in the ppp code pppd: Handle SIGINT and SIGTERM during interrupted syscalls by pali · Pull Request #148 · ppp-project/ppp · GitHub
- the other one that is that netifd is likely not monitoring the process’s signal pipe (SIGTERM) but rather the existence of its /proc//exec*, as observed in another issue Network configuration reloaded to broken wifi state when wpad is installed (#152) · Issues · Turris / Turris OS / Turris Build · GitLab
Good in a way that it helps, looking at the code commit that implements the setting git.openwrt.org Git - project/netifd.git/commitdiff I am not sure why it helps.
well, my TOX is running for 2 years with this [force link X]. it works.
I guess the disadvantage could be that if you pull out the WAN cable and put it back, the router won’t try to reconnect, because it thinks the link is always connected?
Today I’ ve reorganize the location of the router in my office and in these situation I add a new internal SSD.
Actually I don’t have any issues with the connection.
I’m sure now the router will running for few days w/o any interrupts from my side and than it will confirm is the option force_link the solution.
Before I will test the thing with pull out the connector and I will observe what’s happens with the internet connection that will stop or not.
One thing what I`ve observed:
The IPv4 and IPv6 connectivity after the force separation is disturbed.
Only IPv4 is available and after the force separation is IPv6 missing.
The whole day is booth available.
I don`t know when is IPv6 come back and available.
Is there any idea what can be the reason?
Ive done one test: I activate the option "Obtain IPv6 address" => automatically (before was set on manual). Now its a little bit different.
I will test from day to the next one.
Comment: One hour later I’ ve the same result before and only IPv4 is available.
What can be the effects if only IPv4 is available?
I’ ve no idea.
Check if package ds-lite is installed, if so remove it and reboot.
OK.
I’m not so familiar with the package system what is using for Turris Omniar.
I’m coming from Debian.
It’s similar?
How I can search for the package and how is the correct command to delete it?
OpenWrt’s package manager (guide) [OpenWrt Wiki] Opkg package manager
TOS’s package manager Turris Documentation