Init7 just confirmed setting “speed nonegotiate” on the Cat4500 works around the problem:
Does “speed nonegotiate” break things for the tp-link media converter, then? Also, will this keep working, even with newer Turris versions, or is this just a temporary workaround?
Yes, it does. You would have to switch the TP media converter from Auto to Force, if “speed nonegotiate” is configured on the other end.
If this gets fixed in a newer software version, this configuration will break those as well.
Disabling auto-negotiation is a bad idea, it is nothing more than a workaround.
Thanks for the clarification. I don’t mind having to switch the TP converter from Auto to Force, but future Turris updates possibly breaking my internet connection is not acceptable.
@brill Now that it has been established that auto-negotiation is the issue, what are the next steps? I’d be happy to help test any new images if that is of any use.
I can confirm that this definitely works! Speed is the same as with mediaconverter.
Quick Question:
My Turris currently runs
Turris OS version 3.5.1
Kernel version 4.4.39-80079e1c1e5f9ca7ad734044462a761a-3
does this firmware version work with “speed nonegotiate” out-of-the-box, or do I have to download and install a beta firmware?
Thank you
I can confirm that it works now after contacting Init7 support.
They’ll need the OTO-ID and probably customer-ID and configured “Speed No Negotiate” on their side very quickly.
Nothing to be done on the TO, just switch it off before plugging the SFP and fiber cable.
It works like a charm immediately, same perfect fiber7 speed as before.
Good bye media-converter…
My setup:
Turris Omnia - RTROM01
Turris OS version - 3.5.1
Kernel version - 4.4.39-80079e1c1e5f9ca7ad734044462a761a-3
SFP: TP-LINK TL-SM321B
Cheers
2 Likes
It should. I tested it in fact with even older kernel…
Hi! Many thanks for verification of this issue.
I am going to fill in a support case with Marvell and we will try to create a work-around with them. Thanks again!
I’ll keep you posted with updates.
Tomas
1 Like
I’ve called Init7/Fiber7 today at 10:22. The lady wrote down my request, talked to Second Level Support and got back to me with a minute or two telling me to wait 20-30 minutes, to shut down the router, move the SFP from the Mediaconverter into the router and to reboot the router. No OTO or customer ID needed; my name was my “password”.
I did as I was told just a few minutes ago. Since I couldn’t find a Power Off button in Foris, I decided to shut down the router through SSH:
# poweroff
The device didn’t go offline as all LEDs were showing a white color. After a minute of waiting I just unplugged the power cord of the router.
I then proceeded as told and rebooted the router. The SFP got recognized instantly and established connection to Fiber7 without any issues.
Before performing the switch, I updated the router to the newest firmware …
Turris OS version 3.5.2
Kernel version 4.4.39-80079e1c1e5f9ca7ad734044462a761a-4
http://%TURRIS-IP%/config/about/
… and downloaded a configuration backup, just in case, to be safe:
http://%TURRIS-IP%/config/maintenance/ (Foris Interface)
Conclusion: It works, after three long months of waiting for a solution 
Just a minor thing: The Internet/eth1 LED is not working when using the SFP Module in the SFP Port directly
1 Like
Hi
I tried to get SFP module work in Turris.
I got a suitable SFP module (Ligent LTD1391-BH 1310nm/15km/155Mbps) from my ISP provider.
The method is 100BaseFX SM 1310nm.
I installed SFP module and fiber cable to Turris but I couldn’t get it working.
The network has been tested with another hardware and it worked.
Can anybody help me! How can I get SFP module working? Here are some pieces from the log
root@turris:~# cat /var/log/messages | grep sfp
2017-02-02T19:05:42+02:00 err sfpswitch.py[1522]: Switching NIC mode to phy-sfp.
2017-02-02T19:05:43+02:00 err sfpswitch.py[1522]: Shutting down interface eth1
2017-02-02T19:05:44+02:00 err sfpswitch.py[1522]: Bringing up interface eth1
2017-02-02T19:05:56+02:00 emerg sfpswitch.py[1522]: Called /etc/init.d/kresd start
2017-02-02T19:05:58+02:00 emerg sfpswitch.py[1522]: line not found
2017-02-02T19:05:58+02:00 emerg sfpswitch.py[1522]: DIE:
2017-02-02T19:05:58+02:00 emerg sfpswitch.py[1522]: [string “transaction”]:351: No journal to recover
2017-02-02T19:05:58+02:00 emerg sfpswitch.py[1522]: Aborted
2017-02-02T19:06:00+02:00 emerg sfpswitch.py[1522]: setting up led Auto-configuration for PCI1
2017-02-02T19:06:00+02:00 emerg sfpswitch.py[1522]: setting up led Auto-configuration for PCI2
2017-02-02T19:06:00+02:00 emerg sfpswitch.py[1522]: setting up led Auto-configuration for PCI3
root@turris:~# dmesg | grep eth1
[ 24.992261] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 26.702043] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 29.423213] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
root@turris:~# i2cdump -y 5 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 03 04 07 00 00 02 00 00 00 00 00 03 02 00 0f 96 ???..?..??.??
10: 00 00 00 00 4c 69 67 65 6e 74 20 20 20 20 20 20 …Ligent
20: 20 20 20 20 00 00 00 00 4c 54 44 31 33 39 31 2d …LTD1391-
30: 42 48 20 20 20 20 20 20 31 20 20 20 00 00 00 17 BH 1 …?
40: 00 1a 0a 0a 34 31 30 35 30 31 30 31 37 34 20 20 .???4105010174
50: 20 20 20 20 30 35 30 32 31 38 00 00 00 00 00 15 050218…?
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa …?
80: 03 04 07 00 00 02 00 00 00 00 00 03 02 00 0f 96 ???..?..??.??
90: 00 00 00 00 4c 69 67 65 6e 74 20 20 20 20 20 20 …Ligent
a0: 20 20 20 20 00 00 00 00 4c 54 44 31 33 39 31 2d …LTD1391-
b0: 42 48 20 20 20 20 20 20 31 20 20 20 00 00 00 17 BH 1 …?
c0: 00 1a 0a 0a 34 31 30 35 30 31 30 31 37 34 20 20 .???4105010174
d0: 20 20 20 20 30 35 30 32 31 38 00 00 00 00 00 15 050218…?
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa …?
And I thought this only bothers me, but obviously I’m not the only one with this issue … I tried reconfiguring System > LED Configuration and System > Rainbow, but it looks that I didn’t get the right device:
FTR, I just switched from media converter to direct SFP on the Turris Omnia and it works out of the box without reconfiguring anything. Removed power, unplugged the media converter, put the new SFP in place, started Turris Omnia, and voilà, everything except for the WAN LED works.
Init 7 sent me a new SFP with Turris Omnia compatibility this week. I do not know if they enabled speed nonegotiate on their side or not; I did not have to call them when switching from the media converter to the new SFP directly in the TO. The media converter was set to Auto all the time.
Happy to have a solution supported by Init 7 now!
Edit: WAN LED was easily fixed by adding a netdev configuration on eth1.
Interesting my friend told me the exact same thing as “Daniel Roethlisberger”.
He didn’t had to call them or do anything.
He just removed the TP-LINK TL-SM321B Transceiver from the Mediaconverter and plugged it in on the Turris Omnia SFP Port. Tadaaaa! i wonder if something changed
I just updated my Turris Omnia to the latest version:
Turris OS version 3.5.2
Kernel version 4.4.39-80079e1c1e5f9ca7ad734044462a761a-4
Then I tried using the SFP directly, but I still see the same symptom: the link goes up and down every second or so.
I’ll write to fiber7 support and ask them whether they need to change something on their end to make this work for me.
sECuRE, does media converter still works after fiber7 did the change? Can anything be broken in future because of that?
fiber7 replied, stating they changed the speed negotiation configuration on their end. The media converter still worked, and the Turris Omnia now works as well :).
Unfortunately, they say they can’t use this configuration for all customers (not exactly sure why). Therefore, just shoot them a quick email stating you’d like to use the Turris Omnia.
Thank you! Now SFP works for me. BTW, I wasn’t able to notice any latency difference: ping to 8.8.8.8 is 1.37ms on average before and after.
But at least one power supply less, which is already good.
Because the workaround has implications, like breaking existing configurations and devices and loosing important troubleshooting tools.
Speed nonegotiate means that the box will unconditionally force the link up when the RX diode receives (any) laser light.
2 Likes