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


did you talked to the ISP to get a information why the sync is lost?



Yes. I got a call they updated software on their side and it should work now. Ticket closed but no success.


DSLmonitor Lite for ALL4781 (link is valid for 7 days). I didn’t get it working on Windoze 7 and 10, maybe you have more luck.


what is the source of the app, looks like chinese?


I got the link from Gerhard Zerwes (ALLNET product owner) with the permission to publish here.


Assuming that the device MAC is the one of the Allnet SFP and thus inquired its mac via i2cdump 5 0x50 - line 60 (as mentioned previously in this thread).

And then set the local mac and the module mac accordingly


but ending up with



How did you register DSLAK.dll? Which Windows version are you using?


W10 Pro _x64 v1809 b17763.194

There was a cmd window when running DSLmonitor.exe for the first time and indicating that the dll files been registered.

The previous error might been caused by having had the archive unpacked to desktop which is is tightly protected. Now from a less restrictive location it seems to have advanced


Maybe firewall issue somewhere


@renne Did you notice from the monitor manual?


Yes, I bridged eth1 with eth0 and I use brlan.7 for PPPoE. I never got that far because DSLAK.dll is not registered.


W Defender had no qualms with those dlls. Do you deploy other defensive apps that could somehow took a dislike to the dlls?


I just installed Windows 7 Pro 64-bit in Virtualbox. Did you use Windows 7 Pro 32-bit?

Same Problem:

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.DllNotFoundException: Unable to load DLL 'DSLAK.dll': Das angegebene Modul wurde nicht gefunden. (Exception from HRESULT: 0x8007007E)
   at DslMonitor.Program.SetUSBSerialNumber(String strUsbSerial)
   at DslMonitor.DSLmonitor.Connect_pic_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
    Assembly Version:
    Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
    Assembly Version:
    Win32 Version:
    CodeBase: file:///C:/Users/Tester/Downloads/wetransfer-709333/DSLmonitor_Lite_v0.10.7.A_20180813/DSLmonitor_Lite_v0.10.7.A_20180813/DSLmonitor.exe
    Assembly Version:
    Win32 Version: 10.0.30319.1 built by: RTMRel
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
    Assembly Version:
    Win32 Version: 4.0.30319.1 built by: RTMRel
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
    Assembly Version:
    Win32 Version: 4.0.30319.1 built by: RTMRel
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
    Assembly Version:
    Win32 Version: 4.0.30319.1 built by: RTMRel
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the section.
The application must also be compiled with debugging

For example:

    < jitDebugging="true" />

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


I reckon you can stop you efforts anyway. Whilst a packet capture on the machine running the monitor app reveals that the connection attempt is made

and thus indicating the app working it occurred to me that the TO is not aware of the modem’s mac. Thus it would be logical that the router does not know where to route those packets to.

just run from cli ip n and the modem is not present. Or ip l and the pppoe-wan is void of a mac. Or even LuCI

Seems like a caveat of the SFP driver.

Now I even tried USB-UART but reckon that is not the USB meant for the app since it did not work either.

This is really too bad that such tool to interact and diagnose the modem with is not working on the TO. :slightly_frowning_face:
I would have liked to test the different firmwares though it seems neither has yet 35b Supervectoring implemented.


Tried to expose/associate the modem’s mac via


config device
	option name 'pppoe-wan'
	option mac '00:0F:C9:15:76:40'

config interface 'wan'
	option mac '00:0F:C9:15:76:40'

But neither did succeed. :slightly_frowning_face:


@miska @Pepe

Can you comment on this?


Shouldn’t the MAC-Address be on the eth1 interface and not on the pppoe-wan interface (which is a “virtual” device created by the pppd)? I’ll also try to get the Software to run once I get home this evening.


the modem is not a virtual device but a hardware device similar to eth. eth1 cannot be pppoe-wan as it lacks modem capabilities and pppoe-wan is not linked with eth1 but the modem. That would be my understanding.


Well at least for my external modem I also only have the MAC of the Ethernet (eth1) interface, and the PPPD uses the PPPOE-Protokoll to talk to the modem via Ethernet. (there only is a normal ethernet Link between the Modem and the Turris in this case). As far as I remember from my test the ALLNET behaves in the same way, so the Ethernet interface eth1 represents the Modem, and pppd talks over this ethernet interface with it to create the pppoe-wan interface. So if the MAC of the ALLNET is available on the Turris anywhere it should be the eth1 interface.


Looking at the TO schematics you are right apparently with eth1 wired to WAN or SFP. Suppose the eth1 mac is hard coded and thus cannot be manipulated.

Probably when the TO device been developed such DSL-SFP modem was not considered. It would be lovely though if there was an option to be able to communicate with such device as other switch devices do.


Actually eth1 mac is not hard coded and can be manipulated

ifconfig eth1 | grep HWaddr

eth1 Link encap:Ethernet HWaddr D8:58:D7:00:87:4C

ifconfig eth1 down
ifconfig eth1 hw ether 00:0F:C9:15:76:40
ifconfig eth1 up
/etc/init.d/network restart
ifconfig eth1 | grep HWaddr

eth1 Link encap:Ethernet HWaddr 00:0F:C9:15:76:40

ip n or arp -a don’t show eth1 however, not sure if that matters, however the packets sent from the monitor app still do not get response. Likely the pppd/pppoe stack does not know what to do with it or simply does not expect packets from the lan side.