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


#1

Turris Omnia - rtrom01
Turris OS 3.9.6
Kernel version 4.4.119-082ea0f4a4e204b99821bedcb349ed54-0

ISP - PPPoE with Dual-Stack Lite / VDSL2 ITU G.993.2 profile 17a

Having read earlier about the trouble with those SFP VDSL modems I was a bit sceptical when this one finally arrived. But those worries were not necessary as it works perfectly well, at least for this user. :smiley:
Now with one less external DSL modem, its power cable and LAN cable back to the TO router. :relieved:

Prior installation fetched all necessary data/info from the ISP.

Plugged the modem right into the TO router’s SFP port.

the modem activated the internal (down)link in the router (which disabled the WAN port automatically) - indicated by the modem’s orange LED and the readout from the system log

mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off

The modem also picked up the external (up)link to the ISP when the DSL cable connected - indicated by the modem’s green LED.

After deleting the WAN/WAN6 interfaces new interfaces were added through LuCI, but in short resulting in this code in /etc/config/network

config interface 'SFP'
	option proto 'pppoe'
	option ifname 'eth1'
	option username '....'
	option password '....'
	option ipv6 '0'

config interface 'DS_Lite'
	option proto 'dslite'
	option peeraddr '....'
	list tunlink 'SFP'

The WAN entry in the firewall been retained and the interfaces SFP and DS_Lite linked to it.

This took basically 10 minutes and a router reboot to get it working.

There is a warning about the modem getting hot, which holds true - thus keeping the router antennas clear of the modem.


VDSL SFP Bridge Modem
Turris Mox Advantages
Omnia as WIFI bridge!
Setting up router
#2

I can confirm the experience described by n8v8r.

I use the ALL4781-VDSL2-SFP with a 1&1 VDSL 50 Connection (Germany) with PPPoE and full Dual Stack (no DS-Lite here).

Switching from external VDSL-Modem via Ethernet WAN to the SFP module was a piece of cake, I just disconnected the Modem, Inserted the SFP-Module, connected it to the Telephone-Line with the existing cable and it just worked (after about 2 Minutes waiting for DSL-Sync).

Since everything else was already configured for the external Modem I didn’t need to make any further changes to my Configuration.

And yes I also can confirm the Modem gets quite hot as the warning in the instructions says.


#3

@n8v8r: What internet connection speed is provisioned to you by your ISP? I’m wondering which connection speeds are actually supported - I’m about to have 120/40 and my current modem provides unfortunatelly only a 10/100-LAN-connection…
@seiichiro0185: Didn’t you have to set new interfaces via SSH and add username/password options like @n8v8r mentioned?


#4

@ssdnvv I already had my WAN Setup in a way that the external modem was just used to “convert” VDSL to normal ethernet, and did all the PPPoE and VLAN Tagging on the turris already. So in my Case it was enough to unplug the external modem and plug in the SFP-Module (switch to SFP happens automatically, and the WAN-Ethernet Port and SFP-Port both appear as “eth1” on the turris).

Regarding Speeds: According to the datasheet it supports 100 MB/s up and 100MB/s down.


#5

@ssdnvv VDSL2 ITU G.993.2 profile 17a with 100d/20u. Like @seiichiro0185 mentioned the modem is supposed to support 100/100.

To my understanding that would be VDSL2-Vplus ITU G.993.2 Amendment 1 (11/15) and I trust that the modem is not supporting such. If in doubt however you may get in touch with Allnet support and inquire whether perhaps they would provide a firmware update for VDSL2-Vplus


#6

Thanks for that valuable information. I reached out to Allnet via email :blush:

Update: I already got a reply - VDSL2-Vplus aka ITU G.993.2 Amendment 1 (11/15) is simply Supervectoring and cannot be supported via firmware-update. A necessary new hardware will be released somewhen in the future.


#7

@ssdnvv thanks for the feedback which might be helpful for other users. Too bad though for you as it means that you would not get the 120 in download. Suppose you it would still would fallback to VDSL2 ITU G.993.2 (100/100) and you could still could get 100/40, if you want to forgo though 20 on the download. But perhaps better check with the ISP.

Probably Supervectoring is not very propagated (yet) and only a few DSL modems feature support for it.


#8

Some Updates to my Tests with the ALLNET SFP Module:

Unfortunately I had to go back to my external Draytek Vigor130 for VDSL Modem duties for the time being, since the ALLNET module loses DSL Sync every 30 minutes to 2 hours and has to resynchronize (which means the Internet drops out for 2-3 minutes).
With the Draytek I didn’t have a single occurance where the DSL-Sync was lost since I use it (about 8 Months) so I don’t think its a problem with the DSL-Line. According to the Draytek my Line is using Profile 17a which should be supported by the ALLNET Module.
Since I also need my Internet for Work, loosing connection so often is not an option, and I’ll have to go back to the external Modem for now…


#9

@seiichiro0185 too bad. As aforementioned this end it is VDSL2 ITU G.993.2 profile 17a and thus far I have not experienced such behaviour, all well and stable :relieved: Also the sync process here is less than 30 seconds.

Is there anything in the logs indicating the cause of the frequent re-sync?

My ISP is rotating the ip address every 24 hours and other than that there is no interruption. In the logs it looks like this

20:17:35 info pppd[20133]: LCP terminated by peer
20:17:35 info pppd[20133]: Connect time 1470.0 minutes.
20:17:35 info pppd[20133]: Sent 61714181 bytes, received 647845074 bytes.
20:17:35 notice netifd[]: Network device ‘pppoe-SFP’ link is down
20:17:35 notice netifd[]: Interface ‘SFP’ has lost the connection
20:17:35 notice pppd[20133]: Modem hangup
20:17:35 notice pppd[20133]: Connection terminated.
20:17:35 info pppd[20133]: Sent PADT
20:17:35 info pppd[20133]: Exit.
20:17:35 notice netifd[]: Interface ‘SFP’ is now down
20:17:35 notice netifd[]: Interface ‘SFP’ is disabled
22:17:35 info kernel[]: [707228.458090] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
20:17:35 notice netifd[]: Interface ‘SFP’ is enabled
20:17:35 notice netifd[]: Interface ‘SFP’ is setting up now
20:17:35 notice netifd[]: Network device ‘eth1’ link is down
20:17:35 notice netifd[]: Interface ‘SFP’ has link connectivity loss
20:17:37 notice netifd[]: Network device ‘eth1’ link is up
20:17:37 notice netifd[]: Interface ‘SFP’ has link connectivity
20:17:37 notice netifd[]: Interface ‘SFP’ is setting up now
22:17:37 info kernel[]: [707230.460635] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
20:17:43 info dhcp_host_domain_ng.py[]: Refresh unbound leases
20:17:47 info pppd[28384]: Plugin rp-pppoe.so loaded.
20:17:47 info pppd[28384]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
20:17:47 notice pppd[28384]: pppd 2.4.7 started by root, uid 0
20:17:47 info pppd[28384]: PPP session is 32283
20:17:47 warning pppd[28384]: Connected to e0:ac:f1:65:51:b3 via interface eth1
22:17:47 info kernel[]: [707240.981651] pppoe-SFP: renamed from ppp0
20:17:47 info pppd[28384]: Using interface pppoe-SFP
20:17:47 notice pppd[28384]: Connect: pppoe-SFP <–> eth1
20:17:51 notice pppd[28384]: PAP authentication succeeded
20:17:51 notice pppd[28384]: peer from calling number E0:AC:F1:65:51:B3 authorized
20:17:51 notice pppd[28384]: local IP address
20:17:51 notice pppd[28384]: remote IP address
20:17:51 notice pppd[28384]: primary DNS address
20:17:51 notice pppd[28384]: secondary DNS address
20:17:51 notice netifd[]: Network device ‘pppoe-SFP’ link is up
20:17:51 notice netifd[]: Interface ‘SFP’ is now up


#10

Nothing significant in the logs, I just see pppd exiting, and trying to reconnect afterwards. When the Disconnect happens, the Green LED on the Module blinks slow and then faster, indicating a new Sync to the DSLAM according to the instruction sheet that came with the module.
Unfortunately there doesn’t seem to be any way to get statistics / Line Parameters from the module itself, so I have no way to verify that it connects with the correct DSL-Settings. According to the Draytek status the line looks absolutely fine (No Errors, Line Capacity of 100/40, so more than enough for my 50/10 VDSL)


#11

That is a bit difficult to troubelshoot. Maybe there is something about fault/noise tolerance in the line. Perhaps it is worth to you to contact the ALLNET support, they are usually pleasant/competent to deal with and relatively fast in responding to emails. Or you ISP support, maybe they can run some test from their end or can see what happens in their logs.


#12

It might actually be that the noise tolerance isn’t as good with the ALLNET as with the Draytek. The Draytek reports a SNR-Margin of 7dB (for up and down) which isn’t very high (or barely enough according to various sites on the Internet). Looks like the Draytek can create a stable connection with a low signal like this , while the ALLNET module can’t.
I’ll see if I can get anything from ALLNET support, but since there is no way to interact with the module settings (that I know of) I doubt they can do much about it. If I can’t find a fix for this in the next Days, I’ll return the module in time for the 14-day online return policy, since I don’t want to have it end up as a 120€ paperweight.


#13

Further Updates about my case:
I contacted Allnet Support, it seems the Firmware of my Module is not suited for my connection. According to the Line-parameters I have a VDSL-100 Capable Line (although I only have a VDSL50 Contract). According to the Allnet support staff there is an updated Firmware which should fix compatibility with my Line.
To Update the Firmware I’ll have to send the Module to Allnet (through my Seller), since there seems to be no way to do this myself. I’ll check if the online-shop I used can do this.
IIRC I got a module with version 3.4 Firmware (I’ll have to check once I find the command to get the Info again).


#14

And more Updates from ALLNET Support:
Seems like the first charge of SFP-Modules where shipped out with a Firmware which only reliably supports VDSL25/50. Since my line really is a VDSL100-Line (and the Draytek syncs at that speed too), I got the problem with the frequent loss of the sync. Now they seem to offer a free Update of the Firmware to all current owners by sending the Module to a special ALLNET address for flashing it with the VDSL100 capable firmware. All new modules going out from ALLNET will already have the new Firmware according to Support Staff.

btw. here ist the EEPROM Dump from my Module for comparison:

root@turris:~# i2cdump 5 0x50

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 41 4c 4c 4e 45 54 20 20 20 20 20 20    ....ALLNET          
20: 20 20 20 20 00 00 0f c9 41 4c 4c 34 37 38 31 20        ..??ALL4781 
30: 20 20 20 20 20 20 20 20 56 33 2e 34 00 00 00 c7            V3.4...?
40: 08 00 00 00 30 30 30 30 30 30 30 46 43 39 31 35    ?...0000000FC915
50: 37 36 33 31 31 38 30 33 32 39 30 30 00 00 00 e8    763118032900...?
60: 30 30 30 46 43 39 31 35 37 36 33 31 20 20 20 20    000FC9157631        
70: 20 20 20 20 20 20 20 20 45 44 4c 31 36 43 56 31            EDL16CV1
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

Looks like the “wrong” Version is V3.4


#15

@seiichiro0185 thanks for the feedback! The EEPROM Dump my end reads the same. Suppose I will contact their support then too, albeit my connection is stable and I do not have a standin modem available.

Edit: This line reads differently (last 2 digits) from yours, perhaps it is the serial number

60: 30 30 30 46 43 39 31 35 37 36 34 30 20 20 20 20 000FC9157640

Too bad that this would not fix the other issue for @ssdnvv with supervectoring.


#16

And another Update:
Got the upgraded module back from Allnet (which was really fast, module arrived at their office yesterday and was back at my door today). Unfortunately it didn’t help with the disconnects, if anything at all it made them worse. the i2c readout stayed the same btw, so maybe the Firmware Version is not encoded in the dump (I don’t think they just sent the module back without doing anything).
I’m in conact with Allnet Support to see if there is anything else to fix this and keep you updated.

btw. @n8v8r the part in the i2cdump that differs seems to be the MAC-Address of the Module.


#17

What is the current state of the ALL4781?

My line is connected to a Broadcom DSLAM with FW 177.191. The profile is VDSL2 17a G.Vector (ITU G.993.5) according to the Fritz!Box. According to Deutsche Telekom I can get up to 175 MBit/s which would not be supported by the ALL4781 (no SuperVectoring).

Do I understand correctly I can go up to 100/40 MBit/s with the ALL4781?
Are currently shipped versions reliable? Are there any problems on warm/cold start of the Turris Omnia like with the VX-160CE?

Are there any ways to configure DSL parameters?

Is the ALL4781 an OEM version of the MT-V5311?

@n8v8r @seiichiro0185 Is the I2C of the ALL4781 connected via SFP or is it necessary to add wiring?

@ssdnvv It seems there is a G.fast SFP from Metanoia, now


#18

The I2C is connected via SFP, no additional wiring is needed. So far there is no way (that I know of) to configure any parameters or even just show them.

100/40 MBits should be possible, but even with the special VDSL-Firmware was not at all stable on my module. IIRC my DSLAM also is Broadcom running Profile 17a. There might be possible improvements on that, since my module was one of the first, but I didn’t do any further testing after my last tests in April. Because only Allnet can flash new firmware at the moment (at least in April) I also don’t know if there are any new versions.


#19

Modem supports 100 MBits both ways.

Did not experience any issues with the modem since having posted the initial report.

AFAIK Metanoia is designing but not manufacturing but I could be wrong. Certain is that Allnet’s supply chain for this product originates in Far East.

That is a transceiver and not a (V)DSL modem.

No, but then DSL modems usually are not setting DSL parameters but accommodating parameters broadcasted by the DSLAM, or not?


#20

Config for Deutsche Telekom VDSL2 socket with VLAN7 tagging:

/etc/config/network:
config interface 'WAN'
option proto 'pppoe'
option ipv6 'auto'
option username '<Anschlusskennung><Zugangsnummer>#0001@t-online.de'
option password '<password>'
option ifname 'eth1.7'

Run once: /etc/init.d/sfpswitch enable; /etc/init.d/sfpswitch restart && /etc/init.d/network reload && echo 'Success' || echo 'Failed'