<div dir="ltr"><div>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 ?<br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 4:09 AM, Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Youness,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Lorenzo<br><br><div class="gmail_quote">2014-08-22 0:22 GMT+02:00 Youness Alaoui <span dir="ltr"><<a href="mailto:kakaroto@kakaroto.homelinux.net" target="_blank">kakaroto@kakaroto.homelinux.net</a>></span>:<div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Hi,<br></div><div><br></div><div>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 : <a href="https://bugs.freedesktop.org/enter_bug.cgi?product=Nice" target="_blank">https://bugs.freedesktop.org/enter_bug.cgi?product=Nice</a></div>
<div><br></div><div>Thanks,</div><div>Youness.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Thu, Aug 21, 2014 at 12:51 PM, Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br>
</div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks,</div><div>Lorenzo</div></div>
<br></div></div>_______________________________________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org" target="_blank">nice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>