Unfortunately, there is something else wrong, still. Here’s one entry after a bunch of STATUS lines:
2026-10-27 17:11:45: Internet mode not enabled
2026-10-27 17:11:46: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:47: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:48: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:49: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:50: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:51: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:52: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:53: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:54: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:54: Client timeout in ClientConnector::Run
2026-10-27 17:11:55: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:56: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-27 17:11:57: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
“Client timeout in ClientConnector::Run” — not sure, what that means.
Every so often I see this in the client debug log:
2026-10-28 12:46:21: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:22: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:23: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:24: ClientService cmd: STATUS#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:24: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:25: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:26: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:27: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:28: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:29: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:30: Looking for old Sessions... 0 sessions
2026-10-28 12:46:30: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:31: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 12:46:32: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
“Looking for old Sessions… 0 sessions” — that does not look like it might provide a clue as to what is wrong.
I tried one more thing you had suggested in an earlier post in this thread: add a client hint by using its IP address. Lo and behold, it’s doing it now:
2026-10-28 23:50:09: ClientService cmd: #I7O5H5vsYDBGhNtGcVl9R#ADD IDENTITY
2026-10-28 23:50:09: rc=0 hasError=true state=0
2026-10-28 23:50:09: ClientService cmd: #I7O5H5vsYDBGhNtGcVl9R#GET CHALLENGE with_enc=1
2026-10-28 23:50:09: rc=0 hasError=true state=0
2026-10-28 23:50:09: ClientService cmd: #I7O5H5vsYDBGhNtGcVl9R#SIGNATURE#pubkey=MIIBtzCCASsGByqGSM44BAEwggEeAoGBAPGTKAA/1boI0DSwkV7upNM38Ml7TR2X1g8hKChNAiHfL22JwkwJwV6HFFC4Hr5r0ZjRd+U9QrT7yga/eHICB6wkmsSeUHlwa02dODEXk4FN9FYdOapIr4WQLpm+XqlfTPkA4vc4MZiig5neuxbEKoCjpoqg3jPHMCqdI+1kcgV1AhUAwDLv548S/icgtQowKPc/s4qqfA0CgYBUBVv84zkvYfHA2dioS4lbmpCBar41TgI/NYuxhewpBpbh4HYxrYduZWQ3N5ukqvm5euUECi7irU3nvEWIDNf24HzHyGMKJkGnSBfpzJ3FS7RbuTjIE70Ln/31jl2jwie99jmRJ3sjhleoEV33R3QVGmMjhAjN0R2LxpNj4YKZ0gOBhQACgYEAiseG9cfCbpJPqAY5isPCfG+nJ1J+xcKAcdNxbvfnfHFjvN7EXOS5DvKPaSi0HKjm6yDtVSwkPdm/iDswzVrQ/1mArX05VwlWEBBgtYl4sg6SvzsWJPbkE3PqieuIODPkH0XB2dN5LCg79l3DV63hfrsZPlyYsYPvjHy+25HZcy8-&pubkey_ecdsa409k1=MH4wEAYHKoZIzj0CAQYFK4EEACQDagAEALSazd0BvsESwVEJJ/raOJ8jadzS/ztRuKF3lL4SyfUzVeiqnRHqt1VvMZ7N+ZxXDMfUIgFn1HtJfz8GPYLYBSRuLsVXgj5pn2b+bgKvswBQz7oi6p7LyK/hTzxGNseqhN7wkg2rXXE-&signature=sPE9JbcKM1V6JhAnCsHVwjwfElYHcwnW7LlIiGMVEWesrNQir6Ve1Q--&signature_ecdsa409k1=GFeWJySTRLCJhY3Ql/DKiA1lOQ5KU1PTJGvmBRnTx4oGiDBpMplVeSOv1VJeJ3JuUQLwGAJi7UiKO3rfstvjkPKRMfO5phU8cg9EYsH4SLi0wP3/fDljHb1UsC/DXf6BRHp8u7BN&session_identity=qUdtpv6E0A40ElX5qehU&secret_session_key=0x9nKShSY9G22i72+SmCwY9ex8qNjaN5JX9u9B2XMxdLBcNjJ2q4qFe7ZuI2Om6EDBwNJsoO71nkbvFYC8M07Q--&pubkey_ecdh233k1=BAHDV6f9fFsQaZ55sfL48mvFy4UQPmUqvjniImKX1gFE3MReHrqlYUi8z/Ah8NtokgiOo2g0bVMLmMR+fg--&signature_ecdh233k1=QsFTvgt9VneA7/rzL4np/dBaxMRvrzyJ47e+SNlXgcSWHn9DRpW/XnwJ58ETt47fkCHRE+ifXegXBth+F1ciKqXSlsVGJKZ80wE9GtDK6urewVg0UsZJagLyA5IFEyY6KzHEDlXp
2026-10-28 23:50:09: rc=0 hasError=true state=0
2026-10-28 23:50:09: ClientService cmd: #IqUdtpv6E0A40ElX5qehU#ENC?keyadd=6q0H4MpqcW01zlQNtR41hnHC4moAAAAA&compress=zstd&compress_level=6
2026-10-28 23:50:09: Encrypting with key +ANmb1ol4zHREzchEhBgYUB0nnhTqRD0mbPLir0+E8TqrQfgympxbTXOVA21HjWGccLiagAAAABXKjavONP59ngo+JiNZ6M/ (client)
2026-10-28 23:50:09: ClientService cmd: #IqUdtpv6E0A40ElX5qehU#CAPA
2026-10-28 23:50:09: ClientService cmd: STATUS DETAIL#pw=1ijqihkdZgV8rHvG7ya0etFA300wmD
2026-10-28 23:50:09: rc=0 hasError=true state=0
2026-10-28 23:50:09: ClientService cmd: #IqUdtpv6E0A40ElX5qehU#ENC?keyadd=bxkCwq9s9hbAnuTeTrPcO3HC4moAAAAA&compress=zstd&compress_level=6
2026-10-28 23:50:09: Encrypting with key +ANmb1ol4zHREzchEhBgYUB0nnhTqRD0mbPLir0+E8RvGQLCr2z2FsCe5N5Os9w7ccLiagAAAAA9rRwyy1Hd6i7cp6c/la2l (client)
2026-10-28 23:50:09: ClientService cmd: #IqUdtpv6E0A40ElX5qehU#ENC?keyadd=ydQZaMQfeu74P8ycs3VA93HC4moAAAAA&compress=zstd&compress_level=6
2026-10-28 23:50:09: Encrypting with key +ANmb1ol4zHREzchEhBgYUB0nnhTqRD0mbPLir0+E8TJ1BloxB967vg/zJyzdUD3ccLiagAAAADCHdOguXdH6bgsHK4WXsJc (client)
2026-10-28 23:50:09: ClientService cmd: #IqUdtpv6E0A40ElX5qehU#FILESRV
2026-10-28 23:50:09: Start FILESRV thread
2026-10-28 23:50:09: ClientService cmd: #IqUdtpv6E0A40ElX5qehU#1CHANNEL capa=0&token=Vc2zOTf0uDDttUhY7gPx&restore_version=1&startup=1&virtual_client=
2026-10-28 23:50:09: FileSRV received 73
2026-10-28 23:50:09: FileSrv: Received data...
2026-10-28 23:50:09: FileSrv: Received a Packet.
2026-10-28 23:50:09: FileSrv: Sending file (normal) urbackup/settings.cfg metadata_id=0
2026-10-28 23:50:09: FileSrv: Mapped name: C:\Program Files\UrBackup\urbackup\data\settings.cfg
2026-10-28 23:50:09: FileSrv: Reading last file part
2026-10-28 23:50:09: FileSrv: Info: File End
2026-10-28 23:50:09: FileSrv: Closed file.
2026-10-28 23:50:09: FileSRV received 21
2026-10-28 23:50:09: FileSrv: Received data...
2026-10-28 23:50:09: FileSrv: Received a Packet.
2026-10-28 23:50:09: Received flush.
2026-10-28 23:50:09: FileSrv: Recv Error in RecvMessage
2026-10-28 23:50:09: FileSrv: Deleting Memory...
2026-10-28 23:50:09: FileSrv: done.
2026-10-28 23:50:09: New channel: Number of Channels: 1
Neither of those lines is an error. “Client timeout in ClientConnector::Run” means the client closed a connection that had been idle for a while, usually the one from the tray icon. “Looking for old Sessions” is routine cleanup.
Two things I noticed. The pw= value in these STATUS lines (1ijq…) is different from the one in your earlier logs (Bs6u…), so these look like they come from another PC or a reinstall. And the first excerpt is from the 27th, before you turned the firewall off. Which PC are they from?
Your screenshot from 1:05 PM still shows “Online: No” for 192.168.57.25, so the server didn’t find the PC even with the firewall off. Some questions to narrow it down:
- Does any client at that location show up on that server, or none at all? If none, the problem is on the server side, not the PCs.
- In the server log, is there a “New Backupclient:” line at all after you added the IP hint?
- On the PC, what does “Get-NetConnectionProfile” in PowerShell show under NetworkCategory? If it says Public or DomainAuthenticated, turning off the firewall for private networks doesn’t affect that connection.
20:50:09: New Backupclient: BosGamePC
20:50:09: Starting scheduled full file backup...
20:50:24: Indexing of "C" done. 2943 filesystem lookups 0 db lookups and 0 db updates
20:50:24: BosGamePC: Loading file list...
20:50:24: BosGamePC: Started loading files...
20:50:44: Waiting for file transfers...
20:50:48: Waiting for file hashing and copying threads...
20:50:48: Encryption overhead: 1.02832 KB
20:50:51: Writing new file list...
20:50:51: All metadata was present
20:50:52: Encryption overhead: 195.442 KB
20:50:52: Transferred 1.18878 GB - Average speed: 429.38 MBit/s
20:50:52: (Before compression: 1.808 GB ratio: 1.5209)
20:50:59: Time taken for backing up client BosGamePC: 50s
20:50:59: Backup succeeded
20:50:59: Updating statistics...
20:50:59: Updating image stats...
20:50:59: Updating file statistics...
20:51:00: Updating file statistics: 11%
20:51:00: Updating file statistics: 22%
20:51:00: File processing speed: 3.001e+06 files/s
20:51:00: Updating file statistics: 33%
20:51:00: Updating file statistics: 45%
20:51:00: File processing speed: 2e+06 files/s
20:51:00: Updating file statistics: 56%
20:51:00: Updating file statistics: 67%
20:51:00: Updating file statistics: 78%
20:51:00: File processing speed: 3e+06 files/s
20:51:00: Updating file statistics: 89%
20:51:00: Done updating statistics.
20:51:50: ERROR: Error sending client access key
20:51:50: server_prepare_hash Thread finished (exit)
20:51:50: server_hash Thread finished - normal
20:51:50: Starting scheduled incremental image backup of volume "C:"...
20:51:50: Starting scheduled full image backup of volume "SYSVOL"...
20:51:57: Encryption overhead: 125.531 KB
20:52:01: Transferred 774.824 MB - Average speed: 556.862 MBit/s
20:52:01: (Before compression: 793.03 MB ratio: 1.0235)
20:52:01: Updating statistics...
20:52:01: Updating image stats...
20:52:01: Updating file statistics...
20:52:01: Done updating statistics.
20:52:02: Starting scheduled full image backup of volume "ESP"...
20:52:02: Encryption overhead: 3.0791 KB
20:52:04: Transferred 26.6853 MB - Average speed: 94.9333 MBit/s
20:52:04: (Before compression: 200.412 MB ratio: 7.5102)
20:52:04: Updating statistics...
20:52:04: Updating image stats...
20:52:04: Updating file statistics...
20:52:04: Done updating statistics.
20:52:05: Basing image backup on last incremental or full image backup
20:52:05: WARNING: Error retrieving last image backup. Doing full image backup instead.
20:54:40: Encryption overhead: 2.11386 MB
20:56:07: Encryption overhead: 1.22745 MB
20:56:09: Transferred 24.7045 GB - Average speed: 867.103 MBit/s
20:56:09: (Before compression: 40.6094 GB ratio: 1.64381)
20:56:09: Time taken for backing up client BosGamePC: 4m 19s
20:56:09: Backup succeeded
20:56:09: Updating statistics...
20:56:09: Updating image stats...
20:56:09: Updating file statistics...
20:56:09: Done updating statistics.
20:58:59: Socket has error: 111
20:59:44: Starting unscheduled full file backup...
20:59:53: Indexing of "C" done. 2943 filesystem lookups 0 db lookups and 0 db updates
20:59:53: BosGamePC: Loading file list...
20:59:53: Encrypting with key r5OT5oSKjDAXbkck44WIeiccWyhbbowyfKOl1GDII5qorJXstD7REaCDX3TGkyqFucTiagAAAADMmQ2GzkUDDs0LrIGYXr8Q (server)
20:59:53: BosGamePC: Started loading files...
21:00:10: Waiting for file transfers...
21:00:15: Waiting for file hashing and copying threads...
21:00:15: Encryption overhead: 1.02832 KB
21:01:17: Writing new file list...
21:01:18: All metadata was present
21:01:18: Encryption overhead: 195.565 KB
21:01:18: Transferred 1.18862 GB - Average speed: 465.302 MBit/s
21:01:18: (Before compression: 1.80821 GB ratio: 1.52128)
21:01:24: Time taken for backing up client BosGamePC: 1m 40s
21:01:24: Backup succeeded
21:01:24: Updating statistics...
21:01:24: Updating image stats...
21:01:24: Updating file statistics...
21:01:24: File processing speed: 1.60239 files/s
21:01:24: Updating file statistics: 26%
21:01:24: Updating file statistics: 52%
21:01:24: File processing speed: 2e+06 files/s
21:01:24: Updating file statistics: 79%
21:01:24: Done updating statistics.
21:01:25: server_prepare_hash Thread finished (exit)
21:01:25: server_hash Thread finished - normal
So, when it was done, I turned the firewall back on (Get-NetConnectionProfile shows that the Ethernet interface is set to “private”). I tried doing an incremental file backup as initiated on the server on the Status page. It showed, “Starting backup failed.” So far, that’s expected. I then turned the Firewall off again, for the Ethernet interface. I can still not get the server to initiate a backup.
By the way, there is a UrBackup rule in the firewall:
Should that not do, even with the firewall running? Apart from that rule, that host had a fresh copy of Windows 11 Pro installed and was updated to 26200.9711.
Those are from my two different locations being backed up by UrBackup. The original one was not available at the time, which is why I continued demonstrating symptoms on the other system.
Good news: the IP hint was the missing piece. The log shows the server found BosGamePC, and the file and image backups all succeeded. So the name hint wasn’t resolving on the server, and the IP hint gets around that.
“Starting backup failed” on the Status page only means the server thinks the client is offline at that moment. It doesn’t say why. The server checks each client about every 20 seconds. After 5 missed checks in a row it drops the client (“Client exited: BosGamePC” in the server log). After that the client only comes back once the server finds it again (“New Backupclient: BosGamePC”). So after you turn the firewall back off, it can take a minute or two before a manual start works.
Some things to check:
- When you click start, does the Status page show “Online: Yes” for BosGamePC?
- After you turned the firewall off the second time, is there a new “New Backupclient: BosGamePC” line in the server log?
- The rule: in “Windows Defender Firewall with Advanced Security”, Inbound Rules, check that it is enabled, set to Allow, covers the Private profile, and points to C:\Program Files\UrBackup\UrBackupClientBackend.exe. Also look for any Block rule that mentions UrBackup. Windows creates one if someone clicked “Cancel” on the firewall prompt, and a block rule wins over an allow rule.
The “Error sending client access key” line doesn’t affect backups. It’s only used for the “Access/restore backups” link in the tray menu.
Going back to the system I did not have access to yesterday. I found the same UrBackupClientBackend rule there. Its profile was set to Public, which was the status of the Wi-Fi connection used during setup, before I set it to Private. I changed it to Private. I could not find any block rule affecting UrBackup.
On this system entering its IP address as a client discovery hint didn’t have any effect. The firewall for Private networks is still off.
Thanks. Since the firewall is off there, it’s probably not the firewall on this PC.
You run two servers, and that matters here. The client only accepts the first UrBackup server it ever talked to and rejects all others. If this PC was ever found by your other server (or the client was installed while that one was reachable), it will refuse this one. A server refused this way shows the client as “Online: Yes (Server rejected ?)” on its Status page. Your new NaN topic looks exactly like that.
Two things to check on this PC:
Client debug.log (C:\Program Files\UrBackup\debug.log): any “Rejected server identity” lines?
Status page of the server that should back it up: is the PC listed with “Server rejected”?
If yes, see the “Server rejected” entry in the server’s help page. The simplest fix is to stop the UrBackup client service, delete C:\Program Files\UrBackup\server_idents.txt, make sure only the right server can reach the PC, and start the service again. Or copy that server’s identity (shown on its admin page) into server_idents.txt.
If there’s nothing like that: from the server, does nc -vz 35621 connect?
truenas_admin@truenasmini[~]$ nc -vz 192.168.1.35 35621
Connection to 192.168.1.35 35621 port [tcp/*] succeeded!
I got my client WinServer to get backed up again. It was again after using its IP address as a client discovery hint. The next thing to try will be to turn the domain firewall back on and then to try to jump start the backup by submitting another client discovery hint. I will provide an update.
There is that one system at the other location, where that did not work. I’ll stick to one location at a time. I found myself being really confused about what I have tried in which location and on which host.
[some elapsed time]
The firewall on WinServer is fully up again. I added its IP address as a client discovery hint again and then requested an incremental file backup from the Status page of the server. The backup is happening now.
While it is working now, it would have been nice to know, why it requires that discovery hint in the first place. But I will leave well enough alone.
I will not leave the client at the other location that’s not backing up alone, however. More on that later.
Running urbackupsrv run -v debug in the UrBackup server container shell I get this:
# urbackupsrv run -v debug
Raising nice-ceiling to 35 failed. (errno=1)
2026-10-31 16:05:26: Starting HTTP-Server on port 55414
2026-10-31 16:05:26: ERROR: HTTP: Failed binding socket to port 55414. Another instance of this application may already be active and bound to this port.
2026-10-31 16:05:27: Started UrBackup...
2026-10-31 16:05:27: Removing temporary files...
2026-10-31 16:05:27: Recreating temporary folder...
Cannot become root user
2026-10-31 16:05:27: Image mounting disabled: Cannot become root user
2026-10-31 16:05:27: Testing if backup destination can handle subvolumes and snapshots...
Cannot become root user
2026-10-31 16:05:27: Backup destination cannot handle subvolumes and snapshots. Snapshots disabled.
2026-10-31 16:05:27: Testing if backup destination can handle filesystem transactions...
2026-10-31 16:05:27: Testing for hardlinks in backup destination...
2026-10-31 16:05:27: Could create hardlink at backup destination. Hardlinks enabled.
2026-10-31 16:05:27: Testing for reflinks in backup destination...
2026-10-31 16:05:27: Could create reflink at backup destination. Reflinks enabled.
2026-10-31 16:05:27: Binding to interface enp1s0 (ipv4) for broadcasting...
2026-10-31 16:05:27: Broadcasting on ipv4 interface enp1s0 addr 192.168.57.30
2026-10-31 16:05:27: Binding to interface br-68c106e3055a (ipv4) for broadcasting...
2026-10-31 16:05:27: Broadcasting on ipv4 interface br-68c106e3055a addr 172.16.1.1
2026-10-31 16:05:27: Binding to interface docker0 (ipv4) for broadcasting...
2026-10-31 16:05:27: Broadcasting on ipv4 interface docker0 addr 172.16.0.1
2026-10-31 16:05:27: Binding to interface enp1s0 (ipv6) for broadcasting...
2026-10-31 16:05:27: Broadcasting on ipv6 interface enp1s0 addr fe80::265e:beff:fe8e:7f9b
2026-10-31 16:05:27: Binding to interface docker0 (ipv6) for broadcasting...
2026-10-31 16:05:27: Broadcasting on ipv6 interface docker0 addr fdd0::1
2026-10-31 16:05:27: ERROR: InternetService: Failed binding socket to port 55415. Another instance of this application may already be active and bound to this port.
2026-10-31 16:05:27: UrBackup Server start up complete.
2026-10-31 16:05:27: Looking for old Sessions... 0 sessions
2026-10-31 16:05:27: ERROR: Failed binding SOCKET to Port 55413
2026-10-31 16:05:27: ERROR: Error while starting listening to ports. Stopping server.
2026-10-31 16:05:27: Exited Loop
2026-10-31 16:05:27: Deleting at..
2026-10-31 16:05:27: Deleting SelectThreads..
2026-10-31 16:05:27: Deleting lbs...
2026-10-31 16:05:27: Shutting down plugins...
2026-10-31 16:05:27: Deleting server...
Segmentation fault (core dumped)
Are there any clues there?
Why would the server broadcast on 172.16.x.x networks? I have the Host Network option selected in the configuration of the UrBackup Docker container:
The errors in that run come from starting a second server inside the container while the real one is already running. The ports are taken, so the new one stops (and crashes on the way out). That crash isn’t your problem. To get a debug log from the real server, change the container’s log level instead (I answered that in your Docker topic).
The 172.16.x.x lines are normal with host networking: the container sees all of the host’s interfaces, including Docker’s own bridges, and broadcasts on all of them. It’s harmless.
FirmLaptop3: your debug.log shows only the tray polling the client (STATUS). The server never connected at all. Since it’s at another location, the discovery hint has to get there and back over UDP 35622. Your nc test only checked TCP 35621, so a router or VPN that passes TCP but not UDP would explain it. For a PC at another site, the robust option is to make it an internet client: on the server, “Add client” → internet client, then use the client’s Internet settings with the server’s address and port 55415. That uses one outgoing TCP connection from the laptop and needs no discovery.
The server and FirmLaptop3 are both on the same subnet and physically close to each other. I will have to see, how I can change the initialization of the Docker container, so that I can get more verbose logging.
