did you talked to the ISP to get a information why the sync is lost?
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
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?
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: 220.127.116.11 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll ---------------------------------------- DSLmonitor Assembly Version: 18.104.22.168 Win32 Version: 22.214.171.124 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: 126.96.36.199 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_188.8.131.52__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 184.108.40.206 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_220.127.116.11__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System Assembly Version: 18.104.22.168 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_22.214.171.124__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.
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.
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.