did you talked to the ISP to get a information why the sync is lost?
regards
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.
1 Like
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 **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
DSLmonitor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Tester/Downloads/wetransfer-709333/DSLmonitor_Lite_v0.10.7.A_20180813/DSLmonitor_Lite_v0.10.7.A_20180813/DSLmonitor.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 10.0.0.0
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
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
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
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
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
----------------------------------------
System
Assembly Version: 4.0.0.0
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 system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
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. 
I would have liked to test the different firmwares though it seems neither has yet 35b Supervectoring implemented.
1 Like
Tried to expose/associate the modemâs mac via
â/etc/config/networkâ
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. 
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.
1 Like
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.
1 Like
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.