[Bro] Bro trace files - packets truncated in some circumstances?

Jim Mellander jmellander at lbl.gov
Thu Oct 26 16:24:13 PDT 2006


I'm testing Bro on a 10 G link.  In some cases, it seems that the
tracefile created by Bro truncates the received packet.


Here's an instance where the Bro running the 10G card cut off the packet
early:

>From Bro running on 10G:

1161587285.381234 128.3.7.51.80 > 66.94.232.246.46965: FP
2067756330:2067756438(108) ack 53063837 win 24616 <nop,nop,timestamp
1275337162 783243679> (DF)
                         4500 00a0 e4dc 4000 3e06 a4f0 8003 0733
                         425e e8f6 0050 b775 7b3f 752a 0329 b09d
                         8019 6028 6a20 0000 0101 080a 4c04 19ca
                         2eaf 599f
Bro running on 1G:

1161587285.381098 128.3.7.51.80 > 66.94.232.246.46965: FP
2067756330:2067756438(108) ack 53063837 win 24616 <nop,nop,timestamp
1275337162 783243679> (DF)
                         4500 00a0 e4dc 4000 3e06 a4f0 8003 0733
                         425e e8f6 0050 b775 7b3f 752a 0329 b09d
                         8019 6028 6a20 0000 0101 080a 4c04 19ca
                         2eaf 599f 636b 7175 6f74 653e 3c2f 7464
                         3e0d 0a20 203c 2f74 723e 0d0a 3c2f 7461
                         626c 653e 0d0a 0d0a 3c70 3e3c 6120 6872
                         6566 3d22 2e2f 6c65 6164 5f65 7870 6f73
                         7572 652e 7368 746d 6c22 3e4e 6578 743e
                         3c2f 613e 0d0a 0909 0909 0909 0d0a 0d0a
                         3c2f 626f 6479 3e0d 0a3c 2f68 746d 6c3e



Looking at other examples, it looks like Bro cuts off FIN's with data
when recording packets, sometimes.  I've seen this same effect on the 1
Gig traffic too, so I don't think it is a problem with the 10 G card.


In the Bro code, TCP_Rewriter.cc, we see:


void PacketDumper::DumpPacket(const struct pcap_pkthdr* hdr,
                                const u_char* pkt, int len)
        {
        if ( pkt_dump )
                {
                struct pcap_pkthdr h = *hdr;
                h.caplen = len;
                if ( h.caplen > hdr->caplen )
                        internal_error("bad modified caplen");

                pcap_dump((u_char*) pkt_dump, &h, pkt);
                }
        }



So it looks like if passed a smaller len than the original capture
length, the output packet will be smaller than the original received
packet.  Does anyone know why this is being done?  It would be nice if
the entire packet was recorded....


-- 
Jim Mellander
Incident Response Manager
Computer Protection Program
Lawrence Berkeley National Laboratory
(510) 486-7204

The reason you are having computer problems is:

Just type 'mv * /dev/null'.





More information about the Bro mailing list