Hi Karl, I'm sure you will understand my position (and if not, we can drag the discussion on privately): a part from OpenBSD policies, i have to know where the problem lies; then a solution can be discussed.
While the patch is in principle correct - i believe it's consistent to let users opt for DLT_LINUX_SLL support in or out at compile time rather than deciding statically (or semi-statically). This way it would still be possible to let people safely use pmacct as an off-line tool to read captures taken somewhere else, including DLT_LINUX_SLL encapsulation. Will roll out a patch via CVS later during the week - if interested you can check out archives for the pmacct-cvs list to see when it's done. Cheers, Paolo On Fri, Feb 06, 2009 at 11:40:41PM -0600, Karl O. Pinc wrote: > > 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 <k...@meme.com> > 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)) { > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
