kerem commented

Owner

Originally created by @rafi-d on GitHub (Feb 20, 2025).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/869

Originally assigned to: @VShawn on GitHub.

RE-connection is always done to the last active address. So, when switching from main to alternative address - it will never re-connect.
In my case there is a wired and Wifi connections to the same LAPTOP/PC, with different IPs. When docking the PC again, it does not re-connect to the new address automatically.

Originally created by @rafi-d on GitHub (Feb 20, 2025). Original GitHub issue: https://github.com/1Remote/1Remote/issues/869 Originally assigned to: @VShawn on GitHub. RE-connection is always done to the last active address. So, when switching from main to alternative address - it will never re-connect. In my case there is a wired and Wifi connections to the same LAPTOP/PC, with different IPs. When docking the PC again, it does not re-connect to the new address automatically.

kerem

2026-02-26 11:59:25 +03:00

closed this issue
added the
meta-enhancement
label

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 25, 2025):

As for the RDP reconnect, it may be difficult to intervene because MSTSCLib does it, not 1Remote?

@itagagaki commented on GitHub (Feb 25, 2025): As for the RDP reconnect, it may be difficult to intervene because MSTSCLib does it, not 1Remote? ![Image](https://github.com/user-attachments/assets/08738961-e0b4-475e-831a-24f781fc0efd)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Feb 25, 2025):

But isn't the first connection and address selection done by your app? Can't you intervean in this case and take control?

@rafi-d commented on GitHub (Feb 25, 2025): But isn't the first connection and address selection done by your app? Can't you intervean in this case and take control?

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 25, 2025):

Oh, were you referring to the behavior of this?

@itagagaki commented on GitHub (Feb 25, 2025): Oh, were you referring to the behavior of this? <img width="643" alt="Image" src="https://github.com/user-attachments/assets/fd05fbc4-939a-44a4-b729-db7176802872" />

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 26, 2025):

But isn't the first connection and address selection done by your app? Can't you intervean in this case and take control?

No, we cannot control the address when the reconnection is initiated by RDP automaticly.

@VShawn commented on GitHub (Feb 26, 2025): > But isn't the first connection and address selection done by your app? Can't you intervean in this case and take control? No, we cannot control the address when the reconnection is initiated by RDP automaticly.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Feb 26, 2025):

Yeah, and RDP re-tries the current address only. But you can control

Oh, were you referring to the behavior of this?

Yes, this is a good place for the app do the testing/trying both addresses. like you do on the first connection (double click) .

BUT I was actually referring to the time after RDP does its 3-5 retries and disconnects . At his point you might still be able to try re-connect to both addresses.

@rafi-d commented on GitHub (Feb 26, 2025): Yeah, and RDP re-tries the current address only. But you can control > Oh, were you referring to the behavior of this? Yes, this is a good place for the app do the testing/trying *both* addresses. like you do on the first connection (double click) . BUT I was actually referring to the time *after* RDP does its 3-5 retries and disconnects . At his point you might still be able to try re-connect to both addresses.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 26, 2025):

Okay.

The RDP library will internally retry to reconnect 5 times. 1Remote has no control over this behavior.
(As an aside, it is not impossible to extend 1Remote to specify whether retries are enabled or not, and the maximum number of retries. Currently, nothing is specified, so the default is 5 retries).

You are talking about how 1Remote tries to reconnect afterwards, right? I am not sure if it should automatically reconnect at that point (I tried it on my end, but 1Remote crashed. This is another issue. It may be my local problem...), but I think it's up to the product owner, @VShawn, to decide whether to automatically reconnect at this point, and if so, whether to try the last active connection (which may be an alternative), or start with the root setup.

@itagagaki commented on GitHub (Feb 26, 2025): Okay. The RDP library will internally retry to reconnect 5 times. 1Remote has no control over this behavior. (As an aside, it is not impossible to extend 1Remote to specify whether retries are enabled or not, and the maximum number of retries. Currently, nothing is specified, so the default is 5 retries). You are talking about how 1Remote tries to reconnect afterwards, right? I am not sure if it should automatically reconnect at that point (I tried it on my end, but 1Remote crashed. This is another issue. It may be my local problem...), but I think it's up to the product owner, @VShawn, to decide whether to automatically reconnect at this point, and if so, whether to try the last active connection (which may be an alternative), or start with the root setup.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Feb 26, 2025):

Correct. Up to you to decide if to retry the alternate / main (other) connection at this point, if one is defined. This was the idea.

Same goes for the "reconnnect" menu item.

@rafi-d commented on GitHub (Feb 26, 2025): Correct. Up to you to decide if to retry the alternate / main (other) connection at this point, if one is defined. This was the idea. Same goes for the "reconnnect" menu item.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 27, 2025):

It is clear that automatically determining the available address during reconnection is a better user experience. I vote for it.

Annd we only need to keep the current manual reconnect button, since RDP is already capable of automatic reconnect.

@VShawn commented on GitHub (Feb 27, 2025): It is clear that automatically determining the available address during reconnection is a better user experience. I vote for it. Annd we only need to keep the current manual reconnect button, since RDP is already capable of automatic reconnect.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 5, 2025):

Once connected to the alternate host, it seems to always connect to the alternate host, not to the primary host, even if the primary host is subsequently available for connection. When Automatic address switching is unchecked, it connects to the primary host, but when Automatic address switching is checked, it still connects to the alternate host.

@itagagaki commented on GitHub (Mar 5, 2025): Once connected to the alternate host, it seems to always connect to the alternate host, not to the primary host, even if the primary host is subsequently available for connection. When Automatic address switching is unchecked, it connects to the primary host, but when Automatic address switching is checked, it still connects to the alternate host.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 5, 2025):

@itagagaki can you help debugging to verify if it first checks the primary address and then the backup address during reconn? I busy tonight.

set breakpoint here:

https://github.com/1Remote/1Remote/blob/main/Ui/Service/SessionControlService_AlternateCredential.cs#L254-L266

where var ret = await TcpHelper.TestConnectionAsync(newCredential.Address, newCredential.Port, null, 100); is to first checks the primary address, Here we need to check if the main address is correct.

then var connectableAddress = await FindFirstConnectableAddressAsync(credentials, protocol.DisplayName); is to find from credentials to get first credential that responds to the ping.

note that I have reset the main address to its default value at this location: https://github.com/1Remote/1Remote/blob/main/Ui/Service/SessionControlService_AlternateCredential.cs#L216-L221

But if you are busy too, I will test tomorrow. :)

@VShawn commented on GitHub (Mar 5, 2025): @itagagaki can you help debugging to verify if it first checks the primary address and then the backup address during reconn? I busy tonight. set breakpoint here: https://github.com/1Remote/1Remote/blob/main/Ui/Service/SessionControlService_AlternateCredential.cs#L254-L266 where `var ret = await TcpHelper.TestConnectionAsync(newCredential.Address, newCredential.Port, null, 100);` is to first checks the primary address, Here we need to check if the main address is correct. then `var connectableAddress = await FindFirstConnectableAddressAsync(credentials, protocol.DisplayName);` is to find from credentials to get first credential that responds to the ping. note that I have reset the main address to its default value at this location: https://github.com/1Remote/1Remote/blob/main/Ui/Service/SessionControlService_AlternateCredential.cs#L216-L221 But if you are busy too, I will test tomorrow. :)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 5, 2025):

When "Automatic address switching" is checked, the TestConnectionAsync call with the primary host address as newCredential.Address returns false.
Then FindFirstConnectableAddressAsync returns an object with the alternate address.

However, the first time I tried it after reading your instructions, FindFirstConnectableAddressAsync returned an object with the primary host. So I made the connection go to the alternate host by disabling RDP on the primary host, then re-enabling it, then testing again and getting the unexpected result above.

My guess is that the passage of time may have had some effect. But I am not sure because the connection to the primary host is established even without the passage of time by unchecking "Automatic address switching".

@itagagaki commented on GitHub (Mar 5, 2025): When "Automatic address switching" is checked, the `TestConnectionAsync` call with the primary host address as `newCredential.Address` returns false. Then `FindFirstConnectableAddressAsync` returns an object with the alternate address. However, the first time I tried it after reading your instructions, `FindFirstConnectableAddressAsync` returned an object with the primary host. So I made the connection go to the alternate host by disabling RDP on the primary host, then re-enabling it, then testing again and getting the unexpected result above. My guess is that the passage of time may have had some effect. But I am not sure because the connection to the primary host is established even without the passage of time by unchecking "Automatic address switching".

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 6, 2025):

When "Automatic address switching" is checked, the TestConnectionAsync call with the primary host address as newCredential.Address returns false.

strange, TestConnectionAsync works GOOD in my testing environment and returns true as expected.

@VShawn commented on GitHub (Mar 6, 2025): > When "Automatic address switching" is checked, the TestConnectionAsync call with the primary host address as newCredential.Address returns false. strange, `TestConnectionAsync` works GOOD in my testing environment and returns true as expected.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 6, 2025):

I tried to provide a movie recording of the RDP connection procedure and step execution from the breakpoint, but after the RDP connection was disconnected, 1Remote froze (I used to call this a "crash") and could not reach the breakpoint. This happened twice in a row, so I have not yet successfully recorded it. I said randomly, but the frequency is quite high.

I would like to try until I can record it reaching a breakpoint and executing a step without freezing.
But maybe we should prioritize finding the cause of the freeze.

@itagagaki commented on GitHub (Mar 6, 2025): I tried to provide a movie recording of the RDP connection procedure and step execution from the breakpoint, but after the RDP connection was disconnected, 1Remote froze (I used to call this a "crash") and could not reach the breakpoint. This happened twice in a row, so I have not yet successfully recorded it. I said randomly, but the frequency is quite high. I would like to try until I can record it reaching a breakpoint and executing a step without freezing. But maybe we should prioritize finding the cause of the freeze.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 6, 2025):

even stranger

during dozens of tests while debugging, I didn't encounter any froze.

However, this freeze might be related to the async calls. Since the initial design didn't include async calls, now forcibly changing it to async may have introduced some unknown issues.

@VShawn commented on GitHub (Mar 6, 2025): even stranger during dozens of tests while debugging, I didn't encounter any `froze`. However, this freeze might be related to the async calls. Since the initial design didn't include async calls, now forcibly changing it to async may have introduced some unknown issues.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 9, 2025):

After applying the fix for #884, I have tried it a few times and it still does not freeze.
Is it possible that the modified part was related to the freeze?

The issue of not connecting to the primary host is still there and needs to be investigated.

@itagagaki commented on GitHub (Mar 9, 2025): After applying the fix for #884, I have tried it a few times and it still does not freeze. Is it possible that the modified part was related to the freeze? The issue of not connecting to the primary host is still there and needs to be investigated.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 10, 2025):

Is it possible that the modified part was related to the freeze?

i don't think so.

The issue of not connecting to the primary host is still there and needs to be investigated.

My tests are all connected to the main address, perhaps because my testing environment (virtual machine) is too ideal?

@VShawn commented on GitHub (Mar 10, 2025): > Is it possible that the modified part was related to the freeze? i don't think so. > The issue of not connecting to the primary host is still there and needs to be investigated. My tests are all connected to the main address, perhaps because my testing environment (virtual machine) is too ideal?

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 10, 2025):

If you can share your test exe (for x64) I can try to test-run it too. All my PCs are without passwords ATM though.

@rafi-d commented on GitHub (Mar 10, 2025): If you can share your test exe (for x64) I can try to test-run it too. All my PCs are without passwords ATM though.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 10, 2025):

If you can share your test exe (for x64) I can try to test-run it too. All my PCs are without passwords ATM though.

Also reproduced with the latest nightly on my end.
1Remote-1.1.1-net6-x64-nightly-20250309-859e47.zip

Test steps and the results on my end:

Create an RDP entry T with host1 as the primary host and host2 as the alternate host, uncheck 'Automatic address switching'
Make host1 and host2 connectable
Open T --> connected to host1 (OK)
Close T
Make host1 unconnectable
Open T --> got error (OK)
Check 'Automatic address switching'
Open T --> connected to host2 (OK)
Close T
Make host1 connectable again
Open T --> connected to host2 (NG)
Close T
Uncheck 'Automatic address switching'
Open T --> connected to host1 (OK)
Close T
Check 'Automatic address switching'
Open T --> connected to host2 (NG)

Environment: 64-bit Windows 10 Pro 22H2 / Intel Core i7-11700K / 32GB RAM

$ dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Is it possible that the modified part was related to the freeze?

i don't think so.

mystery. I will keep a close eye on the freeze or not.

@itagagaki commented on GitHub (Mar 10, 2025): > If you can share your test exe (for x64) I can try to test-run it too. All my PCs are without passwords ATM though. Also reproduced with the latest nightly on my end. [1Remote-1.1.1-net6-x64-nightly-20250309-859e47.zip](https://github.com/1Remote/1Remote/releases/download/Nightly/1Remote-1.1.1-net6-x64-nightly-20250309-859e47.zip) Test steps and the results on my end: 1. Create an RDP entry T with host1 as the primary host and host2 as the alternate host, uncheck 'Automatic address switching' 2. Make host1 and host2 connectable 3. Open T --> connected to host1 (OK) 4. Close T 5. Make host1 unconnectable 6. Open T --> got error (OK) 7. Check 'Automatic address switching' 8. Open T --> connected to host2 (OK) 9. Close T 10. Make host1 connectable again 11. Open T --> connected to host2 (NG) 12. Close T 13. Uncheck 'Automatic address switching' 14. Open T --> connected to host1 (OK) 15. Close T 16. Check 'Automatic address switching' 17. Open T --> connected to host2 (NG) Environment: 64-bit Windows 10 Pro 22H2 / Intel Core i7-11700K / 32GB RAM ``` $ dotnet --list-runtimes Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] ``` > > Is it possible that the modified part was related to the freeze? > > i don't think so. mystery. I will keep a close eye on the freeze or not.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 10, 2025):

My test results (two PCs with latest Windows 10 x64 enterprise, using the above nightly):
PC1: PC2 set as alternate

Firstly: the app is not crashing nor hanging-up.

Logic tests:

PC1 - disconnected from LAN , PC2 - is connected to LAN

PC1 - click connect from 1remote or click reconnect from PC1 RDP session - both connect to PC2 **OK
Title display - "PC1 name" **NOK (should display PC2 name per #868)

Connect PC1 to LAN again (while 1remote still in PC1-alternate RDP session to PC2)

PC1 - RDP session -> click reconnect, reconnects to PC2 again (the last active session) **NOK (should reconnect o PC1)

Auto-disconnect test

Disconnect PC1 again from LAN , and wait

RDP - triggers auto-re-connect and fails after 5 retries OK
After it fails (or cancel is clicked) - session is disconnected. **** ? Question: can you check again for both PC1 and PC2?

Comment - both RDP #number of retries and/or retry timeout - needs to be configurable in 1remote

Edit:
Looking @ help-about was the incorrect (old) version!

@rafi-d commented on GitHub (Mar 10, 2025): My test results (two PCs with latest Windows 10 x64 enterprise, using the above nightly): PC1: PC2 set as alternate Firstly: the app is not crashing nor hanging-up. Logic tests: ======== PC1 - disconnected from LAN , PC2 - is connected to LAN ------------------------------------------------------------------------- PC1 - click connect from 1remote or click reconnect from PC1 RDP session - both connect to PC2 **OK Title display - "PC1 name" ****NOK** (should display PC2 name per #868) Connect PC1 to LAN again (while 1remote still in PC1-alternate RDP session to PC2) --------------------------------------------------------- PC1 - RDP session -> click reconnect, reconnects to PC2 again (the last active session) ****NOK** (should reconnect o PC1) Auto-disconnect test =============== Disconnect PC1 again from LAN , and wait ---------------------------------------- RDP - triggers auto-re-connect and fails after 5 retries **OK After it fails (or cancel is clicked) - session is disconnected. **** ? Question:** can you check again for both PC1 and PC2? Comment - both RDP #number of retries and/or retry timeout - needs to be configurable in 1remote Edit: Looking @ help-about was the incorrect (old) version! ![Image](https://github.com/user-attachments/assets/aad5705b-e440-415c-a9b0-4410f17e5d12)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 10, 2025):

@rafi-d nope, there is the correct version: https://github.com/1Remote/1Remote/releases/tag/Nightly

@VShawn commented on GitHub (Mar 10, 2025): @rafi-d nope, there is the correct version: https://github.com/1Remote/1Remote/releases/tag/Nightly ![Image](https://github.com/user-attachments/assets/16637a5e-f4e3-4745-a649-88c8783f2dbe)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 10, 2025):

@rafi-d nope, there is the correct version: https://github.com/1Remote/1Remote/releases/tag/Nightly

This was the release taken from the zip above ...

@rafi-d commented on GitHub (Mar 10, 2025): > [@rafi-d](https://github.com/rafi-d) nope, there is the correct version: https://github.com/1Remote/1Remote/releases/tag/Nightly > > ![Image](https://github.com/user-attachments/assets/16637a5e-f4e3-4745-a649-88c8783f2dbe) This was the release taken from the zip above ...

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 10, 2025):

This was the release taken from the zip above ...

I think the old build kept running in the system tray. In that case, the old one would stay even if you ran a different build of the exe. Please exit the old one completely.

@itagagaki commented on GitHub (Mar 10, 2025): > This was the release taken from the zip above ... I think the old build kept running in the system tray. In that case, the old one would stay even if you ran a different build of the exe. Please exit the old one completely.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 10, 2025):

@rafi-d

This was the release taken from the zip above ...

Attention to the compilation time 2025-03-09 means it is the latest. i forgot to edit the version number.

@VShawn commented on GitHub (Mar 10, 2025): @rafi-d > This was the release taken from the zip above ... Attention to the compilation time 2025-03-09 means it is the latest. i forgot to edit the version number.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 10, 2025):

Yes, the old one was running too, at the same time. I'll retest to make sure.

@rafi-d commented on GitHub (Mar 10, 2025): Yes, the old one was running too, at the same time. I'll retest to make sure.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 10, 2025):

The tests with the new (correct ) version) - shows correct re-connection in the previous test (always checking the primary first).

Two issues - A. Just disconnect the physical LAN cable and let it try to re-connect with RDP. After the 5th try - it hangs up
B. It also shows a blank tab if you click "cancel" during the RDP retries . Not a big deal, reconnect works after that.
alternative title - shows BOTH the primary and alternative. I don't mind, but it might not be as designed...

@rafi-d commented on GitHub (Mar 10, 2025): The tests with the new (correct ) version) - shows correct re-connection in the previous test (always checking the primary first). 1. Two issues - A. Just disconnect the physical LAN cable and let it try to re-connect with RDP. After the 5th try - it hangs up B. It also shows a blank tab if you click "cancel" during the RDP retries . Not a big deal, reconnect works after that. 2. alternative title - shows BOTH the primary and alternative. I don't mind, but it might not be as designed... ![Image](https://github.com/user-attachments/assets/9a249d09-08e1-4f07-b635-efd594d84ebe) ![Image](https://github.com/user-attachments/assets/eeee9a49-9389-4a5a-99e5-23e9fca6fd75)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 13, 2025):

After the 5th try - it hangs up

What happens on my end after the 5th try is that the window closes in many cases. This is probably not the expected behavior. It used to happen frequently that the whole application would freeze and I could not do anything, but this has not happened recently. In any case, the behavior seems to be unstable.

It also shows a blank tab

I have only seen this once. However, the reproducibility of this also seems to be random.

For the title, I think the expected behavior is to be "MainName (AltHostName)".
@rafi-d In your example if MainName is “RAFI LT4 (Wired + WiFi)” and the name of the connected alternate host is “RAFI-HTPC (tes... this is the expected behavior.

@itagagaki commented on GitHub (Mar 13, 2025): > After the 5th try - it hangs up What happens on my end after the 5th try is that the window closes in many cases. This is probably not the expected behavior. It used to happen frequently that the whole application would freeze and I could not do anything, but this has not happened recently. In any case, the behavior seems to be unstable. > It also shows a blank tab I have only seen this once. However, the reproducibility of this also seems to be random. For the title, I think the expected behavior is to be "MainName (AltHostName)". @rafi-d In your example if MainName is “RAFI LT4 (Wired + WiFi)” and the name of the connected alternate host is “RAFI-HTPC (tes... this is the expected behavior.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 13, 2025):

Understood about the title. Yeah, there might be instability here

@rafi-d commented on GitHub (Mar 13, 2025): Understood about the title. Yeah, there might be instability here

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 13, 2025):

Comment - both RDP #number of retries and/or retry timeout - needs to be configurable in 1remote

Yeah, it would also be efficient to have that option when repeating this test many times.

@itagagaki commented on GitHub (Mar 13, 2025): > Comment - both RDP #number of retries and/or retry timeout - needs to be configurable in 1remote Yeah, it would also be efficient to have that option when repeating this test many times.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 14, 2025):

For the title, I think the expected behavior is to be "MainName (AltHostName)". @rafi-d In your example if MainName is “RAFI LT4 (Wired + WiFi)” and the name of the connected alternate host is “RAFI-HTPC (tes... this is the expected behavior.

We need to find a way to show/indicate which one is currently on display. The same string X (Y) for both is not a good way to do it.
Either display only the active one, or swap it X (Y [alt.]) or Y [alt.] (X) where the first is the active display.

@rafi-d commented on GitHub (Mar 14, 2025): > For the title, I think the expected behavior is to be "MainName (AltHostName)". [@rafi-d](https://github.com/rafi-d) In your example if MainName is “RAFI LT4 (Wired + WiFi)” and the name of the connected alternate host is “RAFI-HTPC (tes... this is the expected behavior. We need to find a way to show/indicate which one is currently on display. The same string X (Y) for both is not a good way to do it. Either display only the active one, or swap it X (Y [alt.]) or Y [alt.] (X) where the first is the active display.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 15, 2025):

about name

As it mentioned by itagagaki, the "Name" in Common refers to the server name. The "name" in the credentials only represents the credential name.

Therefore, it will be displayed as: Common Name(credential name)

For example:

The server first connect via frp so it named as Test(ViaFrp)

Later, I closed the frp and connected to the wifi, to simulated a network switch. after reconnecting, because I switched to credential LAN, title renamed to Test(LAN).

rdp auto retries..

I am still investigating how to handle the automatic reconnec feature by RDP.

@VShawn commented on GitHub (Mar 15, 2025): ## about name As it mentioned by itagagaki, the "Name" in Common refers to the server name. The "name" in the credentials only represents the credential name. Therefore, it will be displayed as: `Common Name(credential name)` For example: The server first connect via frp so it named as `Test(ViaFrp)` Later, I closed the frp and connected to the wifi, to simulated a network switch. after reconnecting, because I switched to credential `LAN`, title renamed to `Test(LAN)`. ![Image](https://github.com/user-attachments/assets/1247f241-1a0c-4e4f-9f33-3c83862f6819) ![Image](https://github.com/user-attachments/assets/2671deb8-efb2-4da3-9028-0246b07121ad) ## rdp auto retries.. I am still investigating how to handle the automatic reconnec feature by RDP.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 15, 2025):

I am still investigating how to handle the automatic reconnec feature by RDP.

this?
https://learn.microsoft.com/windows/win32/termserv/imsrdpclientadvancedsettings2

@itagagaki commented on GitHub (Mar 15, 2025): > I am still investigating how to handle the automatic reconnec feature by RDP. this? https://learn.microsoft.com/windows/win32/termserv/imsrdpclientadvancedsettings2

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 15, 2025):

As it mentioned by itagagaki, the "Name" in Common refers to the server name. The "name" in the credentials only represents the credential name.

Therefore, it will be displayed as: Common Name(credential name)

Got it.

@rafi-d commented on GitHub (Mar 15, 2025): > As it mentioned by itagagaki, the "Name" in Common refers to the server name. The "name" in the credentials only represents the credential name. > > Therefore, it will be displayed as: `Common Name(credential name)` Got it.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 15, 2025):

this?

yeap, to disabled the auto reconn feature of RDP and enumerate when to display the reconnect button upon RDP disconnection and when it can be closed directly, as the code block mentioned in #878

github.com/1Remote/1Remote@aa84184cdd/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.cs (L143-L184)

@VShawn commented on GitHub (Mar 15, 2025): > this? yeap, to disabled the auto reconn feature of RDP and enumerate when to display the reconnect button upon RDP disconnection and when it can be closed directly, as the code block mentioned in #878 https://github.com/1Remote/1Remote/blob/aa84184cdd40cfa73e745739912f32bce7fb670b/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.cs#L143-L184

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 26, 2025):

Oh, we can already specify maximum times that the RDP client control will retry to reconnect the session.

@itagagaki commented on GitHub (Mar 26, 2025): Oh, we can already specify maximum times that the RDP client control will retry to reconnect the session. ![Image](https://github.com/user-attachments/assets/5f12dc18-921f-4ecd-a69a-74411fa18acf)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Mar 26, 2025):

However, it only works in mstsc mode here, it is invalid under the tab window.

@VShawn commented on GitHub (Mar 26, 2025): However, it only works in mstsc mode here, it is invalid under the tab window.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Mar 26, 2025):

Oh, no?
It also worked as expected in non-mstsc.exe mode (tab window mode).

@itagagaki commented on GitHub (Mar 26, 2025): Oh, no? It also worked as expected in non-mstsc.exe mode (tab window mode).

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Mar 29, 2025):

So, I've tried the latest nightly now. Name(s) display as designed. I've set retries to 1 . The test is simple:

using my laptop, connected to wired network
The wired connection MAC is assigned some IP by the router and the Wifi conneciton MAC is assigned another IP
Wifi IP is defined as primary, Wired as secondary/alternate

Test steps are -

connect (to alternate/wired)
enable Wifi (using 1remote..)
immediately disable Wired connection in "network connections" and wait
The RDP auto-connect starts, and fails.

if I press reconnect during RDP reconnecting - it's fine - switching over and stops retires
if I just let it complete the retry - the program hangs up as "not responding" (I was hoping to get access to the tab "reconnect" button AFTER)

Screenshots:

Some minor findings - some Chinese text in confguration:

Maybe widen the advanced list to show all params letters?

Possibly add a mouse hover display of the tab name(s) so to see longer strings

@rafi-d commented on GitHub (Mar 29, 2025): So, I've tried the latest nightly now. Name(s) display as designed. I've set retries to 1 . The test is simple: * using my laptop, connected to wired network * The wired connection MAC is assigned some IP by the router and the Wifi conneciton MAC is assigned another IP * Wifi IP is defined as primary, Wired as secondary/alternate Test steps are - 1. connect (to alternate/wired) 2. enable Wifi (using 1remote..) 3. immediately disable Wired connection in "network connections" and wait The RDP auto-connect starts, **and fails.** * if I press **reconnect** during RDP reconnecting - it's fine - switching over and stops retires * if I just let it complete the retry - the program **hangs up** as "not responding" (I was hoping to get access to the tab "reconnect" button AFTER) Screenshots: ![Image](https://github.com/user-attachments/assets/d68b355a-bae7-4cf6-8c0c-7a1d4da6c370) ![Image](https://github.com/user-attachments/assets/6c6139c0-b007-4575-863e-27d44ad0cddd) Some minor findings - some Chinese text in confguration: ![Image](https://github.com/user-attachments/assets/21b26d8b-3e00-4daf-b298-4c914ef7ebcd) Maybe widen the advanced list to show all params letters? ![Image](https://github.com/user-attachments/assets/e00b1812-7351-4963-8a87-69c6175c46f9) Possibly add a mouse hover display of the tab name(s) so to see longer strings ![Image](https://github.com/user-attachments/assets/8c35184d-fcec-479e-a385-601963e4537b)

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@itagagaki commented on GitHub (Apr 6, 2025):

I followed rafi-d's test. It reproduced as he said it would.
Precisely as I stated in https://github.com/1Remote/1Remote/issues/869#issuecomment-2721521928.
I believe this is due to issue #878.
So let's work on it.

@itagagaki commented on GitHub (Apr 6, 2025): I followed rafi-d's test. It reproduced as he said it would. Precisely as I stated in https://github.com/1Remote/1Remote/issues/869#issuecomment-2721521928. I believe this is due to issue #878. So let's work on it.

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@VShawn commented on GitHub (Apr 8, 2025):

After giving it some thought, perhaps disabling the auto reconnection feature of RDP could be an option. All reconnections would then be controlled by 1Remote. it might help bypass the "not responding" issue. Although this may increase the workload

BTW：Some minor findings

Maybe widen the advanced list to show all params letters?
Possibly add a mouse hover display of the tab name(s) so to see longer strings
~~some Chinese text in confguration~~ WON'T FIX, That's what design is, the option only for Chinese USERS.

@VShawn commented on GitHub (Apr 8, 2025): After giving it some thought, perhaps disabling the auto reconnection feature of RDP could be an option. All reconnections would then be controlled by 1Remote. it might help bypass the "not responding" issue. Although this may increase the workload BTW：`Some minor findings` - [x] `Maybe widen the advanced list to show all params letters?` - [x] `Possibly add a mouse hover display of the tab name(s) so to see longer strings` - [ ] ~`some Chinese text in confguration`~ **WON'T FIX, That's what design is, the option only for Chinese USERS.**

kerem commented

2026-02-26 11:59:26 +03:00

Author

Owner

@rafi-d commented on GitHub (Apr 8, 2025):

Sound like a good idea. I guess RDP also has some internal workload allocated to connection checks, so yours will just replace it...

@rafi-d commented on GitHub (Apr 8, 2025): Sound like a good idea. I guess RDP also has some internal workload allocated to connection checks, so yours will just replace it...

kerem referenced this issue

2026-02-28 12:05:08 +03:00

[GH-ISSUE #704] [Feature request] 希望提供一个使用 Remote Destop 应用程序替代 mstsc 的选项，来改善 mstsc 存在的性能问题 #1540

kerem referenced this issue

2026-03-01 17:21:02 +03:00

[GH-ISSUE #704] [Feature request] 希望提供一个使用 Remote Destop 应用程序替代 mstsc 的选项，来改善 mstsc 存在的性能问题 #2501

kerem referenced this issue

2026-03-13 11:44:15 +03:00

[GH-ISSUE #704] [Feature request] 希望提供一个使用 Remote Destop 应用程序替代 mstsc 的选项，来改善 mstsc 存在的性能问题 #3498