search

ddvk / rmfakecloud

host your own cloud for the remarkable
GNU Affero General Public License v3.0
775 stars 63 forks source link

Connection issue from the client side: Host not found #320

Open dflaxx opened 2 months ago

dflaxx commented 2 months ago

We've run into connection problems when trying to install rmfakecloud for the first time. rmfakecloud runs fine on the server side, but trying to pair our Remarkable 1 device with a generated code results in a "Host not found" error on the device.

In the following, <server-ip> is the IPv4 of the server running rmfakecloud.

On the device, we're running Remarkable version 3.14.1.9 and installed rmfakecloud-proxy using installer.sh from https://github.com/ddvk/rmfakecloud-proxy/releases/tag/v0.0.4. There were no issues during the installation: ./installer.sh install http://<server-ip>:80.

The server side runs the provided rmfakecloud docker container. Our docker compose file looks as follows:

version: "3"
services:
  rmfakecloud:
    image: ddvk/rmfakecloud
    container_name: rmfakecloud
    restart: unless-stopped
    environment:
      DATADIR: ./data
      #JWT_SECRET_KEY: g8+ddn9me6URbr+rGd6u3/7ZHWK7pYYBbZUL7v3GwiSD7xFtFinhfF3f0Oo+N0NZ
      STORAGE_URL: http://<server-ip>:80
      LOGLEVEL: debug
    ports:
      - "80:3000"
    volumes:
      - ./data:/data

On the device, the proxy.service file looks as follows:

root@reMarkable:~# cat /etc/systemd/system/proxy.service
[Unit]
Description=reverse proxy
#StartLimitIntervalSec=600
#StartLimitBurst=4
After=home.mount

[Service]
Environment=HOME=/home/root
#EnvironmentFile=/home/root/rmfakecloud/proxy.cfg
WorkingDirectory=/home/root/rmfakecloud
ExecStart=/home/root/rmfakecloud/rmfake-proxy -cert /home/root/rmfakecloud/proxy.bundle.crt -key /home/root/rmfakecloud/proxy.key http://<server-ip>:80

[Install]
WantedBy=multi-user.target

We went through the troubleshooting section in the rmfakecloud README with the following results on the Remarkable side:

Test connectivity:

# ping -c 1 my.remarkable.com
PING my.remarkable.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.144 ms

# ping -c 1 local.appspot.com
PING local.appspot.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.130 ms

# ping -c 1 <server-ip>
PING <server-ip> (<server-ip>): 56 data bytes
64 bytes from <server-ip>: seq=0 ttl=62 time=4.671 ms

# wget -qO- <server-ip>:80
<!doctype html><html lang="en"><head><meta charset="utf-8"/><meta name="viewport" content="width=device-width,initial-scale=1"/><meta name="theme-color" content="#000000"/><meta name="description" content="RM FakeApi"/><title>rmfakecloud</title><script defer="defer" src="/static/js/main.9c2de5b1.js"></script><link href="/static/css/main.d94d89ba.css" rel="stylesheet"></head><body><noscript>You need to enable JavaScript to run this app.</noscript><div id="root"></div></body></html>

# wget -qO- https://local.appspot.com
wget: note: TLS certificate validation not implemented
<!doctype html><html lang="en"><head><meta charset="utf-8"/><meta name="viewport" content="width=device-width,initial-scale=1"/><meta name="theme-color" content="#000000"/><meta name="description" content="RM FakeApi"/><title>rmfakecloud</title><script defer="defer" src="/static/js/main.9c2de5b1.js"></script><link href="/static/css/main.d94d89ba.css" rel="stylesheet"></head><body><noscript>You need to enable JavaScript to run this app.</noscript><div id="root"></div></body></html>

Check certificates:

# echo Q | openssl s_client -connect localhost:443  -verify_hostname local.appspot.com -CAfile /etc/ssl/certs/ca-certificates.crt 2>&1 | grep Verify
Verify return code: 0 (ok)
    Verify return code: 0 (ok)

Check proxy status:

# systemctl status -l proxy
● proxy.service - reverse proxy
     Loaded: loaded (/etc/systemd/system/proxy.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2024-09-11 14:37:34 UTC; 20min ago
   Main PID: 2177 (rmfake-proxy)
     CGroup: /system.slice/proxy.service
             └─ 2177 /home/root/rmfakecloud/rmfake-proxy -cert /home/root/rmfakecloud/proxy.bundle.crt -key /home/root/rmfakecloud/proxy.key http://<server-ip>:80

Sep 11 14:37:34 reMarkable systemd[1]: Started reverse proxy.
Sep 11 14:37:34 reMarkable rmfake-proxy[2177]: 2024/09/11 14:37:34 cert-file=/home/root/rmfakecloud/proxy.bundle.crt key-file=/home/root/rmfakecloud/proxy.key listen-addr=:443 upstream-url=http://<server-ip>:80

Verbose output from xochitl:

# systemctl stop xochitl
# QT_LOGGING_RULES=rm.network.*=true xochitl | grep -A3 QUrl
debug: 2024-08-29T12:40:35Z heads/releases/3.14-farfetchd 5125960
debug: we're running on an epaper device
14:41:32.140 rm.network.client        Http::GET QUrl("https://internal.cloud.remarkable.com:443/discovery/v1/webapp")
14:41:32.312 rm.network.client        Received hostname for AbstractNetworkClient::WebApp : "<server-ip>:80"
14:41:32.312 rm.network.authenticationDevice token hostname received: <server-ip>:80 (onRequestDeviceTokenHostNameReceived /home/runner/work/xochitl/xochitl/src/xofm/libs/network/src/authentication.cpp:264)
14:41:32.313 rm.network.client        Http::POST QUrl("https:///token/json/2/device/new")
14:41:32.515 rm.network.authenticationFailed to fetch device token: Host  not found, , https:///token/json/2/device/new (onDeviceTokenReceived /home/runner/work/xochitl/xochitl/src/xofm/libs/network/src/authentication.cpp:240)
14:41:33.121 rm.network.notifications opening connection to <server-ip>:80 (openNotificationSocket /home/runner/work/xochitl/xochitl/src/notifications/src/notifications.cpp:342)
14:41:33.123 rm.network.notifications Opening notification service URL: wss://:443/notifications/ws/json/1 (openNotificationSocket /home/runner/work/xochitl/xochitl/src/notifications/src/notifications.cpp:363)

To me, the line

14:41:32.313 rm.network.client        Http::POST QUrl("https:///token/json/2/device/new")

from xochitl looks suspicious, as if the host is missing from the URL string.

The following is what we see on the server side from the docker container. <remarkable-ip> refer to the Remarkable tablet, and <computer-ip> to the PC requesting the pairing code. <username> is the username of the rmfakecloud account we created.

rmfakecloud  | time="2024-09-11T15:21:18Z" level=warning msg="[auth-middleware]token parsing:wrong token format"
rmfakecloud  | time="2024-09-11T15:21:18Z" level=info msg="[GIN] 2024/09/11 - 15:21:18 | 401 |      60.601µs |  <remarkable-ip> | GET      \"/integrations/v1/\""
rmfakecloud  | time="2024-09-11T15:21:37Z" level=info msg="[ui-authmiddleware] User from token: <username>"
rmfakecloud  | time="2024-09-11T15:21:37Z" level=info msg="[GIN] 2024/09/11 - 15:21:37 | 200 |    1.147874ms |  <computer-ip> | GET      \"/ui/api/newcode\""
rmfakecloud  | time="2024-09-11T15:21:46Z" level=info msg="[GIN] 2024/09/11 - 15:21:46 | 200 |       18.26µs |  <remarkable-ip> | GET      \"/discovery/v1/webapp\""

We appreciate any help regarding this issue! Thanks!

donmerendolo commented 1 month ago

Hey, I had the same issue as you until now. I decided to try set it up again since I saw that 3.14.1.9 is supported as of yesterday. I was able to solve the problem by leaving the STORAGE_URL field empty in the Docker Compose file, as I'm using the proxy (I think that was the error). After that, I reinstalled with

# Stop services
systemctl stop xochitl
systemctl stop proxy

# Reinstall the proxy service
./installer.sh uninstall
./installer.sh install

# Restart services
systemctl daemon-reload
systemctl start proxy
systemctl start xochitl

And tried pairing again, and it worked!

I think I also changed the JWT token.

Hope this helps!

Edit: But i get "Network failure: 404" when trying to sync, no idea why. Edit2: Uploading a pdf from the Web UI fixed it.

mugraph commented 1 month ago

I just did my first setup using version 3.13.1.2 and latest rmfakecloud image behind nginx reverse proxy and I can confirm the solution of leaving out STORAGE_URL mentioned by @donmerendolo seems to make it all work. Happy to be able to test it all out :)

Eeems commented 1 month ago

Based on the configuration guide you should only be populating the STORAGE_URL if you want uploads to skip the proxy and go directly to your rmfakecloud instance. This only works if the URL you provide can be reached by the device. That said, it looks like newer versions of xochitl might be trying to do some sort of hostname lookup on the IP address, and after failing to do so, just running the query without a hostname or ip address. It would probably be best practice to just leave this setting blank and have everything go through the proxy on the device. The docs should probably be updated to reflect this @nemunaire