On 02/06/2009 03:50:06 PM, Paolo Lucente wrote:
Hi Karl,On Fri, Feb 06, 2009 at 02:35:28PM -0600, Karl O. Pinc wrote: >> Unfortunately i don't have access to any OpenBSD at the moment; >> is that something you can give it a try? > > What would I look at? As i was suggesting, please download and compile a recent version of libpcap, say, 0.9.x - then compile pmacct against it (instead of the version of the library shipped with the OS). In order to do that, you can use the --with-pcap-includes and --with-pcap-libs switches of the configure script.
Ok, but I don't believe that using the upstream libpcap is an appropriate solution for OpenBSD users. I won't be using it.. Libpcap is something that OpenBSD users expect to get from their OS. OpenBSD has tweaked it so that it's got millisecond timestamps and has been audited for security. There's no libpcap port or package, the reason being that the libpcap that's part of OpenBSD is not guaranteed to be compatible with the rest of the world's libpcap where the goals of OpenBSD conflict with using the upstream libpcap. I'm not familiar enough with anybody's internals to make definitive statements, and can't speak for OpenBSD in any way, but that's my take. Even if pmacct works today when linked against the upstream libpcap I don't feel comfortable that it will work tomorrow or there won't be subtle problems. Attached is a new patch I like much better than the one I first posted. I don't know if it qualifies as acceptable, but it's no longer stinky. Results of the test you request follow. libpcap seems to be statically linked. ---------------<snip>--------------- tar -xzf libpcap-1.0.0.tar.gz cd libpcap-1.0.0 ./configure make ---------------<snip>--------------- tar -xzf ../pmacct-0.11.5.tar.gz cd pmacct-0.11.5/./configure --with-pcap-includes=../libpcap-1.0.0/ --with-pcap-libs=../libpcap-1.0.0/
make
---------------<snip>---------------
$ ldd src/pmacctd
src/pmacctd:
Start End Type Open Ref GrpRef Name
1c000000 3c044000 exe 1 0 0 src/pmacctd
009d7000 20a0d000 rlib 0 1 0 /usr/lib/libc.so.48.0
0c607000 0c607000 rtld 0 1 0 /usr/libexec/ld.so
$
I-search:
$ ldd src/pmacct
src/pmacct:
Start End Type Open Ref GrpRef Name
1c000000 3c005000 exe 1 0 0 src/pmacct
05868000 2589e000 rlib 0 1 0 /usr/lib/libc.so.48.0
018ae000 018ae000 rtld 0 1 0 /usr/libexec/ld.so
---------------<snip>---------------
Appears to work at first glance. Here's my test:
---------------<snip>---------------
# ./src/pmacctd -i fxp0 -c src_host -P memory src host 192.168.1.4
OK ( default/core ): link type is: 1
OK ( default/memory ): waiting for data on: '/tmp/collect.pipe'
---------------<snip>---------------
$ ./src/pmacct -s
SRC_IP PACKETS BYTES
192.168.1.4 127 16790
For a total of: 1 entries
$ ./src/pmacct -s -e
SRC_IP PACKETS BYTES
192.168.1.4 144 18586
For a total of: 1 entries
$ ./src/pmacct -s -e
SRC_IP PACKETS BYTES
192.168.1.4 7 796
For a total of: 1 entries
---------------<snip>---------------
Here's some references regarding OpenBSD and it's policies:
15.4.2 - The latest version of my Top-Favorite-Software is not
available!
http://www.openbsd.org/faq/faq15.html#Latest"Some individual ports may lag behind the mainstream versions because of this. The ports collection may have a version back of a program from January while a new version of the program has been released by its developers in May three months ago. Often this is a conscious decision; the new version may have problems in it on OpenBSD that the maintainer is trying to solve, or that have simply made the application worse than the old version: OpenBSD may have different goals than the mainstream developers in other projects, which sometimes results in features and design or implementation choices that are undesirable from OpenBSD developers' point of view. The update may also be postponed because the new version is not considered a crucial update."
See also: OpenBSD Porting Policy http://www.openbsd.org/porting.html#Policy and Security Recommendations http://www.openbsd.org/porting.html#Security In particular:"Any software to be installed as a server should be scanned for buffer overflows, especially unsafe use of strcat/strcpy/strcmp/sprintf. In general, sprintf should be replaced with snprintf."
I don't see using an upstream libpcap as meeting this requirement. If upstream did undergo such screening it the new version would be incorporated directly into OpenBSD. FWIW, I've attached a script of a compilation of pmacct 0.11.5 on OpenBSD 4.4 so you can see the complaints the compiler has about security. Regards, Karl <[email protected]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
--- src/pmacctd.c.orig Wed Jul 16 17:38:43 2008
+++ src/pmacctd.c Fri Feb 6 23:22:32 2009
@@ -34,6 +34,13 @@
#include "net_aggr.h"
#include "thread_pool.h"
+/* Platform dependencies */
+#ifdef DLT_LINUX_SLL
+#define PLUGIN_NEEDED device.link_type != DLT_EN10MB && device.link_type != DLT_IEEE802 && device.link_type != DLT_LINUX_SLL
+#else
+#define PLUGIN_NEEDED device.link_type != DLT_EN10MB && device.link_type != DLT_IEEE802
+#endif
+
/* variables to be exported away */
int debug;
struct configuration config; /* global configuration */
@@ -485,7 +492,7 @@
}
else Log(LOG_INFO, "OK ( default/core ): link type is: %d\n", device.link_type);
- if (device.link_type != DLT_EN10MB && device.link_type != DLT_IEEE802 && device.link_type != DLT_LINUX_SLL) {
+ if (PLUGIN_NEEDED) {
list = plugins_list;
while (list) {
if ((list->cfg.what_to_count & COUNT_SRC_MAC) || (list->cfg.what_to_count & COUNT_DST_MAC)) {
pmacctd.script.gz
Description: GNU Zip compressed data
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
