<div dir="ltr"><div><div>Hi Ingela,<br><br></div>Thank you for reply,<br><br></div><div>The packet was in raw format - the socket option: {packet , 0} - and I tried to send the packet formatted as:<br><br>ssl:send(Sock, <<0:8/unit:1, HeaderLen:32/big, DataBin/binary>>)<br><br></div><div>in order to let the Erlang tcp stack to strip the first byte.<br><br></div><div>That was better, in the sense that the length of the packet was what the client expected but only for the first packet sent to it<br></div><div>from server. For subsequent packets the decoding problem persisted.<br><br></div><div>However, I updated that client to the latest version, and it is working with R14 and R17 without adding first byte. In other words, the code:<br>ssl:send(Sock, <<HeaderLen:32/big, DataBin/binary>>)<br><br></div><div>works the same with both R14 and R17 with new client.<br><br></div><div><br></div><div>That's because the new client has put the fread(socket, length) in a 'while(!feof(socket))' construct allowing it to read the 1st byte and then the other 3 bytes, constructing thus the 'header' of the packet correctly accumulating all 4 bytes.<br><br></div><div>So, after all was a client problem, and their update fixed by accident my problem also.<br><br></div><div>I was stubborn to make Erlang speak with a bad client (which is already distributed to our end clients), altough I knew the fact that the client is badly written.<br></div><div><br>The info you gave me was like a revelation and helped me to understand what really is going on.<br><br></div><div>Thank you so much,<br><br></div><div>Bogdan<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 1:18 PM, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@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><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"><div><div class="h5">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></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><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></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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>
</blockquote></div><br></div>