-
Notifications
You must be signed in to change notification settings - Fork 735
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
"same public IP" with IPv6 #55
Comments
This is a problem with assigning two local users in a same room. It is on server side. The two users are on LAN and can see each other. If they are put in same ShareDrop room they can transfer files. The problem is that the server detects their IPv6 address which is poor indicator of clients' subnet. As a result both clients are sent to different rooms and they can't exchange files unless a named room is created. Client A
Client B
|
I can see that putting users with exactly same IP in same room is both
Possible solutions that crossed my mind
Immediate workaroundMy DNS server can't filter AAAA records per domain, but adding this to
|
A quick add-on: Example: When Device A try to send a file to Device B, Device A will try to establish a connection and send a confirmation prompt to Device B, but Device B will show nothing. Same in opposite direction. Currently the only workaround for the IPv6 issue is to join both devices into same room and both having the same IP version (either upgrade both to IPv6 or downgrade to IPv4). |
FYI one great thing is that with named rooms the room IDs don't have to be "created" at all. You can basically enter any (reasonable) identifier after |
Its still not yet resolved lol. Maybe can let the auth specifically get the IPv4 IP address instead of getting the newer version IP, since IPv4 is still the major IP version we had all around the world. |
PRs are welcome. As a workaround, one can create a custom room name and use it on all devices, instead of letting the app generate one based on the public IP address. |
@szimek Just tried, now custom rooms don't work either.
Suspect might be PeerJS's issue, will try to raise issue at there. |
You could create rooms based on the |
Line 79 in 0418b78
pseudo code: if (isIPv6(ip)) {
ip = extractPrefix(ip);
}
const name = crypto.createHmac('md5', secret).update(ip).digest('hex'); |
@szimek looks doable via ippaddr.js const ipaddr = require('ipaddr.js');
var ip = '950b:e036:13c8:3be6:d9cb:b7a3:eccd:3aff'
const addr = ipaddr.process(ip);
if (addr.kind() === 'ipv6') {
ip = ipaddr.IPv6.networkAddressFromCIDR(ip + '/64').toString();
} returns Edit: this is also what paidrop is doing: https://github.com/schlagmichdoch/PairDrop/blob/3fa0873bc4f71f306f0f72afdfecc283bff75b85/docs/host-your-own.md?plain=1#L322-L337 |
With IPv6 there is no NAT (most likely), so all devices even on the same local network will have a different "public" IP address. The restriction that this should match for devices in a room does not make sense in this case. I think.
The first half of the address is seems like the same, so maybe comparing that would be sufficient?
I know that I could use a "named" room to connect the computers despite this, but transferring the room ID is cumbersome given the fact that the very reason I wanted to use ShareDrop (at this moment) is to easily and quickly transfer a token of similar length between computers.
The text was updated successfully, but these errors were encountered: