Sending STUN Binding error / received STUN request with bad local username

[Francois Temasys]

Hi,

I have a problem when trying to connect to a C++ server.

The ICE connection fail and I can see on the google chrome logs the following:

[118:127:0710/184327:VERBOSE1:port.cc(391)] Jingle:Port[audio:1:0::Net[eth1:192.168.1.125/32]]: Received STUN request with bad local usernam from 192.168.1.108:45767

[118:127:0710/184327:VERBOSE3:port.cc(690)] Jingle:Port[audio:1:0::Net[eth1:192.168.1.125/32]]: Sending STUN binding error: reason=Unauthorized to 192.168.1.108:45767

[118:127:0710/184327:VERBOSE1:port.cc(391)] Jingle:Port[audio:1:0::Net[eth1:192.168.1.125/32]]: Received STUN request with bad local usernam from 192.168.1.125:54381

[118:127:0710/184327:VERBOSE3:port.cc(690)] Jingle:Port[audio:1:0::Net[eth1:192.168.1.125/32]]: Sending STUN binding error: reason=Unauthorized to 192.168.1.125:54381

The client and the server are on the same computer and i'm not particularly trying to use any customised stun server: stun.l.google.com:19302

I'm not modifying the sdp and here is the local and remote information exchanged:

localsdp

"v=0 o=- 1125160222871533774 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS foH9zTEzFIcAUMorHLrjCOdLAqxy4sB0X0nV m=audio 57712 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 118.189.54.34 a=rtcp:57712 IN IP4 118.189.54.34 a=candidate:4273728266 1 udp 2122260223 192.168.1.125 57712 typ host generation 0 a=candidate:4273728266 2 udp 2122260223 192.168.1.125 57712 typ host generation 0 a=candidate:1980850359 1 udp 2122194687 192.168.1.108 38567 typ host generation 0 a=candidate:1980850359 2 udp 2122194687 192.168.1.108 38567 typ host generation 0 a=candidate:2146692542 1 udp 1686052607 118.189.54.34 57712 typ srflx raddr 192.168.1.125 rport 57712 generation 0 a=candidate:2146692542 2 udp 1686052607 118.189.54.34 57712 typ srflx raddr 192.168.1.125 rport 57712 generation 0 a=candidate:4149831171 1 udp 1685987071 118.189.54.34 38567 typ srflx raddr 192.168.1.108 rport 38567 generation 0 a=candidate:4149831171 2 udp 1685987071 118.189.54.34 38567 typ srflx raddr 192.168.1.108 rport 38567 generation 0 a=candidate:2956466170 1 tcp 1518280447 192.168.1.125 0 typ host generation 0 a=candidate:2956466170 2 tcp 1518280447 192.168.1.125 0 typ host generation 0 a=candidate:949132359 1 tcp 1518214911 192.168.1.108 0 typ host generation 0 a=candidate:949132359 2 tcp 1518214911 192.168.1.108 0 typ host generation 0 a=ice-ufrag:YiF7OhmC8tZKWd0u a=ice-pwd:eZl0ih1CEXb37UC5C/ZQtFeY a=ice-options:google-ice a=fingerprint:sha-256 9E:35:3F:B2:6D:47:6C:02:F4:12:16:35:F3:86:CF:CC:B0:88:D1:E9:2F:DA:80:33:00:DD:E8:2C:0B:30:D0:F0 a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=recvonly a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=video 57712 RTP/SAVPF 100 116 117 c=IN IP4 118.189.54.34 a=rtcp:57712 IN IP4 118.189.54.34 a=candidate:4273728266 1 udp 2122260223 192.168.1.125 57712 typ host generation 0 a=candidate:4273728266 2 udp 2122260223 192.168.1.125 57712 typ host generation 0 a=candidate:1980850359 1 udp 2122194687 192.168.1.108 38567 typ host generation 0 a=candidate:1980850359 2 udp 2122194687 192.168.1.108 38567 typ host generation 0 a=candidate:2146692542 1 udp 1686052607 118.189.54.34 57712 typ srflx raddr 192.168.1.125 rport 57712 generation 0 a=candidate:2146692542 2 udp 1686052607 118.189.54.34 57712 typ srflx raddr 192.168.1.125 rport 57712 generation 0 a=candidate:4149831171 1 udp 1685987071 118.189.54.34 38567 typ srflx raddr 192.168.1.108 rport 38567 generation 0 a=candidate:4149831171 2 udp 1685987071 118.189.54.34 38567 typ srflx raddr 192.168.1.108 rport 38567 generation 0 a=candidate:2956466170 1 tcp 1518280447 192.168.1.125 0 typ host generation 0 a=candidate:2956466170 2 tcp 1518280447 192.168.1.125 0 typ host generation 0 a=candidate:949132359 1 tcp 1518214911 192.168.1.108 0 typ host generation 0 a=candidate:949132359 2 tcp 1518214911 192.168.1.108 0 typ host generation 0 a=ice-ufrag:YiF7OhmC8tZKWd0u a=ice-pwd:eZl0ih1CEXb37UC5C/ZQtFeY a=ice-options:google-ice a=fingerprint:sha-256 9E:35:3F:B2:6D:47:6C:02:F4:12:16:35:F3:86:CF:CC:B0:88:D1:E9:2F:DA:80:33:00:DD:E8:2C:0B:30:D0:F0 a=setup:actpass a=mid:video a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=sendrecv a=rtcp-mux a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:1366378746 cname:g66tRSz2SaQIFf+F a=ssrc:1366378746 msid:foH9zTEzFIcAUMorHLrjCOdLAqxy4sB0X0nV ce7e337b-471d-4036-8669-6472b9658442 a=ssrc:1366378746 mslabel:foH9zTEzFIcAUMorHLrjCOdLAqxy4sB0X0nV a=ssrc:1366378746 label:ce7e337b-471d-4036-8669-6472b9658442 "

remotesdp

"v=0 o=- 0 0 IN IP4 127.0.0.1 s= t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS lmipTuBs6u m=audio 45767 RTP/SAVPF 0 126 c=IN IP4 192.168.1.108 a=rtcp:45767 IN IP4 192.168.1.108 a=candidate:1 1 udp 2013266431 192.168.1.108 45767 typ host generation 0 a=candidate:1 2 udp 2013266431 192.168.1.108 45767 typ host generation 0 a=candidate:2 1 udp 2013266431 192.168.1.125 54381 typ host generation 0 a=candidate:2 2 udp 2013266431 192.168.1.125 54381 typ host generation 0 a=ice-ufrag:ro57 a=ice-pwd:t5Utvx59JBg9gf+Cyg4QcX a=fingerprint:sha-256 37:E6:2D:01:B9:81:48:AC:BA:61:A0:B4:E7:C6:EF:73:41:09:85:FB:23:98:28:ED:F3:34:45:1D:05:2E:11:75 a=sendrecv a=mid:audio a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:44444 cname:o/i14u9pJrxRKAsu a=ssrc:44444 msid:lmipTuBs6u a0 a=ssrc:44444 mslabel:lmipTuBs6u a=ssrc:44444 label:lmipTuBs6ua0 m=video 45767 RTP/SAVPF 100 116 117 c=IN IP4 192.168.1.108 a=rtcp:45767 IN IP4 192.168.1.108 a=candidate:1 1 udp 2013266431 192.168.1.108 45767 typ host generation 0 a=candidate:1 2 udp 2013266431 192.168.1.108 45767 typ host generation 0 a=candidate:2 1 udp 2013266431 192.168.1.125 54381 typ host generation 0 a=candidate:2 2 udp 2013266431 192.168.1.125 54381 typ host generation 0 a=ice-ufrag:ro57 a=ice-pwd:t5Utvx59JBg9gf+Cyg4QcX a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=fingerprint:sha-256 37:E6:2D:01:B9:81:48:AC:BA:61:A0:B4:E7:C6:EF:73:41:09:85:FB:23:98:28:ED:F3:34:45:1D:05:2E:11:75 a=sendrecv a=mid:video a=rtcp-mux a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:55543 cname:o/i14u9pJrxRKAsu a=ssrc:55543 msid:lmipTuBs6u v0 a=ssrc:55543 mslabel:lmipTuBs6u a=ssrc:55543 label:lmipTuBs6uv0

I have seen other people having quite the same type of issue but I didn't see any specific resolution/answer for it.

Thanks in advance,

Francois

[Jiayang Liu]

It seems the C++ server sends empty username or malformed STUN message:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/p2p/base/port.cc&l=392

[Iñaki Baz Castillo]

2014-07-10 12:53 GMT+02:00 Francois Temasys <regn...@temasys.com.sg>:
> The ICE connection fail and I can see on the google chrome logs the
> following:
> [118:127:0710/184327:VERBOSE1:port.cc(391)]
> Jingle:Port[audio:1:0::Net[eth1:192.168.1.125/32]]: Received STUN request
> with bad local usernam from 192.168.1.108:45767

Could you make a Tshark/Wireshark capture of the STUN request? the
USERNAME attribute value must be:

LOCAL_PEER_UFRAG + ":" + REMOTE_PEER_UFRAG


--
Iñaki Baz Castillo
<i...@aliax.net>

[Francois Temasys]

Thanks all you helped me a lot.

The problem came from a wrong username in the STUN request, as you pointed me. Wireshark with a filter on "stun" helped me for that.

Best regards,

Francois

[dan....@vertigomusic.com]

Greetings!

I realize this is an old comment, but I've been running into the same issue on my WebRTC application and am not sure what the "solution" to this particular issue was.

It appears that a wrong username in the STUN request is behind the "bad local username" error and that (in my case, at least) getting the error causes problems with the ICE handshake. 

What's not clear to me is how the "wrong" username gets wrong -- where is it coming from?  More important, how did you fix the problem?

Thanks!
Dan

[Federico Henze]

Hi

I experienced a similar problem... I was getting an error during the creation of the SDP. The SDP was corrupted by my signalling "system", the "+" sign on the ufrag was replaced by a space.

The solution was disabling the pooling on the socket instance (SocketIO in my case) used to establish the connection. 

If you used polling, the SDP should be base64url encoded in order to avoid this scenario.

Hope this help!

Federico