[libnice] NiceAgentRecvFunc invoked for data no matter the source

[Youness Alaoui]

I guess a patch would be more than welcome. I unfortunately can't handle
this for the next couple of weeks. I would suggest you check the 'from'
address in the list of connchecks, and if it's not a SUCCEEDED or
DISCOVERED pair, then drop the data. Although I think it's more complicated
than that because you could have a pair that hasn't succeeded yet (peer
didn't reply to our conncheck) but is authenticated (then sent a valid
conncheck). Also, I don't remember if the conncheck list is kept once
connectivity is established. This might require a new system to keep track
of the authenticated addresses. Maybe just add a hash table for the
incoming NiceAddress when it's authenticated and use that ?



On Fri, Aug 22, 2014 at 4:09 AM, Lorenzo Miniero <lminiero at gmail.com> wrote:

> Hi Youness,
>
> thanks for the clarification. .Yes, I thought that candidate switching may
> be involved, I was just surprised to see libnice reacting to data coming
> from a source that was not part of the negotiation and so, as you say, not
> authenticated.
>
> So that part is indeed a bug. I'll open an issue as you suggested. No way
> to mitigate it until it is fixed, then?
>
> Lorenzo
>
> 2014-08-22 0:22 GMT+02:00 Youness Alaoui <kakaroto at kakaroto.homelinux.net>
> :
>
> Hi,
>>
>> That's a feature, because while it's usually the same, sometimes your
>> selected pair may be different from the peer's selected pair. Or simply
>> because one interface was disconnected and the peer switched to a different
>> pair, etc.. If libnice receives data from a valid peer, it will send you
>> the data, it's normal. The 'selected pair' is mostly used for sending.
>> However, there is also a bug here, it is currently forwarding back to the
>> application any data it can't parse. It should only do it if the data came
>> from an already authenticated pair. I suggest you file a bug report about
>> this : https://bugs.freedesktop.org/enter_bug.cgi?product=Nice
>>
>> Thanks,
>> Youness.
>>
>>
>>
>> On Thu, Aug 21, 2014 at 12:51 PM, Lorenzo Miniero <lminiero at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I don't know if this is a known bug or feature, as I couldn't find any
>>> reference in the documentation, so I'll try and ask here.
>>>
>>> I noticed that, after a successful ICE setup using libnice, apparently
>>> the NiceAgentRecvFunc callback I set is invoked for a specific component
>>> even when data is not coming from the peer candidate that was selected. To
>>> make a practical and reproduceable exampe, I tried setting up a media
>>> session and, after a successful ICE setup, I used the nc command to send
>>> data to the port my application had selected. Surprisingly, the callback
>>> was notified, and the data was available, while I expected the library to
>>> ignore this external data as it was not part of the "connection"
>>> established between the two parties. Again, not sure if it's a bug or a
>>> feature, but in my case it's pretty awkward as I have no way to understand
>>> whether the message came from who I meant or not.
>>>
>>> Is there any way to force libnice to do this kind of filtering and
>>> actually enforce the "connection" that was negotiated? or, as an
>>> alternative, can I "resolve" the "sender" somehow and do this at an
>>> application level, if needed?
>>>
>>> Thanks,
>>> Lorenzo
>>>
>>> _______________________________________________
>>> 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/20140822/25195f72/attachment.html>