# Artificial SYN-Packets? **URL:** \ **Category:** Zeek\ **Created:** [June 8, 2009, 2:01pm UTC](https://community.zeek.org/t/artificial-syn-packets/1508 "2009-06-08T14:01:37Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Lothar\_Braun2](https://avatars.discourse-cdn.com/v4/letter/l/b5ac83/32.png) [@Lothar\_Braun2](https://community.zeek.org/u/Lothar_Braun2)\ **Post date:** [June 8, 2009, 2:01pm UTC](https://community.zeek.org/t/artificial-syn-packets/1508/1 "2009-06-08T14:01:37Z")
Hi all, 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: $ bin/bro -C -r example.pcap test.bro 0 2 16383 210 16383 208 16383 216 16383 210 16383 208 16383 216 8191 216 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? Best regards,   Lothar [example.pcap](https://community.zeek.org/uploads/short-url/rdLMAb5PYa5tmzS4qgiUwDTAgvq.pcap) (2.01 KB) [test.bro](https://community.zeek.org/uploads/short-url/2rxXheo2KMb5ektvgVemqOwN9uV.bro) (92 Bytes) ---
**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:** [June 8, 2009, 2:31pm UTC](https://community.zeek.org/t/artificial-syn-packets/1508/2 "2009-06-08T14:31:45Z")
A bunch of the packets have bad TCP checksums. This is likely the problem - the event engine is discarding them on that account.     Vern ---
**Author:** ![Lothar\_Braun2](https://avatars.discourse-cdn.com/v4/letter/l/b5ac83/32.png) [@Lothar\_Braun2](https://community.zeek.org/u/Lothar_Braun2)\ **Post date:** [June 8, 2009, 2:49pm UTC](https://community.zeek.org/t/artificial-syn-packets/1508/3 "2009-06-08T14:49:31Z")
Hi Vern, Vern Paxson wrote: > 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. Best regards,   Lothar [example-fixed.pcap](https://community.zeek.org/uploads/short-url/d6pWezlLbP3J8SqkhafXGzVeXmZ.pcap) (2.01 KB) ---
**Author:** ![rmkml](https://avatars.discourse-cdn.com/v4/letter/r/df705f/32.png) [@rmkml](https://community.zeek.org/u/rmkml)\ **Post date:** [June 8, 2009, 3:35pm UTC](https://community.zeek.org/t/artificial-syn-packets/1508/4 "2009-06-08T15:35:03Z")
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](http://Crusoe-Researches.com) ---
**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:** [June 9, 2009, 11:42am UTC](https://community.zeek.org/t/artificial-syn-packets/1508/5 "2009-06-09T11:42:08Z")
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).     Vern ---
**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:38pm UTC](https://community.zeek.org/t/artificial-syn-packets/1508/6 "2022-05-06T15:38:53Z")