rmview hung on authentication about rmview HOT 15 OPEN

I stand corrected. I was looking for a firewall at the router side, and there is none, but there is a firewall on the target laptop and Wireshark captures in front of the firewall. So my issue has been resolved.

from rmview.

Same issue solved in Ubuntu by adding a firewall rule

from rmview.

For anyone on Fedora with exactly the same issue, here is my quick fix:

sudo firewall-cmd --add-port=5901/udp # open the required UDP 5901 port
sudo firewall-cmd --runtime-to-permanent # make the new firewall configuration persistent, so it applies also after reboot

from rmview.

I have the same issue and running 2.12.2.573

[INFO] Loaded known hosts from /Users/triha/Library/Preferences/rmview_known_hosts
[INFO] Connecting...
[INFO] Connected to 192.168.2.217
[INFO] Detected reMarkable 2.0
[INFO] Using backend 'screenshare'
[INFO] Connecting to ScreenShare, make sure you enable it
[WARNING] Authenticating, please wait...
2022-04-21 14:51:43+0200 [-] ChallengeReaderProtocol starting on 5901
2022-04-21 14:51:43+0200 [-] Starting protocol <rmview.screenstream.screenshare.ChallengeReaderProtocol object at 0x1365513d0>
[DEBUG] Stopping connection worker

from rmview.

You need to first enable ScreenShare on the tablet, which unfortunately is only available if you have a subscription.
There's currently no workaround.

from rmview.

I have a subscription and the ScreenShare enabled

from rmview.

@triha74 have you looked at #111 ? That's most likely the issue.

from rmview.

Im not sure it is because I dont have the firewall enabled

from rmview.

@triha74 would you mind listing your specs? What OS are you using? Are you running from WiFI or USB? Have you tried with the official app?

from rmview.

On my mac neither the official app or rmview is working.

On my windows machine (which I only use for gaming) it does work both with the official app and rmview.

Both machines on the same network

from rmview.

@triha74 looks like something in your config is blocking the communication on port 5901 (UDP).
This is not an issue with rmview per-se.

from rmview.

I had the same problem using the docker version of rmview. If you are on Ubuntu just allow TCP/UDP on port 5901: sudo ufw allow 5901 . Tested on Remarkable 2, OS: 2.12.3.606 and Ubuntu 20.04.3 LTS running from WIFI (home network)

from rmview.

I also have the same problem:

[INFO] Connected to 10.144.255.236
[INFO] Detected reMarkable 2.0
[INFO] Using backend 'screenshare'
[INFO] Connecting to ScreenShare, make sure you enable it
[WARNING] Authenticating, please wait...
2022-06-17 16:32:44+0200 [-] ChallengeReaderProtocol starting on 5901
2022-06-17 16:32:44+0200 [-] Starting protocol <rmview.screenstream.screenshare.ChallengeReaderProtocol object at 0x7fce8411cac0>
[DEBUG] Stopping connection worker

In this state the application is stuck.
I activated screenshare on the Tablet and inspected my network traffic via wireshark.
I can see the following packets:
4003 413.035381053 10.144.255.236 10.144.255.255 UDP 93 55606 → 5901 Len=51 on my laptop in regular intervals. I can also see that rmview has a listen port via netstat:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           986/avahi-daemon: r 
udp        0      0 0.0.0.0:5901            0.0.0.0:*                           18831/python3    
<more lines...>

On a different network I verified that screenshare works in windows with the official client. Here I am on debian11.
How do I look deeper here? Is there an easy way to see whether the UDP Packets are actually received in rmview?

/edit: Remarkable is 2.14.0.861

from rmview.

@pizzard without further info, it looks to me like a network config problem.
To see if this is true you should be testing rmview and the official app in the same network.
Are you absolutely positive that UDP traffic on port 5901 is not blocked by a firewall?

from rmview.

As I can see the packets in wireshark I am certain that the network lets them through, but I will try to verify further whether the device receiving them does apply any further filters.
I will try on the same device in the same network with both official and rmview to directly compare.
I am on a Debian11 system, for reference.

from rmview.