<div dir="ltr">Eureka, I got it working! Thanks to the feedback from Matt and Alfred, I managed to create a filter that does what I need. To those who may be interested, it's available here:<div><br></div><div><a href="https://github.com/meetecho/janus-gateway/pull/254">https://github.com/meetecho/janus-gateway/pull/254</a><br></div><div><br></div><div>Thanks for your great support!</div><div>Lorenzo</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-05 13:34 GMT+02:00 Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span>:<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"><div class="gmail_quote"><div><div class="h5">2015-06-05 12:30 GMT+02:00 Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span>:<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"><span><br>
<br>
On 05/06/15 10:20, Lorenzo Miniero wrote:<br>
> Just one quick question about this: are messages/packets passed to the<br>
> BIO actually splitted, and then just queued by the mem BIO in the<br>
> buffer, or can there be cases where a larger than normal buffer is<br>
> passed to the BIO anyway, meaning a manual splitting could be needed<br>
> nevertheless from time to time?<br>
<br>
</span>No, there should be no need for the BIO to do any splitting. Everything<br>
that gets written to the BIO should be a datagram.<br>
<br>
One issue that does spring to mind is that in your filter BIO you may<br>
want to implement some of the dgram ctrls that DTLS uses. This depends<br>
on how you want to manage setting your MTU.<br>
<br>
Do you set an MTU size explicitly using SSL_set_mtu(ssl, mtu) or<br>
DTLS_set_link_mtu(ssl, mtu)? Also, do you set the option<br>
SSL_OP_NO_QUERY_MTU? If you use the option then you should set an MTU<br>
size explicitly.<br>
<br>
If you don't set the SSL_OP_NO_QUERY_MTU option then the DTLS code will<br>
attempt to query the underlying BIO for information about the mtu size.<br>
That would mean you would have to implement the following additional ctrls:<br>
BIO_CTRL_DGRAM_GET_FALLBACK_MTU - returns a "default" MTU size if<br>
querying fails for some reason<br>
BIO_CTRL_DGRAM_QUERY_MTU - queries the transport for the MTU size to be used<br>
BIO_CTRL_DGRAM_SET_MTU - sets the MTU size on the underlying transport<br>
BIO_CTRL_DGRAM_MTU_EXCEEDED - returns true if the datagram we just tried<br>
to send failed because we exceeded the max MTU size<br>
<div><div><br>
Matt<br>
</div><div><br></div></div></blockquote><div><br></div></div></div><div>Hi Matt,</div><div><br></div><div>thanks for the clarification and for the hints.</div><div><br></div><div>I've started looking into filters and I have some doubts, though, also taking into account what you suggested, and I apologize again if this turns out to be silly. As far as I've understood, what I should do is changing the current pattern I use for outgoing packets:</div><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>      application < memBIO < ssl</div></div></div><div><br></div>to something like this:<div><br></div><div><div>      application < memBIO < filter < ssl</div></div><div><br></div><div>or this:</div><div><br></div><div><div>      application < filter < memBIO < ssl</div></div><div><br></div><div><div class="gmail_extra">that is, a new BIO filter that enforces the fragmentation I talked about. Not exactly sure about which one should be the way to go, but I've given this some thought.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The first one seems conceptually correct, in the sense that the filter receives the properly sized packets from the stack; I see issues in how to progressively make them available to the memBIO, though, especially considering that we cannot "relay" a BIO_read call (that is, have the mem BIO ask for data to the next BIO in the chain when data is requested). My guess, looking at the BIOs code, is that this is all asynchronous, that is, the DTLS stack issues a BIO_write that reaches the filter, and then it's the filter that forwards the written data (modified or not) to the next BIO, in this case the mem one, using another BIO_write. My concern here is how to figure out when to issue such a write: in fact, if we want to make sure that the mem BIO never returns too much data when a BIO_read is issued, we should never issue a new BIO_write to feed it with new data from the filter until the previous one has been read, something we cannot do if we don't know when the data has been read in the first place.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">The second one, as a consequence, may actually be more suited for the purpose, as we can always only return what we want to in a BIO_read. The issue there is what I mentioned in my previous post, that is, my fear being that the memBIO could feed too much data to my filter in a BIO_write, which would force my filter to inspect the payload and manually split packets as I'd do in my application. But according to what you said at the beginning of your reply, this shouldn't be the case, right? That is, the DTLS stack will issue different BIO_writes towards the memBIO for each packet/fragment, and this would automatically we forwarded to my filter, am I correct? Since in this case there wouldn't be any explicit BIO_read done from the application that may return what's been buffered so far.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Apologies if I'm adding confusion with these questions, I'm just trying to figure out the best approach to the new filter. As an alternative, I guess I could just extend the existing mem BIO to a new, custom BIO, and handle it all there, but my feeling is that a filter would be a cleaner way to do that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks again!</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">Lorenzo</div></font></span></div>
</blockquote></div><br></div>