Post by: G8B4Life on June 20, 2021, 08:56:44 AM
Looking for a volunteer to two to confirm some observed behavior with RPA.
The reason is hard to explain with becoming technical so most probably won't understand why but...
As anyone who reads my posts here would probably know, RailPro Assistant uses port 4608 on your computer to communicate to Rings server. This port is hardcoded into the program.
This hardcoding was one half of the problem with the CGNat issue a while back. The other half was Rings server was also using a hardcoded port to send back to the user. This got fixed and the server now replies back to which ever port your RPA data arrived from.
What I recently observed was that if RPA couldn't get port 4608 because some other program was using it RPA gets whatever the next-in-line free port was, which technically should still work but it doesn't RPA thinks it can't connect.
What I want to find out is if this behavior happens for more than just myself.
If you are interested, please do the following:
- Download Live TcpUdp Watch (https://www.nirsoft.net/utils/live_tcp_udp_watch.html) from NirSoft. The link to the 32 bit and 64 bit versions are near the bottom of the page. It's freeware and no installation is necessary.
- Download my RailPro Port Blocker from the RPUG files section. Again, no installation is necessary. Note, my program only sends data to itself so it shows up in the Live TcpUdp watch screen
- Run Live TcpUdp watch.
- Run RailPro Port Blocker and start the blocking.
- Within the 30 seconds of port blocking run RPA.
Click for larger view
In this test RailPro Port Blocker had local port 4608 (as intended) and some other random local port (in this case 4105). RPA got port 4106 which was the next free port and RPA sent and received packets of data, yet it did not connect.
This is what I want to check if it's the same for others, if RPA on a local port other than 4608 sent and received data but did not connect.
- Tim
Post by: Josephbw on June 20, 2021, 08:40:12 PM
Joe