You would have to compare the ISP’s line specifications versus the modem’s specification.
According to Guarantees, cancelling and returning your purchases - Your Europe
If you bought a product or a service online or outside of a shop (by telephone, mail order, from a door-to-door salesperson), you also have the right to cancel and return your order within 14 days, for any reason and without a justification.
There is now the ALL4783-g.fast-SFP
that
Supports G.fast standard ITU-T G.994.1, G.9700, G.9701
but most unfortunately is
not backward compatible to VDSL
Thank you for you post, the Name of the product seems to be a bit fuzzy. When searching for this g.fast SFP I could only find the 4781 SFPs as a g.fast version, at first.
In the English-Language shop of allnet this device is titled as a 4781 as well (https://shop.allnet.de/detail/index/sArticle/315567) in the German language shop it is a 4783.
There are two different devices:
Part No.: 141114
Vendor Part No.: ALL4781-VDSL2-SFP
Titled: ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2
Part No.: 180606
Vendor Part No.: ALL4783-g.fast-SFP
Titled: ALLNET g.fast Bridge SFP Modem ALL4781 SFP(Mini-GBIC), VDSL2
Whist the module performs on my IPS’s subscriber line generally stable after the switch from TOS3.x to TOS4.x I noticed intermittent hiccups manifested in the logs
sfp: module transmit fault indicated
sfp: module transmit fault recovered
and sometimes also
sfp: module persistently indicates fault, disabling
Those messages are generated by SFP.C [1] (not available in TOS3.x with kernel 4.9.x) and are pertinent to the check routines implemented for state machine:
with
sfp: module transmit fault indicated
relating to the signal status of TX_FAULT (tx-fault in hi IRQ)
SFP.C tries to clear (recover) the fault fives times in total, pausing one second between each attempt and if successful (tx-fault in lo IRQ) prints
sfp: module transmit fault recovered
If the five attempts are however exhausted it prints
sfp: module persistently indicates fault, disabling
and as a result there is no WAN connectivity. Signal status detection is only attempted again if the interface is being restarted, else the link will remain a down state.
It is not clear why the module most of the times passes the check but other times intermittently fails. Potential reasons could be:
[1] linux/drivers/net/phy/sfp.c at master · torvalds/linux · GitHub
can i get a new link on you version DSLmonitor Lite ?
I have DSLmanager_Lite v0.0.9_Proscend_20180305 - it can be useful to someone too
@anon50890781 Do you have a solution for this problem? I encounter the same issue which leads to multiple reconnects a day. I’m using a new ALL4781-VDSL2-SFP module with the CZ11NIC13 on TurrisOS 5.1.4.
Is ALL4781-VDSL2-SFP working with TOS 5.3? Has anyone tried it on TOS 6?
I read the whole thread now and don’t see a solution for my 15min - 4h DSL sync drops. So no chance to get it working? I’m on ISP O2 Germany 50Mbit line.
Hi DocMAX, i just bought an ALLNET ALL4781-VDSL2-SFP modul for my Turris Omnia such that I could ditch my o2 homebox. Unfortunately I am not able to get the O2 DSL connection working. These are my current network settings:
config interface 'wan'
option proto 'pppoe'
option username 'DSL000XXXXXXXX@s93.bbi-o2.de'
option password 'XXXXXX'
option ipv6 'auto'
option device 'eth0.7'
The error message that i get on the Luci interfaces page is: Error: Connection attempt failed
Could you perhaps share your network settings?
Did you set the 7 vlan tag to device/ eth0? o2 does not mention this in the manuals i have found.
Which software version are you running?
Thanks!
No, VLAN tag has to go to eth2. So it’s eth2.7.
But since nobody helped me with my unstable connection i send this garbage all back and got a FritzBox 7530 with OpenWrt. MUCH better and CHEAPER. Only 75€ in used market. My line is now rocket stable and fast. Replaced my old BT HomeHub 5.
My support ticket from 10.1.23 at ALLNET is still unassigned and untouched.
Thanks for the quick reply! I changed my settings from
option device 'eth0.7'
to
option device 'eth2.7'
and now I am able to connect 
. I will check if my signal drops. How long where your down times? I am on a naked openwrt 22.03 install, maybe your issue has been fixed in this version?
I would add though, that this must mostly be a critique on the Allnet SFP-module, there is little evidence that the Turris Omnia was at fault. Making this explicit seems like a polite gesture, given that this is the Turris forum, no?
Ouch, I see 7520*s on Ebay going for ~40EUR, with 7520 and 7530 hardware being mostly identical, that is an opportunity to save a few more EUR. (The 7520 is a model mostly sold/rented out by German ISP 1&1, so there is quite some second-hand market for those as it is/was non-trivial to book their products without the modem-router; to justify the lower price the 7520 offers less features under FritzOS than the 7530, but IIRC these differences are software not hardware based so under OpenWrt the two boxes should be essentially identical in features/performance).
*) There are apparently at least two versions of the 7520, only the “older” design with the two small “winglet” WiFi antennas is supported, the type B with stick-type antennas seems to use a non-lantig/maxlinear DSL SoC and is not supported.
Critique goes only out to ALLNET. The Turris Omnia overall was ok. Maybe a bit too expensive. I expected more Antenna quality. But i had the same (bad) quality like all other Router WITHOUT antennas.
No WiFI router is “WITHOUT antennas” they are just more or less visible*… in an omnia you could actually disconnect the antennas to see how bad things can get “without antennas”.
I do not want to diminish your experience or report thereof, but what made you believe that the omnia would offer superior WiFi quality? And how did you measure quality (which radio, which band and importantly at what distances to the router?, throughput, latency, or both)
*) Ranging from fully internal antennas on the main PCB, to small winglet antennas in e.g. some fritxbox routers, or visible “stick” antennas like on the omnia.
Yepp, the omnias are not cheap and for the same amount of money one can get a seriously more performant x86 based wired-only router; but that would be without WiFi, and IMHO more importantly without all the turris specific features like automatic updates (from a source I happen to trust). Yes these are subjective assessments, and just because I appreciate and value automatic updates does not mean anybody has to do so as well, but IMHO the turris routers offer something more for the money than the pure hardware (and that can or can not be worth the extra cost depending on one’s preferences).
Of course i know that all routers have antennas. But i assume those are much smaller than the big ones we have outside the Omnia.
I measued the quality simply comparing my Wifi Symbol which has 5 bars. (Maybe not very professional but it does the job)
Yes, not very scientific or reproducible for outside parties, but then I am fine with the WuiFi performance of my omnia being pretty much the same as my older wnder3700v2 (except that the omnia’s 5GHz radio allows higher/faster modulation schemes and wider ‘channels’, resulting generally in more throughput even at similar signal strength).
Coming back to the reliability. I have logging activated on my turris omnia, I push all netdata metrics to an influx database and visualize it using grafana. I am checking my Turris logs as we speak, I noticed multiple drop outs today:
The ping plot indicates how long it take to ping googles dns server 8.8.8.8. More information soon, I will check my systemlog.
Update from my side: I have updated my Turris Omnia to a naked version of OpenWRT 23.05. I was hoping that a newer kernel version would fix the VDSL stability issues I mentioned before. However, this is not the case I still have multiple interrupts each hour.
@anon50890781 could you please specify the log file where you found the “sfp: module transmit fault indicated” message? I want to understand if i am facing DSL interrupts or SFP module disconnects.
Thanks!
Hi @andre
I Tried to adapt your settings such that I can read out my SFP modem on openwrt 23.05. The switch and vlan settings changed in LuCi so I tried to replicate your settings into the new interface.
I created a new device (Network->Interfaces-> Devices) that bridges eth2 and lan3. My windows box running DSLmonitor is connected to lan3 (port number 4). Screenshot of the settings can be found here:
and
Unfortunately reading out the SFP modem does not work. The DSLMonitor application crashes once I click OK after entering the MAC adresses in the port settings window. This behavior does not change when running the app as administrator.
I contacted the allnet support for further instructions, unfortunately they did not really help me. They only provided a newer version of the DSLmonitor application which goes by version index: v0.10.7.A
Do you know how I should change the settings such that I can access my SFP modem logs? I want to figure out if my DSL connection dies OR the modem crashes during my internet hiccups.
Thanks!!
BTW @anon50890781 I reported your detailed observations to gitlab, hoping the turris omnia team could look deeper into it. SFP module unstable after TOS4 - VDSL Modem (#200) · Issues · Turris / user-docs · GitLab
J
