peers/peerjs

Unable to get peerjs working on LAN

Closed this issue · 4 comments

fresheneesz commented

I've been successful in testing peerjs from one localhost browser window to another, but when trying to connect via a different computer on the same LAN (connected to the same wifi network), I'm not able to create a successful webrtc connection.

I'm able to successfully connect to the peer server in both cases, however when trying to connect over the LAN, no offer (or corresponding answer) is given.

My code:

server.js: https://pastebin.com/bmbScpGr
client.html: https://pastebin.com/8NXLAVyg

Run the clients by

  1. loading the listener http://hostname:9001/client.html#1 (on the machine where the server is listening), then
  2. loading the connector http://hostname:9001/client.html#2 (on the separate LAN machine)

The relevant (non-heartbeat) websocket frames (note the listener is named "1" and the connector is named "2") in chronological order:

Listener receive 🡇: {"type":"OPEN"}

Connector receive 🡇: {"type":"OPEN"}

Connector send 🡅:

{"type":"CANDIDATE",
 "payload":{
   "candidate":{
     "candidate":"candidate:4033732497 1 udp 2113937151 192.168.0.104 35946 typ host generation 0 ufrag wLaA network-cost 999",
     "sdpMid":"0",
     "sdpMLineIndex":0
    },
    "type":"data",
    "connectionId":"dc_tyctyod1ak"
  },
  "dst":"1"
}

Connector send 🡅:

{"type":"CANDIDATE",
 "payload":{
   "candidate":{
     "candidate":"candidate:842163049 1 udp 1677729535 76.102.26.97 35946 typ srflx raddr 192.168.0.104 rport 35946 generation 0 ufrag wLaA network-cost 999",
     "sdpMid":"0",
     "sdpMLineIndex":0
   },
   "type":"data",
   "connectionId":"dc_tyctyod1ak"
 },
 "dst":"1"
}

Listener receive 🡇:

{"type":"CANDIDATE",
 "src":"2",
 "dst":"1",
 "payload":{
   "candidate":{
     "candidate":"candidate:4033732497 1 udp 2113937151 192.168.0.104 35946 typ host generation 0 ufrag wLaA network-cost 999",
     "sdpMid":"0",
     "sdpMLineIndex":0
   },
   "type":"data",
   "connectionId":"dc_tyctyod1ak"
 }
}

Listener receive 🡇:

{"type":"CANDIDATE",
 "src":"2",
 "dst":"1",
 "payload":{
   "candidate":{
     "candidate":"candidate:842163049 1 udp 1677729535 76.102.26.97 35946 typ srflx raddr 192.168.0.104 rport 35946 generation 0 ufrag wLaA network-cost 999",
     "sdpMid":"0",
     "sdpMLineIndex":0
   },
   "type":"data",
   "connectionId":"dc_tyctyod1ak"
 }
}

I noticed that in the successful localhost test, the first thing the connector does is make an OFFER, however no OFFER is given at all in the unsuccessful LAN test. This is the offer given in the successful test:

{"type":"OFFER","payload":{"sdp":{"type":"offer","sdp":"v=0\r\no=- 1760611217932831082 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0\r\na=msid-semantic: WMS\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:6enJ\r\na=ice-pwd:bmkMAiyGXd9k/TbN+gYoL39K\r\na=ice-options:trickle\r\na=fingerprint:sha-256 85:C6:63:EA:F7:DE:12:30:A5:8B:3A:C5:13:AC:78:91:E9:6A:41:4F:B8:C4:0A:94:67:E6:D4:2A:27:F7:A8:91\r\na=setup:actpass\r\na=mid:0\r\na=sctp-port:5000\r\na=max-message-size:262144\r\n"},"type":"data","connectionId":"dc_dd4m7huxvz","browser":"Chrome","label":"dc_dd4m7huxvz","serialization":"binary"},"dst":"1"}

Another thing I noticed is that the candidate sent by the connector is slightly different (and there's only one instead of two) - there's the string 5ca864aa-cd92-4296-b875-6d8ed2303d43.local instead of an IP address 192.168.0.104:

{"type":"CANDIDATE","payload":{"candidate":{"candidate":"candidate:1840965416 1 udp 2113937151 5ca864aa-cd92-4296-b875-6d8ed2303d43.local 59461 typ host generation 0 ufrag 6enJ network-cost 999","sdpMid":"0","sdpMLineIndex":0},"type":"data","connectionId":"dc_dd4m7huxvz"},"dst":"1"}

Note that I also tried the reverse (loading the listener on the separate machine and the connector on the same machine as the peerjs server), which also didn't work. The websocket frames were a bit more complex tho.

Does anyone know what might be going on here? I figured a test over a LAN should be just as easy as a local demo, since there's no NAT to traverse.

Deleted user commented

@fresheneesz open chrome://flags/

Search for Anonymize local IPs exposed by WebRTC. and disable it.

This here: 5ca864aa-cd92-4296-b875-6d8ed2303d43.local is a mDNS hostname, Google's way of obfuscating local IPs for "security" reasons, introduced in Chrome 75 or thereabouts. Another example of breaking APIs due to a FAD.

fresheneesz commented

Hmm, I got frustrated by this and quit til now. Trying again, it works! I did try disabling Anonymize local IPs exposed by WebRTC. but after it worked I switched it back to "default" and it continued to work. Maybe I'll try switching it on and seeing if maybe the default has changed in the last 6 months.

fresheneesz commented

Seems to work even after explicitly enabling it. Odd, well I have moved apartments and have messed with my network configuration - so maybe that's it? Thanks for the help!

TheeeEVan commented

Is there any way to get around this issue without enabling the flag? 2 years later we obviously have a new version of chrome and they have removed it. Also, in this situation, I don't have access to the group policy editor so that method isn't an option either... If it's impossible that's fine but just checking before I completely restructure everything. Thanks!