[GH-ISSUE #307] lan-mouse doesn't seem to work well in poor network conditions. #157

New issue

Open

opened 2026-05-05 22:12:03 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

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

Owner

Originally created by @huangsijun17 on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/307

I use lan-mouse on my company's WiFi. Due to the large number of people and poor WiFi optimization, there is a certain packet loss rate. I found that my lan-mouse often reports errors and stops working. Until the controlled service is restarted. Does lan-mouse have no heartbeat and error reconnection mechanism?

[2025-07-01T02:05:26Z WARN  webrtc_util::conn::conn_udp_listener] ListenConfig pconn.recv_from error: io error: 远程主机强迫关闭了一个现有的连接。 (os error 10054)
[2025-07-01T02:05:31Z WARN  lan_mouse::emulation] releasing keys: 192.168.250.137:45599 not responding!

Originally created by @huangsijun17 on GitHub (Jul 1, 2025). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/307 I use lan-mouse on my company's WiFi. Due to the large number of people and poor WiFi optimization, there is a certain packet loss rate. I found that my lan-mouse often reports errors and stops working. Until the controlled service is restarted. Does lan-mouse have no heartbeat and error reconnection mechanism? ``` [2025-07-01T02:05:26Z WARN webrtc_util::conn::conn_udp_listener] ListenConfig pconn.recv_from error: io error: 远程主机强迫关闭了一个现有的连接。 (os error 10054) [2025-07-01T02:05:31Z WARN lan_mouse::emulation] releasing keys: 192.168.250.137:45599 not responding! ```

gitea-mirror commented

2026-05-05 22:12:05 -06:00

Author

Owner

@huangsijun17 commented on GitHub (Jul 1, 2025):

In addition, occasional packet loss can cause some keys to "not be released". For example, the command to press the Shift key is transmitted correctly, but the command to release it is not received. lan-mouse will cause the system to keep pressing the Shift key.

@huangsijun17 commented on GitHub (Jul 1, 2025): In addition, occasional packet loss can cause some keys to "not be released". For example, the command to press the Shift key is transmitted correctly, but the command to release it is not received. lan-mouse will cause the system to keep pressing the Shift key.

gitea-mirror commented

2026-05-05 22:12:06 -06:00

Author

Owner

@DrYak commented on GitHub (Jul 25, 2025):

Due to the large number of people and poor WiFi optimization, there is a certain packet loss rate.

Sadly, there is no way around these types of problem (short of plugging the laptop into corded network (*)).

The only thing one can influence is the specific flavor of failure mode the sharer goes into:

Lan-mouse uses small packets over UDP -- which is connectionless and doesn't any attempt at mitigating network unreliability.
In noisy networks, some packet will be lost and the motions will be missed.
The whole setup behaves exactly like a wireless USB and Keyboard in noisy radio environment and just drops inputs.
Synergy/Deskflow/waynergy/barrier/input-leap/etc. uses TCP -- which try to maintain guaranteed in-order delivery of data (using acks to confirm receive data, or re-sends in case of missing data, packets reordering).
In noisy networks, some packet will be lost and the TCP transport layer will eventually re-send anything missed and it will be reorder.
The whole setup will freeze, then suddenly it will "catch-up" in accelerated motion, then re-freeze... the whole setup will be very jerky

(I speak from experience, having using opensouce Synergy on noisy Wifi at conferences, before moving to Lan-mouse due to Wayland support coming there first).

TL;DR: input sharing will always suck on noisy Wifi, you're merely left chosing the specific type of suck (stopping vs. jerky pause and accelerate)

Does lan-mouse have no heartbeat and error reconnection mechanism?

UDP is connectionless.

What @feschber could do is add a configuration option for increasing the timeout until a client decides that the other side isn't there anymore if it hasn't heard from it recently enough.
But then it means that if the remote really isn't responding it's going to take a minute until the connection is dropped.

Note that I you want to play with it, there ways to forward UDP connections over e.g. a SSH-based tunnel, so you can enjoy the "jerky freeze and then suddenly re-accelerates" type of suck.

(*): such as plugging both into network ports of the same WiFi extender (such as the FRITZ!Repeater I am using home)

@DrYak commented on GitHub (Jul 25, 2025): > Due to the large number of people and poor WiFi optimization, there is a certain packet loss rate. Sadly, there is no way around these types of problem (short of plugging the laptop into corded network (*)). The only thing one can influence is the specific flavor of failure mode the sharer goes into: 1. Lan-mouse uses small packets over UDP -- which is connectionless and doesn't any attempt at mitigating network unreliability. In noisy networks, some packet will be lost and the motions will be missed. The whole setup behaves exactly like a wireless USB and Keyboard in noisy radio environment and just drops inputs. 2. Synergy/Deskflow/waynergy/barrier/input-leap/etc. uses TCP -- which try to maintain guaranteed in-order delivery of data (using acks to confirm receive data, or re-sends in case of missing data, packets reordering). In noisy networks, some packet will be lost and the TCP transport layer will eventually re-send anything missed and it will be reorder. The whole setup will freeze, then suddenly it will "_catch-up_" in accelerated motion, then re-freeze... the whole setup will be very jerky (I speak from experience, having using opensouce Synergy on noisy Wifi at conferences, before moving to Lan-mouse due to Wayland support coming there first). **TL;DR:** input sharing will _always_ suck on noisy Wifi, you're merely left chosing the _specific type of suck_ (stopping vs. jerky pause and accelerate) > Does lan-mouse have no heartbeat and error reconnection mechanism? UDP is connectionless. What @feschber could do is add a configuration option for increasing the timeout until a client decides that the other side isn't there anymore if it hasn't heard from it recently enough. But then it means that if the remote _really_ isn't responding it's going to take a minute until the connection is dropped. Note that I you want to play with it, there ways to forward UDP connections over e.g. a SSH-based tunnel, so you can enjoy the "jerky freeze and then suddenly re-accelerates" type of suck. --- (*): such as plugging both into network ports of the same WiFi extender (such as the FRITZ!Repeater I am using home)

gitea-mirror commented

2026-05-05 22:12:06 -06:00

Author

Owner

@feschber commented on GitHub (Apr 29, 2026):

might be relevant as well: #417

@feschber commented on GitHub (Apr 29, 2026): might be relevant as well: #417

gitea-mirror commented

2026-05-05 22:12:07 -06:00

Author

Owner

@huangsijun17 commented on GitHub (Apr 30, 2026):

Due to the large number of people and poor WiFi optimization, there is a certain packet loss rate.

Sadly, there is no way around these types of problem (short of plugging the laptop into corded network (*)).

The only thing one can influence is the specific flavor of failure mode the sharer goes into:

Lan-mouse uses small packets over UDP -- which is connectionless and doesn't any attempt at mitigating network unreliability.
In noisy networks, some packet will be lost and the motions will be missed.
The whole setup behaves exactly like a wireless USB and Keyboard in noisy radio environment and just drops inputs.

Synergy/Deskflow/waynergy/barrier/input-leap/etc. uses TCP -- which try to maintain guaranteed in-order delivery of data (using acks to confirm receive data, or re-sends in case of missing data, packets reordering).
In noisy networks, some packet will be lost and the TCP transport layer will eventually re-send anything missed and it will be reorder.
The whole setup will freeze, then suddenly it will "catch-up" in accelerated motion, then re-freeze... the whole setup will be very jerky

(I speak from experience, having using opensouce Synergy on noisy Wifi at conferences, before moving to Lan-mouse due to Wayland support coming there first).

TL;DR: input sharing will always suck on noisy Wifi, you're merely left chosing the specific type of suck (stopping vs. jerky pause and accelerate)

Does lan-mouse have no heartbeat and error reconnection mechanism?

UDP is connectionless.

What @feschber could do is add a configuration option for increasing the timeout until a client decides that the other side isn't there anymore if it hasn't heard from it recently enough. But then it means that if the remote really isn't responding it's going to take a minute until the connection is dropped.

Note that I you want to play with it, there ways to forward UDP connections over e.g. a SSH-based tunnel, so you can enjoy the "jerky freeze and then suddenly re-accelerates" type of suck.

(*): such as plugging both into network ports of the same WiFi extender (such as the FRITZ!Repeater I am using home)

I used AI to analyze the code a few days ago, and it seems to be an issue where the port wasn't released after the connection was forcibly disconnected. Since I know absolutely nothing about Rust, I haven't pushed to merge this AI-analyzed code.

@huangsijun17 commented on GitHub (Apr 30, 2026): > > Due to the large number of people and poor WiFi optimization, there is a certain packet loss rate. > > Sadly, there is no way around these types of problem (short of plugging the laptop into corded network (*)). > > The only thing one can influence is the specific flavor of failure mode the sharer goes into: > > 1. Lan-mouse uses small packets over UDP -- which is connectionless and doesn't any attempt at mitigating network unreliability. > In noisy networks, some packet will be lost and the motions will be missed. > The whole setup behaves exactly like a wireless USB and Keyboard in noisy radio environment and just drops inputs. > 2. Synergy/Deskflow/waynergy/barrier/input-leap/etc. uses TCP -- which try to maintain guaranteed in-order delivery of data (using acks to confirm receive data, or re-sends in case of missing data, packets reordering). > In noisy networks, some packet will be lost and the TCP transport layer will eventually re-send anything missed and it will be reorder. > The whole setup will freeze, then suddenly it will "_catch-up_" in accelerated motion, then re-freeze... the whole setup will be very jerky > > (I speak from experience, having using opensouce Synergy on noisy Wifi at conferences, before moving to Lan-mouse due to Wayland support coming there first). > > **TL;DR:** input sharing will _always_ suck on noisy Wifi, you're merely left chosing the _specific type of suck_ (stopping vs. jerky pause and accelerate) > > > Does lan-mouse have no heartbeat and error reconnection mechanism? > > UDP is connectionless. > > What [@feschber](https://github.com/feschber) could do is add a configuration option for increasing the timeout until a client decides that the other side isn't there anymore if it hasn't heard from it recently enough. But then it means that if the remote _really_ isn't responding it's going to take a minute until the connection is dropped. > > Note that I you want to play with it, there ways to forward UDP connections over e.g. a SSH-based tunnel, so you can enjoy the "jerky freeze and then suddenly re-accelerates" type of suck. > > (*): such as plugging both into network ports of the same WiFi extender (such as the FRITZ!Repeater I am using home) I used AI to analyze the code a few days ago, and it seems to be an issue where the port wasn't released after the connection was forcibly disconnected. Since I know absolutely nothing about Rust, I haven't pushed to merge this AI-analyzed code.