RailPro User Group
RailPro => RailPro Specific Help & Discussion => Topic started by: G8B4Life on February 16, 2020, 05:32:30 AM
-
Well as alluded to by Bill and later confirmed by myself I have been working on a workaround for the RPA CGNAT issue. I've had a ball getting the workaround up to this stage (but for the wrong reason; forced unpaid leave from work due to serious downturn caused by do-gooders so lot's of time to fill).
Anyway, the workaround is at stage where I believe the software is stable enough for others to test with. I've tested here quite successfully and without issue but there are things I just can't test myself, mainly I don't know if the workaround will work on 64bit versions of Windows, or any of the later versions of Windows for that matter.
As with everything there is a list of pros and cons to the workaround. I'll start with the cons:
- It will be slow. Not only are you going to contend with how slow Rings servers are anyway you'll also have to contend with your communication with Rings server having to go halfway around the world and back. This will add time. It may make communication so slow that RPA thinks it can't communicate with the server. That shouldn't happen though.
- Only one person at a time can use the proxy. This is due to the combination of how Rings server works with it's fixed source port and the fact that I only have one IP address to use for the proxy.
- When someone else is using the proxy I can't use RPA myself to download from Ring's server (see above point).
- There is probably bugs I haven't found and fixed yet.
Pros:
- If you have very cool freinds or very understanding relatives who are not CGNAT'ed you could set a copy of the proxy up at their place, all you'd need is a Raspberry Pi and a copy of the proxy code*
The software was only supposed to be proof of concept of the various parts of the software and then I was going to code it in a more modern framework. I got carried away and kept on going in the old framework I was programming in. If the softwware works I probably won't redo it in the modern framework.
If anyone, CGNAT issue or not would like to test the workaround let me know and I'll let you know by PM where to download the workaround software from.
- Tim
* your technical ability on setting up a Raspberry Pi and configuring port forwarding in your friends or relatives router would be the limiting factor
-
Tim--I'd like to try the tool.
thanks for developing it!!
ken
faithie999 at hotmail
-
Ken,
Check you personal messages here on rpug.
- Tim
-
I received the info from you. I will try it out later today.
thanks!
-
check for a PM
-
thumbs up! let me know if you got my PM. not sure it went properly.
-
I guess I should provide an update to this...
It works. I did have to go back and recode part of it to work around Windows ASLR which I hadn't considered at the time when it didn't work for Ken the first time but after that Ken reported he successfully downloaded a couple of LM updates without issue. I don't know if he's applied those updates and all is good there though.
Ken, I've also gone back in and changed the communication code so the unresponsive button shouldn't happen any more. I'll let you know when I upload the updated version, I'm in no hurry though as I work on trying to improve the proxy to be better as well.
- Tim
-
Huge congrats to Tim for getting this done!!
Tim--the other day I updated an LM-3S without any error message, but I just checked and the HC says the LM is at V 1.00. It is very possibly operator error. I'll re-download the update and try again.
-
Are you sure you weren't looking at the hardware revision number of the LM-3S? Unless you downloaded and installed the Accessory firmware for the LM-3S (which is at version 1.00) there is no way you could have downloaded and installed version 1.00 of the regular LM-3S firmware.
- Tim
-
you're right. at the bottom of the info page for that decoder, I was looking at the line which says "LM-3S-IVT1637, Rev. 1.00". but the important line is the one above that--"Program--SW1041, Rev. 2.12"