ICE-Lite server re-offers with new ICE ufrag/pwd and Chrome generates wrong STUN requests with ICE-CONTROLLED
Reported by
ibc@aliax.net,
Apr 11 2017
|
||||
Issue descriptionWhat steps will reproduce the problem? 1. Let a ICE-Lite server generate a SDP offer and send it to Chrome. Since the remote SDP has a=ice-lite, Chrome becomes ICE-CONTROLLER as per spec and sends STUN Binding Requests with ICE-CONTROLLED flag. 2. Let the ICE-Lite server re-offer with new ICE candidates and new ICE ufrag/pwd. The SDP also contains a=ice-lite as in the initial offer. 3. Chrome creates a re-answer with also new candidates and ICE ufrag/pwd. What is the expected result? Chrome should generate STUN Binding Requests, again, with ICE-CONTROLLING flag (because the remote is a ICE-Lite server). What do you see instead? Chrome is generating STUN Binding Requests with ICE-CONTROLLED flag instead. What version of the product are you using? On what operating system? Chrome 57.0.2987.133 Canary 59.0.3068.1 OSX 10.12.4 Please provide any additional information below. Full SDP flow: ---------------- Initial SDP offer sent by the ICE-Lite server: v=0 o=mediasoup 16916109 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-lite a=fingerprint:sha-256 62:BB:FF:98:C7:2E:D9:F4:87:5A:D5:FD:1C:48:06:7B:14:55:3E:5A:D6:FD:A5:D9:1E:C9:D7:CA:12:D3:21:9B a=msid-semantic: WMS * a=group:BUNDLE audio-tracks m=audio 7 RTP/SAVPF 100 c=IN IP4 127.0.0.1 a=rtpmap:100 opus/48000/2 a=fmtp:100 minptime=10;useinbandfec=1 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=setup:actpass a=mid:audio-tracks a=sendrecv a=ice-ufrag:ndw7dqsqsf05qlhh a=ice-pwd:4uh4ybhj9w96r6qqd7i9f4u8yx2z8rn3 a=candidate:udpcandidate 1 udp 1078862079 192.168.1.33 49819 typ host a=end-of-candidates a=rtcp-mux a=rtcp-rsize SDP answer generated by Chrome: v=0 o=- 5625395524928908224 3 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio-tracks a=msid-semantic: WMS 9vB59NixoLeICrQBLbYSUietIwocMW8BandO m=audio 9 RTP/SAVPF 100 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:bued a=ice-pwd:TAHVQnA/+msMmt4XUnaanUqF a=fingerprint:sha-256 12:F2:B0:6F:D4:9C:87:60:D5:8C:5E:F9:7D:B0:52:EE:D7:FA:3A:1A:4C:D4:5C:F8:14:89:E8:FE:B5:4D:95:99 a=setup:active a=mid:audio-tracks a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux a=rtpmap:100 opus/48000/2 a=fmtp:100 minptime=10;useinbandfec=1 a=ssrc:2389652053 cname:6xVe/36KuVruy1WD a=ssrc:2389652053 msid:9vB59NixoLeICrQBLbYSUietIwocMW8BandO 10b1ba8a-f94a-42c8-a568-dc5e147191ab a=ssrc:2389652053 mslabel:9vB59NixoLeICrQBLbYSUietIwocMW8BandO a=ssrc:2389652053 label:10b1ba8a-f94a-42c8-a568-dc5e147191ab SDP re-offer sent by the ICE-Lite server (ice-ufrag/pwd and candidate changed): v=0 o=mediasoup 16916109 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-lite a=fingerprint:sha-256 62:BB:FF:98:C7:2E:D9:F4:87:5A:D5:FD:1C:48:06:7B:14:55:3E:5A:D6:FD:A5:D9:1E:C9:D7:CA:12:D3:21:9B a=msid-semantic: WMS * a=group:BUNDLE audio-tracks m=audio 7 RTP/SAVPF 100 c=IN IP4 127.0.0.1 a=rtpmap:100 opus/48000/2 a=fmtp:100 minptime=10;useinbandfec=1 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=setup:actpass a=mid:audio-tracks a=sendrecv a=ice-ufrag:nu2ulbm9rsm061ev a=ice-pwd:g3bn6w7q4hzd3aj8d8oczp8rxe8a8zgl a=candidate:udpcandidate 1 udp 1078862079 192.168.1.33 46567 typ host a=end-of-candidates a=rtcp-mux a=rtcp-rsize SDP re-answer generated by Chrome (ice-ufrag/pwd and candidate changed): v=0 o=- 5625395524928908224 4 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio-tracks a=msid-semantic: WMS 9vB59NixoLeICrQBLbYSUietIwocMW8BandO m=audio 9 RTP/SAVPF 100 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:WgIF a=ice-pwd:oI8EpZGPFS59ZpyI99soYVFb a=fingerprint:sha-256 12:F2:B0:6F:D4:9C:87:60:D5:8C:5E:F9:7D:B0:52:EE:D7:FA:3A:1A:4C:D4:5C:F8:14:89:E8:FE:B5:4D:95:99 a=setup:active a=mid:audio-tracks a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux a=rtpmap:100 opus/48000/2 a=fmtp:100 minptime=10;useinbandfec=1 a=ssrc:2389652053 cname:6xVe/36KuVruy1WD a=ssrc:2389652053 msid:9vB59NixoLeICrQBLbYSUietIwocMW8BandO 10b1ba8a-f94a-42c8-a568-dc5e147191ab a=ssrc:2389652053 mslabel:9vB59NixoLeICrQBLbYSUietIwocMW8BandO a=ssrc:2389652053 label:10b1ba8a-f94a-42c8-a568-dc5e147191ab After this new SDP O/A, Chrome sends wrong STUN Binding Requests with unexpected/wrong ICE-CONTROLLED flag.
,
Apr 12 2017
NOTE: After the second SDP O/A, Chrome sends those wrong ICE-CONTROLLED STUN requests to the new remote port, but from the SAME local port as before. Received by the ICE-Server from Chrome. a) After the first O/A: <StunMessage> Binding Request size: 112 bytes transactionId: 56464b2b742f4d746a495449 username: ndw7dqsqsf05qlhh:XwGk priority: 1845501695 iceControlling: 9341764652791506412 useCandidate messageIntegrity: 34683756afbd1699a81ee5405cc9da2ce7c60bc9 fingerprint </StunMessage> <TransportTuple> [UDP, local:192.168.1.33 :49622, remote:192.168.1.33 :55328] </TransportTuple> b) After the second O/A: <StunMessage> Binding Request size: 108 bytes transactionId: 6a446f702b544f456934667a username: nu2ulbm9rsm061ev:DDgr priority: 1845501695 iceControlled: 9341764652791506412 messageIntegrity: f22a67974c0d43e38eab1aa17d2a9820662d2c7f fingerprint </StunMessage> <TransportTuple> [UDP, local:192.168.1.33 :41548, remote:192.168.1.33 :55328] </TransportTuple>
,
Apr 12 2017
,
Apr 12 2017
,
Apr 12 2017
i went check it out on my crosh with that local ip address it says its "unknown host" but i did not check the remote ip addresse
,
Apr 12 2017
so i don't know what it means because i can't even retrace it because i only have a chromebook and i don't have a phoneline jack on my chromebook it only runs on wifi which is sucks because some unknown host so called "hacking" using a phoneline jack to have so much firewall which you can't trace it.
,
Apr 12 2017
By ignoring the ICE_CONTROLLED flags things work, but obviously Chrome should not generate ICE Binding Requests with ICE_CONTROLLED when the remote is an a=ice-lite server.
,
Apr 12 2017
This may be related to https://bugs.chromium.org/p/webrtc/issues/detail?id=5470
,
Apr 12 2017
Your suspicion was correct. Fix here: https://codereview.webrtc.org/2812173003 Also, question for kjellander: Why was this moved to the chromium bug tracker?
,
Apr 12 2017
Great, will check as soon as it lands in Canary.
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/897d08ef1b314e8d8fcd24d1dcfba820cb2501b7 commit 897d08ef1b314e8d8fcd24d1dcfba820cb2501b7 Author: deadbeef <deadbeef@webrtc.org> Date: Thu Apr 20 07:57:25 2017 Fixing bug that results in incorrect ICE role with ICE lite endpoints. There's some code that resets the ICE role on an ICE restart (behavior that's specified in ICE, but removed from ICEbis). And it wasn't taking into account that the remote endpoint may be an ICE lite endpoint, in which case the WebRTC endpoint's role should always be "controlling". BUG= chromium:710760 Review-Url: https://codereview.webrtc.org/2812173003 Cr-Commit-Position: refs/heads/master@{#17779} [modify] https://crrev.com/897d08ef1b314e8d8fcd24d1dcfba820cb2501b7/webrtc/p2p/base/transportcontroller.cc [modify] https://crrev.com/897d08ef1b314e8d8fcd24d1dcfba820cb2501b7/webrtc/p2p/base/transportcontroller_unittest.cc
,
Apr 20 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by ibc@aliax.net
, Apr 11 2017