If there is possibility of a pcap I would like to look at it as well .<br>Thanks<br><br><div class="gmail_quote">On Thu, Dec 15, 2011 at 9:01 PM, Eric Leblond <span dir="ltr"><<a href="mailto:eric@regit.org">eric@regit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello<br>
<br>
That look really interesting.<br>
<br>
<br>
Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> a écrit :<br>
<div class="im"><br>
>Hi,<br>
><br>
>The more thorough response will come form the coders but a few<br>
>questions if<br>
>I may:<br>
>1. the stream is just HTTP - correct?<br>
>2. Does it occur only when gzip is around<br>
>3. how do you compile  Suri and do you have chksms enabled or not in<br>
>yaml -<br>
>disabled by default, but just asking?<br>
<br>
</div>4. Could the part of the pcap file triggering the behaviour be sent privately to me or to another developer?<br>
<br>
BR<br>
<div><div class="h5">><br>
>thank you for your help<br>
><br>
>On Thu, Dec 15, 2011 at 8:49 PM, Christophe Vandeplas <<br>
><a href="mailto:christophe@vandeplas.com">christophe@vandeplas.com</a>> wrote:<br>
><br>
>> Hello,<br>
>><br>
>> As said in a previous mail I have many many HTTP errors "Unable to<br>
>> match response to request" like the following error:<br>
>> After analysis I notice that only 20-30% of the whole TCP session is<br>
>> analyzed and all further HTTP requests in the same TCP session are<br>
>> simply ignored by Suricata.<br>
>><br>
>> I was able to find the place and partial origin of the error by<br>
>adding<br>
>> some breakpoints, but I can't really understand what's happening in<br>
>> the code.<br>
>><br>
>> Some info about my pcap: The pcap file contains many http requests in<br>
>> one TCP session.<br>
>><br>
>> The engine steps at the first request, then the response, then the<br>
>> second request and so on.<br>
>> Just after a gzipped response (decoded correctly) the next packet<br>
>> encountered by the engine is not the next request from the pcap, but<br>
>> it's the response. It seems like the engine is simply skipping this<br>
>> http request. But as I don't really understand the code yet I don't<br>
>> understand the cause and can't locate the bug.<br>
>><br>
>> I'm motivated to debug this problem and help find the real origin of<br>
>> the problem but I really need some guidance/help.<br>
>><br>
>> Thanks for the assistance.<br>
>><br>
>><br>
>> On Wed, Dec 14, 2011 at 1:47 PM, Christophe Vandeplas<br>
>> <<a href="mailto:christophe@vandeplas.com">christophe@vandeplas.com</a>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > As I have loads and loads of HTTP (and smtp) parsing errors on my<br>
>> Suricata<br>
>> > instance I wanted to analyze why they occur and try<br>
>debugging/solving the<br>
>> > issue myself. However I'm having a weird behavior with Suricata<br>
>once I<br>
>> > enable --enable-debug.<br>
>> ><br>
>> > I compiled Suricata from the git master repo.<br>
>> ><br>
>> > I load a PCAP file that throws HTTP parsing errors and get the<br>
>following<br>
>> > output.<br>
>> > I get the same output I run this Suricata in gdb.<br>
>> > Pcap file contains a single tcp session in 82kB<br>
>> ><br>
>> > [6659] 14/12/2011 -- 11:18:10 - (source-pcap-file.c:212) <Info><br>
>> > (ReceivePcapFileThreadInit) -- reading pcap file<br>
>> > ../proxytraff-error-parsing.pcap<br>
>> > [2059] 14/12/2011 -- 11:18:10 - (tm-threads.c:1810) <Info><br>
>> > (TmThreadWaitOnThreadInit) -- all 5 packet processing threads, 3<br>
>> management<br>
>> > threads initialized, engine started.<br>
>> > [6659] 14/12/2011 -- 11:18:10 - (app-layer-htp.c:550) <Error><br>
>> > (HTPHandleResponseData) -- [ERRCODE: SC_ERR_ALPARSER(59)] - Error<br>
>in<br>
>> parsing<br>
>> > HTTP server response: [1] [htp_response.c] [677] Unable to match<br>
>> response to<br>
>> > request<br>
>> > [6659] 14/12/2011 -- 11:18:10 - (app-layer-parser.c:977) <Error><br>
>> > (AppLayerParse) -- [ERRCODE: SC_ERR_ALPARSER(59)] - Error occured<br>
>in<br>
>> parsing<br>
>> > "http" app layer protocol, using network protocol 6, source IP<br>
>address<br>
>> > 10.80.96.37, destination IP address 10.7.108.10, src port 63272 and<br>
>dst<br>
>> port<br>
>> > 8080<br>
>> > [6659] 14/12/2011 -- 11:18:10 - (source-pcap-file.c:189) <Info><br>
>> > (ReceivePcapFileLoop) -- pcap file end of file reached (pcap err<br>
>code 0)<br>
>> ><br>
>> ><br>
>> > When I compile ./configure --enable-debug , and load exactly the<br>
>same<br>
>> PCAP I<br>
>> > get the following output:<br>
>> > (also the same with ./configure  --enable-debug<br>
>> --enable-debug-validation )<br>
>> ><br>
>> > [6659] 14/12/2011 -- 11:24:37 - (source-pcap-file.c:212) <Info><br>
>> > (ReceivePcapFileThreadInit) -- reading pcap file<br>
>> > ../proxytraff-error-parsing.pcap<br>
>> > [2059] 14/12/2011 -- 11:24:37 - (tm-threads.c:1810) <Info><br>
>> > (TmThreadWaitOnThreadInit) -- all 5 packet processing threads, 3<br>
>> management<br>
>> > threads initialized, engine started.<br>
>> > Bus error: 10 (core dumped)<br>
>> ><br>
>> ><br>
>> > Running that DEBUG enabled Suricata in gdb I get  (After a first<br>
>> breakpoint<br>
>> > I 'continue'd )<br>
>> > [3091] 14/12/2011 -- 11:39:33 - (tm-threads.c:1810) <Info><br>
>> > (TmThreadWaitOnThreadInit) -- all 5 packet processing threads, 3<br>
>> management<br>
>> > threads initialized, engine started.<br>
>> ><br>
>> > Program received signal EXC_BAD_ACCESS, Could not access memory.<br>
>> > Reason: KERN_PROTECTION_FAILURE at address: 0x00000001029920f8<br>
>> > [Switching to process 93462 thread 0x1a03]<br>
>> > 0x00000001001b5205 in ?? ()<br>
>> ><br>
>> > (gdb) bt<br>
>> > #0  0x00000001001b5205 in ?? ()<br>
>> > #1  0x00000001001acfb7 in ?? ()<br>
>> > #2  0x00000001001a5336 in ?? ()<br>
>> > #3  0x000000010018911a in ?? ()<br>
>> > #4  0x00000001001906c9 in ?? ()<br>
>> > #5  0x000000010016ddd7 in ?? ()<br>
>> > #6  0x000000010017b9ce in ?? ()<br>
>> > #7  0x00000001001667c0 in ?? ()<br>
>> > #8  0x000000010014fe72 in ?? ()<br>
>> > #9  0x00000001000140f3 in ?? ()<br>
>> > #10 0x000000010034872c in pcap_offline_read ()<br>
>> > #11 0x0000000100013814 in ?? ()<br>
>> > #12 0x000000010014e92b in ?? ()<br>
>> > #13 0x00007fff883548bf in _pthread_start ()<br>
>> > #14 0x00007fff88357b75 in thread_start ()<br>
>> ><br>
>> > It's weird that I don't get resolved functions in the backtrace,<br>
>no?<br>
>> > Any advice what I should do next?<br>
>> ><br>
>> > Thanks<br>
>> > Christophe<br>
>> _______________________________________________<br>
>> Oisf-users mailing list<br>
>> <a href="mailto:Oisf-users@openinfosecfoundation.org">Oisf-users@openinfosecfoundation.org</a><br>
>> <a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
>><br>
><br>
><br>
><br>
>--<br>
>Peter Manev<br>
>_______________________________________________<br>
>Oisf-users mailing list<br>
><a href="mailto:Oisf-users@openinfosecfoundation.org">Oisf-users@openinfosecfoundation.org</a><br>
><a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
--<br>
</div></div>Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.<br>
</blockquote></div><br><br clear="all"><br>-- <br>Peter Manev<br>