# segmentation fault by adding an analyzer to port 80

**URL:** <https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632>\
**Category:** Zeek\
**Created:** [April 4, 2013, 9:15am UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632 "2013-04-04T09:15:06Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Eric\_Asselin](https://avatars.discourse-cdn.com/v4/letter/e/9f8e36/32.png) [@Eric\_Asselin](https://community.zeek.org/u/Eric_Asselin)\
**Post date:** [April 4, 2013, 9:15am UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632/1 "2013-04-04T09:15:06Z")

</div>

When I force the anaylzer to be activated by modifying the DPM.cc, everything works well. But when I try to activate it by using a Bro script, like this:

global foo\_ports: set[port] = { 80/tcp } &redef;  
redef dpd\_config += { [ANALYZER\_MYPROTO] = [$ports = foo\_ports] };

a segmentation fault appear at the end of the script.

There is the command I use to execute it (note that the browse.pcap file came from a Bro workshop):

bro -b -r browse.pcap my\_proto.bro

Here’s the complete code of the analyzer and the Bro script:

MyProto.h

---

<div class="post-metadata">

**Author:** ![Eric\_Asselin](https://avatars.discourse-cdn.com/v4/letter/e/9f8e36/32.png) [@Eric\_Asselin](https://community.zeek.org/u/Eric_Asselin)\
**Post date:** [April 4, 2013, 11:41am UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632/2 "2013-04-04T11:41:03Z")

</div>

Additional information from gdb:

Program received signal SIGSEGV, Segmentation fault.  
0x0000000000000000 in ?? ()  
(gdb) bt  
#0 0x0000000000000000 in ?? ()  
#1 0x000000000082b156 in TCP\_Analyzer::EndpointEOF (this=0xed24b0,  
endp=0xed2920) at /home/easselin/bro/src/TCP.cc:1756  
#2 0x000000000082f8b5 in TCP\_Reassembler::CheckEOF (this=0xed2920) at  
/home/easselin/bro/src/TCP\_Reassembler.cc:574  
#3 0x000000000082d4db in TCP\_Endpoint::CheckEOF (this=0xed2570) at  
/home/easselin/bro/src/TCP\_Endpoint.cc:98  
#4 0x0000000000828e7f in TCP\_Analyzer::DeliverPacket (this=0xed24b0,  
len=0, data=0xec1a06 "\r\n", is\_orig=true, seq=-1, ip=0x7fffffffe310,  
caplen=0) at /home/easselin/bro/src/TCP.cc:1051  
#5 0x0000000000686c2f in Analyzer::NextPacket (this=0xed24b0, len=20,  
data=0xec19f2 "\300\203", is\_orig=true, seq=-1, ip=0x7fffffffe310,  
caplen=20) at /home/easselin/bro/src/Analyzer.cc:348  
#6 0x00000000006b3733 in Connection::NextPacket (this=0xed23b0,  
t=1320329772.929872, is\_orig=1, ip=0x7fffffffe310, len=20, caplen=20,  
data=@0x7fffffffe088, record\_packet=@0x7fffffffe084,  
record\_content=@0x7fffffffe080, hdr=0xebdc90, pkt=0xec19d0 "RT",  
hdr\_size=14) at /home/easselin/bro/src/Conn.cc:259  
#7 0x0000000000805a09 in NetSessions::DoNextPacket (this=0xebe740,  
t=1320329772.929872, hdr=0xebdc90, ip\_hdr=0x7fffffffe310, pkt=0xec19d0  
"RT", hdr\_size=14, encapsulation=0x0) at  
/home/easselin/bro/src/Sessions.cc:706  
#8 0x0000000000804011 in NetSessions::NextPacket (this=0xebe740,  
t=1320329772.929872, hdr=0xebdc90, pkt=0xec19d0 "RT", hdr\_size=14,  
pkt\_elem=0x0) at /home/easselin/bro/src/Sessions.cc:244  
#9 0x0000000000803d56 in NetSessions::DispatchPacket (this=0xebe740,  
t=1320329772.929872, hdr=0xebdc90, pkt=0xec19d0 "RT", hdr\_size=14,  
src\_ps=0xebdc50, pkt\_elem=0x0) at /home/easselin/bro/src/Sessions.cc:186  
#10 0x000000000079f00c in net\_packet\_dispatch (t=1320329772.929872,  
hdr=0xebdc90, pkt=0xec19d0 "RT", hdr\_size=14, src\_ps=0xebdc50,  
pkt\_elem=0x0) at /home/easselin/bro/src/Net.cc:353  
#11 0x000000000079f25f in net\_packet\_arrival (t=1320329772.929872,  
hdr=0xebdc90, pkt=0xec19d0 "RT", hdr\_size=14, src\_ps=0xebdc50) at  
/home/easselin/bro/src/Net.cc:416  
#12 0x00000000007b6ea1 in PktSrc::Process (this=0xebdc50) at  
/home/easselin/bro/src/PktSrc.cc:312  
#13 0x000000000079f397 in net\_run () at /home/easselin/bro/src/Net.cc:447  
#14 0x000000000067df27 in main (argc=5, argv=0x7fffffffebd8) at  
/home/easselin/bro/src/main.cc:1077

---

<div class="post-metadata">

**Author:** ![Siwek\_Jon](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)\
**Post date:** [April 4, 2013, 3:48pm UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632/3 "2013-04-04T15:48:19Z")

</div>

I don't think there's a way to attach packet-based analyzers to TCP connections like that, so manually adding it in DPM.cc via TCP\_Analyzer::AddChildPacketAnalyzer() for the ports you want may be the right thing.

But if what you really wanted is a stream-based analyzer (it only sees the content after TCP reassembly), you can derive from TCP\_ApplicationAnalyzer instead of Analyzer and override DeliverStream() instead of DeliverPacket(). Then the dpd\_config redef you had should work.

- Jon

---

<div class="post-metadata">

**Author:** ![Eric\_Asselin](https://avatars.discourse-cdn.com/v4/letter/e/9f8e36/32.png) [@Eric\_Asselin](https://community.zeek.org/u/Eric_Asselin)\
**Post date:** [April 5, 2013, 9:05pm UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632/4 "2013-04-05T21:05:07Z")

</div>

I try the same code but with the use of a signature to trigger my  
analyzer which worked, but again at the end I have the same  
"segmentation fault". If I derive the analyzer with  
TCP\_ApplicationAnalyzer instead of just Analyzer and still use  
DeliverPacket(), the "seg fault" disappear.

But in fact, I don't care about TCP connection stream, I just want the  
analyzer to be triggered regardless of the transport layer... and  
process the packet.

---

<div class="post-metadata">

**Author:** ![Eric\_Asselin](https://avatars.discourse-cdn.com/v4/letter/e/9f8e36/32.png) [@Eric\_Asselin](https://community.zeek.org/u/Eric_Asselin)\
**Post date:** [April 10, 2013, 8:05am UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632/5 "2013-04-10T08:05:28Z")

</div>

I think I've found why it doesn't work. When the inital tree of the DPD  
is build, the transport layer is hardcoded within a switch so further  
analyzer started by it's corresponding PIA (for UDP and TCP only) should  
derive from the corresponding class to work properly. So an analyzer  
itself can't act regardless of the transport layer.

In this case, for an analyzer to support both transport layer protocols,  
it should derive TCP\_ApplicationAnalyzer class and "extract or compute"  
packet like the DNS Analyzer does.

---

<div class="post-metadata">

**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:40pm UTC](https://community.zeek.org/t/segmentation-fault-by-adding-an-analyzer-to-port-80/2632/6 "2022-05-06T15:40:54Z")

</div>


