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

[Youness Alaoui]

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/5c25f2a5/attachment.html>