iftop-users

iftop-users@domain

195 discussions

[Iftop-users] Forwarded bug reports from Debian
by Markus Koschany 19 Nov '13

19 Nov '13

Hi all, I am the current maintainer of iftop for Debian GNU/Linux. In the past months and years users reported various bugs and feature requests for iftop and since I don't see that someone forwarded them upstream, I have made a short compilation of those outstanding issues. Feedback is much appreciated. 1. iftop does not notice changes to ppp interfaces and stops refreshing its output http://bugs.debian.org/543138 Iftop does not recognize changes to interfaces. If the interface goes temporarily down and then up again, iftop is not capable of recognizing the change and cannot display the traffic anymore. A manual restart is required to make it work again. It would be nice if iftop could detect such a change and continue with monitoring. 2. iftop: chooses eth0 as the default interface instead of the default route http://bugs.debian.org/644998 If the -i option is not specified, iftop looks for the first interface which is up and falls back to eth0 if none are found. On systems where two interfaces such as eth0 and wlan0 are up and the default route points to wlan0, iftop still chooses eth0 by default. The code could be changed in two ways: * Only consider interfaces with routes associated with them. * Prefer the interface with a default route to other ones. 3. Add a command-line option to specify the Display Mode http://bugs.debian.org/511174 "Currently, the display mode can be toggled between "One line per host", "Received traffic only", "Sent traffic only" and "Two lines per host": - either by pressing the "t" key, - or by setting the "line-display" parameter in the config file. It would be very useful to have a way to specify this through a command-line option, like it's currently possible with most other frequently-used iftop adjustments." 4. Add a "min-bandwidth" option, so less resolution is wasted on logarithmic scale. http://bugs.debian.org/520386 "A "min-bandwidth" option analogous to the "max-bandwidth" option should be added. Currently the logarithmic display wastes a lot of space in the 0 - few-kilobytes-per-second range, which is often not useful (unless you're trying to examine intrusion attempts or something like that), causing the interesting range up to the maximum bandwidth to be crammed into just the right half of the screen. Being able to specify the minimum bandwidth to display would help a lot." 5. NAT support http://bugs.debian.org/631682 One user asked for NAT support for using iftop on a router to monitor traffic. 6. bar graph average should be an option in iftoprc http://bugs.debian.org/704813 The option "bar graph average (-B)" can be used within iftop but there is no corresponding option in iftoprc. Thanks for reading Regards, Markus

3 7

[Iftop-users] iftop mishandling multicast packages
by Andreas Schwab 25 Nov '12

25 Nov '12

For incoming multicast packages handle_eth_packet cannot determine a direction from the MAC since the dest MAC will be a multicast MAC. Neither can handle_ip_packet defer a direction since the multicast address won't match the interface address. It then use a totally arbitrary direction from comparing the IP address numerically (which depends on the host byte order), but only for IPv4 packages. IPv6 multicast packages are not handled at all, and causes the resolver to be called with af == AF_UNSPEC (which is an error). This patch makes handle_ip_packet treat packages with a multicast dest address as incoming packages, and otherwise drop any other unrecognized packages. Andreas. diff --git a/iftop.c b/iftop.c index 06778d6..2805cd6 100644 --- a/iftop.c +++ b/iftop.c @@ -286,6 +286,14 @@ static void handle_ip_packet(struct ip* iptr, int hw_dir) assign_addr_pair(&ap, iptr, 1); direction = 0; } + else if (IP_V(iptr) == 4 && IN_MULTICAST(iptr->ip_dst.s_addr)) { + assign_addr_pair(&ap, iptr, 1); + direction = 0; + } + else if (IP_V(iptr) == 6 && IN6_IS_ADDR_MULTICAST(&ip6tr->ip6_dst)) { + assign_addr_pair(&ap, iptr, 1); + direction = 0; + } /* * Cannot determine direction from hardware or IP levels. Therefore * assume that it was a packet between two other machines, assign @@ -304,6 +312,8 @@ static void handle_ip_packet(struct ip* iptr, int hw_dir) direction = 0; } /* Drop other uncertain packages. */ + else + return; } if(IP_V(iptr) == 4 && options.netfilter != 0) { -- 1.8.0 -- Andreas Schwab, schwab(a)linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

1 0

[Iftop-users] Outputting iftop to a file
by Shannon Rodrigues 25 Sep '12

25 Sep '12

Hi Team, I would like to view the output of command iftop to a file instead of it being displayed on the CLI. The need for this requirement is to monitor bandwidth usage of users. Please let me know if this is possible. Any help will be appreciated. Thanks and regards, Shannon R

6 8

[Iftop-users] Fwd: iftop compiled against ipv4-only libpcap
by Michael Orlitzky 13 Jun '12

13 Jun '12

I initially sent this to Paul & Chris because I am unable to read (sorry). Forwarded to the list. -- It's possible to compile libpcap without ipv6 via a configure flag. This is the default at least on the hardened flavor of Gentoo, but users are able to disable ipv6, too, and a lot of people do. For the moment, this results in a runtime crash: iftop-1.0pre2 $ ./configure && make iftop-1.0pre2 $ sudo ./iftop Password: interface: eth0 Unable to get IP address for interface: eth0 ioctl(SIOCGIFADDR): Cannot assign requested address MAC address is: e0:cb:4e:c3:cb:6b set_filter_code: ip6 not supported Ideally, iftop could check for ipv6 support in libpcap and fall back to ipv4-only if it doesn't exist. On the other hand, that's a pain in your butt, and introduces another configuration you have to support. It "should be" (ha ha!) easy enough to fail ./configure if libpcap is missing ipv6 support though. Unfortunately, autotools are dark magic to me, so I can't provide any insights there.

1 0

[Iftop-users] iftop-1.0pre2 doesn't resolve own ipv6 correctly
by Vladimir-M. Obelic 23 Apr '12

23 Apr '12

Just compiled the 1.0pre2 version (pre1 has missing counter_hash.h file). Apparently the resolver for ipv6 has a problem with resolving local host (do not confuse with localhost) own ipv6 address. I.e. Here the host where iftop is being run has ip6 addres 2001:470:b4a7::102 (amagi.gbit6.net) Iftop with dns resolution: amagi.intr.gbit6.net <=> cam.intr.gbit6.net yamato.gbit6.net <=> yamato.gbit6.net <http://pool-173-79-27-59.washdc.fios.verizon.net> same situation without dns resolution: 10.1.0.102 <=> 10.1.0.101 2001:470:b4a7::102 <=> 2001:470:b4a7::11 It's as if it wrongly uses the fqdn resolved for the remote host. Resolving of remote hosts that have ipv6 addr works properly. A simple mistake I guess? Regards Vladimir-M. Obelic

2 2

[Iftop-users] drawing bar scale with bandwidth_in_bytes option
by Stephen Hamer 03 Apr '12

03 Apr '12

The bar scale at the top of the window doesn't change units along with the bandwidth_in_bytes option. Given that the host bars change to be in bytes it seems reasonable for the scale to change as well. I've included the diff to make this change below. Cheers, Stephen Hamer *** ui.c.orig 2012-03-31 18:47:53.460042245 -0400 --- ui.c 2012-03-31 18:47:51.146083037 -0400 *************** *** 263,269 **** char s[40], *p; int x; /* This 1024 vs 1000 stuff is just plain evil */ ! readable_size(i, s, sizeof s, options.log_scale ? 1000 : 1024, 0); p = s + strspn(s, " "); x = get_bar_length(i * 8); mvaddch(*y + 1, x, ACS_BTEE); --- 263,269 ---- char s[40], *p; int x; /* This 1024 vs 1000 stuff is just plain evil */ ! readable_size(i, s, sizeof s, options.log_scale ? 1000 : 1024, options.bandwidth_in_bytes); p = s + strspn(s, " "); x = get_bar_length(i * 8); mvaddch(*y + 1, x, ACS_BTEE);

2 1

[Iftop-users] Cross-compilation, libpcap issue ?
by Mihai Tanasescu 02 Feb '12

02 Feb '12

Hi guys, I'm trying to cross-compile iftop while using a custom install location of libpcap. So far, I am unsuccessful with going past a configure script error... First of all I have libpcap installed here: /usr/src/DVG1000_V1.1.01.04_WN_src/apps# ls libpcap-1.2.0/pcap-install/ bin include lib share root@builder:/usr/src/DVG1000_V1.1.01.04_WN_src/apps# ls libpcap-1.2.0/pcap-install/include/ pcap pcap-bpf.h pcap.h pcap-namedb.h root@builder:/usr/src/DVG1000_V1.1.01.04_WN_src/apps# ls libpcap-1.2.0/pcap-install/include/pcap bluetooth.h bpf.h ipnet.h namedb.h pcap.h sll.h usb.h vlan.h root@builder:/usr/src/DVG1000_V1.1.01.04_WN_src/apps# ls libpcap-1.2.0/pcap-install/lib/ libpcap.a libpcap.so libpcap.so.1 libpcap.so.1.2.0 # CC=mips-linux-uclibc-cc ac_cv_linux_vers=2 ac_cv_func_malloc_0_nonnull=yes ./configure --host=mips-linux --with-libpcap=/usr/src/DVG1000_V1.1.01.04_WN_src/apps/libpcap-1.2.0/pcap-install checking gethostbyaddr_r usability... can't test because we are cross-compiling checking where to find pcap.h... /include checking for pcap_open_live in -lpcap... no configure: error: can't find libpcap You're not going to get very far without libpcap. Looking at the ./configure --help => --with-libpcap=WHERE Where the libpcap packet-capture library is found. The pcap library should be installed in WHERE/lib, and the header file in either WHERE/include or WHERE/include/pcap. I've already checked and the library files + header files really are in "WHERE"/lib and /include/pcap.... So what am I doing wrong ? Is there a way to convince the configure script to take a better look in there ? Thanks, Mihai

1 1

[Iftop-users] question aout redirect the iftop output to a log file
by Robert WANG 24 Jan '12

24 Jan '12

Hi, I am a server support engineer. Now I want to monitor the whole day or whole week network traffic throught the network port of my Sun Solaris server. I tried to use the iftop and I found it can show the network traffic in real time , it is cool. But how can I re-direct the iftop output to a log file? So that I can analysis some network performace issue. I have checked man page , did not find any clue. Hope for your reply. Thank you very much!Best regards, Robert WANG

2 1

[Iftop-users] Problem with iftop and libpcap 1.1.1 on Solaris
by Dagobert Michelsen 11 Nov '11

11 Nov '11

Hi, I am currently working on an iftop package for OpenCSW for Solaris 9 Sparc and noted that neither 0.17 not 1.0pre2 work with libpcap 1.1.1 - they just show zeros for the stats and no connections. They do work with older versions of libpcap like 0.9.4. Additionally, I needed a couple of patches to compile it on Solaris 9 with GCC 3.4.6 which you may want to incorporate: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/iftop/trunk/files Edit: My patches are essentially the same as the ones posted here: http://lists.beasts.org/pipermail/iftop-users/2011-October/000354.html Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896

1 0

Re: [Iftop-users] Portability to GNU/kFreeBSD
by Mats Erik Andersson 26 Oct '11

26 Oct '11

måndag den 24 oktober 2011 klockan 00:11 skrev Mats Erik Andersson detta: > > First off, renew the four files > > {,config/}config.{guess,sub} > > The present versions are six years old. They are incapable > of working with GNU/kFreeBSD. > > These are necessary changes (variations present also in [1]): > > * The correct conditionals in "addrs_ioctl.c" is > > defined __GLIBC__ & ! defined __linux__ > > in order to catch GNU/kFreeBSD and to avoid NexentaCore. > This MUST be changed, whether or not you decide to ignore > OpenSolaris. I feel compelled to clarify the changes needed to get a valid and buildable support for GNU/kFreeBSD: * config.guess, config.sub, config/config.guess, config/config.sub are outdated and must be renewed. * The patch below must be used to insert correct conditionals. The originals are misconceived. (I am myself to blame for that, but they were sufficient for the Debian package improvements, my original target!) One could argue that defined __GLIBC__ && defined __FreeBSD_kernel__ is even more precise, as it avoids capturing GNU/Hurd, but the check on __GLIBC__ alone is preferred for user land, so __FreeBSD_kernel__ is best avoided. Make an informed choice from this additional points, Mats Erik Andersson, Debian Maintainer (but not for this software) diff -Naur iftop-1.0pre2.orig/addrs_ioctl.c iftop-1.0pre2/addrs_ioctl.c --- iftop-1.0pre2.orig/addrs_ioctl.c 2011-10-02 23:11:30.000000000 +0200 +++ iftop-1.0pre2/addrs_ioctl.c 2011-10-25 11:59:52.000000000 +0200 @@ -19,7 +19,7 @@ #include <netinet/in.h> #if defined __FreeBSD__ || defined __OpenBSD__ || defined __APPLE__ \ - || ( defined __GNUC__ && ! defined __linux__ ) + || ( defined __GLIBC__ && ! defined __linux__ ) #include <sys/param.h> #include <sys/sysctl.h> #include <net/if_dl.h> @@ -81,7 +81,7 @@ } #else #if defined __FreeBSD__ || defined __OpenBSD__ || defined __APPLE__ \ - || ( defined __GNUC__ && ! defined __linux__ ) + || ( defined __GLIBC__ && ! defined __linux__ ) { int sysctlparam[6] = {CTL_NET, PF_ROUTE, 0, 0, NET_RT_IFLIST, 0}; size_t needed = 0;

2 2

← Newer
1
2
3
4
5
6
7
8
9
...
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