[Nice] Received unexpected message both before and after component state ready

[Jianbin Kang]

Thanks!
This issue doesn't bring troulbe (Just a warning on the console).

Seems that libjingle doesn't have the problem. I will try to find out how
libjingle deal with server response.



2014-04-08 16:05 GMT+08:00 Youness Alaoui <kakaroto at kakaroto.homelinux.net>:

> This is a very old bug, and it's caused by the STUN server. I just added a
> /* FIXME */ in the code about it.
>
> https://github.com/tieto/libnice/commit/3727a574960a341e4a472567d3cdcf81d21681a3#diff-3f00c4bd712ae194ed79810bcb41210eR678
> Basically what happens is that the ICE specification says that we must
> send keepalives on the UDP sockets to keep the port open. If the connection
> is established, then we send a binding request on the connection which is
> fine, on reception, libnice will parse it and ignore it. In the case of a
> non-established connection (component is CONNECTING or CONNECTED state),
> then it can't do it, so it will keep the candidate alive by sending a STUN
> request to the server from which the server-reflexive candidate was
> discovered.
> See section 4.1.1.4 of the ICE specification :
> http://tools.ietf.org/html/rfc5245#section-4.1.1.4
> The problem is that the STUN server only accepts RFC3489 STUN requests,
> and ICE uses RFC5389, so when the response is received by the STUN server,
> it cannot be parsed as a valid stun message, so libnice assumes it's
> application data and forwards it back to the application.
> This was never a problem because when using RTP, the application will
> reject the stun as it validates the data it receives.
> We would need to fix this either by using a binding indication (which does
> not generate a response from the server) but it would break the ICE RFC
> which says we must send a binding request, or by using RFC5389 to send the
> request, which will cause the server to ignore it or response with an error
> (which will probably still be in RFC3489 format, which won't solve the
> problem), or on reception, we would have a RFC3489 stun agent that we can
> use to parse those kinds of messages.
>
> Youness.
>
>
>
> On Sun, Mar 30, 2014 at 12:41 PM, Olivier Crête <
> olivier.crete at collabora.com> wrote:
>
>> Hi,
>>
>> This doesn't look right, and this packet indeed looks like a STUN
>> packet. But any UDP based application should be ready to receive garbage
>> packets and somehow validate its input, so it shouldn't matter.
>>
>> Olivier
>>
>> On Sun, 2014-03-30 at 22:40 +0800, Jianbin Kang wrote:
>> > Hello, All
>> >
>> >
>> > I used nice examples/simple-example.c to test ice, but found that
>> > 'cb_nice_recv' was called both before and after
>> > NICE_COMPONENT_STATE_READY.
>> >
>> > I changed the function 'cb_nice_recv' to print the length of received
>> > data, like this:
>> >
>> >   printf("****Recv(%u): %.*s", len, len, buf);
>> >
>> >
>> > And during candidate allocating, cb_nice_recv was called with 32 bytes
>> > of data:
>> > cb_nice_recv(32):
>> >      01 01 00 0c 7c f4 b8 25 a2 68 67 2a 87 fe 06 8f 59 3c 2f 2b 00 01
>> > 00 08 00 01 40 04 3c 08 75 49
>> >
>> >
>> >
>> > After state ready, cb_nice_recv was called with the another 32 bytes.
>> > The first four bytes was same (01 01 00 0c)
>> >
>> >
>> > The stun server I used was: stun.l.google.com:19302
>> >
>> > stunserver.org has the same problem too, but the length of data was 88
>> > bytes.
>> >
>> >
>> > Is this a bug or just something I misunderstand?
>> >
>> > Thanks
>> >
>> > Jianbin
>> >
>> > _______________________________________________
>> > nice mailing list
>> > nice at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/nice
>>
>> --
>> Olivier Crête
>> olivier.crete at collabora.com
>>
>> _______________________________________________
>> nice mailing list
>> nice at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nice
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140408/aa97152f/attachment.html>