Integrating arbitary packet sources

[sushrut...@gmail.com]

Hi,

I want to use the tcp reassembly feature in this library. However my TCP segment source isn't a standard n/w interface nor a pcap file. It is actually another library that forwards tcp segments to me. Is there a way I can integrate this source somehow with libtins? I will not have access to the network interface at all and this library is the only source for me. At a high level, my intent is to do all these using libtins:

   1 get tcp segment retrieved from segment source library ('another library' referred to above).

   2 send segment to libtins tcp reassembler

   3 wait for next segment

   4 goto 1

My expectation (based on current libtins understanding) is that libtins should be able to resolve all these tcp segments into one or more reassembled tcp streams from which I can then extract the application layer data and do further processing on.

Thank you for your time. Let me know if you have follow up queries.

Rgds,

Sushrut.

[Matias Fontanini]

Hi,

this can indeed be done using libtins. If you have a look at the TCPStreamFollower class, you'll see that one of the overloads of the follow_streams member function takes 2 iterators as parameters. What you'd need to do is create an iterator class that wraps the other library. The interface of those iterators should roughly look like this:

class SomeLibraryIterator : public std::iterator<std::forward_iterator_tag, PDU> {

public:

    PDU& operator*();

    PDU* operator->();

    // ....

private:

    std::unique_ptr<PDU> the_packet_sniffed_from_some_library;

    something some_library_handler;

};

You can have a look at the SnifferIterator class which does exactly the same over a Tins::Sniffer. The iterator should extract a packet from this other library each time operator++ is called, and return the last retrieved packet on operator* or operator->. 

Let me know if you need more guidance on this.

Cheers,

Matias

[sushrut...@gmail.com]

Thanks Matias. I'll try this out. I have a couple of queries in addition:

 - Is libtins multithread safe? Can I share libtins object instances amongst threads? Is there a guideline somewhere (I saw this, but is there something else that I should be aware of?).

 - Can you share who all are using libtins currently in production?

Rgds,

Sushrut.

[Matias Fontanini]

Hi Sushrut,

first of all, please keep in mind that the TCP stream reassembly feature
does not handle overlapping fragments, so you'll probably have problems
with it. However, I'm working on improving it right now, so luckily in a
couple of hours I'll be pushing the changes.

Regarding libtins thread-safety, almost everything in the library
provides the same thread-safety guarantees that the C++ standard does:
that means you can have multiple readers accessing an object at the same
time, but one or more readers and one or more writers at the same time
will cause troubles. This means you can sniff a packet and have multiple
objects reading its properties and that will be perfectly fine. This
also means that you can't access a Sniffer object in a multi-thread
manner, since the libpcap handle is not thread safe either. If you're
only sniffing(and not sending packets) you shouldn't encounter any problems.

I don't think I can share who is using it in production, but I can
assure you that there are some people who are. If you're worried about
the library's stability, you shouldn't be. I'm currently using it a lot
and have *never* seen a crash/bug/memory leak ever since the library got
mature enough(around version 1.0).

If you have any other questions, please ask.

Regards,
Matias

On 02/04/14 03:23, sushrut...@gmail.com wrote:
> Thanks Matias. I'll try this out. I have a couple of queries in addition:
> - Is libtins multithread safe? Can I share libtins object instances

> amongst threads? Is there a guideline somewhere (I saw this<http://libtins.github.io/tutorial/sending/#thread-safety>,

> but is there something else that I should be aware of?).
> - Can you share who all are using libtins currently in production?
>
> Rgds,
> Sushrut.
>
> On Tuesday, April 1, 2014 6:43:52 PM UTC+5:30, Matias Fontanini wrote:
>> Hi,
>>
>> this can indeed be done using libtins. If you have a look at the

>> *TCPStreamFollower* class, you'll see that one of the overloads<https://github.com/mfontanini/libtins/blob/master/include/tcp_stream.h#L248>of the
>> *follow_streams* member function takes 2 iterators as parameters. What

>> you'd need to do is create an iterator class that wraps the other library.
>> The interface of those iterators should roughly look like this:
>>
>> class SomeLibraryIterator : public
>> std::iterator<std::forward_iterator_tag, PDU> {
>> public:
>> PDU& operator*();
>> PDU* operator->();
>> // ....
>> private:
>> std::unique_ptr<PDU> the_packet_sniffed_from_some_library;
>> something some_library_handler;
>> };
>>

>> You can have a look at the SnifferIterator class<https://github.com/mfontanini/libtins/blob/master/include/sniffer.h#L325> which
>> does exactly the same over a *Tins::Sniffer*. The iterator should extract

[Matias Fontanini]

I've just pushed the overlapping segments problem fix. TCPStreamFollower should now handle all streams without problems. 

[sushrut...@gmail.com]

Thanks Matias.

Are there any other pending features that I need to be aware of?

Rgds,

Sushrut.

[Matias Fontanini]

No, there aren't any features that are planned to be added in the near
future. You are free to propose new ones, though :P.