search

saljam / webwormhole

Peer authenticated WebRTC.
BSD 3-Clause "New" or "Revised" License
1.82k stars 92 forks source link

chromeos 80 sometimes does not use peer-reflexive address #26

Closed johnstultz-work closed 4 years ago

johnstultz-work commented 4 years ago

First, this is really cool! Thanks so much for your efforts on it!

Trying to test sending from local Linux system (via ww cmdline) to ChromeOS device via the web interface, and it doesn't seem to ever connect. Same issue trying to receive on the Linux system via cmdline.

Oddly, my phone (Android w/ Chrome using the web interface) transfers ok between both the Linux system cmdline and the ChromeOS in both directions.

Not sure what the best approach is to debug this, as I'm not seeing any obvious errors.

saljam commented 4 years ago

Did you get anything on the browser console on ChromeOS?

The tool definitely needs to export better diagnostics for situations like this. (e.g. #31)

johnstultz-work commented 4 years ago

Unfortunately nothing useful: main.js:195 dialling slot 0 pass tunnel-ultimate

And the web page just says "Connecting"

tyehle commented 4 years ago

I have also seen something similar between brave on Linux and Crome on iOS, but not all the time. I think maybe some better logging is needed to figure this one out.

On Thu, Apr 30, 2020 at 11:44 AM John Stultz notifications@github.com wrote:

Unfortunately nothing useful: main.js:195 dialling slot 0 pass tunnel-ultimate

And the web page just says "Connecting"

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/saljam/webwormhole/issues/26#issuecomment-622033033, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDJJ4XCORLO5L5WT6JKXODRPHBKDANCNFSM4MU3I7VQ .

saljam commented 4 years ago

@johnstultz-work @tyehle i've just redeployed webwormhole.io with a better signalling scheme. i'd appreciate if you tried again and let me know if you still get the same issues!

(you'll need to update the command line client unfortunately: go get -u webwormhole.io/cmd/ww.)

johnstultz-work commented 4 years ago

Sadly no luck.

On the chromeos-web/receiving side: dial.js:108 dialling slot: 8 dial.js:157 websocket opened dial.js:162 message a: 2IkTZOnkff925Y6-hS92YnyRYnFiRSGf5ZF0LhYlMo8s8vBMXAP-dh9gzJYqp19l dial.js:118 got pake message b: KiNVex8G2A4Vd9cCdhYldSd84TqmtGRRcc9XlZshlnQ= dial.js:123 generated key [and it sits here "Connecting"]

No extra debug output on the cli/sending side.

Flipping it, sending from the chromeos-web side: dial.js:82 websocket session established dial.js:33 assigned slot: 3 [sits here until I try to receive from the client] dial.js:38 got pake message a: tvuv6d2WiGNPO2zwXKymMb7Dis7-rQ62e8QdjumkR0sPPleQci_IqwkKorrBPPwC dial.js:41 message b: iB-brWVvu-gsYXoiB51pL9feE3C3kP7r5dq90cHsu3Y= dial.js:45 generated key [and here it sits again without transferring anything]

No extra debug output on the cli side.

And again, using my phone, I can send/receive from both the cli linux system or the chromeos web interface device.

dncohen commented 4 years ago

Same symptoms here. Can reproduce on localhost:8000 and also https://webwormhole.io/.

For me, always fails with chromium:

$ chromium --version
Chromium 80.0.3987.162 built on Debian 10.3, running on Debian 10.3

The A side shows "WAITING FOR THE OTHER SIDE - SHARE CODE OR URL", while B side shows "CONNECTING". Both tabs yellow.

But firefox succeds. (Those two are all I've tested at this point.)

Also. chromium <--> chromium incognito fails, the same as two chromium tabs. And, chromium <--> firefox succeeds. So good enough for my local testing. FYI.

johnstultz-work commented 4 years ago

I did also try with two ChromeOS devices on the same network. That connecting between them works, but neither could talk to the cli tool on the Linux machine.

Oddly I am seeing the same if I run Firefox (Android app) on one of the ChromeOS devices. It can connect to my phone (Chrome on Andorid), or the other ChromeOS device, but not the cli tool.

saljam commented 4 years ago

Very curious. I've added a -very-verbose flag to the command line client on current master. I've also added a bit more logging to the web console.

This should print the full offer and answer SDP. On Chrome or Chromium chrome://webrtc-internals/ can give you the equivalent, and on Firefox it's about:webrtc. I'm interested in comparing the candidates they can gather. (Be careful when pasting these here they will have your IP addresses - please mask those!)

I'd appreciate any help figuring out the root cause!

johnstultz-work commented 4 years ago

On Chromeos web console:

main.js:351 hash changed dialling new code dial.js:97 dialling slot: 6 dial.js:148 websocket opened dial.js:153 message a: D7Z9PhWn-7mukmwLp7VwUBrfCveJvu6poHIrqNvGqWxcTQZO1JrxHk1-oIe1dNIN dial.js:107 got pake message b: 6H54yjAryaHKh2Dw7dwyqlmyJp1ATuRcBHH1zks9xio= dial.js:112 generated key dial.js:134 got offer dial.js:136 created answer 3dial.js:115 got local candidate dial.js:210 local udp candidates: 3 (host: 2 stun: 1) dial.js:220 nat: cone or none: 1:1 port mapping dial.js:226 for more webrtc troubleshooting try https://test.webrtc.org/ and your browser webrtc logs (about:webrtc or chrome://webrtc-internals/) main.js:228 webrtc connection failed connectionState: failed iceConnectionState checking

On cli tool

../go/bin/ww -very-verbose send bad.log 2020/05/12 00:01:57 connected to signalling server, got slot: 6 6-snapline-confidence █████████████████████████████████████ █████████████████████████████████████ ████ ▄▄▄▄▄ ██▀▄██▀ ▀██ ▀█ ▄▄▄▄▄ ████ ████ █ █ █▄▀█▄▀█ █▄█▀███ █ █ ████ ████ █▄▄▄█ ██▄▀▀ ▀ █▄ ▄█ █▄▄▄█ ████ ████▄▄▄▄▄▄▄█ █▄▀▄▀ █ ▀▄█ █▄▄▄▄▄▄▄████ ████▄▄▄█▄ ▄ ▄▀█▀ ▄██ ███ ██▀▄█▀████ ████▀▄█ ██▄▄▄▀ ▄ ██ ▀ ██ █▀ █▄ ▄████ ████▄▄ ▀▀▄▀ ▀ █ █▄ ▀█▄▀ ██ █▄ ████ ████ ██▀▀▀▄▄█▀█▀█ █▀▀▄█▀ ▀▄ █ ▄████ ██████▀ █▄▀ ▄▄▀ █▄ ▄█▄▄ ██ ▀▄ ████ ████▄▀▀██▀▄ ▀█▄ ▀▀██▀███ █▀█▀█ ▄████ ████▄███▄▄▄█ ██ ██▄█ ▄█ ▄▄▄ █▀▀▀████ ████ ▄▄▄▄▄ █ ▄▀█▄█▀▀▀ ▄ █▄█ █▄▄████ ████ █ █ █▄▀▄▀ ▀█▄▄▄█▀ ▄▄▄ █▀▀▀████ ████ █▄▄▄█ █ ▄▀▄ ▀ ▀▀ █ ▀▀▀▄ ▄█▀▄████ ████▄▄▄▄▄▄▄█▄▄▄▄██▄█▄▄█▄▄▄▄▄▄▄█▄▄████ █████████████████████████████████████ █████████████████████████████████████ https://wrmhl.link/#6-snapline-confidence 2020/05/12 00:02:06 got A pake msg (48 bytes) 2020/05/12 00:02:06 have key, sent B pake msg (32 bytes) 2020/05/12 00:02:06 sent offer 2020/05/12 00:02:06 v=0 o=- 551475737 1589241726 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 31:2C:8C:A7:C4:49:43:92:A7:5B:94:9D:57:C8:F6:09:D3:18:6E:D6:B0:3D:C6:6E:A1:5A:69:32:DF:BD:D0:4B a=group:BUNDLE 0 m=application 9 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 a=setup:actpass a=mid:0 a=sendrecv a=sctpmap:5000 webrtc-datachannel 1024 a=ice-ufrag:dIEcnNHzmnezdkSk a=ice-pwd:YZtOYNMXZjknHhpCZJapelHlBhSItfBf a=candidate:foundation 1 udp 2130706431 172.17.0.2 57789 typ host generation 0 a=candidate:foundation 2 udp 2130706431 172.17.0.2 57789 typ host generation 0 a=candidate:foundation 1 udp 1694498815 [ip] 58585 typ srflx raddr 0.0.0.0 rport 58585 generation 0 a=candidate:foundation 2 udp 1694498815 [ip] 58585 typ srflx raddr 0.0.0.0 rport 58585 generation 0 a=candidate:foundation 1 udp 1694498815 [ip] 35039 typ srflx raddr 0.0.0.0 rport 35039 generation 0 a=candidate:foundation 2 udp 1694498815 [ip] 35039 typ srflx raddr 0.0.0.0 rport 35039 generation 0 a=end-of-candidates 2020/05/12 00:02:06 got answer 2020/05/12 00:02:06 v=0 o=- 9182970336794454628 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 a=msid-semantic: WMS m=application 9 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 b=AS:30 a=ice-ufrag:ty6m a=ice-pwd:dfBbmqI5ny/+ixM1W8XVyOsS a=ice-options:trickle a=fingerprint:sha-256 B4:88:A2:F0:04:20:10:AA:D2:26:E5:CA:99:C0:D7:41:C4:1B:BE:9A:E0:7E:03:E0:24:4D:49:FD:F5:41:57:B4 a=setup:active a=mid:0 a=sctpmap:5000 webrtc-datachannel 1024 2020/05/12 00:02:06 local udp candidates: 6 (host: 2 stun: 4) 2020/05/12 00:02:06 nat: cone or none: 1:1 port mapping 2020/05/12 00:02:06 received new remote candidate 2020/05/12 00:02:06 {candidate:2138393493 1 udp 2113937151 f1661070-5332-4042-8d1d-ead0e92a6a92.local 45631 typ host generation 0 ufrag ty6m network-cost 999 0xc00011ebc0 0xc0004cc180 } 2020/05/12 00:02:06 received new remote candidate 2020/05/12 00:02:06 {candidate:4103169675 1 udp 2113939711 aa89275b-ef05-4eda-85e6-51c499f42208.local 37205 typ host generation 0 ufrag ty6m network-cost 999 0xc00011ebf0 0xc0004cc1a0 } 2020/05/12 00:02:07 received new remote candidate 2020/05/12 00:02:07 {candidate:842163049 1 udp 1677729535 [ip] 45631 typ srflx raddr 0.0.0.0 rport 0 generation 0 ufrag ty6m network-cost 999 0xc0001d6020 0xc0001be008 }

saljam commented 4 years ago

So chrome is using the mDNS extensions for the local addresses. I wonder if your linux machine can ping those ".local" addresses under the "received new remote candidate" line (e.g. f1661070-5332-4042-8d1d-ead0e92a6a92.local)

They'll be different next time you try, the browser generates them for privacy.

(It's been a while, but on linux that used to mean having avahi-daemon running, and most distros did that by default.)

saljam commented 4 years ago

There's also a flag to disable mDNS in chrome://flags/#enable-webrtc-hide-local-ips-with-mdns. I'd recommend against changing that permanently - but it might be helpful to rule out mDNS resolution problems.

johnstultz-work commented 4 years ago

(It's been a while, but on linux that used to mean having avahi-daemon running, and most distros did that by default.)

So on my linux system I don't have avahi-daemon.

I also disabled enable-webrtc-hide-local-ips-with-mdns but that didn't seem to resolve it. Will provide logs shortly

johnstultz-work commented 4 years ago

On ChromeOS web side:

hash changed dialling new code dial.js:97 dialling slot: 4 dial.js:148 websocket opened dial.js:153 message a: Vx13sJpq7c-rS7jyVEC6j4JeZ06E7HovmCRLgtkZL_yP3blwf7HbXHE_29ZkuxBz dial.js:107 got pake message b: rv5iei2DtBMPHPQsWs8ZybTvLSCM-7UAzL7YJUJWQT4= dial.js:112 generated key dial.js:134 got offer dial.js:136 created answer 3dial.js:115 got local candidate dial.js:210 local udp candidates: 3 (host: 2 stun: 1) dial.js:220 nat: cone or none: 1:1 port mapping dial.js:226 for more webrtc troubleshooting try https://test.webrtc.org/ and your browser webrtc logs (about:webrtc or chrome://webrtc-internals/)

On cli side

https://wrmhl.link/#4-dupont-revolver 2020/05/12 00:35:09 got A pake msg (48 bytes) 2020/05/12 00:35:09 have key, sent B pake msg (32 bytes) 2020/05/12 00:35:09 sent offer 2020/05/12 00:35:09 v=0 o=- 80304653 1589243709 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 1D:0E:6F:15:91:4F:11:5F:3E:4E:C6:BC:12:A6:34:30:42:13:80:E9:50:E2:EC:BE:50:E6:6D:7A:EC:D5:5F:F7 a=group:BUNDLE 0 m=application 9 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 a=setup:actpass a=mid:0 a=sendrecv a=sctpmap:5000 webrtc-datachannel 1024 a=ice-ufrag:PfibQaGIjFYkHiAQ a=ice-pwd:ulrcoXKElGYzodhmtBduhssiIWdjONOA a=candidate:foundation 1 udp 2130706431 172.17.0.2 54654 typ host generation 0 a=candidate:foundation 2 udp 2130706431 172.17.0.2 54654 typ host generation 0 a=candidate:foundation 1 udp 1694498815 [ip] 58996 typ srflx raddr 0.0.0.0 rport 58996 generation 0 a=candidate:foundation 2 udp 1694498815 [ip] 58996 typ srflx raddr 0.0.0.0 rport 58996 generation 0 a=candidate:foundation 1 udp 1694498815 [ip] 45797 typ srflx raddr 0.0.0.0 rport 45797 generation 0 a=candidate:foundation 2 udp 1694498815 [ip] 45797 typ srflx raddr 0.0.0.0 rport 45797 generation 0 a=end-of-candidates 2020/05/12 00:35:09 got answer 2020/05/12 00:35:09 v=0 o=- 5231384489408617850 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 a=msid-semantic: WMS m=application 9 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 b=AS:30 a=ice-ufrag:Q8b0 a=ice-pwd:8zTrGdXGQDbpEOPXnHMFmffw a=ice-options:trickle a=fingerprint:sha-256 0D:A1:E8:0C:96:64:23:C7:58:93:69:9A:68:DB:CE:E0:FB:0A:BF:4A:52:23:3C:7F:D1:E0:FA:E3:CE:12:1C:0E a=setup:active a=mid:0 a=sctpmap:5000 webrtc-datachannel 1024 2020/05/12 00:35:09 local udp candidates: 6 (host: 2 stun: 4) 2020/05/12 00:35:09 nat: cone or none: 1:1 port mapping 2020/05/12 00:35:09 received new remote candidate 2020/05/12 00:35:09 {candidate:2138393493 1 udp 2113937151 192.168.0.4 37631 typ host generation 0 ufrag Q8b0 network-cost 999 0xc0001c0120 0xc0004be1c8 } 2020/05/12 00:35:09 received new remote candidate 2020/05/12 00:35:09 {candidate:4103169675 1 udp 2113939711 [ipv6] 36505 typ host generation 0 ufrag Q8b0 network-cost 999 0xc0002a4020 0xc0004aa010 } 2020/05/12 00:35:09 received new remote candidate 2020/05/12 00:35:09 {candidate:842163049 1 udp 1677729535 [ip] 37631 typ srflx raddr 192.168.0.4 rport 37631 generation 0 ufrag Q8b0 network-cost 999 0xc0002a4080 0xc0004aa040 }

saljam commented 4 years ago

Ok thanks for posting the logs so quickly! At least it rules out mdns.

Another thing I noticed: the cli is on the private network 172.17.0.0/24 but the chromebook is on 192.168.0.0/24. Is this running in a net namespace?

if it's docker try with -net=host.

johnstultz-work commented 4 years ago

So yes, it is, and running the cli under docker is partly the issue. Using --net=host seems to work around the issue I'm seeing connecting to ChromeOS devices.

Going back to not using --net=host trick, and looking at what I get when connecting with my phone (chrome on Android):

2020/05/12 01:32:39 received new remote candidate 2020/05/12 01:32:39 {candidate:3440244257 1 udp 2113937151 192.168.0.114 39076 typ host generation 0 ufrag MUuN network-cost 999 0xc0001aa170 0xc000486150 } 2020/05/12 01:32:39 received new remote candidate 2020/05/12 01:32:39 {candidate:2419053564 1 udp 2113939711 [ipv6] 44210 typ host generation 0 ufrag MUuN network-cost 999 0xc0004b6010 0xc0004a0008 } 2020/05/12 01:32:39 received new remote candidate 2020/05/12 01:32:39 {candidate:842163049 1 udp 1677729535 [ip] 39076 typ srflx raddr 192.168.0.114 rport 39076 generation 0 ufrag MUuN network-cost 999 0xc000484060 0xc000444018 } 2020/05/12 01:32:39 webrtc connection succeeded, closing signalling channel sending bad.log... done

So there it doesn't run into trouble, but its also not getting privatized .local addresses.

saljam commented 4 years ago

the candidates from chromeos and chrome on android look very similar to me, only the local address different.

Android Chrome
3440244257  1 udp 2113937151 192.168.0.114 39076    typ host generation 0 ufrag MUuN network-cost 999
2419053564  1 udp 2113939711 [ipv6] 44210       typ host generation 0 ufrag MUuN network-cost 999
842163049   1 udp 1677729535 [ip] 39076     typ srflx raddr 192.168.0.114   rport 39076 generation 0 ufrag MUuN network-cost 999

ChromeOS
2138393493  1 udp 2113937151 192.168.0.4 37631  typ host generation 0 ufrag Q8b0 network-cost 999
4103169675  1 udp 2113939711 [ipv6] 36505       typ host generation 0 ufrag Q8b0 network-cost 999
842163049   1 udp 1677729535 [ip] 37631     typ srflx raddr 192.168.0.4 rport 37631 generation 0 ufrag Q8b0 network-cost 999

When you tried with android were the offer and answer on the cli any different to the ChromeOS case?

I'm not really sure why the docker NAT would let one through but not the other.

saljam commented 4 years ago

i'm trying to replicate a similar topology in order to reproduce this. as far as I understand, this is what we have:

doublenat

here we have the command line client (ww) behind a nat, which is itself, along with the browser, behind another nat.

let's analyse this. each of the two peers will generate some candidates:

ww:

  1. server-reflexive (i.e. from stun server): 203.0.113.123
  2. host with mdns masking: xxxx.local
  3. host ipv4 without mdns: 172.17.0.2

browser:

  1. server-reflexive: 203.0.113.123
  2. host with mdns masking: yyyy.local
  3. host ipv4 without mDNS: 192.168.0.20
  4. host (or server-reflexive) ipv6

ww.1 and browser.1 are most likely unreachable from either peer because i think most routers bind the external address for a nat entry to the external interface. at least, all of mine do that.

ww.2 and browser.2 will most likely fail, since the two peers are on separate broadcast networks and won't be able to resolve mdns (.local) names. the exception is if docker handles dns resolution via the host, which makes browser.2 equivalent to browser.3

ww.3 will fail, since 172.17.0.2 is not directly reachable from 192.168.0.20.

browser.4 is out since docker doesn't do ipv6.

of all the possible combination here, this leaves only one candidate that can possibly succeed, browser.3: the ww client has to initiate a connection to 192.168.0.20.

the browser will receive with source address 192.168.0.10 (notice, not one of the original candidates for ww) and create a "peer-reflexive" candidate for it. then and only then the connection would succeed.

i set this up, albeit with docker running in a VM so there a bit more network restriction there. i can confirm that i got the behaviour described here with chrome, chromium, firefox, and safari (all on mac) on both the same machine and a different machine on the same network. that is, it works with peer-reflexive candidates and only with mdns is disabled.

@johnstultz-work i couldn't replicate what you saw with chromeos. i'm curious:

(also, trying now the connection would probably succeed with the relay fallback. need to check chrome://webrtc-internals/ to see whether it's direct or using relay. i should add argument to disable relay on command line client.)

@dncohen given that it's in the same browser on the same machine, and the amount of patches and bugs debian has for chromium, i suspect your issue is different. curious what chrome://webrtc-internals/ says during the handshake.

johnstultz-work commented 4 years ago

@saljam So I went to reproduce, and updated the userland and tried it again, but its working!

2020/05/22 23:59:50 got A pake msg (48 bytes) 2020/05/22 23:59:50 have key, sent B pake msg (32 bytes) 2020/05/22 23:59:50 sent offer 2020/05/22 23:59:50 v=0 o=- 776092648 1590191990 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 93:D4:24:47:88:F2:1F:D5:D0:50:E1:36:2E:75:8E:A2:61:D3:FE:83:3E:3C:3D:5C:2C:86:48:67:18:A3:35:50 a=group:BUNDLE 0 m=application 9 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 a=setup:actpass a=mid:0 a=sendrecv a=sctpmap:5000 webrtc-datachannel 1024 a=ice-ufrag:oNCfzmrPNIAxsKVw a=ice-pwd:JoBLvIXmEYbmXhWHSadvbDLvyGMjJfZa a=candidate:foundation 1 udp 2130706431 172.17.0.2 41280 typ host generation 0 a=candidate:foundation 2 udp 2130706431 172.17.0.2 41280 typ host generation 0 a=candidate:foundation 1 udp 1694498815 [ipv4] 52519 typ srflx raddr 0.0.0.0 rport 52519 generation 0 a=candidate:foundation 2 udp 1694498815 [ipv4] 52519 typ srflx raddr 0.0.0.0 rport 52519 generation 0 a=candidate:foundation 1 udp 16777215 157.245.15.73 50953 typ relay raddr 0.0.0.0 rport 42401 generation 0 a=candidate:foundation 2 udp 16777215 157.245.15.73 50953 typ relay raddr 0.0.0.0 rport 42401 generation 0 a=end-of-candidates 2020/05/22 23:59:50 got answer 2020/05/22 23:59:50 v=0 o=- 6609965196702311259 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 a=msid-semantic: WMS m=application 9 DTLS/SCTP 5000 c=IN IP4 0.0.0.0 b=AS:30 a=ice-ufrag:S/qj a=ice-pwd:8/0MLZLkhnQp+ZUX6z6BLILU a=ice-options:trickle a=fingerprint:sha-256 7F:40:90:CF:87:9D:CB:6E:A3:81:C2:50:7E:4B:AB:06:10:11:79:19:EA:CA:37:B0:C0:16:C1:31:A5:C8:58:E6 a=setup:active a=mid:0 a=sctpmap:5000 webrtc-datachannel 1024 2020/05/22 23:59:50 local udp candidates: 6 (host: 2 stun: 2) 2020/05/22 23:59:50 nat: 1:1 port mapping 2020/05/22 23:59:50 received new remote candidate 2020/05/22 23:59:50 {candidate:2138393493 1 udp 2113937151 5aef0ad2-c8a0-4ede-9a35-1d26f1785552.local 42417 typ host generation 0 ufrag S/qj network-cost 999 0xc000320510 0xc000318548 } 2020/05/22 23:59:50 received new remote candidate 2020/05/22 23:59:50 {candidate:2842378962 1 udp 2113939711 934a2dce-e2bb-4fb5-bfce-c884fb709fd7.local 46943 typ host generation 0 ufrag S/qj network-cost 999 0xc000320540 0xc000318568 } 2020/05/22 23:59:50 received new remote candidate 2020/05/22 23:59:50 {candidate:842163049 1 udp 1677729535 [ipv4] 42417 typ srflx raddr 0.0.0.0 rport 0 generation 0 ufrag S/qj network-cost 999 0xc0002a6140 0xc0002cc0b0 } 2020/05/22 23:59:50 received new remote candidate 2020/05/22 23:59:50 {candidate:797711510 1 udp 33562367 157.245.15.73 59812 typ relay raddr [ipv4] rport 42417 generation 0 ufrag S/qj network-cost 999 0xc000303740 0xc000300aa8 } 2020/05/22 23:59:50 received new remote candidate 2020/05/22 23:59:50 {candidate:797711510 1 udp 33562367 157.245.15.73 56878 typ relay raddr 2601:1c2:680:1319:c983:f3a7:ffec:889e rport 46943 generation 0 ufrag S/qj network-cost 999 0xc0003038c0 0xc000300bc8 } 2020/05/22 23:59:54 webrtc connection succeeded, closing signalling channel sending bad.log... done 2020/05/22 23:59:54 closing

Maybe something added recently resolved this?

As for ChromeOS: I earlier saw this on two separate devices running the same version of ChromeOS (I think it was 80 or an earlier 81). Currently I'm on 81.0.4044.141.

johnstultz-work commented 4 years ago

@saljam Unless you're wanting to keep digging on this, I'm good to close it. Is that ok?

Thanks so much for your patience and persistence in helping debug and analyzing the details! Really happy its working now. This project is one of the coolest I've seen in quite awhile. Thanks again for all your efforts!

saljam commented 4 years ago

Thanks for the logs and report! Glad it's working now. However, my guess is that it's falling back to using the relay. That's the only recent addition. (That works by sending the cyphertext via a server accessible by both peers. The latest version tells you if it's using relay or not whenever it connects.)

I'm still curious why it couldn't get a direct connection before, but there will always be cases where direct connections don't work, and "double nat" is quite often problematic. We now have the relay for those edge cases. So I'm fine with closing.

johnstultz-work commented 4 years ago

@saljam I gave it another spin today and I do see: connected: relay

So your assessment seems to be correct.

Thanks again!