jnettop logo jnettop wiki

jnettop Home
jnettop-gui Home
ChangeLog file
Bug report/Feature request


jnettop crashes on FreeBSD

Some versions of FreeBSD contained multithreaded versions of DNS resolving functions, but these were blatantly implemented as not being thread-safe. If you wish to use single-threaded resolving (and thus make jnettop functional on these versions of FreeBSD), pass --disable-multithreaded-resolver option when you configure jnettop.

why can't I switch interfaces like I see on the screenshots?

There are various libpcap versions out there with different capabilities. Notably there are 0.6.2 and older, which don't support interface discovery. With these versions of libpcap, you won't be able to switch between interfaces while running jnettop. Anyway, you can use "-i" parameter to specify which interface to listen on (since jnettop 0.2). With libpcap version 0.7 and younger, you will be able to switch between various interfaces while running jnettop.

If you want to get newer version of libpcap, go to http://www.tcpdump.org to get sources or you can find newer versions in RPMs on http://rpmfind.net/

will there be port for glib < 2 versions?

No. This package is heavily dependant on thread functions contained in glib2. I believe, that there are (will be) various platforms for which glib2 is ported and thus prefer to depend on generic threading capabilities of glib2 to meet less portability problems later. Glib2 is now available in RPMs for RedHat (and simmilar), DEBs for Debian and .tar.gz for the others.

why do I see lots of UNKNOWN traffic and UNK. protocol?

Jnettop was done as basic analysis tool and does not interpret most of the protocols on Internet. Namely it can only interpret TCP/UDP/IP (v4 as well as v6 since 0.10) on EtherNet or Linux "any" device. This is sufficient for vast majority of linux users (=me .-)). In case you want me to add support for another encapsulation (802.11, etc...), please send me output of jnettop -d and a piece of tcpdump dumpfile with examples of packets. I'll do my best :) In case you want me to add support for another higher-level protocol (IPX, AppleTalk,...), please, send me a vote for that protocol.

why does jnettop consume all CPU time?

Libpcap's features don't include reading a packet with timeout. On some systems this can be overcomed by using select() call. On others, we loop between non-blocking read and thread_yeald() function (notably BSD). On these systems (BSD) jnettop consumes all available CPU time, but should behave nicely, so that it consumes all time up to 100%. Other processes should have theire appropriate time. This behaviour should not include Linux.

Copyright (c) Jakub Skopal 2002-2006 <j@kubs.cz>