you can send your enquiry to email@example.com.
For the moment I received a pair and conducted some successful tests with Mikrotik routers first but have set some time aside over the weekend to test with the Omnia.
Please note that I’m testing against the master modem of the pair and a private DSLAM only currently.
I got only easy access to a public BT ADSL (spec of the SFP suggests that it can handle ADSL too) and Inode VDSL which I’l likely going to test against if the test against the private DSLAM is successful.
However for BT I’ve not seen any sign of even an attempt to certify the modem as SIN compliant therefore it wouldn’t be something permanently usable.
Funguje nějaký VDSL2 SFP modul s našimi operátory?
What about this one:
Hi level20peon. Does your SFP works with Omnia for VDSL/2 ? Thnx
No idea, I hoped you guys could tell me before I bought it
tragic how people with sufficient resources to “simply buy one”, seldom have the time and incentive to report back whereas “normal” ppl usually dont want to put up the money for trial and error.
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
- I had used windows 7 (fresh with all updates at the time) and installed .net and wireshark as both were required. I believe the software setup was fine because the ethernet packet goes out, just no response.
- I’ve now switched to Win10 Dev (1811) . The Versatek provided software (DSLMonitor Lite 0.10.3) ssems not to work with that version. However the Allnet provided (0.10.7) works fine.
- I had not much luck with versatek or @1112 so far. I might give them both another prod.
- I got an Allnet sfp (ALL4781-VDSL2-SFP via Innet which works and Allnet provided me with software (newer version of what I got from Versatek) and that works with the Allnet SFP but not with the Versatek ones.
- from a first look it seems the protocol works in that the client asks the SFP to read a specific bit of memory and the client knows what that bit of memory means. If so then the meaning may be specific to the sfp firmware.
- I suspect that versatek didn’t programm the SFP correctly and the MAC address printed on doesn’t match the actual MAC the SFP has.
- I used the USB NIC mentioned before and Mikrotik routers with the Allnet SFP. I’ll try to give the Omnia a try esp. with a Deutsche Telekom VDSL (100/40) when back in Germany in May 2019.
- If someone with an SFP feels like experimenting then give me a prod and I’ll try to make some time.
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!