search

mscdex / cap

A cross-platform binding for performing packet capturing with node.js
MIT License
360 stars 46 forks source link

Cap Module ignores TCP segment of Reassembled PDU #54

Closed dheerajreddy1 closed 6 years ago

dheerajreddy1 commented 6 years ago

Since the chuck of data is reassembled into two packets. Cap module is not capturing the first reassembled TCP packet. It is capturing only the second packet. How to capture both the packets ?

mscdex commented 6 years ago

Can you provide details on how to reproduce the issue?

dheerajreddy1 commented 6 years ago

It took some time to analyse, sorry for the late reply. I have segregated my analysis in the three scenarios. Please find it below.

Case 1 : I tried sending TCP data of 1646 bytes. And capturing it through the cap module parallely. . In wireshark, the packet is divided into 1506 bytes and remaining (since MTU size is 1500). Cap module is not able to capture that 1506 bytes packet and it captured remaining content in another packet.

Case 2 : I tried sending TCP data of 1203 bytes and the total length including Ethernet,IP and TCP header(1257 bytes). Cap module still not able to capture the packet.

Case 3: I tried sending TCP data of 1202 bytes and the total length including Ethernet,IP and TCP header(1256 bytes). Now, Cap module is able to capture the whole 1256 packet.

From this, I conclude maximum buffer allocated to capture the any packet (no filter with protocol) through cap module is 1256 bytes (including all the headers).

Is there a way to increase the buffer size in cap module to capture the packet greater than 1256 bytes ? Where should i modify it? (PS: I went through decoders.js file , but I didnt find any option to increase the buffer size.)

On Tue, Oct 31, 2017 at 6:07 PM, Brian White notifications@github.com wrote:

Can you provide details on how to reproduce the issue?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mscdex/cap/issues/54#issuecomment-340749217, or mute the thread https://github.com/notifications/unsubscribe-auth/AQO0boWG-QIDJWM-H2AQ7TF8Mq86LDvnks5sxxRvgaJpZM4QMpEX .

wyxcoder commented 4 years ago

Right, why this is closed? is it solved? I am facing the same problem

mscdex commented 4 years ago

@wyxcoder libpcap (and thus cap) operates at a lower level than Wireshark and thus does not process packets, including reassembly. This is up to cap users if they wish to reassemble packets.

Supamiu commented 3 years ago

Hi,

I saw this issue while trying to udnerstand why reassembly wasn't done and I understand your choice as Cap must stay as flexible as possible. However, I'm thinking maybe you could provide an example of how one would do that.

As someone who is inexperienced with TCP reassembly, this seems very complex to do and I'm surprised nobody provided a nodejs example before, and I'm currently just lost in the RFC, trying to understand how this should be implemented in nodejs.

guyharris commented 2 months ago

If by "the RFC" you mean RFC 793, that's not sufficient to figure out what to do.

TCP (and, for another example, TLS) is a byte-stream protocol, meaning it transports a sequence of bytes, with no packet boundary indications. Protocols running atop TCP have to indicate packet/message boundaries themselves, and there's one fashion that is used by all protocols.

This means that reassembly has to be done cooperatively between the code that dissects TCP and the code that dissects the higher-level protocol, as packet boundaries cannot be discovered purely at the TCP layer.

One common way to indicate packet boundaries is to have, in the packet header, a length indication from which the total length of the packet in bytes, including the header, can be calculated. Text-based protocols such as HTTP might use other mechanisms; in the case of HTTP, the header of a request or response is terminated by a blank line, and, by parsing the header fields, the presence of and, if present, the end of the body can be determined.

Note also that this also means that a single TCP segment can contain parts of more than one higher-level packet, so you will also have to carve a single TCP segment into pieces. A single segment might, for example, contain the last part of one higher-level packet, one or more full higher-level packets, and the first part of an additional higher-level packet.

(And, yes, this means that the receiving side of an implementation of a protocol that runs atop a byte-stream transport layer has to do the same sort of work. A single read from a TCP socket, for example, is not guarantee to contain all of one and only one higher-level packet.)