VDSL SFP Bridge Modem

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 :slight_smile: 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 :frowning:

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:

  1. 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.
  2. Windows-pc–usb2sfp–sfp(CO)
    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 :slight_smile:

Update (2019-Jan-21):

  • 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

  1. 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
  1. 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”

  2. It’s possible to use I2C, at least for getting basic info about this Versa :slight_smile: 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    ???????????????.
  1. 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.

1 Like

Any news?

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.

Hi @pmatous & @andre

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 :slight_smile:

Any progress on making these (metanoia chipset based) VDSL SFP modems working with the Turris Omnia?

1 Like

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.

Success message:
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

@anarcat the ALL4781-VDSL2-SFP specifications are listed here. If overlapping with the ISP network standards it should work, e.g. G.993.2

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!

Do Allnet provide you with some way of gathering stats ?
What line stats/params did the BM100 report when it was running ?

I took a risk spending €100 on a SFP VDSL modem with no guarantees that it would work. I am pleased to report that it works well in my environment:

Router: Turris Omnia
Firmware version: OpenWrt omnia 15.05 r47055

SFP module: VX-160CE VDSL2 SFP Modem (Remote Telco Grade)
(Purchased from Meconet, Germany)

ISP: NowTV (part of Sky), United Kingdom. VDSL FTTC

Approximate process (a lot of trial and error went on!):

  1. Put the SFP port in your Turris – it should work out of the box. Check it is recognised:

    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 01 00 00 00 00 01 0d 00 00 00 ??"…?..??..
    10: 00 00 ff 00 50 72 6f 73 63 65 6e 64 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 34 00 00 00 da V3.4…?
    40: 08 00 00 00 31 38 32 33 34 48 35 4d 39 31 37 41 ?..18234H5M917A
    50: 30 33 36 38 31 37 30 39 32 36 30 30 00 00 00 20 036817092600…
    60: 30 30 33 30 35 30 30 43 35 30 42 42 20 20 20 20 0030500C50BB
    70: 20 20 20 20 20 20 20 20 45 44 4c 31 36 43 56 31 EDL16CV1

  2. Get your ISP settings correct. For me, this was the limiting factor.

For others reading this struggling with Sky FTTC broadband, it is possible; don’t give up! There are many resources on forums across the net but not all in one place. The key settings that I had to look carefully at were:


option broadcast ‘1’ # VLAN tagging
# SFP port is linked to eth1 (sfpswitch.py may be required if link isn’t correctly configured)
option ifname ‘eth1.101’ # use VLAN 101
option clientid ‘<DHCP client identifier string>’ # use Wireshark (filter udp.port == 67)to obtain, then hex encode without padding (=)
option vendorid ‘<obtain from wireshark>’


Very interesting. However, for most ADSL use cases, one needs to set VPI and VCI. How did you do that? Or, are you saying that you were just lucky that the defaults match what your ISP uses?

The example by is for VDSL not ADSL. A large percentage of UK VDSL is based on BT and uses vlan 101 for data (plus pppoe on top usually) as per https://www.btplc.com/SINet/SINs/pdf/498v7p5.pdf . For SKY it isn’t pppoe but DHCP settings (looks for SKY MER dhcp options 60 and 61).
Therefore @s11erm didn’t need VPI/VCI.

By “default” the SFP maps specific VLANs to specific VPI/VCI combinations for ADSL see https://forum.mikrotik.com/viewtopic.php?f=3&t=104109&start=50#p598656 .
The usual default for UK is 0/38 which isn’t covered by the SFP.
I’ve no idea if these mappings can be tweaked.
In addition the spec sheet suggests that ADSL isn’t supported at all if some of higher speed VDSL options are enabled.
Therefore don’t waste your time trying to get ADSL working with these SFPs.

@s11erm , good work .

Have you tried to get software to monitor the SFP (line stats etc.)?
What you are looking for is “DSLMonitor Lite” and it looks likely that you need to request it (from the vendor/integrator).
It is windows software and needs to be on the same layer 2 network as the SFP (I just bridge the sfp into a management vlan and have the windows box see that).
I got a copy from versatek (which I never got to work with the versatek SFPs) and got a newer copy from Allnet for their ALL4781-VDSL2-SFP (Innet) which works like a charm.
I’d be interested if the config files to the software are vendor specific.

@mona @renne

I don’t know if you noticed but the Allnet SFPs are available now.
I got one ALL4781-VDSL2-SFP via Innet and it worked on an Telekom VDSL (100/40 via 1&1).
I tried it with a Mikrotik routerboard which I had at hand but can give it a try with an Omnia when I’m back there in May.

I did contact Allnet and was provided with some windows software (newer version what I got from Versatek but no idea if the config files are specific to a vendor) which seems to actually work to get (line) stats.

@MiKe Yes, seen this thread in fact I’m “breili” over there :wink:
@pmatous Did Versatek provide the software to you? Does it work? Note that if it complains about some DSL dll missing then you need to install wireshark (it is looking for libpcap).

There is a ALL4781-VDSL2-SFP-specific thread.

1 Like