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

I can confirm DSLmonitor-Lite works with a TP-Link MC220L media converter.

I observed the same behavior like @seiichiro0185 when doing a SOC dump.

The chain ALL4781 -> MC220L -> Fritz!box 7490 shows the same VDSL-sync losses like the ALL4781 with Turris Omnia.

SOC-dump

1 Like

@renne @seiichiro0185

Did you, or are you planning to, share the dumps with the ISP and ALLNET to figure the connectivity issues?

I already sent the dump to Gerhard Zerwes (Allnet).
Telekom standard slogan: It’s your equipment, not our socket."

Unfortunately got more or less the same response from my ISP (1&1) “You’re not using our supplied router, so you are on your own. All looking good on our end”

Hello,
I have no success with SFP yet, but I now tried an external Modem successful:
https://www.allnet.de/en/allnet-brand/produkte/modems-router/modems-adsl/p/allnet-all0333cj-adsladsl2-modem-annex-b-und-j/
I have 14.6 MBit download and 1.6 MBit upload.
This is my configuration.

onfig interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’

config interface ‘lan’
option ifname ‘eth0 eth2’
option force_link ‘1’
option type ‘bridge’
option proto ‘static’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option ipaddr ‘192.168.1.1’

config interface ‘wan’
option ifname ‘eth1.7’
option ipv6 ‘auto’
option keepalive ‘5 5’

config interface ‘wan6’
option ifname ‘@wan
option proto ‘pppoe’
option username ‘U@t-online.de’
option password ‘PW’
option ipv6 ‘auto’

config switch
option name ‘switch0’
option reset ‘1’

config switch_vlan
option device ‘switch0’
option vlan ‘1’
option ports ‘0 1 2 3 5’
option vid ‘1’

config switch_vlan
option device ‘switch0’
option vlan ‘2’
option ports ‘4 6’
option vid ‘2’

Yeah, that’s german services. 1und1 has to rent the last mile from Telekom. So they pass through the Telekom answer and add their subtle “rent our router” message.

@SteJe, accoding to the working external modem, your Connection is an ADSL2+ Line, not a VDSL2 one. Since the ALL4781 SFP is only specified for VDSL2 and not for ADSL, it will not work with your current DSL Line. That also corresponds to the PADO Timeouts (meaning no DSL Sync most probably) from the Log you posted earlier. So unless you can get a VDSL2 Line at your place (50MBit or higher should normally be VDSL2) the SFP won’t work unfortunately.

I made a comment on VDSL SFP Bridge Modem

I just bridge the sfp into a management vlan and have the windows box see that)

and @anon50890781 asked me to elaborate.
So there an example how I have set it up on an test rig.

First keep in mind what the DSL SFP really is, a DSL modem connected to an ethernet port condensed into an SFP. Therefore to talk to the modem (for stats) you need to address it by using the modem’s MAC address (the one printed on the SFP). If you would use the address of eth1 you would address the Omnia.
In addition note that this is all L2, e.g. no IP/routing involved (the windows box in my example doesn’t have an IP address at all).
Therefore a “simple” bridge will get the result required because a packet with an destination MAC the bridge doesn’t know yet (when the first packet from the Windows box to the modem arrives) will be flooded onto all bridge ports. The bridge will learn where the MAC is when the response from the modem arrives and then send it out the correct port without flooding. (normal switch/bridge principles).

Now to the test setup for illustration.

Setup Overview

I started of with an factory reset Omnia with “current” aka 3.11.2.
Then I deleted some unnecessary stuff plus reconfigured the switch into tagged mode by:

  • enabled VLAN functionality on switch0
  • switched the CPU port into tagged mode
  • removed all other LAN ports from VLAN 1 but LAN0/Port 0 and CPU (tagged mode)
  • replaced eth0 with eth0.1 in the “LAN” interface definition
    Note: only “apply” after all the last step or you will lose connectivity
    In this way I’m free to use all other ports assigning them to other then the default vlan.

Next I set up the config the the DSL and SFP so that the windows box connected to LAN1 was able to talk to the modem inside the SFP and set up an example PPPoE connection on VLAN 7 via the modem. I picked VLAN 111 as for sfp management.

  • added an “SFP” interface as eth1 (SFP port) for visibility, not really required
  • changed the “WAN” interface definition to use eth1.7 (VLAN 7 on SFP port) and PPPoE
  • created new VLAN 111 on switch0 and added LAN1/Port 1 (the one the windows box is connected to)
  • added an “SFPMGT” network interface bridging eth1 (the SFP port) and eth0.111
    Apply and it started working.
    Note that the bridge needs to be “up” (ifconfig br-sfpmgt up) or it will not pass traffic. OpenWRT sometimes takes “unmanaged” as meaning not to up the interface. In that case I usually assign an random IP (unused private) to it.

The net result is below

LUCI switch0 config

  • Port 0 (on VLAN 1): Client device which can browse the internet via the Omnia
  • Port 1 (on VLAN 111): Windows host with the DSLMonitor software running which can only access the modem inside the SFP
  • Port 5 (tagged): CPU port between switch and Omnia CPU
  • Port 6 (VLAN 2): 2nd CPU port left unchanged
swconfig dev switch0 show output
root@turris:/etc/config# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        mask: 0x0000: (0)
        qmode: 3
        pvid: 1
        link: port:0 link:up speed:1000baseT full-duplex
Port 1:
        mask: 0x0000: (1)
        qmode: 3
        pvid: 111
        link: port:1 link:up speed:1000baseT full-duplex
Port 2:
        mask: 0x0000: (2)
        qmode: 0
        pvid: 0
        link: port:2 link:down
Port 3:
        mask: 0x0000: (3)
        qmode: 0
        pvid: 0
        link: port:3 link:down
Port 4:
        mask: 0x0000: (4)
        qmode: 3
        pvid: 2
        link: port:4 link:down
Port 5:
        mask: 0x0000: (5)
        qmode: 3
        pvid: 0
        link: port:5 link:up speed:1000baseT full-duplex
Port 6:
        mask: 0x0000: (6)
        qmode: 3
        pvid: 2
        link: port:6 link:up speed:1000baseT full-duplex
VLAN 1:
        port_based: 0
        vid: 1
        ports: 0 5t
VLAN 2:
        port_based: 0
        vid: 2
        ports: 4 6
VLAN 3:
        port_based: 0
        vid: 111
        ports: 1 5t
root@turris:/etc/config#
LUCI Interfaces overview

LUCI interface SFPMGT general

dsl-test-luci-sfpmgt-general

LUCI interface SFPMGT physical

/etc/config/network file content
root@turris:/etc/config# cat network    

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdad:76d0:3276::/48'

config interface 'lan'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option _orig_ifname 'eth0 eth2 radio0.network1 radio1.network1'
        option _orig_bridge 'true'
        option ifname 'eth0.1'

config interface 'wan'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option ifname 'eth1.7'
        option proto 'pppoe'
        option username 'hello'
        option password 'world'
        option ipv6 'auto'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 5t'
        option vid '1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6'
        option vid '2'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option ports '1 5t'
        option vid '111'

config interface 'sfp'
        option proto 'none'
        option ifname 'eth1'

config interface 'sfpmgt'
        option ifname 'eth0.111 eth1'
        option _orig_ifname 'eth0.111'
        option _orig_bridge 'false'
        option proto 'none'
        option type 'bridge'

root@turris:/etc/config#
DSLMonitor output

Any questions are welcome.
Just a warning, don’t bridge the SFP onto your standard internal network. After all whatever is visible to the modem will be visible to the remote end.

3 Likes

Excellent write up! :+1:

One thing I am not comprehending is the extra step with the bridging. To my humble understanding the switch does flood as well to any client on the same vlan id. But then it lacks the intelligence to deal with responses and that is where the bridge/kernel comes in?

No, as far as I know (and shown there https://doc.turris.cz/doc/en/howto/vlan_settings_omnia ) the SFP/WAN port is connected to the CPU directly (not a switch port on the switch) and the only way going from LANX to SFP is via CPU because the switch has no “wire” to the SFP/WAN.
Therefore the switch floods it to the CPU port and the CPU bridge then floods it to it’s directly connected connect SFP.
In a way the packet from the windows box travels via two connected switches. So similarly to chaining two desktop switches with the modem connected to one and the windows box to the other.

The ALLNET support clarified on Super-Vectoring which apparently is not downward compatible to VDSL.
They might be looking into a new unit of this size that supports g.fast which is said to be downward compatible.

Some reference design seems to be existing already since '15/'16 but I haven’t found yet an actual unit in retail.

https://www.proscend.com/en-gb/product/sfp/190t.html
http://www.sckipio.com/first-gfast-sfp-design-announced/
http://www.methode.com/documents/technicallibrary/Marketing Data sheet%20 DM7087 G.Fast Rev 4p1.pdf

Yep, waiting for those for a while too to upgrade my connectivity (can’t lay fibre or copper down but got a nice phone line between floors of a building).

Pardon my ignorance but where/how is VLAN 7 achieved with

config interface 'sfp'
        option proto 'none'
        option ifname 'eth1'

Not with that one. That just gives “eth1” a nice name of “sfp”. I think I could delete that definition with no effect.

The one with vlan 7 on the sfp is there:

The way to do that in the UI is to tick “custom interface” on the “physical settings” tab and type “eth1.7” into the text box.

If I do that wan is not connecting and the log showing

err pppd[20618]: Unable to complete PPPoE Discovery.

wan pppoe settings
config interface 'wan'
	option proto 'pppoe'
	option username ''
	option password ''
	option peerdns '0'
	option zone 'wan'
	option zone_dslite 'wan'
	option zone_map 'wan'
	option zone_464xlat 'wan'
	option ipv6 '1'
	option ifname 'eth1.7'
	option keepalive '2 5'

config interface 'wan6'
	option ifname '@wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'

No issue with eth1. Is eth1.7 sending a vlan tag 7 to the ISP?

Yes, all traffic from/to eth1.7 is expected to have a vlan id (tag) with value 7.
If eth1 works it would imply that your ISP runs the pppoe untagged and not within some vlan.
In that case the pppoe would go onto the bridge SFPMGT in my example. Note that in that case the monitoring client (windows box) would see part of the pppoe traffic too then.

Your ISP’s connectivity instructions including this vlan id (tag) with value 7 then and you did not just pulled that out of the blue? My ISP never mentioned anything about such vlan tag.

VLAN-tag 7 is in Germany for example used by Deutsche Telekom (and therefore for all resellers of their VDSL/Super Vectoring(?)- connections).
Edit: Can be found on Wikipedia :nerd_face:

1 Like

Well, good to know that it is particular to DT but apparently not necessarily a common standard a/o deployed by other ISP

Do you mean tag 7? Or do you mean tagging in general? If i remember correctly, the Switzerland’s init7-company uses also tagging (but for fibre traffic).