VDSL SFP Bridge Modem

Turris Omnia
#27

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:

#28

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

1 Like
#29

@MiKe
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.

#30

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.

2 Likes
#31

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
#32

@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

#33

Yeah, it doesn’t look like it support the “Stinger” extensions. Thanks
for the pointers!

#34

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

#35

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:

/etc/config/network:

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>’

2 Likes
#36

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?

#37

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.

#38

@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.

#39

@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).

User experience - ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2
#40

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

1 Like
#41

Would you mind to elaborate/share on setting this up? There are few users that would be interested to know how to get DSLMonitor working. User experience - ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2.

Suppose by SFP you mean eth1? Which MAC you are sending the query frames to - eth1?

#42

No, the SFP.
Just visualize what the SFP is, a stand alone modem connected via ethernet (imagine that you got an external DSL modem connected via ethernet to an copper/rj45 SFP) – just all squashed into the shape of an SFP.
Therefore to address the modem inside the SFP you need to send the packets to the MAC address of the modem (MAC printed on the SFP). If you would send it to the MAC of eth1 you would address the Omnia.

I’ll put my example config into the user experience thread.

1 Like
#43

Sure, it just that the router has no awareness of the modem’s MAC and earlier tests did not yield any result.

Looking forward to your sample config, particularly about bridging eth1 with the vlan.

#44

It is how a normal switch/bridge (like desktop switch) works and is mirrored by an Linux software bridge.
If it hasn’t knowledge of an MAC then it floods it to all ports. It learns MAC to port relations by watching source MACs of packets which arrive.
The standard linux bridge is pretty poor in functionality (esp. in the diagnostics department).
However with a recent brctl you can get the forwarding table including learned MACs via "brctl showmacs ", e.g.

root@dtank0:~# brctl showmacs wsbr0
port no mac addr                is local?       ageing timer
  1     00:16:3e:7c:c4:1a       no                32.21
  1     0c:c4:7a:c6:e4:17       yes                0.00
  1     0c:c4:7a:c6:e4:17       yes                0.00
  2     12:04:0a:7c:c4:1b       no                 0.00
  1     3c:a8:2a:9f:d1:54       no                 2.04
  1     e4:8d:8c:7e:4b:30       no                 0.46
  2     fe:04:0a:7c:c4:1b       yes                0.00
  2     fe:04:0a:7c:c4:1b       yes                0.00

The ones with an ageing timer are learned ones.
Note that older brctl versions as well as the busybox based one doesn’t include the showmacs option.

1 Like
#45

Thanks for the notice, Andre, I went with a different solution since but remain interested. I’ll keep an eye on this and the ‘Allnet experience’ thread others have mentioned here.

#46

I just wanted to let people here know there’s a similar discussion happening on OpenWRT’s forum:

I’m curious to see if the conclusions are similar…

1 Like