Author Topic: Looking for a volunteer or two to test RPA behavior  (Read 1376 times)

G8B4Life

  • Signalman (Global Mod)
  • Conductor
  • *****
  • Posts: 1193
  • I'll think of a catchy tag line one day
Looking for a volunteer or two to test RPA behavior
« on: June 20, 2021, 08:56:44 AM »
Edit 25th June 2021: My port blocker program referenced in this post is no longer downloadable, hence this test is no longer relevant and is left here for posterity.

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 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
And then in order:
  • Run Live TcpUdp watch.
  • Run RailPro Port Blocker and start the blocking.
  • Within the 30 seconds of port blocking run RPA.
RPA should not connect to Ring. When you look at the Live TcpUdp Watch screen it should look like this:

rpa_strange_port_behavior.png
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
« Last Edit: June 25, 2021, 04:55:36 AM by G8B4Life »

Josephbw

  • Conductor
  • ****
  • Posts: 251
Re: Looking for a volunteer or two to test RPA behavior
« Reply #1 on: June 20, 2021, 08:40:12 PM »
Hi Tim, I ran the programs and it did not connect to Rings /RPA.

Joe