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 #248] No client authorization request coming through #118

New issue

Closed

opened 2026-05-05 22:10:18 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 22:10:18 -06:00

Owner

Originally created by @Horghski on GitHub (Jan 12, 2025).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/248

I'm trying to get lan-mouse working between an Arch Linux "server" and a Windows 11 "client" on my home network. The Linux box is on a wired connection while the Windows 11 laptop is on wireless, but within the same subnet. As far as I know I don't have any firewalls in place. I'm able to start lan-mouse on both devices, but after that I'm not sure what to do as the GitHub instructions are a little vague.

On the Linux server, I start lan-mouse, it says it is using port 4242, so I hit the + to add a new connection and enter the hostname of the Laptop, which seems to get looked up correctly when I click the little button in the upper right of the connection session. That turns green, so I then flip the slider to "on" and... nothing happens.

I try the same on the Windows client, but this time enter the Linux hostname (which again seems to be looked up correctly in DNS) and nothing. Is there an "Apply" or "Connect" button somewhere that I'm not seeing? I'm expecting to see some sort of authorization, but nothing is popping up.

Ideally I want the Linux box to run lan-mouse in daemon mode and for the Windows client to connect when the laptop is booted, so I can control the laptop via the Linux box mouse/keyboard. So should I have an entry for the other one in each of the lan-mouse instances, or just on the client, or what?

Edit: When I add the laptop as a connection in the Linux lan-mouse GUI, then scroll my mouse to the edge where I would expect it to hop over to the Windows machine, I now see this error repeatedly in the Windows shell that lan-mouse starts:

[2025-01-12T00:05:09Z WARN lan_mouse::server::emulation_task] network error: network error: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself. (os error 10040)

Originally created by @Horghski on GitHub (Jan 12, 2025). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/248 I'm trying to get lan-mouse working between an Arch Linux "server" and a Windows 11 "client" on my home network. The Linux box is on a wired connection while the Windows 11 laptop is on wireless, but within the same subnet. As far as I know I don't have any firewalls in place. I'm able to start lan-mouse on both devices, but after that I'm not sure what to do as the GitHub instructions are a little vague. On the Linux server, I start lan-mouse, it says it is using port 4242, so I hit the + to add a new connection and enter the hostname of the Laptop, which seems to get looked up correctly when I click the little button in the upper right of the connection session. That turns green, so I then flip the slider to "on" and... nothing happens. I try the same on the Windows client, but this time enter the Linux hostname (which again seems to be looked up correctly in DNS) and nothing. Is there an "Apply" or "Connect" button somewhere that I'm not seeing? I'm expecting to see some sort of authorization, but nothing is popping up. Ideally I want the Linux box to run lan-mouse in daemon mode and for the Windows client to connect when the laptop is booted, so I can control the laptop via the Linux box mouse/keyboard. So should I have an entry for the other one in each of the lan-mouse instances, or just on the client, or what? Edit: When I add the laptop as a connection in the Linux lan-mouse GUI, then scroll my mouse to the edge where I would expect it to hop over to the Windows machine, I now see this error repeatedly in the Windows shell that lan-mouse starts: [2025-01-12T00:05:09Z WARN lan_mouse::server::emulation_task] network error: network error: `A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself. (os error 10040)`

gitea-mirror closed this issue

2026-05-05 22:10:19 -06:00

gitea-mirror commented

2026-05-05 22:10:21 -06:00

Author

Owner

@Horghski commented on GitHub (Jan 12, 2025):

Ok, I think I figured something out... the version in Arch is actually 0.9.1, while I grabbed version 0.10 for Windows. I just downloaded version 0.9.1 for Windows and now things are working.

However, I would still like to understand, does each lan-mouse instance (so on the server and the client) have to have a configuration for the other one? Meaning, does my server have to have the client configured to the "right" and my client has to have the server configured to the "left", for example? Or can you just have the configuration on one of the machines (server?) and have the other (client) just listen?

Either way, I still haven't seen any authorization requests, the cursor just works across the devices now.

@Horghski commented on GitHub (Jan 12, 2025): Ok, I think I figured something out... the version in Arch is actually 0.9.1, while I grabbed version 0.10 for Windows. I just downloaded version 0.9.1 for Windows and now things are working. However, I would still like to understand, does each lan-mouse instance (so on the server and the client) have to have a configuration for the other one? Meaning, does my server have to have the client configured to the "right" and my client has to have the server configured to the "left", for example? Or can you just have the configuration on one of the machines (server?) and have the other (client) just listen? Either way, I still haven't seen any authorization requests, the cursor just works across the devices now.

gitea-mirror commented

2026-05-05 22:10:21 -06:00

Author

Owner

@MatteoGalletta commented on GitHub (Feb 16, 2025):

I have the same problem. Fixed using 0.10 for both devices but I still don't see any incoming authorization request.

@MatteoGalletta commented on GitHub (Feb 16, 2025): I have the same problem. Fixed using 0.10 for both devices but I still don't see any incoming authorization request.

gitea-mirror commented

2026-05-05 22:10:22 -06:00

Author

Owner

@feschber commented on GitHub (Feb 16, 2025):

However, I would still like to understand, does each lan-mouse instance (so on the server and the client) have to have a configuration for the other one? Meaning, does my server have to have the client configured to the "right" and my client has to have the server configured to the "left", for example? Or can you just have the configuration on one of the machines (server?) and have the other (client) just listen?

In the latest git version this has changed. <= 0.10 you have to add the devices on both sides, now (with encryption) you only need to add the device you want to control and authorize the controling device on the other end.

@feschber commented on GitHub (Feb 16, 2025): > However, I would still like to understand, does each lan-mouse instance (so on the server and the client) have to have a configuration for the other one? Meaning, does my server have to have the client configured to the "right" and my client has to have the server configured to the "left", for example? Or can you just have the configuration on one of the machines (server?) and have the other (client) just listen? In the latest git version this has changed. <= 0.10 you have to add the devices on both sides, now (with encryption) you only need to add the device you want to control and *authorize* the controling device on the other end.

gitea-mirror commented

2026-05-05 22:10:25 -06:00

Author

Owner

@feschber commented on GitHub (Feb 16, 2025):

@MatteoGalletta There is no such thing as an authorization request at the moment. If a device is not authorized it simply will fail to connect (the only thing that happens is a log message printed saying "accept: expected and actual verify data does not match").

@feschber commented on GitHub (Feb 16, 2025): @MatteoGalletta There is no such thing as an authorization request at the moment. If a device is not authorized it simply will fail to connect (the only thing that happens is a log message printed saying "accept: expected and actual verify data does not match").

gitea-mirror commented

2026-05-05 22:10:26 -06:00

Author

Owner

@MatteoGalletta commented on GitHub (Feb 16, 2025):

I saw the screenshot in the readme and I was expecting something similar

@MatteoGalletta commented on GitHub (Feb 16, 2025): I saw the screenshot in the readme and I was expecting something similar

gitea-mirror commented

2026-05-05 22:10:26 -06:00

Author

Owner

@feschber commented on GitHub (Feb 16, 2025):

It will look like that in the latest git version. However you dont get a popup or new client appearing when you try to connect. The "authorize" section simply is a list of public key fingerprints that you can manually configure. (for now)

@feschber commented on GitHub (Feb 16, 2025): It will look like that in the latest git version. However you dont get a popup or new client appearing when you try to connect. The "authorize" section simply is a list of public key fingerprints that you can manually configure. (for now)

gitea-mirror commented

2026-05-05 22:10:27 -06:00

Author

Owner

@feschber commented on GitHub (Mar 23, 2025):

latest git version now has this feature, if you want to check it out ;)
I will close this issue for now

@feschber commented on GitHub (Mar 23, 2025): latest git version now has this feature, if you want to check it out ;) I will close this issue for now

gitea-mirror referenced this issue

2026-05-05 22:16:03 -06:00

[PR #118] [MERGED] Separate config state #291