Project

General

Profile

Actions
Copy link

Support #1882

closed

I don't know why the 2nd file TRUNCATED

Added by seungho yang over 8 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
seungho yang
Affected Versions:
Label:

Description

There are 2 files in the pcap file.
I get the pcap file from test network env. using TAP.

suricata 3.1.1 result
  • first file is closed
  • second file is truncated
wireshark 1.12.6 result
  • 2 files(systemd)
NetworkMiner 2.0 result
  • 2 files(systemd)

I don't know why the 2nd file TRUNCATED.
I tried to check the source, stream-tcp-reassemble.c

execution
[root@suricata suricata3]# /opt/suricata3/bin/suricata -c /opt/suricata3/config/suricata.yaml -r log.pcap.1472709340.tcp8080.dport49736.pcap

line 2920,add 3 printf
(stream->seg_list != NULL && /*2*/
SEQ_GT(stream->seg_list->seq, stream->ra_app_base_seq+1) &&
SEQ_LT(stream->seg_list->seq, stream->last_ack)))
printf("ysh-stream->seg_list->seq: %u\n", stream->seg_list->seq);
printf("ysh-stream->ra: %u\n", stream->ra_app_base_seq+1);
printf("ysh-stream->last_ack: %u\n", stream->last_ack);
then printed,
ysh-stream->seg_list->seq: 4098035050
ysh-stream->ra: 4098030962
ysh-stream->last_ack: 4098036510

suricata.yaml -config for file extraction, noting special
  • depth: 0
  • request-body-limit: 0
  • response-body-limit: 0

Files

Download all files
log.pcap.1472709340.tcp8080.dport49736.pcap (5.31 MB) log.pcap.1472709340.tcp8080.dport49736.pcap pcap file captured by suricata3(pcap-log) seungho yang, 09/02/2016 05:17 AM
wireshark1.12.6-http-object.png (53.4 KB) wireshark1.12.6-http-object.png wireshark 1.12.6 export objects result(2 files) seungho yang, 09/02/2016 05:18 AM
networkminer2.0.png (13.3 KB) networkminer2.0.png networkminer 2.0 result(2 files) seungho yang, 09/02/2016 05:21 AM
suricata3.1.1.png (29.2 KB) suricata3.1.1.png suricata 3.1.1 result(closed, truncated) seungho yang, 09/02/2016 05:25 AM
Actions
Copy link
 #1

Updated by seungho yang over 8 years ago

It cased by window size.
In IDS mode, server or client packets may excess real packet window size.

stream-tch.c
ssn->server.window = TCP_GET_WINDOW(p); // window set current as packet window
ssn->server.window = TCP_GET_WINDOW(p); // window set current as packet window

ssn->server.window = TCP_GET_WINDOW(p) << ssn->server.wscale; // don't understand wscal

/* update next_win */
StreamTcpUpdateNextWin(ssn, &ssn->server, (ssn->server.last_ack + ssn->server.window));

line 2035
/* in window check */
if (zerowindowprobe) {
SCLogDebug("ssn p: zero window probe, skipping oow check", ssn);
} else if (SEQ_LEQ(TCP_GET_SEQ(p) + p->payload_len, ssn->client.next_win) ||
(ssn->flags x%x STREAMTCP_FLAG_MIDSTREAM) ||
(ssn->flags & STREAMTCP_FLAG_ASYNC)) {

I can extract 2 files, temperary modify the source

if (zerowindowprobe) {
SCLogDebug("ssn p: zero window probe, skipping oow check", ssn);
} else if (SEQ_LEQ(TCP_GET_SEQ(p) + p->payload_len, ssn->client.next_win+100000) ||
(ssn->flags x%x STREAMTCP_FLAG_MIDSTREAM) ||
(ssn->flags & STREAMTCP_FLAG_ASYNC)) {

Can you recommend the right way?

Actions
Copy link
 #2

Updated by Victor Julien over 8 years ago

  • Target version deleted (3.1.2)
Actions
Copy link
 #3

Updated by Andreas Herz over 8 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions
Copy link
 #4

Updated by Andreas Herz over 5 years ago

I only get 1 truncated file when I run this with 5.0.0 beta.

Actions
Copy link
 #5

Updated by Victor Julien about 5 years ago

Can we get this test as a SV test?

Actions
Copy link
 #6

Updated by Victor Julien over 4 years ago

  • Tracker changed from Bug to Support
  • Status changed from New to Feedback
  • Assignee changed from OISF Dev to seungho yang
  • Target version deleted (TBD)

I've (finally) been looking at this pcap and I it simply looks like packets are in fact out of window. Packet 3744 is rejected for being out of window, and if you look at the pcap in a recent version of wireshark you see this confirmed. The 'bytes in flight' go over the 'window size' for that packet.

How was the pcap recorded? Maybe some packet reordering has happened during capture or pcap writing.

Suricata is more strict than some other tools about this.

Actions
Copy link
 #7

Updated by Andreas Herz over 4 years ago

  • Status changed from Feedback to Closed

Hi, we're closing this issue since there have been no further responses.
If you think this bug is still relevant, try to test it again with the
most recent version of suricata and reopen the issue. If you want to
improve the bug report please take a look at
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Reporting_Bugs

Actions
Copy link

Also available in: Atom PDF