-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RMS Express - TCP/IP communication issues? #116
Comments
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 |
Thanks for the Here are some terminal outputs with mono_trace enabled with mono installed in a fresh wineprefix This is RMS Express (aka "Winlink Express") trying and failing to launch the "ARDOP" Modem from within RMS Express:(All the different modems have different names. The ham radio convention is to call a modem a "TNC" for some reason that is beyond my understanding.)
Then here's a log of when I launch ARDOP manually:(I believe it tries to find RMS Express via TCP/IP upon launch)
These are my Mono + RMS Express install steps in a nutshell:(I didn't do # Make a fresh 32bit wineprefix
WINEARCH=win32 wine wineboot
# Install RMS Express
wget -q -r -l1 -np -nd -A "Winlink_Express_install_*.zip" https://downloads.winlink.org/User%20Programs || { echo "RMS Express download failed!" && run_giveup; } # Download Winlink no matter its version number
7z x Winlink_Express_install_*.zip -o"WinlinkExpressInstaller"
wine WinlinkExpressInstaller/Winlink_Express_install.exe /SILENT
WINE_MONO_TRACE=x wine ~/.wine/drive_c/RMS\ Express/RMS\ Express.exe 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) |
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 |
I'd check on the NotImplementedException first, try |
Thanks for more tips here! Partial (most likely relevant) console output:
Full console output:
I'm kind of surprised by the visual basic errors. I've often run Here's a log of relevant terminal output with vb6run installed:
|
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. |
vb6run wouldn't have any effect on this, these are VB.NET libraries, not VB6. |
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 System.ArgumentException: 'CP1252' trace in ARDOP_Win.exe:
|
Interaction.Shell turned out to be in winforms so I made a PR to import it along with some other methods: #117 |
Sick! Thank you again for looking into this and for your work on it |
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 |
Does it normally communicate through TCP? Does the listening socket show up in |
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. In any case, here's my output from `netstat -l` while RMS Express and ARDOP were running and refused connections with eachother:(I'm not super sure what I'm looking for tbh, but I think the top "Active Internet Connection" on localhost looks open for * ports?)
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 |
OK, so the problem is server-side, and the "connection refused" errors are because the listening socket isn't opened. |
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 We could try to rename this type, but the last time I tried something similar (with 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. |
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 |
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. |
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 |
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.
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. |
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.
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.
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. |
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.
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. |
Hm, yeah. Maybe they misunderstood that wine-mono was different than mono.
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. |
I've opened madewokherd/mono#13 which will allow for hiding these types using I expect you'll get a NotImplementedException with this set. |
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. |
Alright, using the latest Winlink 1.5.39.0 (released some time before Jul 26, 2021), I ran
becomes
Full log of WINE_MONO_HIDETYPES=0 here:
Full log of WINE_MONO_HIDETYPES=1 here:
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. |
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. |
Oh right, that makes sense. Thank you. Ok here's what we get on the only instance of
Maybe hanging on more VisualBasic winforms functions? EDIT: Or maybe nsoftware.Sys.Internal.Public.SystemIPHlpAPI.GetAdapterInfo returning with an error? |
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. |
If you can get a log with |
I think this means iphlpapi.GetAdaptersAddresses is returning an IP_ADAPTER_ADDRESSES_LH structure with FirstDnsServerAddress->Address.lpSockAddr equal to NULL. |
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. |
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. |
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. |
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
becomes
And 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 Full logs here: WINE_MONO_HIDETYPES=0 (wine-devel_6.19)
WINE_MONO_HIDETYPES=1 (wine-devel_6.19)
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 Thank you again for all the in-depth help with this. |
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: 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. |
I was poking around with this again today and found something kind of interesting. ARDOP doesn't want to connect no matter what - however .... 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 ( I did a trace of mono exceptions on just ARDOP_Win.exe. The exceptions near the top looked maybe interesting:
Full log of ARDOP_Win.exe mono exception trace here:
I also ran
Here's that full log of WINE_MONO_TRACE=E:System.NullReferenceException on ARDOP_Win.exe (including me setting the port again - I think that's where the ini bit comes in on the second time the exception comes up):
Anyways, 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! |
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? |
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 |
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 |
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: 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 |
Where does it say it's GPL 3+? I couldn't find a license in the source archives. |
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 You might be able to work around it by deleting the file. |
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.
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:
EDIT: |
Impressive sleuthing. Yeah, after deleting the ini file the following exceptions don't show up when running ARDOP_Win.exe anymore.
Full log:
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
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 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))) Then EDIT 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. |
Hmm, looking at our definition of that function, it doesn't seem to match the MSDN documentation: https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualbasic.interaction.command MSDN says that it returns just the command line arguments, but our version returns the exe filename as well. I don't know if it's related to the problem, but it should be fixable. |
For bookkeeping purposes, the fix for this bug is in Wine Mono 7.0.0. |
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.sh
Just 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
The text was updated successfully, but these errors were encountered: