Tragic how I get trolled for just asking if anyone already had experience with the device. You think I should just buy it, test it and report back if someone already did this and found out that it didn’t work? Makes perfect sense.
That’s exactly the reason I’ve recently bought one of VX-160CE, just for fun or being tired of lack of information, not sure anymore, and finally unpacked and updated Omnia (using Turris RTRS02 so far as I don’t have reason to switch for Omnia). Sadly it doesn’t seem Turris OS is able to recognize and manage it properly; not yet, so far it’s able to see “there is SFP connected” and that’s pretty much it.
It’s also worth mentioning that I currently have only ADSL2+ connection at my disposal but according to specs this SFP should be backward compatible.
So the main obstacle for me at this point is to find a way to manage SFP configuration from within Turris OS or from somewhere else (because I don’t have anything else around to be able to pre-configure SFP and then just plug it in; if it has persistent memory), either OS is not ready yet or I’m just too stupid to find out But I’ll definitely going to spend some time playing with it…
@fuller indeed, that is how the world is. The people who have enough interest to commit the financial resources are usually short in the time resource department therefore get easily delayed
But seeing some movement on here I’m happy to provide an update:
- the time I had set aside to test was taken up by trying to get some information out of the windows software which Versatek had provided. Unfortunately I failed on that. The setup(s) I have tried I’ll discuss below.
- I had a brief exchange with @1112 but run out of time to keep that up (on my todo list to respond with some details)
- I managed to confirm that the Versatek CPE SFP will sync with ADSL and VDSL and pass either the ethernet (VDSL) through or the pppoe (ADSL)
- In terms of management I have not found anything (as @pmatous found too) apart from the windows software. As I didn’t get that to work there is nothing what could be used for Linux yet. The way it would work currently would be to bridge the SFP on the Omnia and use the Windows software to configure the SFP and get stats out. Maybe @pmatous will have more luck with the software.
On my todo as next steps are:
- get in touch with Versatek asking them for a working Windows software or at least confirmation if it works for them and if so if they had to do any specific windows configuration
- get in touch with @1112 with answers to his questions and ask for protocol details [again] and if he could share a more current version of the windows software.
- finally get the Omnia set up with one of the SFPs and check if there are any surprises (I don’t expect any esp. with the positive feedback by @pmatous ).
For the Allnet SFP I wouldn’t expect any surprises either. In addition I found Allnet very supportive in getting their wares to work esp. with Linux. Therefore I’m glad that they followed through with their promise of looking to have an SFP available in 2017.
If someone got the skills and time I’d suggest that person to approach Allnet. I wouldn’t be surprised if they are happy to help (best case with a trial unit and some configuration protocol information). I certainly will only contact them when I’m sure I have enough time set aside to meet their expectations.
Now for the setup I tried to get the Windows software working:
- laptop-rj45-microtik-sfp(CPE)–(CO)sfp-mikrotik-rj45-windows pc:
Both mikrotiks were configured as a network bridge, e.g. everything in the same broadcast domain. With that I confirmed that I was able to ping between the latop and windows pc. I started the software on the windows PC, keyed in the MAC of the CO-sfp and was able to see the packet sent to the SFP in wireshark. Unfortunately the SFP didn’t respond. I tried the MAC of the CPE-sfp as well and swapping the two SFPs over. No luck either.
Again, started the Windows software, keyed in the MAC of the SFP and watched the packet going to the SFP but no reply. I tried the other SFP too with no effect. The USB NIC I used is something like https://www.aliexpress.com/item/Winyao-USB1000F-SX-USB-3-0-Gigabit-Fiber-Ethernet-Network-Adapter-SFP-NIC-1000Mbps-SX-LC/32789715514.html (two of them in an laptop with a linux bridge come in handy to diagnose fibre connections ;). I tried using the MAC of the USB NIC too but didn’t get any response either (I’d have been surprised because the USB NIC wouldn’t know about the “EBM” frames).
@pmatous The way the configuration/diagnostic of the SFP works is via EtherBootManagement (EBM) which is a protocol Metanoia use (don’t know if they developed it). In an nutshell you send an ethernet packet with an query/instructon to the SFP and the SFP responds with an corresponding ethernet packet. Because the NIC presents as a ethernet SFP (fixed to 1G full duplex) this works including with switches.
In theory you should be able to establish the connection (pppoe if you have ADSL2 I’d assume) when the SFP has synced. Unfortunately you will not see stats on Linux.
Did you get provided with the Windows software by Versatek too ? Have you tried it ?
Is your SFP getting really hot too ?
In terms of physical items I won’t do tests before 26-Aug. I might be lucky to find some time to talk to @1112 and Versatek before then.
Hope that helps
So far I’ve SFP and a “Quick Installation Guide” explaining LEDs and stating “device gets hot while operating” which is true by the way. Nothing else apart from that; I guess I might get in touch with them to ask them to provide that Windows app mentioned there (and on Mikrotik forum).
As for other things worth mentioning
- Omnia is aware of SFP presence and switches wan to “phy-sfp-sgmii” mode via sfpswitch.py, you can set mode forcefully by editing /usr/sbin/sfpswitch.py (there is a variable at the beginning of the file), I guess this could be used as a workaround for some auto-negotiation related problems.
root@turris:~# cat /usr/sbin/sfpswitch.py ... force_mode = None # possible force_mode values are: # None : autodetection # 'phy-def' - metallic PHY # 'phy-sfp' - 1000BASE-X # 'phy-sfp-noneg' - 1000BASE-X, no up/down in-band signalling (force up) # 'phy-sfp-sgmii' - SGMII
lockfile = '/var/run/sfpswitch.lock' debug = False daemon = False ...
It’s quite common you can read some info about SFP using ethtool; this is not the case, it simply returns “Cannot get module EEPROM information: Not supported”
It’s possible to use I2C, at least for getting basic info about this Versa SFP (I’ve replaced my SN by *)
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 22 00 00 00 08 00 00 00 00 01 00 00 00 00 ??"...?....?.... 10: 00 00 ff 00 50 52 4f 53 43 45 4e 44 20 20 20 20 ....PROSCEND 20: 20 20 20 20 00 00 00 00 31 38 30 2d 54 20 20 20 ....180-T 30: 20 20 20 20 20 20 20 20 56 33 2e 32 00 00 00 f2 V3.2...? 40: 08 00 00 00 30 30 30 30 30 30 ** ** ** ** ** ** ?...000000****** 50: ** ** ** ** ** ** ** ** ** ** 00 00 00 00 00 4f **********.....O 60: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 70: 20 20 20 20 20 20 20 20 56 65 72 2e 41 20 20 20 Ver.A 80: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ???????????????? 90: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ???????????????? a0: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ???????????????? b0: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ???????????????? c0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ???????????????? d0: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ???????????????? e0: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ???????????????? f0: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff ???????????????.
- Apart from EtherBootManagement/EBM which I haven’t been be able to find much about so far (either I end up listening to FLA, Rotersand, VNV Nation or something else… or at pages related to various PXE tools), I bumped into pair of abbrevations related to SFP management and debugging: DDM and DOM (and some related tools), worth taking a note.
And that’s all for now.
I’m also looking for a VDSL-SFP-module working with Deutsche Telekom. I need at least VDSL2 profile 17a (ITU G.993.2).
@renne For what it’s worth, at this time, the Metanoia SFP won’t work for you. Allnet is working with Metanoia to make their own ALL4781 (which is based on the Metanoia SFP) compatible with Deutsche Telekom VDSL, however, tests so far have not succeeded. They have received more than one batch of test hardware with modified firmwares since, and have also provided Metanoia with all parameters needed to get the DSL sync going, however, so far, no luck.
At this point it is not known whether Metanoia’s SFPs will be able to work with DT’s VDSL2 linecards. FWIW, https://docs.google.com/spreadsheets/d/1T6I1wGoikYCEZX5Geoc9LlGrBmoN_6Q1pPlxu-19hUE/edit lists commonly used linecards in Germany.
it seems both of you are much more experienced than me so my question/hint won’t bring any more light into this but I’ll take a shot.
Have you read this? - https://forum.mikrotik.com/viewtopic.php?f=3&t=104109
Did you tried force mode to ‘phy-sfp-noneg’ and set PPPoE on WAN?
You mentioned that you cannot read EEPROM - isn’t problem that there is something written from reseller or because it’s empty (but it should be empty according to mentioned mikrotik thread) ?
If I’m just wasting forum space let me know I’ll delete this post
Any progress on making these (metanoia chipset based) VDSL SFP modems working with the Turris Omnia?
Finally got some spare time to give it another session (three months since the last one passed already?!) now with 3.8.6 Turris OS.
I believe I’ve seen this thread on Mikrotik site before, I see it got updated a bit since summer, almost forgot about it, thanks for reminder. I will definitely read that.
I’ve already tried ‘phy-sfp-noneg’ mode with PPPoE back then, tried it today as well, so far the result is the same: eth1 interface goes up, yet SFP’s green LED itself still blinks as it’s trying to sync (as it seems per attached document attached when SFP arrived).
As for EEPROM contents, I’m not that much into that to give you a qualified answer, yet I remember when modem modules integrated into home routers/gateways needed some closed source binary blobs to be loaded during boot, otherwise they can’t be used properly.
As @andre suggested, I’ve reached Versatek by end of August and asked about software availability and ADSL2+ features and such; response was these things and their availability is some-what limited (don’t know it it mean hard-coded) to chipset<->telco’s cooperation, so they don’t mention these that much by themselves.
Not sure if that means a dead end for me for a while (ADSL, remember) or not. I think my next step will be approaching somebody near me, who has VDSL to give another try.
The newly arrived ALL4781-VDSL2-SFP is working out of the box.
I’m running the Turris Omnia with an ALL-BM100VDSL2V VDSL Modem at VDSL100 from Deutsche Telekom. After plug-in the ALL4781, the Turris Omnia switches the WAN connection to the SFP automatically without any reconfiguration. Very nice.
any thoughts on the compatibility of this thing? how portable would this setup be across ISPs? I’m specifically thinking of Bell Canada who deployed non-standard Lucent Stinger in their first VDSL2 phase…
Turris Mox Advantages
Bell has recently started to deploy Alcatel-Lucent 7330 remote SLAMs which do conform to ITU G.993.2 spec and customers served on those are able to use standard VDSL2 modems.
My own experience with this device here
Yeah, it doesn’t look like it support the “Stinger” extensions. Thanks
for the pointers!