Thanks Robert, and Balasz, I understand
the functioon of libnet :).
I beleive it to be the source of my
memory problems, and not syslog-ng necessarily.
>The funny part is that this version of libnet
seem to expect port
>numbers in host byte order whereas I pass it to libnet in network byte
>order. I'm almost confident that this used to work when I originally
did
>the libnet support, judging the libnet changelog again, this was a
>change between 1.0 <-> 1.1
> >Is your syslog-ng sending messages to the correct
port? Can you check
>that with tcpdump for example? Or maybe you are using a big-endian
>machine?
Balasz, spoofed UDP packets are
being sent properly, as far as I can tell - the data is getting
to the target properly.
tcpdump shows some minor strangeness
- the source address is that of the spoofed syslog host, which is
to be expected, and the target host is correct, as is the target port (514/UDP).
What is strange is that all the spopofed packets are all useing UDP/514
as the source.
An example of a tcpdump ron on the UDP
spoofer syslogmachine(syslogng1.testdomain.org):
10:10:39.4092332 IP cisco2121.testdomain.org.syslog
> syslogng2.testdomain.org.syslog: UDP, length 150
I don't thing the endianness is coming
into play here. Also, I verified that libnet was not installed prior
to the 1.2.2 installtion, I am certain that syslog-ng was compiled against
1.2.2.
The output of libnet-config --defines:
-D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD
-DHAVE_NET_ETHERNET_H
The output of libnet-config --cflags:
The output of libnet-config --libs:
-lnet
One more thing, the only confiure options
I used when compiling syslog-ng was "--enable-spoof-source"
Oh, and I reran valgrind with Robert's
exact command line - the output is pretty much the same as I had prior:
# valgrind --tool=memcheck --trace-children=yes --leak-check=yes syslog-ng
==9888== Memcheck, a memory error detector for x86-linux.
==9888== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==9888== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==9888== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==9888== For more details, rerun with: -v
==9888==
==9888==
==9888== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==9888== malloc/free: in use at exit: 32811 bytes in 508 blocks.
==9888== malloc/free: 734 allocs, 226 frees, 40605 bytes allocated.
==9888== For counts of detected errors, rerun with: -v
==9888== searching for pointers to 508 not-freed blocks.
==9888== checked 1598824 bytes.
==9888==
==9888== LEAK SUMMARY:
==9888== definitely lost: 0 bytes in 0 blocks.
==9888== possibly lost: 0 bytes in 0 blocks.
==9888== still reachable: 32811 bytes in 508 blocks.
==9888== suppressed: 0 bytes in 0 blocks.
==9888== Reachable blocks (those to which a pointer was found) are not
shown.
==9888== To see them, rerun with: --show-reachable=yes
==9890== Invalid read of size 2
==9890== at 0x805A987: libnet_in_cksum (in /root/syslog-ng-1.6.6/src/syslog-ng)
==9890== Address 0x1BA790BA is 178 bytes inside a block of size 179
alloc'd
==9890== at 0x1B902E28: malloc (vg_replace_malloc.c:131)
==9890== by 0x805912D: libnet_pblock_coalesce (in /root/syslog-ng-1.6.6/src/syslog-ng)
==9890== by 0x804C063: do_handle_log (destinations.c:103)
==9890== by 0x804B5EC: do_distribute_log (center.c:149)
Balazs Scheidler <bazsi@balabit.hu> Sent by: syslog-ng-admin@lists.balabit.hu
03/03/2005 07:27 AM
Please respond to
syslog-ng@lists.balabit.hu
To
syslog-ng@lists.balabit.hu
cc
Subject
Re: [syslog-ng]Syslog-NG
1.6.6 memory leak when sending UDP logs
On Wed, 2005-03-02 at 22:19 +0100, Roberto Nibali
wrote:
> > io.c: Preparing fd 6 for writing
> > ==27361== Invalid read of size 2
>
> There seems to be a off-by-one error in a string. This is the result
if
> you do something like follows:
This message is not triggered for me, but I'm going to try to use your
exact configuration as well.
> > ==27361== at 0x805A987: libnet_in_cksum (in /usr/local/sbin/syslog-ng)
> > ==27361== Address 0x1BA764E2 is 178 bytes inside a block
of size 179
> > alloc'd
>
> There seems to be a wrong free, not really a missing one.
>
> > ==27361== at 0x1B902E28: malloc (vg_replace_malloc.c:131)
> > ==27361== by 0x805912D: libnet_pblock_coalesce (in
> > /usr/local/sbin/syslog-ng)
> > ==27361== by 0x804C063: do_handle_log (destinations.c:103)
> > ==27361== by 0x804B5EC: do_distribute_log (center.c:149)
> > ==27361== by 0x804B02A: do_add_source_name (sources.c:289)
> > ==27361== by 0x804AA8C: do_handle_line (sources.c:75)
> > ==27361== by 0x804ADA5: do_read_line (sources.c:134)
> > ==27361== by 0x8054AF8: read_callback (in /usr/local/sbin/syslog-ng)
> > ==27361== by 0x804A079: main_loop (main.c:253)
> > ==27361== by 0x804A75C: main (main.c:549)
> > io.c: Preparing fd 8 for writing
> > io.c: connecting using fd 11
> > io.c: connecting using fd 11
Again, this one does not show up in my valgrind output. In fact it
reports that no blocks are leaked.
I'm using 1.1.2.1-2 Debian package. The libnet changelog shows some
fixed leaks before 1.1.1, but as I see you also have a newer version.
Isn't it possible that you linked syslog-ng to an older libnet
statically and then upgraded your libnet package?
The funny part is that this version of libnet seem to expect port
numbers in host byte order whereas I pass it to libnet in network byte
order. I'm almost confident that this used to work when I originally did
the libnet support, judging the libnet changelog again, this was a
change between 1.0 <-> 1.1
Is your syslog-ng sending messages to the correct port? Can you check
that with tcpdump for example? Or maybe you are using a big-endian
machine?
This patch fixes the byte order issue, and I'm still hunting the memory
leak with your configuration:
>
> > Which doesent say too much. I'm using libnet 1.1.2.1. The
valgrind
> > message only appears once - and does not appear as the memory
leak
> > contiues.
>
> Was libnet linked statically against syslog-ng?
Yes, libnet is linked in statically by default.
>
> > I'm no valgrind expert, but I'm guessing it leaks one byte for
each UDP
> > packet sent. Not sure why spoofing would cause this inside libnet.
>
> If you need to create a packet, you'd want to use libnet, unless you've
> got enough spare time to code. Otherwise I don't see why libnet could
be
> used within syslog-ng.
syslog-ng uses libnet for creating UDP packets sent via a raw socket.