iftop-users

iftop-users@lists.beasts.org

195 discussions

iftop segfaults on amd64 (proposed patch)
by William Robinet 02 Dec '05

02 Dec '05

Hi, Iftop segfaults on my amd64 machine (Gentoo Linux 2.6.14) when I'm using a .iftoprc file containing the line: dns-resolution: no Here is a patch that fixes it (it seems that it does not break the i386 version): --- iftop-0.16/cfgfile.c 2003-11-06 19:22:16.000000000 +0100 +++ iftop-0.16_patched/cfgfile.c 2005-12-02 11:17:11.677579447 +0100 @@ -46,8 +46,13 @@ int is_cfgdirective_valid(const char *s) { char* t; - for (t = config_directives[0]; t != NULL; ++t) + int i = 1; + t = config_directives[0]; + while(t != NULL) { if (strcmp(s, t) == 0) return 1; + t = config_directives[i++]; + } + return 0; } William -- GPG Key ID: 74C7A949

2 2

iftop: scaling, 1024 base, patch
by Aidas Kasparas 15 Nov '05

15 Nov '05

Hello, iftop is fantastic tool! Thanks for it. On the other hand, I found little strange when it's scale ends at 977kb with traffic in the ranges 256+ .. ~1000 kb and then jumps right to 9.54Mb. If someone has 1-1.5Mbit (and I'm one of such), then suddenly all the graphs become very small. I tried to add more steps and at the same time move to base 1024. Attached patch solves these problems. Unfortunately, I had no setup to test correctness of this patch for speeds above 2Mbps. -- Aidas Kasparas IT administrator GM Consult Group, UAB --- iftop-0.16.orig/ui.c +++ iftop-0.16/ui.c @@ -169,7 +169,7 @@ } while(1) { - if(n < size * 1000 || i >= UNIT_DIVISIONS - 1) { + if(n < size * 1024 || i >= UNIT_DIVISIONS - 1) { snprintf(buf, bsize, " %4.0f%s", n / size, bytes ? unit_bytes[i] : unit_bits[i]); break; } @@ -191,19 +191,26 @@ static struct { int max, interval; } scale[] = { - { 64000, 10 }, /* 64 kbit/s */ - { 128000, 10 }, - { 256000, 10 }, - { 1000000, 10 }, /* 1 Mbit/s */ - { 10000000, 10 }, - { 100000000, 100 }, - { 1000000000, 100 } /* 1 Gbit/s */ + { 64 * 1024, 10 }, /* 64 kbit/s */ + { 128 * 1024, 10 }, + { 256 * 1024, 10 }, + { 512 * 1024, 10 }, + { 1024 * 1024, 10 }, /* 1 Mbit/s */ + { 2 * 1024 * 1024, 10 }, + { 5 * 1024 * 1024, 10 }, + { 10 * 1024 * 1024, 10 }, + { 20 * 1024 * 1024, 10 }, + { 50 * 1024 * 1024, 10 }, + { 100 * 1024 * 1024, 100 }, + { 200 * 1024 * 1024, 100 }, + { 500 * 1024 * 1024, 100 }, + { 1024 * 1024 * 1024, 100 } /* 1 Gbit/s */ }; static int rateidx = 0, wantbiggerrate; static int get_bar_interval(float bandwidth) { int i = 10; - if(bandwidth > 100000000) { + if(bandwidth > 100 * 1024 * 1024) { i = 100; } return i;

4 4

Cumulative column
by Beto Reyes 02 Aug '05

02 Aug '05

The cumulative column is no presenting the correct information when resize the window (Ctrl-L) grows in Mbytes instead of Kbytes..., I hide it and redisplay it again the cumulative is reset... and works again.. It happens in 0.16 version -- Linux es el proceso de colaboración humana e internacional más sensacional de la época postmoderna, que es una extraordinaria expresión de la LIBERTAD en la DIVERSIDAD (Ian Murdock)

1 0

Cumulative display
by Beto Reyes 01 Aug '05

01 Aug '05

The cumulative column is no presenting the correct information... If I hide it and redisplay it again the cumulative is reset... but it grows in Mbytes instead of Kbytes... not always happens, so I've to quit and start it again... it happens in 0.16 version. -- Linux es el proceso de colaboración humana e internacional más sensacional de la época postmoderna, que es una extraordinaria expresión de la LIBERTAD en la DIVERSIDAD (Ian Murdock)

1 0

can't monitor traffic on a gigabit subnet
by Igor Schein 13 Jul '05

13 Jul '05

Hi, When bandwidth usage for any connection is very high ( in my tests - 20MB/s or 160Mb/s ), iftop-0.16 stops reporting usage for that connection and becomes unresponsive - ^C doesn't work. More specifically - the connection in question represents NFS UDP traffic. Anyone else has this issue? Thanks Igor

2 2

Supporting cross-compilation
by Tim Freeman 14 Jun '05

14 Jun '05

I was using my PC running Linux to compile iftop for my Linksys WRT54GS router running Openwrt (which is an instance of Linux), and I discovered that the "configure" script for iftop doesn't support cross-compilation. It insists on running experiments on the local host. I rearranged configure.in so the generated "configure" script supports cross-compilation. Some of the macros used in the old configure.in were deprecated according to current autoconf documentation, so I substituted current ones. Here's a patch to configure.in. The patch also adds a NO_SYSTEM compiler flag that, when set, disables the "!" key that starts a subshell. This makes me more willing to run iftop as the login shell of a passwordless account so the other users of my router can triage some network performance problems without bugging me. If you apply this patch to the distributed iftop tarball, you'll also need to rerun autoheader, aclocal, automake, and autoconf before you get a good "configure" script. It's also possible to patch the "configure" script directly, but that diff is large and meaningless because it's updating a generated file. I can generate a patch for that if there's interest. I would like to contribute this to the iftop source. Let me know what you decide to do with this. I'll be happy to assign copyright if that's an issue. -- Tim Freeman http://www.fungible.com tim(a)fungible.com Programmer/consultant in the Sunnyvale, CA area. diff -ru orig/iftop-0.16/configure.in ./configure.in --- orig/iftop-0.16/configure.in 2004-02-28 10:53:37.000000000 -0800 +++ ./configure.in 2005-06-11 11:02:04.000000000 -0700 @@ -9,7 +9,15 @@ dnl dnl $Id: configure.in,v 1.23 2004/02/28 18:53:37 pdw Exp $ dnl - +dnl To regenerate everything from source, do: +dnl autoheader +dnl aclocal +dnl automake +dnl autoconf +dnl Now you should have good sources to make into a tarball and distribute. +dnl ./configure (perhaps with some arguments) +dnl make +dnl Tested with Automake 1.4 and autoconf 2.59. dnl dnl Boilerplate configuration dnl @@ -34,15 +42,23 @@ dnl AC_ARG_WITH(resolver, - [ --with-resolver=TYPE Technique iftop should use for name resolution. Valid - options are netdb, netdb_1thread (for systems without - working gethostbyaddr_r), ares for the MIT ARES - asynchronous resolver library, forking for the REALLY - SUCKY forking resolver, or none if you don't need any - name resolution. - [default=netdb]], + [ --with-resolver=TYPE Technique iftop should use for name resolution. + Valid options are: + netdb use gethostbyaddr_r in multiple + threads. + netdb_1thread use gethostbyaddr_r and + assume it is not reentrant. + ares use the MIT ARES asynchronous + resolver library. + forking use the REALLY SUCKY forking resolver. + guess run experiments to guess a + reasonable value. Only works if you + aren't cross-compiling. This + is the default. guess will + either select netdb or netdb_1thread. + none don't do name resolution.], [resolver=$withval], - [resolver=netdb]) + [resolver=guess]) AC_ARG_WITH(libpcap, [ --with-libpcap=WHERE Where the libpcap packet-capture library is found. @@ -151,7 +167,12 @@ dnl First, the default resolver, which uses getnameinfo or gethostbyaddr_r. If dnl not available, we fall back to gethostbyaddr. We could fall back to ARES, dnl but that's probably not available on typical machines. -if test x$resolver = xnetdb ; then + +dnl If we've been asked to guess, remember that fact in specified_resolver. +dnl From this point on, resolver is our preferred resolver given the +dnl experiments we've done so far, or "guess" if we have no idea. +specified_resolver=$resolver +if test x$specified_resolver = xguess ; then dnl Best possibility is getnameinfo. use_getnameinfo=0 AC_SEARCH_LIBS(getnameinfo, [nsl], [use_getnameinfo=1]) @@ -164,75 +185,101 @@ dnl Done. AC_DEFINE(USE_GETNAMEINFO, 1, [use getnameinfo for name resolution]) else - dnl Now see if we can use gethostbyaddr_r. - AC_SEARCH_LIBS(gethostbyaddr_r, [nsl], , [resolver=forking]) + dnl Best hope is netdb, which presently means gethostbyaddr_r. + resolver=netdb + fi +fi + +if test x$resolver = xnetdb ; then + dnl Can use gethostbyaddr_r? + AC_SEARCH_LIBS(gethostbyaddr_r, [nsl], , [resolver=guess]) + if test x$resolver = xguess && test x$specified_resolver != xguess ; then + dnl They wanted gethostbyaddr_r, but they can't have it, so stop. + AC_MSG_ERROR([no library defines gethostbyaddr_r]) + fi +fi + +dnl We still might do gethostbyaddr_r. Figure out whether we have +dnl glibc-style or Solaris-style gethostbyaddr_r (or neither...). +dnl Separate determining how to call gethostbyaddr_r from testing +dnl whether it works so we can support cross-compilation. +if test x$resolver = xnetdb ; then + AC_MSG_CHECKING([how to call gethostbyaddr_r]) + dnl Try 7 arguments returning a struct hostent*. + AC_LINK_IFELSE(AC_LANG_SOURCE([`cat config/hostentp_ghba_r.c`]), + [AC_MSG_RESULT([7 args]) + ghba_args=8 + AC_DEFINE(GETHOSTBYADDR_R_RETURNS_HOSTENT_P, 1, + [7-argument gethostbyaddr_r returns struct hostent*])], [ + dnl Try 8 arguments returning an int. + AC_LINK_IFELSE(AC_LANG_SOURCE([`cat config/int_ghba_r.c`]), + [AC_MSG_RESULT([8 args, int return]) + ghba_args=8 + AC_DEFINE(GETHOSTBYADDR_R_RETURNS_INT, 1, + [8-argument gethostbyaddr_r returns int])], [ + dnl Neither. + AC_MSG_RESULT([don't know how]) + resolver=guess])]) + if test x$resolver = xguess && test x$specified_resolver != xguess ; then + dnl They wanted gethostbyaddr_r, but they can't have it, so stop. + AC_MSG_ERROR([gethostbyaddr_r has no known calling convention]) + fi +fi - dnl Still want gethostbyaddr_r.... - if test x$resolver = xnetdb ; then - dnl Figure out whether we have glibc-style or Solaris-style - dnl gethostbyaddr_r (or neither...). - AC_MSG_CHECKING([how to call gethostbyaddr_r]); - - AC_TRY_RUN([`cat config/int_ghba_r.c`], [ - dnl 8-arg, int - AC_MSG_RESULT([8 args, int return]) - AC_DEFINE(GETHOSTBYADDR_R_RETURNS_INT, 1, - [8-argument gethostbyaddr_r returns int]) - ], [ - AC_TRY_RUN([`cat config/hostentp_ghba_r.c`], [ - dnl 7-arg, struct hostent* - AC_MSG_RESULT([7 args, struct hostent* return]) - AC_DEFINE(GETHOSTBYADDR_R_RETURNS_HOSTENT_P, 1, - [7-argument gethostbyaddr_r returns struct hostent*]) - ], [ - dnl neither - AC_MSG_RESULT([no idea; dropping back to the forking resolver]) - resolver=forking - ]) - ]) - - dnl Found a gethostbyaddr_r we know how to use and which seems to - dnl work. - if test x$resolver = xnetdb ; then - AC_DEFINE(USE_GETHOSTBYADDR_R, 1, [use gethostbyaddr_r for name resolution]) - fi +dnl If we still want to do gethostbyaddr_r, and we aren't +dnl cross-compiling, test it. +if test x$resolver = xnetdb ; then + if test x$ghba_args = x8 ; then + testfile=int_ghba_r + else + testfile=hostentp_ghba_r + fi + AC_MSG_CHECKING(gethostbyaddr_r usability) + AC_RUN_IFELSE([`cat config/$testfile.c`], + [AC_MSG_RESULT([yes])], + [AC_MSG_RESULT([no]) + resolver=guess], + [AC_MSG_RESULT([can't test because we are cross-compiling])]) + if test x$resolver = xguess ; then + if test x$specified_resolver = xguess ; then + AC_MSG_RESULT([gethostbyaddr_r doesn't work, so we'll try something else]) + else + dnl They wanted gethostbyaddr_r, but it doesn't work, so stop. + AC_MSG_ERROR([gethostbyaddr_r doesn't work]) fi fi fi -dnl If we've been told to use ARES, then see if it's available. If it isn't, -dnl fall back to gethostbyaddr, since we can probably assume that if the -dnl machine had a working gethostbyaddr_r, the user wouldn't be pissing about -dnl with ARES. +dnl We found a gethostbyaddr_r we know how to use and which seems to +dnl work. +if test x$resolver = xnetdb ; then + AC_DEFINE(USE_GETHOSTBYADDR_R, 1, [use gethostbyaddr_r for name resolution]) +fi + +dnl They may have asked for ares. if test x$resolver = xares ; then dnl See if ares is to hand.... AC_SEARCH_LIBS(ares_init, [ares], [ AC_DEFINE(USE_ARES, 1, [use ARES for name resolution]) ], [ - dnl no ares - AC_MSG_RESULT([can't find ARES; dropping back to the forking resolver]) - resolver=forking]) + dnl They asked for ares, but we can't give it to them, so stop. + AC_MSG_ERROR([can't find ARES. Re-run configure and ask for a different resolver.])]) fi +dnl Last thing to try if we haven't decided yet is netdb_1thread. +if test x$resolver = xguess ; then + resolver=netdb_1thread +fi dnl Ugh. Both the single-threaded and the forking resolvers use gethostbyaddr. if test x$resolver = xnetdb_1thread || test x$resolver = xforking ; then AC_SEARCH_LIBS(gethostbyaddr, [nsl], , [ - AC_MSG_ERROR([not even gethostbyaddr is available - What sort of UNIX system is this, anyway? - - You will have to recompile with no name resolution at all. -]) - - ] - ) + AC_MSG_ERROR([gethostbyaddr is not available. You will have to + recompile with no name resolution at all.])]) if test x$resolver = xnetdb_1thread ; then - dnl Oh dear, just use gethostbyaddr; but whine about it - AC_MSG_WARN([using single-threaded resolver with gethostbyaddr Consider obtaining ARES or a machine with a working gethostbyaddr_r.]) - AC_DEFINE(USE_GETHOSTBYADDR, 1, [use gethostbyaddr for name resolution]) else AC_DEFINE(USE_FORKING_RESOLVER, 1, [use a REALLY SUCKY forking resolver for name resolution]) @@ -332,7 +379,7 @@ dnl libraries, etc. We use a test program to figure this stuff out. dnl -AC_MSG_CHECKING([how to compile a working program with POSIX threads]) +AC_MSG_CHECKING([POSIX threads compilation]) thrfail=1 oldCFLAGS=$CFLAGS oldLIBS=$LIBS @@ -340,7 +387,7 @@ CFLAGS="$oldCFLAGS $flag" for lib in "" -lpthread "-lpthread -lposix4" ; do LIBS="$oldLIBS $lib" - AC_TRY_RUN([`cat config/pthread.c`], [ + AC_LINK_IFELSE(AC_LANG_SOURCE([`cat config/pthread.c`]), [ foundthrlib=$lib foundthrflag=$flag thrfail=0 @@ -356,10 +403,16 @@ AC_MSG_RESULT([no idea]) AC_MSG_ERROR([can't figure out how to compile with POSIX threads If your system actually supports POSIX threads, this means we've messed up.]) -else - AC_MSG_RESULT([$foundthrflag $foundthrlib]) fi +AC_MSG_RESULT([CFLAGS=$foundthrflag and LIBS=$foundthrlib]) +AC_MSG_CHECKING([POSIX threads usability]) +AC_RUN_IFELSE([`cat config/pthread.c`], + [AC_MSG_RESULT([yes])], + [AC_MSG_ERROR( + [it fails. We probably guessed the wrong CFLAGS.])], + [AC_MSG_RESULT([can't test because we are cross-compiling])]) + dnl dnl Are we on a system (like Solaris) that requires promiscuous mode in order to dnl see any outgoing packets? @@ -374,7 +427,8 @@ esac AC_ARG_ENABLE(default-promiscuous, - [--enable-default-promiscuous If enabled, iftop will operate in promiscuous mode to capture outgoing packets]) + [ --enable-default-promiscuous If enabled, iftop will operate in promiscuous mode + to capture outgoing packets]) AC_MSG_RESULT([$enable_default_promiscuous]) diff -ru orig/iftop-0.16/ui.c ./ui.c --- orig/iftop-0.16/ui.c 2004-02-05 14:53:19.000000000 -0800 +++ ./ui.c 2005-06-04 11:03:06.000000000 -0700 @@ -1045,6 +1045,7 @@ break; } case '!': { +#ifndef NO_SYSTEM char *s; dontshowdisplay = 1; if ((s = edline(0, "Command", "")) && s[strspn(s, " \t")]) { @@ -1073,6 +1074,9 @@ xfree(s); } dontshowdisplay = 0; +#else + showhelp("Sorry, subshells have been disabled."); +#endif break; } case 'T':

2 2

Re: [Iftop-users] working in 10baseT/UTP
by Paul Warren 03 May '05

03 May '05

On Mon, May 02, 2005 at 01:55:18AM +0300, Martins Dzelde wrote: > The FreeBSD box is configured to work as bridge, That'll be it. When iftop starts up, does it say "Cannot obtain MAC address on this platform"? (you should be able to see this message after you quit). If so, then the problem is that it can't get the hardware address, and because it's a bridge, the interfaces don't have an IP address, so it can't determine which way the packets are actually moving. Either we need to figure out how to get the hardware address on FreeBSD, or add an option to specify the hardware address. Paul

3 4

Re: [Iftop-users] iftop continue running after exit
by Chris Lightfoot 01 May '05

01 May '05

[ Cc: back to list ] On Sat, Mar 19, 2005 at 10:46:12AM +0200, Martins Dzelde wrote: > sorry, but i cannet find where is the resolver code.. nor where is the > actual config file located. where should it be? The particular version of the resolver code which iftop uses is decided by the configure script at compile time. I thought the configure script printed that out, but it looks like it doesn't, necessarily. So, the easiest way to find out is, in the build directory, to type, grep USE config.h you'll get output something like this: /* #undef USE_ARES */ /* #undef USE_FORKING_RESOLVER */ /* #undef USE_GETHOSTBYADDR */ #define USE_GETHOSTBYADDR_R 1 /* #undef USE_GETNAMEINFO */ -- the #define line in this case indicates that that build of iftop uses name-resolution code based on gethostbyaddr_r(3). -- Mr Newton is trying to collapse the star. Mr Pauli is trying to save it. Who wins? Mr Chandrasekhar is the referee. (physics lecture)

3 6

(no subject)
by George Genov 19 Mar '05

19 Mar '05

1 0

iftop continue running after exit
by Martins Dzelde 19 Mar '05

19 Mar '05

hi, few days ago i installed and took a look at iftop. i think its great, shows the info i need to see. i have few questions thought: 1) after exiting if top (with command 'q') i still find it in the process list. and even if i run another iftop afterwards all the proccess fill up the list until i restart or just kill each iftop running. am i doing smth wrong? 2) is it possible to group the traffic list per ip address so that it doesnt show every connection for each ip, just the overall bandwidth usage for each ip? regards, Martins.

2 1

← Newer
1
...
10
11
12
13
14
15
16
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

iftop-users