From: Christopher B. <bla...@um...> - 2005-01-01 20:08:56
|
Nick Rogness wrote: > On Thu, 30 Dec 2004, Christopher Black wrote: > >> Well, I've included patches I've generated so far. The snort.h patch is >> required to compile, decode.c is required for it to not drop every >> packet, and inline.c adds a (commented out) ugly fix for the segfault, >> and two debug statements demonstrating the problem. All patches were >> created outside the top-level snort_inline-2.2.0a directory. >> >> A rule triggering a "reject" will segfault the program. I have traced >> it to inline.c, roughly line 398 (400 after my patch). Printing the >> value once returns the same value as printing it anywhere prior in the >> execution chain. Printing it again returns 0 and a segfault. My C >> skills aren't up to par I guess, because I'm stumped here. > > >> >> [root@mobilebeast1 blackchr]# gdb /usr/local/bin/snort_inline >> snort_inline.core >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you >> are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-marcel-freebsd"... >> Core was generated by `snort_inline'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /usr/local/lib/libpcre.so.0...done. >> Loaded symbols for /usr/local/lib/libpcre.so.0 >> Reading symbols from /usr/lib/libpcap.so.3...done. >> Loaded symbols for /usr/lib/libpcap.so.3 >> Reading symbols from /lib/libm.so.3...done. >> Loaded symbols for /lib/libm.so.3 >> Reading symbols from /lib/libc.so.5...done. >> Loaded symbols for /lib/libc.so.5 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x0806224d in HandlePacket () at inline.c:400 >> 400 iph->ip_src.s_addr = tmpP->iph->ip_dst.s_addr; >> (gdb) >> >> Is there any more info I can provide? > > > - What do your ipfw rules look like? > > I'll see if I can track down this issue. I'm amazed it even runs > in FreeBSD 5.X at all. I'll have to get a FreeBSD 5.3 box up and > running. > > Nick Rogness <ni...@ro...> > - > How many people here have telekenetic powers? Raise my hand. > -Emo Philips > IPFW rules just forward everything to the queue: ipfw add divert 6666 all from any to any ipfw add allow all from any to any It has some issues, but it runs. One important issue is that the checksum calculation for the IP header fails on EVERY packet. I have no idea why, so all I did was remove the InlineDrop() call when it failed the check. |