github-starred/lan-mouse

Fork 0

mirror of https://github.com/feschber/lan-mouse.git synced 2026-05-15 06:06:07 -06:00

[GH-ISSUE #388] Development version releases capture immediately, returns "<device_name> entered this device" #200

New issue

Open

opened 2026-05-05 22:13:39 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 22:13:39 -06:00

Owner

Originally created by @penguinairlines on GitHub (Feb 13, 2026).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/388

Background

I'm just getting started with lan-mouse. Other, similar projects have not been working for me since switching from Windows 10, to Arch Hyprland, in October. Of course, I expect to run into some display management hurdles with the current shape of things, but overall, I'm fairly pleased with most things working as I expect.

I couldn't get the lan-mouse v0.10.0 client to properly handle the initial connection, so I'm here on the development version, trying to get something going. I wasn't able to get that released version to act as a server on my Arch system, and when I pointed both clients at each other, they were both acting like servers, but there were some weird things going on with my keyboard inputs, such as Shift not working. Anyway that's not in scope of this issue. The lack of "Incoming Connections" section, and meaningful connection logs made troubleshooting this version difficult, so I'm glad to see some improvements on the development version in this area.

Issue Description

When my mouse crosses the defined border, I immediately see a log about its return to the server. This happens whether I have configured computer A or computer B as the server. My logs look like this:

[2026-02-12T18:59:42Z INFO  lan_mouse::capture] client 0 acknowledged the connection!
[2026-02-12T18:59:42Z INFO  lan_mouse::service] entering client 0 ...
[2026-02-12T18:59:42Z INFO  lan_mouse::emulation] releasing capture: 192.168.0.37:50276 entered this device
[2026-02-12T18:59:42Z INFO  lan_mouse::capture] sending Leave event to client 0
[2026-02-12T18:59:42Z INFO  lan_mouse::capture] client 0 acknowledged the connection!
[2026-02-12T18:59:42Z INFO  lan_mouse::capture] client 0 acknowledged the connection!
[2026-02-12T18:59:42Z INFO  lan_mouse::service] entering client 0 ...
[2026-02-12T18:59:42Z INFO  lan_mouse::emulation] releasing capture: 192.168.0.37:50276 entered this device
[2026-02-12T18:59:42Z INFO  lan_mouse::capture] sending Leave event to client 0
[2026-02-12T18:59:42Z INFO  lan_mouse::capture] client 0 acknowledged the connection!
[2026-02-12T18:59:42Z INFO  lan_mouse::capture] client 0 acknowledged the connection!
[2026-02-12T18:59:42Z INFO  lan_mouse::service] entering client 0 ...
[2026-02-12T18:59:42Z INFO  lan_mouse::emulation] releasing capture: 192.168.0.37:50276 entered this device

I was able to install the client successfully on both systems, accept the client fingerprint, and theoretically establish a connection, but the mouse transition to the client seems to terminate instantly, regardless of the (border) position used (I tried all 4 sides, in case something was strange with my monitor profiles), or resetting the software.

It's interesting to me that the traffic returns on an ephemeral port 50276. Both of my software clients are set up as 4242, and I've made sure the Windows firewall has this port enabled inbound. When my Arch system is the server, it returns the same log with 56055 as the port. I assume this is just selecting some ephemeral port each time the service starts, but I wonder if this could be conflicting with my firewall.

It seems the reason why the mouse is returning to the server is that the client released the capture, but it happens so fast, and repeats thousands of times, while I'm continuously moving the mouse in the direction of the client, that I do not believe that this is the intended behavior. It produces this error at a rate of what seems like hundreds of times per second.

Expected Behavior

After a client has connected ( activated client 0 (left) ), I should be able to move my mouse to the client and see the core functionality of the software engage. Logs should demonstrate this.

Failing that, an error should appear stating the issue - what caused the same-millisecond return to the server display. This feels kind of idealistic when I read it back, but I'm not sure how else to say it. This unnatural behavior needs to be detected and handled somehow.

Perhaps the software could detect when these events repeat faster than a human could simulate.

Perhaps additional logs could detail why an ephemeral port was selected when the connection is established, so that the user can diagnose their firewall configuration.

Environment

lan-mouse-git v0.10.0.r75.gad63b6ba20-1 - downloaded 2/12/2026
Windows 11, latest stable build
Arch Hyprland
I'm using IP as hostname to avoid DNS issues while trying to set up this connection for the first time.

I'm happy to go try some more tests if anyone has suggestions. I know not to expect a working clipboard feature yet with lan-mouse, but getting my basic functionality back would be a big win for my daily workflow.

Originally created by @penguinairlines on GitHub (Feb 13, 2026). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/388 # Background I'm just getting started with lan-mouse. Other, similar projects have not been working for me since switching from Windows 10, to Arch Hyprland, in October. Of course, I expect to run into some display management hurdles with the current shape of things, but overall, I'm fairly pleased with most things working as I expect. I couldn't get the lan-mouse v0.10.0 client to properly handle the initial connection, so I'm here on the development version, trying to get something going. I wasn't able to get that released version to act as a server on my Arch system, and when I pointed both clients at each other, they were both acting like servers, but there were some weird things going on with my keyboard inputs, such as Shift not working. Anyway that's not in scope of this issue. The lack of "Incoming Connections" section, and meaningful connection logs made troubleshooting this version difficult, so I'm glad to see some improvements on the development version in this area. # Issue Description When my mouse crosses the defined border, I immediately see a log about its return to the server. This happens whether I have configured computer A or computer B as the server. My logs look like this: ``` [2026-02-12T18:59:42Z INFO lan_mouse::capture] client 0 acknowledged the connection! [2026-02-12T18:59:42Z INFO lan_mouse::service] entering client 0 ... [2026-02-12T18:59:42Z INFO lan_mouse::emulation] releasing capture: 192.168.0.37:50276 entered this device [2026-02-12T18:59:42Z INFO lan_mouse::capture] sending Leave event to client 0 [2026-02-12T18:59:42Z INFO lan_mouse::capture] client 0 acknowledged the connection! [2026-02-12T18:59:42Z INFO lan_mouse::capture] client 0 acknowledged the connection! [2026-02-12T18:59:42Z INFO lan_mouse::service] entering client 0 ... [2026-02-12T18:59:42Z INFO lan_mouse::emulation] releasing capture: 192.168.0.37:50276 entered this device [2026-02-12T18:59:42Z INFO lan_mouse::capture] sending Leave event to client 0 [2026-02-12T18:59:42Z INFO lan_mouse::capture] client 0 acknowledged the connection! [2026-02-12T18:59:42Z INFO lan_mouse::capture] client 0 acknowledged the connection! [2026-02-12T18:59:42Z INFO lan_mouse::service] entering client 0 ... [2026-02-12T18:59:42Z INFO lan_mouse::emulation] releasing capture: 192.168.0.37:50276 entered this device ``` I was able to install the client successfully on both systems, accept the client fingerprint, and theoretically establish a connection, but the mouse transition to the client seems to terminate instantly, regardless of the (border) position used (I tried all 4 sides, in case something was strange with my monitor profiles), or resetting the software. It's interesting to me that the traffic returns on an ephemeral port 50276. Both of my software clients are set up as 4242, and I've made sure the Windows firewall has this port enabled inbound. When my Arch system is the server, it returns the same log with 56055 as the port. I assume this is just selecting some ephemeral port each time the service starts, but I wonder if this could be conflicting with my firewall. It seems the reason why the mouse is returning to the server is that the client released the capture, but it happens so fast, and repeats thousands of times, while I'm continuously moving the mouse in the direction of the client, that I do not believe that this is the intended behavior. It produces this error at a rate of what seems like hundreds of times per second. # Expected Behavior After a client has connected ( `activated client 0 (left)` ), I should be able to move my mouse to the client and see the core functionality of the software engage. Logs should demonstrate this. Failing that, an error should appear stating the issue - what caused the same-millisecond return to the server display. This feels kind of *idealistic* when I read it back, but I'm not sure how else to say it. This unnatural behavior needs to be detected and handled somehow. Perhaps the software could detect when these events repeat faster than a human could simulate. Perhaps additional logs could detail why an ephemeral port was selected when the connection is established, so that the user can diagnose their firewall configuration. # Environment lan-mouse-git v0.10.0.r75.gad63b6ba20-1 - downloaded 2/12/2026 Windows 11, latest stable build Arch Hyprland I'm using IP as hostname to avoid DNS issues while trying to set up this connection for the first time. I'm happy to go try some more tests if anyone has suggestions. I know not to expect a working clipboard feature yet with lan-mouse, but getting my basic functionality back would be a big win for my daily workflow.

gitea-mirror commented

2026-05-05 22:13:40 -06:00

Author

Owner

@feschber commented on GitHub (Feb 13, 2026):

Could you send a log from the remote device?
It feels like you are somehow routing events back to yourself ...

The port being ephemeral is expected. Since the encryption rewrite, the whole network model was rearchitected to a client-server model with the client being the device that sends input and the server being the on receiving input.

(Yes, the terminology is confusing here, since I'm also calling the remote controlled device "client" in the logs ...)

@feschber commented on GitHub (Feb 13, 2026): Could you send a log from the remote device? It feels like you are somehow routing events back to yourself ... The port being ephemeral is expected. Since the encryption rewrite, the whole network model was rearchitected to a client-server model with the client being the device that sends input and the server being the on receiving input. (Yes, the terminology is confusing here, since I'm also calling the remote controlled device "client" in the logs ...)

gitea-mirror commented

2026-05-05 22:13:42 -06:00

Author

Owner

@penguinairlines commented on GitHub (Feb 16, 2026):

Gotcha. Thank you for your direction! Your comments helped me to find my issue quickly.

So I was doing a very silly thing since I mixed up .37 and .77, so I had pointed the server at itself. This is why the system handed the connection back to itself instantly. Hopefully, the next dummy like me can find this issue and realize their problem.

I got it working with the Windows workstation acting as the server. Even Shift and Super work now!

Just trying to troubleshoot why I can't set the Arch system as the server, which would be my preference, as it's the desktop computer and always on. I know this is moving away from the original issue so feel free to tell me to open a new one if that's the policy around here.

Right now I'm getting

connecting to <hostname> ...
failed to connect to <hostname>:4242: `Connection timed out`

And interestingly, on the client

releasing capture: left remote client device region

but nothing else.

I cleared both fingerprints, since I was previously a dummy and saved my own fingerprint. Maybe an opportunity to detect that and let the client know they may have accidentally just done something silly.

When the Windows system is the server, I got the opportunity to add its fingerprint to the Arch system. Then I turn the connection off on Windows, turn it on on Arch, and get the errors seen above when moving the arch mouse to the border position.

When I close the Windows client, I see releasing keys: <hostname>:55485 not responding! in the Arch server logs.

I'm wondering if my company's security software (Carbon Black Cloud Sensor) may be blocking the server's connection request. Is there some detailed documentation about how the connection is established?

Edit > my Security analyst tells me that CB is not blocking it, but their software is detecting it as a keylogger risk. I figure that's because of the hooks into the keyboard stream, but I'd appreciate any explanation/documentation I can take back to them about the security concerns a traditionally compliant organization needs to manage.

@penguinairlines commented on GitHub (Feb 16, 2026): Gotcha. Thank you for your direction! Your comments helped me to find my issue quickly. So I was doing a very silly thing since I mixed up .37 and .77, so I had pointed the server at itself. This is why the system handed the connection back to itself instantly. Hopefully, the next dummy like me can find this issue and realize their problem. I got it working with the Windows workstation acting as the server. Even Shift and Super work now! Just trying to troubleshoot why I can't set the Arch system as the server, which would be my preference, as it's the desktop computer and always on. I know this is moving away from the original issue so feel free to tell me to open a new one if that's the policy around here. Right now I'm getting ``` connecting to <hostname> ... failed to connect to <hostname>:4242: `Connection timed out` ``` And interestingly, on the client ``` releasing capture: left remote client device region ``` but nothing else. I cleared both fingerprints, since I was previously a dummy and saved my own fingerprint. Maybe an opportunity to detect that and let the client know they may have accidentally just done something silly. When the Windows system is the server, I got the opportunity to add its fingerprint to the Arch system. Then I turn the connection off on Windows, turn it on on Arch, and get the errors seen above when moving the arch mouse to the border position. When I close the Windows client, I see `releasing keys: <hostname>:55485 not responding!` in the Arch server logs. I'm wondering if my company's security software (Carbon Black Cloud Sensor) may be blocking the server's connection request. Is there some detailed documentation about how the connection is established? Edit > my Security analyst tells me that CB is not blocking it, but their software is detecting it as a keylogger risk. I figure that's because of the hooks into the keyboard stream, but I'd appreciate any explanation/documentation I can take back to them about the security concerns a traditionally compliant organization needs to manage.