# tcp contents **URL:** \ **Category:** Zeek\ **Created:** [November 30, 2004, 9:20am UTC](https://community.zeek.org/t/tcp-contents/636 "2004-11-30T09:20:34Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [November 30, 2004, 9:20am UTC](https://community.zeek.org/t/tcp-contents/636/1 "2004-11-30T09:20:34Z")
> Bad news: Although it took just a simple modification to a copy of > "demunx\_conn()", I couldn't get it to work when writing to 1 file by using > the CONTENTS\_BOTH flag. Ah - I realized the key problem, which is that CONTENTS\_BOTH is not in fact a valid parameter for set\_contents\_file. The way that contents are extracted from streams, it simply can't work. (The definition is lying around because it's used internal to the event engine in a slightly different context.) Is there some reason why you want to have both directions in a single file? If so, then the way to do it is by defining a tcp\_contents handler that writes out the contents directly to a file: event tcp\_contents(c: connection, is\_orig: bool, seq: count, contents: string) though this won't easily do the right thing in the presence of packet loss/retransmission.     Vern ---
**Author:** ![john\_mcnicholas](https://avatars.discourse-cdn.com/v4/letter/j/fbc32d/32.png) [@john\_mcnicholas](https://community.zeek.org/u/john_mcnicholas)\ **Post date:** [November 30, 2004, 12:21pm UTC](https://community.zeek.org/t/tcp-contents/636/2 "2004-11-30T12:21:05Z")
> Is there some reason why you want to have both directions in a single file? The initial reason was twofold: just to reduce the number of files and to be compatible with a prototype that had been developed. Clearly neither are critical and if the 2 file approach is faster/efficient then that should be enough to trump the single file approach given the importance of speed. > Ah - I realized the key problem, which is that CONTENTS\_BOTH is not in > fact a valid parameter for set\_contents\_file. The way that contents are > extracted from streams, it simply can't work. (The definition is lying > around because it's used internal to the event engine in a slightly > different context.) I really don't want anyone spending more time on this but: a. do you think I just didn't look hard enough at the data for a single file (i.e., it wasn't working when I thought it was) or b. the single file approach would work "most of the time" or all of the time if a connection (such as HTTP\_Conn or SMTP\_Conn) added a contents processor derived from TCP\_ContentLine. i.e. it would work if the TCP\_Connection's BuildEndpoints() method did something functionally equivalent to: orig-\>AddContentsProcessor( new TCP\_ContentLine(orig,1,0,1)); resp-\>AddContentsProcessor( new TCP\_ContentLine(resp,0,0,1)); Obviously "most of the time" isn't good enough but it would explain why a cursory check of the output looked valid. Once again even if the single file did work, if the 2 file approach has a measurable speed advantage we'll probably make the necessary changes to our protocol handlers/applications. Thanks again for your time and help. John ---
**Author:** ![Ruoming\_Pang](https://avatars.discourse-cdn.com/v4/letter/r/df788c/32.png) [@Ruoming\_Pang](https://community.zeek.org/u/Ruoming_Pang)\ **Post date:** [November 30, 2004, 3:14pm UTC](https://community.zeek.org/t/tcp-contents/636/3 "2004-11-30T15:14:06Z")
> event tcp\_contents(c: connection, is\_orig: bool, seq: count, contents: string) > > though this won't easily do the right thing in the presence of packet > loss/retransmission. In fact, tcp\_contents won't be affected by packet loss/retransmission, and it always delivers contents in the order of TCP sequence numbers, because it is called after TCP reassembly in TCP\_Contents::DeliverBlock(). However: 1) There can be content gaps in case some packets are not captured by Bro. Gaps are reported by event content\_gap, but you can also tell by looking at parameter \ and length of \ of tcp\_contents. 2) Also, if the connection is "skipped" (some analyzers, e.g. Netbios/SSN, will automatically skip after seeing a content gap.) function skip\_further\_processing%(cid: conn\_id%): bool the content afterwards won't reach tcp\_contents. The same also applies to "TCP content files". Ruoming ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:37pm UTC](https://community.zeek.org/t/tcp-contents/636/4 "2022-05-06T15:37:15Z")