Integrating arbitary packet sources - 2

[sushrut...@gmail.com]

Hi,

I got a great response to my earlier query on this. After doing a study of libtins and also the packet source library that I have to work with, I've come up with a different way of building streams. Would you be able to look at the psuedocode below and let me know if it looks right? (I have some queries too after that).

Couple of things:

   - my packet source library sends packets to me via callbacks. for each packet that it encounters, it will invoke a callback within which I would be able parse that packet.

   - Considering the above, what I've done is to create a PDU for each packet that I get in a callback and then push it into a vector of PDU's. Once a certain number of PDU's are available    in the vector I intend to call TCPStreamFollower::follow_stream overload that was pointed out in the response to my first post.

Psuedo code:

   a) create a TCP PDU (TCP tcp);

   b) assign dport,sport, seq, ack_seq, window to tcp members as relevant;

   c) assign payload data to a RawPDU;

   d) push the RawPDU into the TCP PDU;

   e) push the TCP PDU into the vector;

   f)  if the vector is over a certain size, call TCPStreamFollower->followstream(vector.begin, vector.end, data_handler, end_handler);

   g) In data_handler / end_handler, analyze server_payload and client_payload as needed;

Queries:

   1) I am still a bit confused by what exactly would libtins need to start forming a stream. For e.g., are there any members of TCP that I should populate apart from the ones I wrote in b) above?

   2) Will passing in a TCP PDU with app layer data as its inner_pdu suffice? Or do I need to pass the whole packet as [ETH II] / [IP] / [TCP] / [RawPDU]?

   3) At what points will data_handler be invoked?

   4) I am assuming that a single TCPStreamFollower object will be able to hold multiple parallel reassembled streams - is this correct?

Thank you for your time!

Rgds,

Sushrut.

[Matias Fontanini]

Hi,

first of all, I want to mention that I've just done a small fix on
TCPStreamFollower::follow_streams, which you need to pull before using
it the way you want to use it. follow_streams used to clear the object's
internal state before following streams, so calling it twice would make
the partial data collected on the first call disappear. Now it's fixed
and you can call it several times without any troubles(I don't even know
why it behaved like that in the first place...).

The mechanism you described seems okay. The only thing left would be to
add a network layer(see answer number 2 below).

Now, regarding your questions:

1) libtins can only follow streams for which the connection
establishment has been seen. This means that it will only follow those
connections for which it sees the SYN, SYN-ACK, ACK handshake. This
could be fixed in the future, but the problem would be how to determine
who is the client and who is the server in the connection. I don't think
this will be a problem for you anyway.
2) The link layer(Eth2 in this case) is not relevant. The network layer
data is required, since in order to distinguish different connections,
both the IP addresses and TCP ports are required.
3) The data_handler functor will be called everytime there's new data
from either the client or the server. The end_handler will be called
when the connection is closed.
4) Yes, a single TCPStreamFollower object can follow several
connections(and that's the reason for answer 2) ).

If you have any other questions, feel free to ask.

Regards,
Matias

On 07/04/14 08:46, sushrut...@gmail.com wrote:
> Hi,
>
> I got a great response to my earlier query

> <https://groups.google.com/forum/#!topic/libtins/THADLSPhRpI>on this. After

> doing a study of libtins and also the packet source library that I have to
> work with, I've come up with a different way of building streams. Would you
> be able to look at the psuedocode below and let me know if it looks right?
> (I have some queries too after that).
>
> Couple of things:
> - my packet source library sends packets to me via callbacks. for each
> packet that it encounters, it will invoke a callback within which I would
> be able parse that packet.
> - Considering the above, what I've done is to create a PDU for each
> packet that I get in a callback and then push it into a vector of PDU's.
> Once a certain number of PDU's are available in the vector I intend to

> call TCPStreamFollower::follow_stream overload<https://groups.google.com/d/msg/libtins/THADLSPhRpI/wXEGxYVP1Z0J>that was pointed out in the response to my first post.

[sushrut...@gmail.com]

Thanks Matias. Should I get only the stream follower class or the whole master package at https://github.com/mfontanini/libtins/archive/master.tar.gz?

Rgds,
Sushrut.

[Matias Fontanini]

Any of those. I've just changed tcp_stream.h, so getting only that file
will do.

Regards,
Matias