Move this patch into 5.0.0 milestone please.
Which patch? You mean that undocumented hack? Did you test it?
- If it helps you, feel free to write it there.
- If it doesn’t write it there as well.
Has not been tested by all users of previous TOS versions?
Why you move my posts?
Vodafone CZ VDSL with Comtrend VR-3031eu modem in bridge mode: I’m completely unable to connect to my ISP without the mentioned workaround. I tried /etc/init.d/network restart, but even that did not help without the sleep.
Yes, this line is part of TOS for long time and reason, why I can’t update many router in production environment to latest TOS 4 or TOS 5.
This should be added to that issue, which was linked.
This patches “/lib/netifd/proto/ppp.sh” and forces it to all PPP users? What if I don’t need it at all, have to remove it every time PPP gets re-installed?
1 Like
Yes, it is forced to all users and it is the same as in Turris OS 3.x. It shouldn’t harm any issues. It will delay the first connecting (and retrying of ppp connection) to the Internet for about 10 seconds. It is not great as it should be, but it narrows down the issue, which I would say many people have. If you would like, feel free to improve as it was said in a pull request. 
We know and we admit that it is a hack, which works and there is still investigation of this bug ongoing. I think we both agree that having a working Internet is very important and it is something that should be fixed ASAP as it was present in Turris OS 4.x!
1 Like
I had the dream. TOS 5.0.0 HBS with updated kernel, working DSL and mwan and functional Managed devices. And this dream could come to truth.
But it does
It does not cause the delay just for PPPoE upstream connectivity by PPP operations in general.
Looking at the Gitlab issue it seems that very little effort has been made at debugging (4 months since the issue been opened?), which there are various options by the components involved, e.g.
- netifd increase the log level (from default 2) with the
-loption - ppp use
option pppd_options 'debug kdebug 7'
How so, I can hardly debug the connectivity issue of the issue reporter?
Your opinion and I am not going to argue with you. If you think that there was a little effort at debugging it, you are wrong. The important thing is that it helps other users. Feel free to remove it from the file or improve it, e.g. uci option can be good as it was suggested there. I understand you are not affected and it works for you, but imagine other people as well.
And why it has not been implemented as such instead?
Are you willing to read that Gitlab issue or not? It is described there.
Hey @anon82920800, I am going to implement an UCI config option for the sleep length, (which was mentioned here as well).
My colleagues want just to speed up this fix of this issue as it bothers many of our users. This simple sleep 10 variant is straight-forward solution (and the same was used in TOS 3.x).
Please be patient.
2 Likes
Appreciated. Just gotten concerned that the OpenWrt trend to reduce code maintenance to lowest common denominator swaps into TOS as well. More so since in the particular case I trust that the issue is not really pppd but some sort of timing issue of netifd with xDSL connectivity (through external modem) in combination with PPPoE (being a common combo).
Great idea. I was afraid to say it.
HBK users can start with testing.
Installed version 2.4.7.git-2019-05-25-4.0 of package ppp
Installed version 2.4.7.git-2019-05-25-4.0 of package ppp-mod-pppoeProbably yes. I am really curious why this issue happen on Turris HW/Turris OS only. There were some ideas it’s due to faster HW and multicore CPU, which is not so common for an OpenWrt router (and DSL connection 
) I think.
Maybe you find something with netifd debug options. Since there are no such reports for fibre + PPPoE I would not reckon this being related to the hardware performance, my personal wager is more on some untimely communication between the external modem and netifd, some late feedback from the modem on the uplink state, owned to either the copper line and potential interferences (as opposed to fibre) or the xDSL modem(s) self or the even the xDSL technology (synch with the ATM).