[Oisf-devel] Problem identifying direction correctly for app-layer preprocessor

[Adrian Falk]

Thanks Anoop.

Is there an example of how to implement what you suggest?

>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?

Thanks.

On Sun, Dec 28, 2014 at 11:33 AM, Anoop Saldanha <anoopsaldanha at gmail.com>
wrote:

> On Sun, Dec 28, 2014 at 12:30 AM, Adrian Falk <adrianfalk2 at gmail.com>
> wrote:
> > I'm working on an app-layer preprocessor for a TCP-based protocol,
> modeled
> > after Modbus.
> >
> > While running different traffic through my app-layer preprocessor I
> notice
> > while replaying certain capture files the protocol packets identified
> are in
> > the wrong direction (a to-server packet is identified as a to-client
> > packet). I have also noticed that for certain other capture files the
> > preprocessor doesn't successfully identify any protocol packets although
> > such packets are present.
> >
> > I'm running Suricata as follows:
> > suricata -c /etc/suricata.yaml -r protocol.pcap
> >
> > I'm using suricata.2.0.4 with mostly default settings except I'm running
> > with 'midstream equal to true'.
> >
> > What function in RegisterXParsers() ensures that the protocol packets are
> > identified successfully and in the correct direction?
> >
>
> If you are picking the flow up midstream, there is no way atm to
> reverse the direction, if the stream layer sees the wrong direction
> first.  That's something that needs to be implemented along with
> picking the statrt offset for the next full/new app layer record, in
> the stream, so that the app layer parser can initiate parsing from
> that offset.
>
> --
> -------------------------------
> Anoop Saldanha
> http://www.poona.me
> -------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20141228/5d4a4403/attachment-0002.html>