<div dir="ltr"><div><div><div>Hi!<br><br></div>It could have to do with that with the fact that the length argument is only relevant for raw sockets,<br></div>and that in R15 we implemented  1/n-1 splitting countermeasure to the
            Rizzo Duong BEAST attack, which<br></div>will split all packets to the into the first byte and the following bytes. <br><div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-28 10:50 GMT+01:00 Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi folks,<br><br></div>sorry for  my problem but I am stuck after <br>turning it on every facet.<br><br></div><div>I have an application server that processes xml structures<br></div><div>with the following listen parameters:<br><br>{ok, ListenSock} = ssl:listen(Port, [binary, <br>                                                       {packet, 0}, % app specific packaging<br>                                                        {active, false},<br>                                                        {ip, IPv4},<br>                                                        {mode, binary},<br>                                                        {certfile, Certfile},<br>                                                        {cacertfile, CACertfile},<br>                                                        {keyfile, Keyfile},<br>                                                        {verify, verify_none},<br>                                                        {fail_if_no_peer_cert, false},<br>                                                        {ssl_imp, new}<br>                ]),<br><br></div>I have the following piece of code:<br><div><br></div><div>%% receiving part:<br></div><div>recv_frame_ssl(S, N, SslRecvTimeout) -><br>        {ok, Header} = ssl:recv(S, 4, SslRecvTimeout),<br>        <<Length:32/big>> = Header,<br><br>        {ok, Data} = ssl:recv(S, Length - 4, SslRecvTimeout),<br>        <<Data1/binary>> = Data,<br>        <br>        {ok, binary_to_list(Data1)}.<br>        <br>%%and sending part - the problematic piece of code:<br>send_frame_ssl(Sock, Data) -><br>        DataBin = unicode:characters_to_binary(Data),<br>        HeaderLen = erlang:size(DataBin) + 4,<br>        <br>        ssl:send(Sock, <<HeaderLen:32/big>>),<br>        ssl:send(Sock, <<DataBin/binary>>).<br><br></div>In R14B04 variable HeaderLen is encoded in network byte order correctly and the client is able to extract the header and to read the rest of packet which has (HeaderLen - 4) length in bytes.<br><br></div>In R15, R16 and R17 variable HeaderLen is no more encoded correctlty, apparently, as the client receives a large value and is unable to extract the correct length of the packet and hence, is not able to read the rest of the packet which is xml payload.<br></div>For example, instead of receiving a HeaderLen with value 390 the client receives a HeaderLen with value 189756.<br><br></div>I really don't know how to approach this problem and I am sure I miss something obvious.<br><br></div><div>I tried different combination of HeaderLen encoding with no success whatsoever.<br></div><div><br></div>Please shed some light on this as I am puzzled and I do not know what to do.<br><br></div>Thank you,<br><br></div>Bogdan<br><div><div><br><div><div><div><br><br></div></div></div></div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div></div></div></div></div>