<div dir="ltr">I could use help on how Suricata deals with app-layer protocol packets when its sees a toclient packet as the first protocol packet. <div><br></div><div>1. From looking at the debug logs, for my new app-layer-protocol, I observe that in the registered ProbingParser if the first protocol packet seen is toclient then the registered Parse function is never invoked and no "app layer state" is allocated. Also, the registered ProbingParser is never invoked for the other direction. In short, Suricata fails to inspect any of these protocol packets even though it sees them and logs them at the TCP layer.</div><div><br></div><div>2. Anoop mentioned that this functionality needs to be implemented. Is there an example of such functionality implemented? If not are there any plans to implement?</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 28, 2014 at 4:01 PM, Adrian Falk <span dir="ltr"><<a href="mailto:adrianfalk2@gmail.com" target="_blank">adrianfalk2@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">Thanks Anoop.<div><br></div><div>Is there an example of how to implement what you suggest?</div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">From what I see, the field 'first_data_dir' would need to be reset appropriately after parsing the packet to identify direction. But where should this protocol specific functionality be implemented (to parse packet) that also has access to the structure containing 'first_data_dir'. Or, is there some other easier way?</span></div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">Thanks.</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 28, 2014 at 11:33 AM, Anoop Saldanha <span dir="ltr"><<a href="mailto:anoopsaldanha@gmail.com" target="_blank">anoopsaldanha@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><div>On Sun, Dec 28, 2014 at 12:30 AM, Adrian Falk <<a href="mailto:adrianfalk2@gmail.com" target="_blank">adrianfalk2@gmail.com</a>> wrote:<br>
> I'm working on an app-layer preprocessor for a TCP-based protocol, modeled<br>
> after Modbus.<br>
><br>
> While running different traffic through my app-layer preprocessor I notice<br>
> while replaying certain capture files the protocol packets identified are in<br>
> the wrong direction (a to-server packet is identified as a to-client<br>
> packet). I have also noticed that for certain other capture files the<br>
> preprocessor doesn't successfully identify any protocol packets although<br>
> such packets are present.<br>
><br>
> I'm running Suricata as follows:<br>
> suricata -c /etc/suricata.yaml -r protocol.pcap<br>
><br>
> I'm using suricata.2.0.4 with mostly default settings except I'm running<br>
> with 'midstream equal to true'.<br>
><br>
> What function in RegisterXParsers() ensures that the protocol packets are<br>
> identified successfully and in the correct direction?<br>
><br>
<br>
</div></div>If you are picking the flow up midstream, there is no way atm to<br>
reverse the direction, if the stream layer sees the wrong direction<br>
first.  That's something that needs to be implemented along with<br>
picking the statrt offset for the next full/new app layer record, in<br>
the stream, so that the app layer parser can initiate parsing from<br>
that offset.<br>
<span><font color="#888888"><br>
--<br>
-------------------------------<br>
Anoop Saldanha<br>
<a href="http://www.poona.me" target="_blank">http://www.poona.me</a><br>
-------------------------------<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>