Hi, I’m currently on Turris OS 3.11.8 and would like to switch to Turris OS 4.0.1. I own a Turris Omnia 2019 (last revision). The problem is that passing from version 3.11.8 to version 4.0.1 I can no longer make the PPPoE connection work to access the internet via ISP. I currently use an SFP connector provided by the operator inserted in Omnia’s SFP port and I have this network configuration: https://gist.github.com/lucenera/2f36fb5eb58c256e9c0f0cea13957b4a
On 3.11.8 everything works perfectly, but on Turris OS 4.0.1 creating an eth2.xxx interface with the operator tag, the connection does not go, from dmesg does not even appear authentication error or connection attempt. I don’t know if the problem derives from the current impossibility of Turris OS 4 to manage multiprocessor VLAN on Omnia.
I hope someone from the staff or someone more experienced can help me to be able to configure Turris OS 4 correctly and finally make the move. Thanks in advance.
EDIT: I’m almost sure the problem comes from handling the SFP and the eth2 interface. In fact, the interface is never ready. Therefore it is impossible to make any kind of connection.
Meanwhile, I thank you for the answer. Of course, I activated SFP by linking the corresponding module in the boot folder and in fact from dmesg it is connected and working. I think the problem is in the eth2.xxx interface. Using your own configuration I can’t connect to the internet on 4.0. Do you use Omnia or MOX? Because they are supported differently at present. MOX is born with Turris OS 4, while Omnia does not support multiprocessor VLAN.
I use Omnia. I reflashed the Omnia to 4.0, activated the SFP and configured it again from scratch. The only difference I see in our configuration is that you have the config switch configurations. Have you tried removing that. I also had the config switch in the 3.x but in 4.0 I didn’t need it. It connects perfectly to my service provider on VLAN 6 (internet) and 4 (iptv)
I have carried out all the necessary tests and both on Turris OS 4.0.1 stable and on the hbk branch and the hbd branch I cannot activate the connection to the ISP. I receive two an unknown error (user request) and in the dmesg an entry pppd timeout waiting for pad0 packets. With the same simple configuration made on Turris OS 3.11.8 no problem, everything works as it should.
These timeouts are really super unspecific they only tell you that your PPPoE-client send a request and did not get the expected response (or any response actually) in the allotted time. Any type of misconfiguration or physical problem (like modem phsycally not connected to the router or the upstream network) will result in this error.
Thank you for the reply. By now I just think it’s a bug in the PPPoE protocol. Although some people tell me they can easily connect to Turris OS 4 via PPPoE, I can’t, but as soon as I switch to 3.11.8, like magic, as soon as I enter the usual parameters, I’m connected. I do not use devices in the middle, except the operator’s SFP which is directly connected to Turris Omnia. So since there is an access error on Turris OS 4 and since there is no 3.11.8 (verified with countless tests), I came to the conclusion that there is a bug in the authentication phase. I read on the forum that already in the past, it seems to me on version 3.6 there was a similar problem, then solved by an update. However I sent an email with the diagnostic file to the technical support, hoping that someone from the team could give me a hand.
As @moeller0 pointed out - without proper logs it would be only guesswork to understand of what is going wrong.
Having said that, I doubt that the PPPoE kernel module is the issue, but rather:
the VLAN is not connected prior PPPoE tries to authenticate, assuming that is the order of things
or
there is an issue with the driver for the SFP module.
When having transited from TOS3.x to TOS4/5/6 I ran into issues with PPP connectivity but it turned out being caused by something else, as outlined here
Thank you so much for your answer. I am attaching the Omnia log file to 4.0 once I have configured everything. If you feel like it, you can take a look. Unfortunately, I don’t know which way to look.
Mmmh: Oct 31 00:08:35 turris kernel: [ 437.429244] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Eth2 never becomes ready or up, no wonder that eth2.835 also never comes up, and given that PPPoE on eth2.835 will wait for a response until the cows come home ;). To my layman’s eyes it looks like the SFP module is not properly recognized yet…
I am even more profane than you, but I can tell you that I have disabled IPv6 and the error seems to be related to IPv6.
Could it depend on the vlan? How do I configure it correctly?
Mmmh, maybe you could post the diagnostic also for 3.11.8? That said, I am really just curious and have no relevant know-how so I will be unlikely to be able to help even with more information…
What could I do about it? On the other hand, if you look for the sfp entry in the dmesg you will see that it is recognized. Why does everything work on 3.11.8? Is it a problem of the module that manages the SFP?