[Oisf-devel] help, not understand the use of slot_pre_pq and slot_post_pq

Victor Julien victor at inliniac.net
Thu May 24 13:30:00 UTC 2012


In some cases, a thread module (like Decode, Detect, etc) has the need
to create an extra packet. This packet is internal to the engine only.
The easiest example is dealing with tunnel packets. In Suricata, when we
encounter a ip6-in-ip4 packet for example, we process the embedded ip6
packet separately in the engine. It remains connected to the original,
so that IPS mode can drop it. To enable this creation of extra packets,
the api needs to support it.

Each thread module is given 2 queues to put new packets in. The "pre"
and "post" queues. The difference is only timing: when will the new fake
packet be processed by the engine.

On 05/23/2012 05:12 PM, iswalker wrote:
> hi,when I read suricata code,the following two data item slot_pre_pq and
> slot_post_pq    confused me
> In a packet process path,when should we use slot_pre_pq and when we
> should use slot_post_pq?
> can anyone show an example ??
> 
> thanks!!
> 
>  /* queue filled by the SlotFunc with packets that will
>      * be processed futher _before_ the current packet.
>      * The locks in the queue are NOT used */
>     PacketQueue slot_pre_pq;

These are processed right after the thread module finished. So in case
of the ip6-in-ip4 we have:

thread module starts:
- gets raw ipv4 packet
- runs Decode
 => decode creates fake ip6 pkt, places it into "pre"
- Decode completes
- pre queue packets are processed*
- original packet is processed further*

*) processing here means passing it on to the next module directly, or
passing it to a queue to the next thread

This makes sure that the ipv6 packet is processed before the original
(and real) ipv4 packet.

>     /* queue filled by the SlotFunc with packets that will
>      * be processed futher _after_ the current packet. The
>      * locks in the queue are NOT used */
>     PacketQueue slot_post_pq;

Likewise, the packets in post_pq are processed _after_ the original
completed.

Note that completion here refers to the thread processing the packet. In
some runmodes multiple threads process a packet sequentially.

As far as I can see now, the post_pq is really only used to inject fake
packets into from the flow manager. The flow manager times out flows and
injects fake packets to trigger final stream reassembly, detection and
logging.

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------




More information about the Oisf-devel mailing list