I wrote a bro script that works on the flags in the TCP header and on
the identifier field in IP header. While some TCP connections can be
processed without any problems, others seem to produce strange results
with my script.
The attached pcap file (example.pcap) contains a problematic connection.
As you can see this starts with four SYN-Packets (probably due to
retransmits) which also have ECN and CWR set. The identifier field of
this packets is set a custom 0x3fff.
If you run bro-1.4 with the attached script (test.bro), which prints the
id-field and the flags, you will get this output:
As you can see only one SYN-Packet has been passed to new_packet() in
the script. And this packet does neither transport the correct id nor
the correct flags. I think this problem only occurs when the first SYN
packet has been retransmitted.
My questions:
1.) Is it the desired behavior to only pass one SYN-Packet to
new_packet() instead of all SYN-Packets? In my opinion it might be a
good idea to get all packets, that have been transmitted (or observed).
2.) Is it desired behavior that the passed SYN-packet does not contain
all the information that have been in the original packet?
3.) Can I tune bro to give me the original packet?
A bunch of the packets have bad TCP checksums. This is likely the problem -
the event engine is discarding them on that account.
Thank you for the quick reply.
All the packets have bad checksums, because I padded them with
tcprewrite and forgot to use the fix checksum option. I therefore used
bro -C to disable checksum testing when I ran my script (bro actually
would have discarded these packets without -C). So I don't think this is
the source of the problem.
To make sure, I fixed the checksums with tcprewrite (see attached pcap)
and still get the same problem.
Hi Lothar,
I you read your last network pcap trace with wireshark, you have same+multiple first Syn (and WE flags) tcp packet, bro understand simply tcp retransmit? confirmed by conn.log:
1022404512.136083 ? 194.44.56.35 139.103.147.106 http 59235 80 tcp 361 ? S1 X
and packet number 9 are duplicate, and packets number 10 and 11 are retransmit.
Regards
Rmkml Crusoe-Researches.com
Okay, I analyzed this, and the answer is that the connection compressor
can't generate new_packet events for some packets because new_packet
requires an associated connection (first parameter to the event handler),
and the point of the compressor is to not initially create connections.
It can't really fake up a new_packet event in this context once it does
create the connection, because it has (deliberately) lost the interesting
detail.
Your script should work as expected if you run it with
use_connection_compressor=F. Perhaps the presence of a new_packet
event handler should turn off the compressor automatically; or
perhaps we should change new_packet to not have an associated
connection (though I imagine that would often prove inconvenient).