First click on Rotate IP always fails

[ltguillaume]

Describe the bug
Just like the first click on the tray icon (#258), the first click on the Rotate IP button simply ignores the command as if you had click the X next to it. Only the second time, the IP rotation works.

OS and app information:

• OS: Win10 all
• App version: 2.20.x (now .7)

To Reproduce
Steps to reproduce the behavior:

1. Open app from tray
2. Click on '...' button
3. Click on Rotate IP button
4. See the same IP as before

Expected behavior
Should rotate IP.

[bernerdad]

We've confirmed this erroneous behavior. It's on our internal board for investigation in the 2.21 release.

[bernerdad]

Hi. Turns out this is a backend implementation detail and not a bug in the client app. The server one is connected to randomly selects an IP from its pool of available IPs. If one is connected to a server with a limited available IP pool, they may get the same IP back when rotating. I'm told this is not something we're going to change since each server does not internally track each connected user's current IP. The long-and-short of it, if this is happening regularly for one with a certain location, use another location.

Now, I'm assuming here that you are experiencing the above. The rotate request is not being ignored/failing, it succeeds but returns the same IP as you had before. The UI would (should) have shown an error if the rotate failed. The check for this is:

• Note your current IP.
• Rotate IP.
• Look in the log for the latest tunnel test result which will indicate the 'new' IP. If the tunnel test succeeded and the new IP is the same as the previous one, you've run into the limited available IP pool issue.

[ltguillaume]

This cannot be the problem, because the issue always happens the first time it's clicked

1. after the client app has started, or
2. right after changing to any other server.

There is no random factor here. I can just change to another server, click rotate button and see that the IP does not change. Every time.

Tried over 50 times, with about 10 different servers, there was not a single time it did rotate the IP the first time.

[bernerdad]

Does the app log indicate if the rotate request was successful? You should see bridge_api BridgeApiManager::rotateIp success in the log and shortly after that Tunnel test "1" successfully finished with IP: "NN.NN.NN.NN".

[ltguillaume]

Yes, it does. So 50+ times and it's just chance?

Either way, there could be a very easy client-side check that retries the rotation if the IP is still the same.

[bernerdad]

This would be a server-side fix if it is as non-random as you indicate. I, and one of the QA members, tried a bunch of North American locations and received a new IP just about every time. We also checked if there was an issue due to a rotate being requested shortly after connecting, but that does not appear to be the case. Can you share a couple of the locations you've tested which reproduce the issue every time? I can then ask the backend team to revisit this.

[ltguillaume]

See your mail, subject Issue #304.

[bernerdad]

Thank you for the locations list. I tried each of them using 2.21.6, but granted I'm in North America, and only the second one in your list gave me the same IP on the first rotate request. I'll run it by the backend team and see if they can figure out the discrepancy. Does the first rotate work for you if you use geographically distant locations?

[ltguillaume]

This is crazy haha 🤣 I guess this explains why I never won the lottery 🤷‍♂️

Does the first rotate work for you if you use geographically distant locations?

I tried Fake Greenland and that was the very first time rotating worked right away!

[bernerdad]

It is indeed a bizarre one. We'd prefer not to add the client-side check you mention above, as that would entail putting a band-aid patch in the desktop, Android, iOS, and browser extension apps. I'll liaise with the backend team and try to pin down why it could be non-random for you. Are you using the mobile app? If yes, does this occur in the mobile app as well?

[ltguillaume]

We'd prefer not to add the client-side check you mention above, as that would entail putting a band-aid patch in the desktop

I get that, but this way you're just assuming that every user isn't trusting that clicking rotate IP actually rotates the IP.

And I'd say that's a very bad assumption.

Are you using the mobile app? If yes, does this occur in the mobile app as well?

Yes, I am. And yes, I see now it happens there as well. It even shows the "IP rotated successfully", even though it's not rotated, so the behavior is exactly the same as with the desktop client.