New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug? device discovery not working without manual pairing #69
Comments
Thank you kindly for the reply! I definitely do have IPv6 on both the docker host as well as the connecting devices, so maybe that's it! I'm at work now but will give it a shot later and see what I can find out. Nothing special on the CF tunnel side, I don't see anywhere that I could enable or disable those forwardfor headers so that's a bit of a black box. If that turns out to be the problem I'll have to switch to nginx + LetsEncrypt etc |
I did some testing. The docker container doesn't have
Not sure that there's any way I can "fix" this from the CF side, I poked around in their dashboard for a while but didn't find much (except for this "No Happy Eyeballs" switch which I tried toggling—made no difference) I found this hacky method for disabling IPv6 on a per-container basis (adding Here's the output of
What DID work was removing the localhost-only bind (change So it seems the end result is that, for now, this isn't compatible with Cloudflare tunnels and I will need to switch to a slightly more complicated setup e.g. Nginx+LE. |
Thanks for testing so thoroughly!
It is expected, that the connecting IP is not the real IP of the client but that of the proxy. The same happens when you use traefik or another reverse proxy in between that relays the requests.
To get around this there is a if (request.headers['cf-connecting-ip']) {
this.ip = request.headers['cf-connecting-ip'].split(/\s*,\s*/)[0];
} else if (request.headers['x-forwarded-for']) {
this.ip = request.headers['x-forwarded-for'].split(/\s*,\s*/)[0];
} else {
this.ip = request.connection.remoteAddress;
} I will create a debugging flag to log the headers and the remoteAddress of the connecting peers to make it easier for you to debug. I would put it on a separate branch first. Could you then clone the repo, checkout the branch and build the docker image yourself for testing purposes?
Does this mean that the problem indeed lies with cloudflare-one? |
Sure I am happy to test a separate branch. I will do a bit more testing today, I am trying to set up a new docker host and a fresh nginx setup. I should have put this detail in: when I got it to work at the end of the above post, I was connecting directly to the docker host's IP over a site to site VPN, so there was no HTTP proxy involved, and PairDrop would have seen the actual real IPs of the clients. |
🚀 Nice! Yes sure I will test now. The new build btw is a separate VM entirely, I won't touch the original setup, so we can definitely do any testing you want on there. |
Any news? :) |
Sorry. I got totally derailed by something else. And had to rebuild my VMware infra this past week, set up new Docker hosts, ROUTE-48 shutdown caused some issues, has to move some things to HE.net, etc... 😵💫 I'm planning to revisit this weekend, will post soon! |
No worries! I'm just trying to keep the issue board somewhat tidy. Post whenever you're ready! Thanks for the quick reply and good luck with your rebuild! :) |
@luckman212 Have you tried again? The debugging flag is now also available on the master branch:
See https://github.com/schlagmichdoch/PairDrop/blob/master/docs/host-your-own.md#debug-mode for more info |
Thanks for your patience. Been a really busy time and I didn't have time to look at this (until now). Spent the last 2 days working on it, debugging etc and am here to report my findings, as well as a Pull Request. Findings
All that added up to me not able to "see" local devices even when they were on the same LAN, due to fully working IPv6 across the board from PRI made a patch that adds a I also encountered another bug/problem while testing which doesn't seem related to any of this: sending a TEXT message to another peer using the Submit button seems broken in recent builds (tested with If you instead send using CTRL+ENTER it works. I made a couple of small edits to the scripts and HTML which fixes that as well, plus a bug about disabling/enabling the submit button due to After building a new image from that branch, and running with e.g.:
I now have a fully working instance of PairDrop, with working HTTPS behind the Cloudflare proxy, and device discovery working! 🚀 Hope these are ok, awaiting your feedback. |
Awesome, good work! PR looks good so far, but I need to do some testing myself and look into localizing IPv6 addresses. Before we merge this, we must add this env var to the docs as well: here and here
Not sure if I understand that correctly: Is disabling IPv6 on the docker network level sufficient to solve this issue or not?
Thanks for reporting these issues! As they are independent from the rest and urgent, I committed fixes for them adding you as co-author: 6e4bda0 & 8a17b82 Would be great if you could fixup your PR only keeping your changes to index.js. |
Updated PR is coming shortly. To answer the other question about "is disabling IPv6 on the docker network level sufficient to solve this issue or not?" - the answer is NO. In my case even when IPv6 was fully disabled at the network level (Docker host and/or container) the proxy headers |
@schlagmichdoch I am new to the process of reverting individual files from a PR, so I hope I did that correctly! Hope the Made a bit of a mess by accidentally hitting the Sync Fork button in GitHub 😡 but I believe I was able to revert that cleanly and squash everything down to a single commit. LMK. |
(squashed, docs updated)
Thanks for clarifying!
Everything looks good! Thanks for rebasing and tidying up so quickly. I did some digging and if I understand it correctly, global IPv6 addresses are always comprised of 48bits routing identifier + 16bits subnet identifier: So even if you define your local network e.g. as /96 you could still identify devices from this (sub)network by using the first 64 bits. In that regard your approach of using the first 4 hexdects of the IPv6 address would be analoguous to using the complete IPv4 address regardless of the used subnet mask (e.g. 255.255.0.0). In that regard I'm thinking whether it would maybe even make sense to use What do you think? Apart from that I think this is ready to be merged. Thanks a lot for contributing! |
Thanks for looking it over. After 10 years or so of monkeying around with IPv6, about the only thing I can say with certainty is: I've seen some crazy stuff. Some ISPs do weird or broken things, so I wouldn't be surprised if there are edge cases we haven't thought of where peers that aren't on the same logical network end up sharing part of a /64 somehow and surprisingly becoming visible to each other. So, not sure about making I pushed 1 more change to explicitly handle |
(squashed, docs updated, handle IPV6_LOCALIZE=false)
(squashed, docs updated, IPV6_LOCALIZE input validation)
Hey @schlagmichdoch 👋 Just wanted to drop in another data point: I've been using this patched version for a week or so now and it's working great for me among a handful of devices, both on- and off-net. Macs using Safari, iPhones, Windows laptops using Edge browser, IPv4 & v6. All working well (for me at least). Let me know what you think of the PR in its current form. |
Great! Been busy the last weeks but I will merge this later today. Thanks again! :) |
Just a final comment to say I nuked my custom docker image and re-pulled this morning from 1.7.3 All worked smoothly, zero problems. |
The following comments were deleted by GitHub (via hubot) as part of mistakenly marking this account as spam on 17th February 2024. The correct thread order and the creation date is unclear. I decided to manually restore them anyway in order to complete the information this issue holds even though the restored information might be outdated: Comment by @schlagmichdoch:Glad to hear this is mostly working for you!
As everything else is working fine, probably here is the issue. For auto discovery, PairDrop groups all devices with the same ip address together. Therefor, the header https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs Is there any additional http server between cloudflare and the docker? The docs have examples for apache2 and nginx. Not sure how to do it with cloudflare-one but if you could present your current config I could have a look and add a working version to the docs later. what’s weird though is, when there is a problem with the cloudflare config normally all devices are mutually visible no matter what their original ip is. In your case every device seems to present a different ip. It could also be, that devices connect to your server with their ipv6 ip address which is different for every device. You would then have to find a way to prevent users from connecting via ipv6 for auto discovery to work Comment by @schlagmichdoch:Looking forward to your findings! If it does not work I should probably add a flag to log the incoming ip addresses for debugging. That way you could easily find out whether PairDrop sees the correct ip address or any of the proxy ip addresses is used instead Comment by @schlagmichdoch:Top! I just pushed the debugging bit to
Then it will log the following on every peer connect:
Would be nice, if you could test this before setting up your new nginx setup to make it work with cloudflare-one :)
Thanks for the clarification! |
Sorry to raise this as a bug, since it's more likely my ignorance on some part of the setup. I'm trying to set up a selfhosted PairDrop instance. I have read host-your-own.md and combed through the Issues but I can't figure this out.
v1.4.4-ls13
)localhost:8081
)coturn
for my own STUN serverstunclient stun.mydomain.com 3478
All of that seems to work fine!
I then prepared the PairDrop docker image with the following:
docker create \ --name=pairdrop \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=America/New_York \ -e RATE_LIMIT=true \ -e RTC_CONFIG="rtc_config.json" \ -e WS_FALLBACK=true \ -p 127.0.0.1:8081:3000 \ -v pairdrop:/app \ --restart unless-stopped \ lscr.io/linuxserver/pairdrop:latest
I created my custom
rtc_config.json
via:And finally, start the PairDrop container and tail the logs:
docker start pairdrop && docker logs -f pairdrop
It all opens and runs fine (with the exception of a node error about not being able to write to
/root/.npm/_logs
, which I believe is totally unrelated, but the output is below anyway)BUT, upon visiting the page (drop.mydomain.com) no devices are seeing each other. It doesn't matter whether I'm accessing from desktop browser (Chrome, Safari) or mobile device, 4G LTE network or over WiFi/Ethernet.
I've tried it also with
WS_FALLBACK=false
, as well as with and without the customRTC_CONFIG
. No differences noted.I opened the Chrome devtools console and don't see any errors there.
If I manually pair the devices with a pairing code, everything works fine. It's just the autodiscovery that's broken for me. Any help would be wonderfully appreciated 🙏
Output of the
docker logs -f pairdrop
belowThe text was updated successfully, but these errors were encountered: