This 3.11.8 diagnostics.
Thanks, on 3.11.8 it is eth1 and there we see"
2019-10-31 01:15:50 info kernel[]: [ 35.322531] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[...]
2019-10-31 01:15:50 info kernel[]: [ 37.425187] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[...]
2019-10-31 01:15:50 info kernel[]: [ 39.421143] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
2019-10-31 01:15:50 info kernel[]: [ 39.421218] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
So to me that still looks like there are issues with properly setting up the link for eth2 on TOS4, and without the interface being in the “up” state, pppoe connection attempt will timeout. It might be interesting to try connecting without a VLAN configured (just to see whether the connection comes up, it will not be usable, but the first challenge would be to get the inface into “up” state somehow).
I installed everything from scratch and didn’t set the VLAN, but still eth2 doesn’t work.
Maybe this means something?
@Pepe Can you help me figure out how to configure it on Omnia and Turris OS 4.0.1? In the thread you have all the elements. Thanks a lot.
IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Pv6: ADDRCONF(NETDEV_UP): eth2.835: link is not ready
does not matter unless the ISP provides ipv6 only,
for an ipv4 upstream connection it can be expected
kernel: [ 88.322518] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
kernel: [ 88.324181] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
kernel: [ 88.324245] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
insmod: module is already loaded - slhc
insmod: module is already loaded - ppp_generic
insmod: module is already loaded - pppox
insmod: module is already loaded - pppoe
pppd[7872]: Plugin rp-pppoe.so loaded.
pppd[7872]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
pppd[7872]: pppd 2.4.7 started by root, uid 0
pppd[7872]: PPP session is 14121
pppd[7872]: Connected to e0:ac:f1:65:51:ba via interface eth2
kernel: [ 88.888749] pppoe-wan: renamed from ppp0
pppd[7872]: Renamed interface ppp0 to pppoe-wan
pppd[7872]: Using interface pppoe-wan
pppd[7872]: Connect: pppoe-wan ↔ eth2
pppd[7872]: PAP authentication succeeded
pppd[7872]: peer from calling number E0:AC:F1:65:51:BA authorized
pppd[7872]: local IP address xxx.233.130.188
pppd[7872]: remote IP address xxx.46.104.107
pppd[7872]: primary DNS address xxx.209.104.220
pppd[7872]: secondary DNS address xxx.209.104.250
netifd: Network device ‘pppoe-wan’ link is up
Bears no relevance to the issue.
mvneta f1034000.ethernet eth2: configuring for SGMII/sgmii link mode
I still trust that being either an issue with the SFP driver in TOS4.x or that the SFP link is not set correctly
ls -al /boot/
total 3428
drwxr-xr-x 1 root root 158 Nov 1 12:27 .
drwxr-xr-x 1 root root 176 Nov 1 12:27 …
-rw-r–r-- 1 root root 18773 Nov 1 00:50 armada-385-turris-omnia-phy.dtb
-rw-r–r-- 1 root root 18809 Nov 1 00:50 armada-385-turris-omnia-sfp.dtb
-rw-r–r-- 1 root root 1189 Nov 1 00:50 boot.scr
lrwxrwxrwx 1 root root 37 Aug 28 07:12 dtb → /boot/armada-385-turris-omnia-sfp.dtb
-rwxr-xr-x 1 root root 3460632 Nov 1 00:50 zImage
ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot
which needs to be done every time after a 4.x medkit reset, unless you have two separate installations, one for 3.x and one for 4.x
1 Like
I make the connection with ln towards sfp. This always. As I told you from the dmseg appears and is recognized as Technicolor and corresponds to reality. Perhaps even if recognized it is not the same. For me it’s the stuff of VLAN, Omnia, switches, CPUs, kernels and switching to 4.x.
For now I stay on 3.11.8 waiting for updates. Sin! This router fulfilled all my fetishes, but now it links the Linksys WRT3200ACM with the latest version of OpenWRT. Maybe I need to get an external ONT and switch to another router. The strange thing that the processor looks the same in both routers yet on OpenWRT 18.06.4 the VLAN works perfectly.
Apparently it does not bring up the physical WAN link however.
I still trust this being a driver issue for that SFP module in TOS4.x
Might be worth to open an issue at Turris / Turris OS / Turris Build · GitLab
2 Likes
I will open an issue.
No, I disagree, this is indicating that the interface eth2 has not come up (yet). This is independent of whether IPv6 is actually used on the WAN link. In your ipv4 example, I bet after the kernel: [ 88.324181] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode message there are no further kernel: [ 88.322518] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready messages?
But I agree IPv6 is not the issue here, eth2 not coming up is the problem ;).
1 Like
Thanks, I opened an issue on the Gitlab project page.
1 Like
Could you post the output of dmesg and especially the part related to sfp and eth2?
I have a similar if not the same problem.
Hardware
- Omnia turris EU version 2019
- ALLNET ALL4781-VDSL2-SFP
The following steps have already been performed
- Update the Omnia to version 4.01
- SFP port activated via
ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot
ls -al /boot/
showed the following afterwards
root@turris:~# ls -al /boot/
drwxr-xr-x 1 root root 158 Nov 10 21:49 .
drwxr-xr-x 1 root root 142 Nov 10 17:29 ..
-rw-r--r-- 1 root root 18773 Oct 9 01:24 armada-385-turris-omnia-phy.dtb
-rw-r--r-- 1 root root 18809 Oct 9 01:24 armada-385-turris-omnia-sfp.dtb
-rw-r--r-- 1 root root 1189 Oct 9 01:24 boot.scr
lrwxrwxrwx 1 root root 31 Nov 10 21:49 dtb -> armada-385-turris-omnia-sfp.dtb
-rwxr-xr-x 1 root root 3378136 Oct 9 01:24 zImage
as did
dmesg | grep eth2
[ 4.473490] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:ad:0b
[ 5.385458] mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
[ 21.534237] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 21.544608] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 24.546411] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 24.581405] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 24.909390] mvneta f1034000.ethernet eth2: Link is Down
[ 26.307271] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 30.598480] mvneta f1034000.ethernet eth2: Link is Down
[ 30.620692] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 30.629938] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 46.000207] mvneta f1034000.ethernet eth2: Link is Down
[ 46.013538] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 46.021558] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 61.269943] mvneta f1034000.ethernet eth2: Link is Down
[ 61.289600] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 61.297683] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 76.560345] mvneta f1034000.ethernet eth2: Link is Down
[ 76.577440] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 76.585533] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 91.812935] mvneta f1034000.ethernet eth2: Link is Down
[ 91.826532] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 91.834643] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 107.075020] mvneta f1034000.ethernet eth2: Link is Down
[ 107.089136] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 107.097175] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 107.105797] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 108.151469] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 122.349772] mvneta f1034000.ethernet eth2: Link is Down
[ 122.363585] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[ 122.371631] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 122.380088] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
and kernel this
[ 4.977528] libphy: SFP I2C Bus: probed
[ 4.984894] random: fast init done
[ 4.992000] mv88e6085 f1072004.mdio-mii:10: switch 0x1760 detected: Marvell 88E6176, revision 1
[ 5.003204] mmc0: new high speed MMC card at address 0001
[ 5.008787] mmcblk0: mmc0:0001 008G30 7.28 GiB
[ 5.013402] mmcblk0boot0: mmc0:0001 008G30 partition 1 4.00 MiB
[ 5.019391] mmcblk0boot1: mmc0:0001 008G30 partition 2 4.00 MiB
[ 5.025409] mmcblk0rpmb: mmc0:0001 008G30 partition 3 4.00 MiB
[ 5.032479] mmcblk0: p1
[ 5.186121] libphy: mv88e6xxx SMI: probed
[ 5.190194] DSA: switch 0 0 parsed
[ 5.193617] DSA: tree 0 parsed
[ 5.312662] sfp sfp: module ALLNET ALL4781 rev V3.4 sn 0000000FC91A0A6E dc 29-08-19
[ 5.322000] sfp sfp: unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[ 5.330198] sfp sfp: 1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
[ 5.340313] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[ 5.346597] sfp sfp: Wavelength 0nm, fiber lengths:
[ 5.351663] sfp sfp: 9µm SM : unsupported
[ 5.356377] sfp sfp: 62.5µm MM OM1: unsupported/unspecified
[ 5.362138] sfp sfp: 50µm MM OM2: unsupported/unspecified
[ 5.367895] sfp sfp: 50µm MM OM3: unsupported/unspecified
[ 5.373657] sfp sfp: 50µm MM OM4: 2.540km
[ 5.378024] sfp sfp: Options: retimer
[ 5.381870] sfp sfp: Diagnostics:
[ 5.385458] mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
[ 5.965447] mv88e6085 f1072004.mdio-mii:10 lan0 (uninitialized): PHY [mv88e6xxx-1:00] driver [Marvell 88E1540]
[ 6.086157] mv88e6085 f1072004.mdio-mii:10 lan1 (uninitialized): PHY [mv88e6xxx-1:01] driver [Marvell 88E1540]
[ 6.207683] mv88e6085 f1072004.mdio-mii:10 lan2 (uninitialized): PHY [mv88e6xxx-1:02] driver [Marvell 88E1540]
[ 6.325449] mv88e6085 f1072004.mdio-mii:10 lan3 (uninitialized): PHY [mv88e6xxx-1:03] driver [Marvell 88E1540]
[ 6.445450] mv88e6085 f1072004.mdio-mii:10 lan4 (uninitialized): PHY [mv88e6xxx-1:04] driver [Marvell 88E1540]
[ 6.465253] armada38x-rtc f10a3800.rtc: setting system clock to 2019-11-11 20:21:31 UTC (1573503691)
Can anyone contribute information, thoughts or ideas? Has anyone found a solution to this problem?
I talked to those who develop the software on GitLab, really very kind. The problem is exactly mine. Unfortunately there does not seem to be a simple solution. Either you manipulate the code and modify the kernel module that controls the SFP or you go back to version 3.11.8, which anyway, even if it is up to date is now the past, or you buy a transceiver and make a connection between SFP and ethernet cable, using the WAN port of the Turris Omnia (solution that I adopted). The error is due to the SFP device provided by the ISP (which in my case is not replaceable, because it has a MAC address necessary for connection with the service provider). In fact, with the transition to Turris OS 4.x and the basis of OpenWRT 18.04.6, the developers decided not to introduce those hacks that allowed greater compatibility with different types of devices. So either you know how to develop code or put your soul at peace.
The issue is not identical since @lucenera referrers to a SFP transceiver module for a fibre optic line provided by the ISP whilst @mk_ultra uses a small form factor (x)DSL modem SFP module.
@mk_ultra The modem (ALL4781) works in my node with TOS versions 4.x | 5.x | 6.x, albeit with issues, as mentioned previously
The difference between your node and mine however
802.3z is Gigabit Ethernet delivered over fibre optics and thus with the ALL4781 being a (x)DSL modem it would not be compatible.
whilst on my node it reports
mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
Whist this topic is headed
PPPoE config
the issue is not with PPP at all but SFP modules suffering connectivity problems with the physical upstream link to the ISP, and which only subsequently fails PPPoE.
From my observation it seems to be caused by the mvneta driver and potential link-up signal mismatch.
You made a long speech to confirm what I was saying: the cause is the SFP module. Thanks for the clarification.
There are different types of SFP modules and different issues and the use case by @mk_ultra is entirely different from yours and even mine.
And the issues with your SFP module and mine are not caused by or due to the SFP modules in question but the mvneta driver handling the uplink to the ISP.
It won’t be identical, but for me too, eth2 is down and it’s never ready. I realized that the modules are of different brands and one on fiber the other on xdsl, but the juice does not change. Be more elastic.
You are trying to generalize your use case but that just does not hold not water as such:
- the SFP transceiver for fibre optics supplied by your ISP does not get an uplink at all
- the SFP (x)DSL modem I use gets uplink connectivity but with hiccups
- SFP (x)DSL modem by @mk_ultra does not get uplink because it would appear not compatible with the subscriber line
hey people @anon50890781 @lucenera don’t argue!
i am sure we will find solutions.
more information about my configuration
ALLNET ALL4781-VDSL2-SFP is directly connected to the TAE socket (copper cable).
- orange LED lights up constantly
- green LED lights up constantly
I assume that a connection between ALLNET ALL 4781 to the ISP will be established.
My ISP is 1und1, the last kilometer is provided by the German Telekom.
- 1TR112 German Telekom,
- VDSL2 vectoring according to ITU-T G.993.5 and ITU G.993.2/.3, as well as RFC 5072, RFC 6333 and RFC 6334
@n8v8rhow is your configuration different for mine?
@anon50890781 Do you have any idea how I could solve the problem with
mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
is there a way to change or switch settings mvneta driver or how do I solve
potential link-up signal mismatch
thank you very much for your help upfront. sry for the late reply.