Closed WheezyE closed 2 years ago
madewokherd
commented
3 years ago It sounds a bit too involved for me to want to try.
Does the program display any error messages relating to the commands? You can also try getting a log with WINE_MONO_TRACE=x which will print out any exceptions as they occur.
WheezyE
commented
3 years ago Thanks for the WINE_MONO_TRACE=x command.
Here are some terminal outputs with mono_trace enabled with mono installed in a fresh wineprefix
Everything behaves normally with dotnet35sp1 installed in wine (though box86 can't get dotnet35sp1 working in wine on Raspberry Pi at the moment, so mono would be a great option to use instead)
WheezyE
commented
3 years ago dotnet35sp1 - 01 - RMS Express's TCP/IP modem communication setup window
dotnet35sp1 - 02 - ARDOP Modem has connected to RMS Express over TCP/IP
dotnet35sp1 - 03 - RMS Express successfully controls ARDOP Modem over TCP/IP
mono - 01 - Modem does not launch automatically
mono - 02 - RMS Express not connecting to manually launched ARDOP
WheezyE
commented
3 years ago Sorry to spam: I should also mention that RMS Express needs a callsign and login to get running. I can email you my login if you were interested in installing/playing with it. Just lmk. And thank you again
madewokherd
commented
3 years ago I'd check on the NotImplementedException first, try WINE_MONO_TRACE=E:System.NotImplementedException MONO_INLINELIMIT=0
WheezyE
commented
3 years ago Thanks for more tips here!
I ran those flags before wine RMS\ Express.exe and got this output in the terminal when I tried to run ARDOP TNC (the ardop modem).
I'm kind of surprised by the visual basic errors. I've often run winetricks -q vb6run pdh_nt4 win7 sound=alsa in the past for another modem called VARA whenever RMS Express was installed.
madewokherd
commented
3 years ago Well, implementing Interaction.Shell should be pretty simple, I'll try that and get back to you when there's a build you can try.
madewokherd
commented
3 years ago vb6run wouldn't have any effect on this, these are VB.NET libraries, not VB6.
WheezyE
commented
3 years ago Awesome! I really really appreciate you giving it a shot.
I was just about to post this log too of the ARDOP_Win.exe errors in case they help when I saw your replies. But yeah let's try one error at a time.
I also ran WINE_MONO_TRACE=E:System.ArgumentException MONO_INLINELIMIT=0 wine ARDOP_Win.exe and got this Trace of System.ArgumentException: 'CP1252' is not a supported encoding name for ARDOP_Win.exe in case that helps.
madewokherd
commented
3 years ago Interaction.Shell turned out to be in winforms so I made a PR to import it along with some other methods: https://github.com/madewokherd/wine-mono/pull/117
WheezyE
commented
3 years ago Sick! Thank you again for looking into this and for your work on it
madewokherd
commented
3 years ago The CI process for that PR finished and passed the tests, so I merged it. It also produced a build you can test. https://github.com/madewokherd/wine-mono/actions/runs/1214173669
WheezyE
commented
3 years ago Thank you very much for the link to the binary. I wasn't sure if I was building mono correctly with git cherry-pick fa2dd85e7765156ca6c93f15bfb04081864f9b82 && git submodule update --recursive && make msi using the PR commit before it was merged and the link to the pre-built msi gave me a lot of peace of mind. I thought my wine version was out of date for the build or something.
Also nice job! RMS Express opens ARDOP now on its own. That crash is fixed, but I then still run into the TCP/IP connection issues.
(don't worry about "codec failed to start" - that happens any time there's no active TCP/IP connection.
madewokherd
commented
3 years ago Does it normally communicate through TCP?
Does the listening socket show up in netstat -l?
WheezyE
commented
3 years ago Sorry for these slow replies. And thank you again for the help!
Yeah, RMS Express (the radio "email-like" client program) and its modems ("TNC's", like ARDOP, VARA, WINMOR, etc) communicate with each other via TCP.
RMS Express and its modems listen/talk on 127.0.0.1 (localhost), port 8200, by default. I'm running wine-devel 6.16 ~buster-1 on a Debian 9 VMWare install on my Windows laptop.
Note sure if this matters, but I recently upgraded wine from 5.21-devel to 6.16-devel to test this mono build since I thought maybe the latest mono needed the latest wine. Also, this sounds kind of funny, but I haven't been able to test dotnet35sp1 with wine 6.16 yet since I'm working on my laptop remotely via my phone and the keyboard doesn't let me up/down or tab - but I'm really eager to see if the TCP issue might be an issue in the latest wine? My Raspberry Pi (running box86) did crash with this newest mono running wine-devel 5.21 (hasn't crashed with older mono's), but that's with the added layers of box86 emulation and older wine with new mono.
Sorry for all these caveats. I'll try to give you something more definative about whether this is just a wine 6.16 issue as soon as I can
WheezyE
commented
3 years ago I was able to confirm that wine-devel 6.16 with dotnet35sp1 installed (winetricks --force dotnet35sp1) still runs RMS Express and ARDOP with TCP connections. I also found that port 8201 is also involved. So I can confirm that it's a bug in mono.
This is with dotnet35sp1 in wine-devel 6.16
madewokherd
commented
2 years ago OK, so the problem is server-side, and the "connection refused" errors are because the listening socket isn't opened.
madewokherd
commented
2 years ago [00000024:] EXCEPTION handling: nsoftware.IPWorks.IPWorksIpinfoException: The AdapterCount property is not available in Mono.Seems like they're testing for Mono specifically. I was able to get a copy of this library from nuget, and they are looking for the Mono.Runtime type.
We could try to rename this type, but the last time I tried something similar (with System.MonoType), it caused regressions because of code that had detected Mono and worked correctly.
Maybe an envvar to "hide" those types could work, and then we could work on fixing the known bugs before flipping the default and eventually remove them. I'm also expecting it to encounter some unimplemented methods if we do that.
WheezyE
commented
2 years ago I may not even be understanding the problem you identified quite right, but would this be something that could be fixed by the authors of RMS Express? I think they might be amenable to catering to wine-mono if it would just be a small string renaming fix on their end.
This software is a bit odd: RMS Express.exe and ARDOP_Win.exe don't connect to an internet server (well, just for software updates but those are working with mono), they just talk to each other over TCP while both running on the same PC. The software is intended for use in disaster environments where there is no internet
madewokherd
commented
2 years ago I think nsoftware.IPWorks is a third-party library: https://www.nuget.org/packages/nsoftware.IPWorks/
So maybe it could be fixed by that library's devs, or maybe RMS would have to handle that exception and have a fallback. It's hard to say because I don't know exactly how they're using the library and what they need from it.
WheezyE
commented
2 years ago Ah, I think I see now. Thank you for explaining all that.
Maybe an envvar would be good for now to test mono with RMS Express and find any other unimplemented functions that might crop up? Then if the functions that nuget were worried about are implementable, I could email the IP Works authors to tell them that they don’t have to block mono for that unimplemented function(?) anymore? That way they could test it and see themselves that it works now and remove the check so mono users don’t have to invoke any envvars for RMS Express.
I super super super appreciate all of your help! Is there some way to donate to you or wine-mono or anything? I don’t expect any particular outcome - I just am really grateful for all the help this far
madewokherd
commented
2 years ago Maybe an envvar would be good for now to test mono with RMS Express and find any other unimplemented functions that might crop up? Then if the functions that nuget were worried about are implementable, I could email the IP Works authors to tell them that they don’t have to block mono for that unimplemented function(?) anymore? That way they could test it and see themselves that it works now and remove the check so mono users don’t have to invoke any envvars for RMS Express.
Well, maybe. Getting bugs fixed in upstream Mono is more difficult because they support more platforms than just Windows (with wine-mono we can usually just use the Windows API and let Wine do the rest), and because they are very slow to review patches. I've pretty much given up on getting things fixed there.
I'm guessing IPWorks needs this, which is unimplemented in Mono and would have to be platform-specific: https://docs.microsoft.com/en-us/dotnet/api/system.net.networkinformation.networkinterface?view=netframework-4.7.2
My suggestion for them would be to try the things they need and catch the NotImplementedException, then it can work if the implementation is there.
I super super super appreciate all of your help! Is there some way to donate to you or wine-mono or anything? I don’t expect any particular outcome - I just am really grateful for all the help this far
Well, the Wine project has a fund set up through Software Freedom Conservancy: https://www.winehq.org/donate
I work for CodeWeavers, which also employs Wine's maintainer, and many other Wine devs, so buying CrossOver (https://www.codeweavers.com/crossover) also helps.
WheezyE
commented
2 years ago I'm guessing IPWorks needs this, which is unimplemented in Mono and would have to be platform-specific: https://docs.microsoft.com/en-us/dotnet/api/system.net.networkinformation.networkinterface?view=netframework-4.7.2
I emailed nuget and they forwarded my email to /n software. One of the /n software devs was really awesome and got back to me today with more info - And it seems you were spot-on: They say that the class throwing the exception is called "IPInfo" and it uses low-level calls specific to Windows, which is why they are not available in mono. They also said that if RMS Express wants to support non-Windows platforms they might need a different approach to detecting available network adapters (or whatever functionality IPInfo is used for) than using IPInfo. They also offered support if the RMS Express dev wanted to reach out about IPInfo with figuring out another way to accomplish whatever RMS Express tries to do with IPInfo.
My suggestion for them would be to try the things they need and catch the NotImplementedException, then it can work if the implementation is there.
I signed up for the Winlink forum yesterday where I might be able to get in touch with the RMS Express devs and am awaiting approval. I'll try to see if they'd be interested in giving a backup or bypass method a shot for wine-mono compatibility.
Well, the Wine project has a fund set up through Software Freedom Conservancy: https://www.winehq.org/donate
I work for CodeWeavers, which also employs Wine's maintainer, and many other Wine devs, so buying CrossOver (https://www.codeweavers.com/crossover) also helps.
Done and done. I signed up for a 12 mo Linux license just now and also just gave winehq a tip. I hope some of that finds its way back to you. You are incredible. Thank you for all your help getting me to this point. I'll try to keep you in the loop about what ideas the Winlink team might have.
madewokherd
commented
2 years ago I emailed nuget and they forwarded my email to /n software. One of the /n software devs was really awesome and got back to me today with more info - And it seems you were spot-on: They say that the class throwing the exception is called "IPInfo" and it uses low-level calls specific to Windows, which is why they are not available in mono. They also said that if RMS Express wants to support non-Windows platforms they might need a different approach to detecting available network adapters (or whatever functionality IPInfo is used for) than using IPInfo. They also offered support if the RMS Express dev wanted to reach out about IPInfo with figuring out another way to accomplish whatever RMS Express tries to do with IPInfo.
Whatever they are doing on Windows "should" work the same in Wine (and possibly even Mono on Windows), with the caveat that Wine may have bugs and unimplemented features. If they are accessing .NET Framework internals using reflection, that also may not work (but there's a lot of code sharing with parts of .NET that have been open-sourced so it's not impossible).
To be fair, we really should remove Mono.Runtime so they don't detect Mono and don't have to change anything, it's just going to take time to make that the default because of the risk of regressions.
Done and done. I signed up for a 12 mo Linux license just now and also just gave winehq a tip. I hope some of that finds its way back to you. You are incredible. Thank you for all your help getting me to this point. I'll try to keep you in the loop about what ideas the Winlink team might have.
Much appreciated.
It may take me some time to get that envvar setting implemented because it's non-trivial and some other things have come up.
WheezyE
commented
2 years ago Whatever they are doing on Windows "should" work the same in Wine (and possibly even Mono on Windows), with the caveat that Wine may have bugs and unimplemented features. If they are accessing .NET Framework internals using reflection, that also may not work (but there's a lot of code sharing with parts of .NET that have been open-sourced so it's not impossible).
Hm, yeah. Maybe they misunderstood that wine-mono was different than mono.
To be fair, we really should remove Mono.Runtime so they don't detect Mono and don't have to change anything, it's just going to take time to make that the default because of the risk of regressions.
It may take me some time to get that envvar setting implemented because it's non-trivial and some other things have come up.
No worries at all on the timeframe. You've already done a lot. I would love to see where dodging that mono type detection with an envvar could get us, but I also don't want to cause regressions for you folks.
In the meantime, I'll try to see if I can reach out to the RMS Express devs to see if IPInfo isn't super critical and if they can dodge/workaround IPInfo's mono-type-detection exception. Maybe, like you said, RMS Express could catch that IPInfo exception, and just have RMS Express try using a less-robust/secondary/fallback method for those cases.
madewokherd
commented
2 years ago I've opened https://github.com/madewokherd/mono/pull/13 which will allow for hiding these types using WINE_MONO_HIDETYPES=1.
I expect you'll get a NotImplementedException with this set.
WheezyE
commented
2 years ago Thank you 🙂 I’ll try to build this tonight (or maybe wait for the CI build) and look for exceptions ASAP
I posted a message to the Winlink forum last week and somebody said they would forward the info to the RMS Express dev but I haven’t heard anything back yet.
WheezyE
commented
2 years ago Alright, using the latest Winlink 1.5.39.0 (released some time before Jul 26, 2021), I ran WINE_MONO_HIDETYPES=0 and WINE_MONO_HIDETYPES=1 and ran a text compare on both terminal outputs. There seems to be a difference around line 427 between the two logs:
[00000124:] EXCEPTION handling: System.Security.Cryptography.CryptographicException: Missing private key
0024:fixme:uiautomation:UiaClientsAreListening ()
0024:fixme:uiautomation:UiaClientsAreListening ()
0024:fixme:uiautomation:UiaClientsAreListening ()
[00000024:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load file or assembly 'C:\RMS Express\en-US\RMS Express.resources.dll' or one of its dependencies.
[00000024:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load file or assembly 'C:\RMS Express\en\RMS Express.resources.dll' or one of its dependencies.
0110:fixme:ntdll:EtwEventRegister ({c651f5f6-1c0d-492e-8ae1-b4efd7c9d503}, 0BEF1EE0, 00000000, 01095C00) stub.
[00000024:] EXCEPTION handling: ipw90S.No: Adapter index out of range.
[00000024:] EXCEPTION handling: nsoftware.IPWorks.IPWorksIpinfoException: The AdapterCount property is not available in Mono.
0024:fixme:server:invoke_system_apc syscall frame changed in APC function, frame (nil), saved_frame 0x21eb14.
[00000124:] EXCEPTION handling: System.Security.Cryptography.CryptographicException: `MonoBtlsPkcs12.Import` failed.becomes
[00000130:] EXCEPTION handling: System.Security.Cryptography.CryptographicException: Missing private key
0110:fixme:ntdll:EtwEventRegister ({c651f5f6-1c0d-492e-8ae1-b4efd7c9d503}, 0BEF1CB8, 00000000, 0132B840) stub.
0024:fixme:uiautomation:UiaClientsAreListening ()
0024:fixme:uiautomation:UiaClientsAreListening ()
0024:fixme:uiautomation:UiaClientsAreListening ()
[00000024:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load file or assembly 'C:\RMS Express\en-US\RMS Express.resources.dll' or one of its dependencies.
[00000024:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load file or assembly 'C:\RMS Express\en\RMS Express.resources.dll' or one of its dependencies.
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
0024:fixme:server:invoke_system_apc syscall frame changed in APC function, frame (nil), saved_frame 0x21eb14.
[00000120:] EXCEPTION handling: System.Security.Cryptography.CryptographicException: `MonoBtlsPkcs12.Import` failed.
EDIT: The nsoftware devs did suggest that (even though they weren't sure what RMS Express / Winlink was using IPInfo for either) IPInfo might be being used to detect available network adapters.
madewokherd
commented
2 years ago Great, let's find out where that NullReferenceException is coming from. I'd do it in a similar way to the NotImplementedException earlier, with MONO_INLINELIMIT so we know we get the full stacktrace. WINE_MONO_TRACE=E:System.NullReferenceException MONO_INLINELIMIT=0
WheezyE
commented
2 years ago Oh right, that makes sense. Thank you. Ok here's what we get on the only instance of System.NullReferenceException:
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
"<unnamed thread>" tid=00000024 this=02590120 , thread handle : 00a44ac8, state : not waiting
at ipw90q.xK.x (ipw90q.Y) [0x0042c] in <148389691d344cc193ab7167a5da4a62>:0
at ipw90q.xK.n (object) [0x00031] in <148389691d344cc193ab7167a5da4a62>:0
at ipw90q.xB.K (System.Collections.IList,bool) [0x00030] in <148389691d344cc193ab7167a5da4a62>:0
at nsoftware.Sys.Internal.Public.SystemIPHlpAPI.GetAdapterInfo (System.Collections.IList,bool) [0x00001] in <148389691d344cc193ab7167a5da4a62>:0
at ipw90S.gB.rQ () [0x00035] in <dd7189f274524ed8aefc7e991a12cbaa>:0
at ipw90S.gB.ro () [0x0002d] in <dd7189f274524ed8aefc7e991a12cbaa>:0
at ipw90S.gB..ctor (object,object) [0x00116] in <dd7189f274524ed8aefc7e991a12cbaa>:0
at nsoftware.IPWorks.Ipinfo..ctor (System.ComponentModel.IContainer,string) [0x0002d] in <dd7189f274524ed8aefc7e991a12cbaa>:0
at nsoftware.IPWorks.Ipinfo..ctor () [0x00000] in <dd7189f274524ed8aefc7e991a12cbaa>:0
at (wrapper remoting-invoke-with-check) nsoftware.IPWorks.Ipinfo..ctor () [0x00018] in <dd7189f274524ed8aefc7e991a12cbaa>:0
at RMS_Express.Globals.InitializeLocalIPAddresses () [0x00000] in <b8af23dd533f41859858880df1e258ee>:0
at RMS_Express.Main.tmrStart_Tick (object,System.EventArgs) [0x00032] in <b8af23dd533f41859858880df1e258ee>:0
at System.Windows.Forms.Timer.OnTick (System.EventArgs) [0x0000a] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Timer/TimerNativeWindow.WndProc (System.Windows.Forms.Message&) [0x0002c] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067>
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW (System.Windows.Forms.NativeMethods/MSG&) <0x00012>
at System.Windows.Forms.Application/ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop (intptr,int,int) [0x001d7] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Application/ThreadContext.RunMessageLoopInner (int,System.Windows.Forms.ApplicationContext) [0x00282] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x0001a] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x00033] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) [0x00006] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun () [0x00044] in <8c0c33d4b0a44b0f95f6eef6a363f124>:0
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel () [0x00035] in <8c0c33d4b0a44b0f95f6eef6a363f124>:0
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run (string[]) [0x0001b] in <8c0c33d4b0a44b0f95f6eef6a363f124>:0
at RMS_Express.My.MyApplication.Main (string[]) [0x0000f] in <b8af23dd533f41859858880df1e258ee>:0
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00027] in <b8af23dd533f41859858880df1e258ee>:0
0024:fixme:server:invoke_system_apc syscall frame changed in APC function, frame (nil), saved_frame 0x21eb84.Maybe hanging on more VisualBasic winforms functions? EDIT: Or maybe nsoftware.Sys.Internal.Public.SystemIPHlpAPI.GetAdapterInfo returning with an error?
madewokherd
commented
2 years ago I tried messing around with this library, and I got the same exception about mono not being supported when trying to access Ipinfo.AdapterCount. When I set WINE_MONO_HIDETYPES=1, it actually worked and I was able to get information from it.
So it seems like whatever's going wrong is specific to either the context of RMS Express or your network setup somehow.
Based on an iphlpapi log it does call GetAdaptersAddresses, and I think the code that's crashing is trying to read the IP_ADAPTER_ADDRESSES_LH structure. There must be a null pointer in there somewhere that it tries to access.
madewokherd
commented
2 years ago If you can get a log with WINE_MONO_TRACE=N:ipw90q, it'll probably show a method returning null before the exception. I think knowing what that method is will provide a hint that could be used to track this down.
WheezyE
commented
2 years ago Thanks again for looking into this. My setup is Debian 10 (x86) on a VMWare virtual machine (but that setup works with RMS Express when using dotnet35sp1). I tested this out on my Pi4 setup (running box86 and wine + wine-mono 6.4.99) and got the same error though. (The Pi4+box86+wine has trouble installing/running dotnet35sp1 in newer versions of box86 though and we haven't located that bug for the past year. The length of the dotnet35sp1 install on Termux+box86 makes Android devices time-out too).
I'm not sure if I'm searching correctly, but using that trace (and hiding wine-mono), I can't find anything returning "null" before the exception, though there are a few OBJECT:00000000 and =0x's that pop up.
Here's maybe a relevant section.
[00000024: 0.10907 4] LEAVE:c ipw90q.M:K (intptr)([ipw90q.I:0113bd00]
[00000024: 0.10908 3] LEAVE:c ipw90q.I:n ()([ipw90q.I:0113bd00]
[00000024: 0.10910 3] ENTER:c ipw90q.I:x ()(this:0113bd00[ipw90q.I RMS Express.exe])
[00000024: 0.10911 4] ENTER:c ipw90q.M:p (int)(this:0113bd00[ipw90q.I RMS Express.exe], 12)
[00000024: 0.10913 4] LEAVE:c ipw90q.M:p (int)([System.Net.IPAddress:0113bd38]
[00000024: 0.10915 3] LEAVE:c ipw90q.I:x ()([System.Net.IPAddress:0113bd38]
[00000024: 0.10916 3] ENTER:c ipw90q.I:x ()(this:0113bd00[ipw90q.I RMS Express.exe])
[00000024: 0.10918 4] ENTER:c ipw90q.M:p (int)(this:0113bd00[ipw90q.I RMS Express.exe], 12)
[00000024: 0.10920 4] LEAVE:c ipw90q.M:p (int)([System.Net.IPAddress:0113bd90]
[00000024: 0.10921 3] LEAVE:c ipw90q.I:x ()([System.Net.IPAddress:0113bd90]
[00000024: 0.10924 3] ENTER:c ipw90q.I:n ()(this:0113bd00[ipw90q.I RMS Express.exe])
[00000024: 0.10926 4] ENTER:c ipw90q.M:K (intptr)(this:0113bd00[ipw90q.I RMS Express.exe], 00000000)
[00000024: 0.10928 4] LEAVE:c ipw90q.M:K (intptr)([OBJECT:00000000]
[00000024: 0.10929 3] LEAVE:c ipw90q.I:n ()([OBJECT:00000000]
[00000024: 0.10931 3] ENTER:c ipw90q.Y:k ()(this:0113a560[ipw90q.Y RMS Express.exe])
[00000024: 0.10932 3] LEAVE:c ipw90q.Y:k ()(result=384
[00000024: 0.10934 3] ENTER:c ipw90q.Y:d ()(this:0113a560[ipw90q.Y RMS Express.exe])
[00000024: 0.10936 4] ENTER:c ipw90q.M:L (intptr)(this:0113a560[ipw90q.Y RMS Express.exe], 0029ef76)
[00000024: 0.10993 5] ENTER:c ipw90q.G:.cctor ()()
[00000024: 0.11005 5] LEAVE:c ipw90q.G:.cctor ()(
[00000024: 0.11021 5] ENTER:c ipw90q.G:.ctor (bool,intptr)(this:0113be08[ipw90q.G RMS Express.exe], 0, 0029ef76)
[00000024: 0.11033 6] ENTER:c ipw90q.M:.ctor (bool,intptr)(this:0113be08[ipw90q.G RMS Express.exe], 0, 0029ef76)
[00000024: 0.11043 6] LEAVE:c ipw90q.M:.ctor (bool,intptr)(
[00000024: 0.11053 5] LEAVE:c ipw90q.G:.ctor (bool,intptr)(
[00000024: 0.11062 4] LEAVE:c ipw90q.M:L (intptr)([ipw90q.G:0113be08]
[00000024: 0.11072 3] LEAVE:c ipw90q.Y:d ()([ipw90q.G:0113be08]
[00000024: 0.11105 3] ENTER:c ipw90q.G:x ()(this:0113be08[ipw90q.G RMS Express.exe])
[00000024: 0.11117 4] ENTER:c ipw90q.M:p (int)(this:0113be08[ipw90q.G RMS Express.exe], 12)
[00000024: 0.11128 4] LEAVE:c ipw90q.M:p (int)([OBJECT:00000000]
[00000024: 0.11138 3] LEAVE:c ipw90q.G:x ()([OBJECT:00000000]
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
0024:fixme:server:invoke_system_apc syscall frame changed in APC function, frame (nil), saved_frame 0x21eb04.I think this means iphlpapi.GetAdaptersAddresses is returning an IP_ADAPTER_ADDRESSES_LH structure with FirstDnsServerAddress->Address.lpSockAddr equal to NULL.
madewokherd
commented
2 years ago Looking at iphlpapi code, this shouldn't be possible in current Wine. GetAdaptersAddresses was rewritten in 6.15, and based on your shell script you are using 5.21. So if iphlpapi was broken in 5.21, that would explain why you get this exception and I don't.
WheezyE
commented
2 years ago Oh! I didn't even think about how I was running outdated wine. Sorry about that! I'll update my Debian VM & Pi4 and test this out around 7:30pm MST after I get home today.
madewokherd
commented
2 years ago I think the error in GetAdaptersAddresses, at least on 5.21, is that it doesn't initialize the FirstDnsServerAddress field if there are no dns servers. Looking at the current implementation, it zeroes the GetAdaptersAddresses structure before filling it, so that should fix the bug. All of that is assuming I'm guessing right based on looking at the code, I could be completely off base here.
WheezyE
commented
2 years ago Omg 🤦‍♂️ yeah, I had an outdate version of wine. I'm so sorry for putting you on a wild goose chase since Sept 24: I've been reporting all logs from a Debian VM with wine-6.16 on Sept 12 & (for some reason) wine-6.6 on Sept 24+. After upgrading my Debian VM's wine to wine-devel_6.19, I get a different error messages when running wine-mono trace with/without WINE_MONO_HIDETYPES=1:
[00000024:] EXCEPTION handling: ipw90S.No: Adapter index out of range.
[00000024:] EXCEPTION handling: nsoftware.IPWorks.IPWorksIpinfoException: The AdapterCount property is not available in Mono.becomes
0060:fixme:nsi:ipv6_forward_enumerate_all not implemented
0060:fixme:nsi:ipv6_forward_enumerate_all not implemented
0060:fixme:nsi:ipv6_forward_enumerate_all not implemented
0060:fixme:nsi:ipv6_forward_enumerate_all not implementedAnd this is the only difference I can find in the two logs. I guess it's just an unimplemented function in wine? EDIT: Just to clarify too, RMS Express still has the "TNC initialization failed" error when WINE_MONO_HIDETYPES=1.
Full logs here:
I also upgraded the version of wine to wine-devel_6.19 on my Pi4 and it's still having "TNC initialization failed" errors in RMS Express with upgraded wine-mono and WINE_MONO_HIDETYPES=1
Thank you again for all the in-depth help with this.
madewokherd
commented
2 years ago The stub ipv6_forward_enumerate_all reports success and no routes. It probably only shows up because iphlpapi queries all the information about all the network interfaces. I don't know enough about what it does to say whether it's needed, but the fact that it shows up in a log isn't an indication of that.
I may have been completely off base in blaming those exceptions.
I am suspicious of these two: [00000130:] EXCEPTION handling: System.ObjectDisposedException: Safe handle has been closed [00000130:] EXCEPTION handling: System.Net.Sockets.SocketException: interrupted
It'd probably be good to recheck for listening sockets with netstat, just in case that changed and the problem now is connecting to them.
WheezyE
commented
2 years ago I got a chance to look at this today again and ran netstat -l with these results:
EDIT: The "socket" with I-Node 90726 displays when I run RMS Express.
It looks like localhost:ipp is listening on 0.0.0.0: (tcp) and on [::]: (tcp6). If I set ARDOP & RMS Express to listen on 0.0.0.0:8200, I still get "Failure to open Command Port 8200 to Ardop TNC at 0.0.0.0" though
I tried the same with another "TNC" (modem) program called VARA (like ARDOP) with the same connection issues on 127.0.0.1 and 0.0.0.0 .
Hm, I'm stumped on it. I'll try to keep digging around with it
WheezyE
commented
2 years ago I was poking around with this again today and found something kind of interesting. ARDOP doesn't want to connect no matter what - however ....
VARA does connect if I set its port to localhost or 127.0.0.1 (its default)! (though not 0.0.0.0). It sends/receives tones and otherwise behaves as it should. I'm not sure why it wasn't connecting before - maybe due to me using the older version of wine.
Side-note: VARA's black screen is just a bug with wine's window manager (setting Managed"="N" gets around it, but I like the way wine manages X11 windows) which is I think somehow related to RMS Express launching VARA. It doesn't impact performance at all.
I also tried changing to lots of different ports in ARDOP (including the ports that worked for VARA) and they're still not connecting.
The Winlink software suite is an odd collection of programs that all run side-by-side and talk to eachother over local TCP/IP. So I think this means that RMS Express.exe is sending/receiving properly, VARA.exe is sending/receiving properly, but ARDOP_Win.exe is not. So I'm thinking maybe trying to debug just ARDOP alone might give us better error messages?
This might be a nicer spot to be in since ARDOP is open-source [source1] [source2] (although I don't know if the Winlink implementation of ARDOP is open source). ARDOP has two exe's to choose from (ARDOP_Win.exe and ARDOP_2Win.exe) and I'm honestly not sure which one gets used in what instance, but at least on my Debian VM, when ARDOP is opened through RMS Express, ps -a shows that ARDOP_Win.exe is chosen as the exe to run.
I did a trace of mono exceptions on just ARDOP_Win.exe. The exceptions near the top looked maybe interesting:
[00000024:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load file or assembly 'C:\RMS Express\en-US\ARDOP_Win.resources.dll' or one of its dependencies.
[00000024:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load file or assembly 'C:\RMS Express\en\ARDOP_Win.resources.dll' or one of its dependencies.
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
[00000024:] EXCEPTION handling: System.Collections.Generic.KeyNotFoundException: The given key 'Top' was not present in the dictionary.
[00000024:] EXCEPTION handling: System.Collections.Generic.KeyNotFoundException: The given key 'Left' was not present in the dictionary.I also ran WINE_MONO_TRACE=E:System.NullReferenceException MONO_INLINELIMIT=0 to get this, but I'm not sure if this is useful at all:
"<unnamed thread>" tid=00000024 this=03730120 , thread handle : 01a44ab8, state : not waiting
at ARDOP_Win1.INIFile.Load () [0x00054] in <3a9f668defbb44cca36e388899b9cc5a>:0
at ARDOP_Win1.INIFile..ctor (string) [0x00018] in <3a9f668defbb44cca36e388899b9cc5a>:0
at ARDOP_Win1.Main.Main_Load (object,System.EventArgs) [0x00079] in <3a9f668defbb44cca36e388899b9cc5a>:0
at (wrapper delegate-invoke) <Module>.invoke_void_object_EventArgs (object,System.EventArgs) [0x00071] in <711c2ed04b12414db0a39c902d5f3beb>:0
at System.Windows.Forms.Form.OnLoad (System.EventArgs) [0x000d1] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Form.OnCreateControl () [0x00031] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control.CreateControl (bool) [0x000ed] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control.CreateControl () [0x00008] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control.WmShowWindow (System.Windows.Forms.Message&) [0x00051] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) [0x0071b] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message&) [0x00043] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.ContainerControl.WndProc (System.Windows.Forms.Message&) [0x0001a] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Form.WmShowWindow (System.Windows.Forms.Message&) [0x00013] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message&) [0x00290] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067>
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Windows.Forms.SafeNativeMethods.ShowWindow (System.Runtime.InteropServices.HandleRef,int) <0x00012>
at System.Windows.Forms.Control.SetVisibleCore (bool) [0x00061] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Form.SetVisibleCore (bool) [0x000d1] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Control.set_Visible (bool) [0x00001] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control.set_Visible (bool) [0x00032] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Application/ThreadContext.RunMessageLoopInner (int,System.Windows.Forms.ApplicationContext) [0x000cb] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x0001a] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x00033] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) [0x00006] in <bb3337ca3e8d420ebfedaf6995d9ae09>:0
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun () [0x00044] in <8c0c33d4b0a44b0f95f6eef6a363f124>:0
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel () [0x00035] in <8c0c33d4b0a44b0f95f6eef6a363f124>:0
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run (string[]) [0x0001b] in <8c0c33d4b0a44b0f95f6eef6a363f124>:0
at ARDOP_Win1.My.MyApplication.Main (string[]) [0x00012] in <3a9f668defbb44cca36e388899b9cc5a>:0
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00027] in <3a9f668defbb44cca36e388899b9cc5a>:0Anyways, not sure if this gets us any farther or not, but thank you again for looking into this whole thing. I'm pretty excited that at least VARA is working with wine-mono, even if ARDOP isn't for some reason yet. That is seriously huge!
madewokherd
commented
2 years ago That ARDOP source appears to be a Qt application, and it doesn't have the classes that are failing. The one you're using appears to be VB.NET?
WheezyE
commented
2 years ago Hmmmm yeah huh. ARDOP is covered by the GNU 3+ licenses though. Would that mean I could ask the Winlink team for their ARDOP source?
Here's an old Winlink news page about ARDOP where they said users could find ARDOP sources (though the link is dead and internet archive doesn't have any archived pages for it): https://www.winlink.org/content/ardop_news
WheezyE
commented
2 years ago WheezyE
commented
2 years ago Ok, there's apparently a files folder on the https://ardop.groups.io/g/developers forum, but I need membership first. I'll report back in when I get a copy of the latest Winlink ARDOP source
WheezyE
commented
2 years ago Ok, was approved to the groups.io group and got a copy of the ARDOP_Win VB open source code. This should be the same open source ARDOP_Win.exe that RMS Express packages and uses.
For example, this is the image of this fork of ARDOP running - which looks identical to the Winlink version (image from https://ardop.groups.io/g/users):
Here is the directory listing from the groups.io / dev files section along with relevant files:
ARDOP Overview.pdf - Link redacted
_ARDOPWin TNC source code analysis.pdf - Link redacted
_Host Interface Spec for WL2K supported ProtocolsTNCs.pdf - Link redacted
_ARDOP2Win TNC Rev 2..0.3.7 Source.zip - Link redacted
_ARDOPWin VBSource Rev1.0.4.zip - Link redacted
I'd post the ARDOP_Win.exe, but github doesn't like it.
NOTE TO ANY ARDOP DEVS: Since ARDOP is open source and GNU 3+, I'm assuming it's ok to post the source here. If this is not ok, please notify me and I will remove these files/links from this issue tracker.
UPDATE 11/1/2021: I still haven't heard anything from the ARDOP devs regarding copyright after asking, so I've removed links to files just for courtesy
madewokherd
commented
2 years ago Where does it say it's GPL 3+? I couldn't find a license in the source archives.
madewokherd
commented
2 years ago Given that there's no license or copyright attribution in here at all, I think we must be dealing with hobbyists who don't bother with such things. So it's probably fine, but there's nothing legally protecting you if you redistribute the code.
Anyway, based on the code I think the only way you should get a NullReferenceException with that stack is if "ARDOP_Win TNC.ini" has a Key=Value pair before a [Section]. It's also possible there's something else going wrong that's causing it to not recognize a section line, such as our String.Trim() function being broken, but that seems unlikely.
You might be able to work around it by deleting the file.
WheezyE
commented
2 years ago Where does it say it's GPL 3+? I couldn't find a license in the source archives.
I guess I just assumed ARDOP_Win (by Rick Muething) had the same license as ARDOPc (by John Wiseman, which has GNU 3+ - ARDOPc is a C port of ARDOP_WIN that runs on Linux). But you're right - I can't find a specific license file for ARDOP_Win. I can't seem to find a straight answer on the ardop.groups.io/g/developers forum either. I'll ask around.
Thank you for being cautious though. I think I'll just take the links down pretty soon. I think you're right about the hobbyist aspect though and they just not bothering with a license file.
You might be able to work around it by deleting the file.
Thanks, I'll give that a shot when I get home today!
This is all the info I have about possible ARDOP_Win license info:
#ardop.c
/*
Copyright 2001-2018 John Wiseman G8BPQThis file is part of LinBPQ/BPQ32.
LinBPQ/BPQ32 is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
LinBPQ/BPQ32 is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with LinBPQ/BPQ32. If not, see http://www.gnu.org/licenses */
2. John Wiseman also said _"My version of ARDOP is basically just a port of Rick's Windows code. ... The code is available for anyone interested in using it as the basis for further developments."_
3. In 2015, Rick Muething said _"The open source code must be posted under an appropriate Open source format/license. Currently there is no open source code posted. ... We currently have only 3 part time developers working on ARDOP. If someone thinks they can contribute in one or more of the above efforts and can make a substantial COMMITMENT ... we would welcome some additional help. (Contact me, Mathew Pitts or John Wiseman. )"_ However the ARDOP_Win source code is posted (in 2018) on the groups.io dev forum just says `Copyright 2015-2016 Rick Muething, KN6KB`.
EDIT:
4. The ARDOP Win source by Rick Muething mentions John Wiseman.
5. ARDOP is supposed to be an acronym for "Amateur Radio Digital Open Protocol"Impressive sleuthing. Yeah, after deleting the ini file the following exceptions don't show up when running ARDOP_Win.exe anymore.
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
[00000024:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
[00000024:] EXCEPTION handling: System.Collections.Generic.KeyNotFoundException: The given key 'Top' was not present in the dictionary.
[00000024:] EXCEPTION handling: System.Collections.Generic.KeyNotFoundException: The given key 'Left' was not present in the dictionary.EDIT: Then I noticed that the ini file had a linebreak as its first line. I deleted that with nano and re-ran the exception trace on ARDOP_Win.exe and then the exception went away. I put the linebreak back and ran it again and the exception came back. So I guess that exception isn't what we're looking for after all.
I also just noticed though that ARDOP has been outputting logs of exceptions on its own and those logs say that the MS-DOS command lines used to launch ARDOP through RMS Express have "syntax errors" for some reason with wine-mono. I also get these syntax errors when ARDOP_Win.exe is launched on its own, or when I do wine cmd and run commands like C:\RMS Express\ARDOP_Win.exe TCPIP 8200 127.0.0.1:
pi@debian:~/.wine/drive_c/RMS Express/Logs$ more ARDOP_WinTNC_Debug_20211016.log
22:35:30.992 [ARDOP_Win TNC.Main.Load] Command line =C:\RMS Express\ARDOP_Win.exe TCPIP 8200 localhost
pi@debian:~/.wine/drive_c/RMS Express/Logs$ more ARDOP_WinTNC_Exceptions_20211016.log
2021/10/16 22:35:31 [1.0.2.5] [Main.Load] Syntax error in command line: C:\RMS Express\ARDOP_Win.exe TCPIP 8200 localhost ... ini file
values used.When the syntax error happens, it looks like ARDOP falls-back on the ini file. Maybe that's where the problem could be? (EDIT: This syntax error shows up regardless of whether or not that top linebreak is in the ARDOP_Win TNC.ini file).
These syntax errors seem to only appear with wine-mono and not with regular windows or in wine 6.19 with dotnet35sp1. All setups were with the same version of RMS Express (1.5.40)
EDIT 10/17/2021: The ARDOP source seems to maybe implicate these VB.NET functions?
#Main.vb
Dim strCmds() As String = Microsoft.VisualBasic.Command().Split(CChar(" "))
If strCmds.Length = 3 AndAlso (strCmds(0).ToUpper = "TCPIP" And (IsNumeric(strCmds(1).Trim) And (CInt(strCmds(1).Trim) >= 0 And CInt(strCmds(1).Trim) < 65536))) ThenEDIT 10/17/2021: On second thought, I tried hard-coding the IP and port in the source, built it, and run it with wine-mono and still have connection issues so maybe that's not it. I also might not have done it quite right though since I've never actually coded in VB.
Hm... I'm stumped for the moment.
Hey all. I'd like to ask for help with a bug in wine-mono but I'm not entirely sure if this is the right place to ask for help.
My bug relates to RMS Express (a Windows-only .NET 3.5sp1 / Visual C program for ham radio) not being able to send/receive TCP/IP text commands to other programs on localhost listening for commands if it's run with mono.
If you want a quick script to get everything installed and working on x64 Linux Mint (using dotnet35sp1) run
wget https://raw.githubusercontent.com/WheezyE/Winelink/main/docs/experiments/x86-64_Linux_distros/Debian-Ubuntu_x64.sh && bash Debian-Ubuntu_x64.shJust as proof-of-concept. Then compare this behavior to running with wine-mono instead. This script hasn't been tested on Debian or Ubuntu so far, just Linux Mint