Hey, thanks for the PR!

In my case this hangs the program when pressing q if we are listening on all interfaces and there is no traffic in some of them.

  Id   Target Id                                           Frame
* 1    Thread 0x7fdab9a11a80 (LWP 26878) "bandwhich"       0x00007fdab9d3f4a8 in __GI___pthread_timedjoin_ex (threadid=140577385203456, thread_return=0x0,
    abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:84
  2    Thread 0x7fdab91bc700 (LWP 26883) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=4, readfds=0x559ce11b8478, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  3    Thread 0x7fdab8fbb700 (LWP 26884) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=5, readfds=0x559ce11bbf38, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  4    Thread 0x7fdab8dba700 (LWP 26885) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=6, readfds=0x559ce11b8e58, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  5    Thread 0x7fdab89b8700 (LWP 26887) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=8, readfds=0x559ce11b9048, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  6    Thread 0x7fdab87b7700 (LWP 26888) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=9, readfds=0x559ce11b91c8, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  7    Thread 0x7fdab85b6700 (LWP 26889) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=10, readfds=0x559ce11b92b8, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  8    Thread 0x7fdab83b5700 (LWP 26890) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=11, readfds=0x559ce11b93a8, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  9    Thread 0x7fda93fff700 (LWP 26891) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=12, readfds=0x559ce11b9498, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
  10   Thread 0x7fda93dfe700 (LWP 26892) "sniffing_handle" 0x00007fdab9c4d2c6 in __pselect (nfds=13, readfds=0x559ce11b9698, writefds=0x0, exceptfds=0x0,
    timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69

TBH for the moment I'm not understanding the main problem, how the timeout can change the behavior of showing or not showing traffic. I would say something in the specific MacOS code must be influencing the behavior, but I'm not sure what.

TBH for the moment I'm not understanding the main problem, how the timeout can change the behavior of showing or not showing traffic. I would say something in the specific MacOS code must be influencing the behavior, but I'm not sure what.

Which OS did you run this on? Trying to reproduce the hanging problem

I'm on Linux

Linux caprica 5.3.0-3-amd64 #1 SMP Debian 5.3.15-1 (2019-12-07) x86_64 GNU/Linux

According to the man page of pselect for MacOS X, it seems that the behavior should be the same regarding the timeout:

The timeout argument in pselect() points to
a const struct timespec, rather than the (modifiable) struct timeval used
by select(); as in select(), a null pointer may be passed to indicate
that pselect() should wait indefinitely.

And how libpnet uses it for the relevant part of the code:
https://github.com/libpnet/libpnet/blob/dc2203a32a00981995b548eed4b4a90010e9491e/pnet_datalink/src/bpf.rs#L351-L360

Hmm... according to the pnet docs (if I understand correctly), read_timeout is only relevant to linux: https://docs.rs/pnet/0.22.0/pnet/datalink/struct.Config.html#structfield.read_timeout

If the quitting issue only happens on linux, and the no-traffic issue only happens on (some) macs, how about if as a quick and ugly fix we add a #[cfg(not(target_os = "linux"))] (with a relevant comment explaining this)?

Correct me if I'm wrong, but I think OS X uses the BPF implementation by default

https://github.com/libpnet/libpnet/blob/dc2203a32a00981995b548eed4b4a90010e9491e/pnet_datalink/src/lib.rs#L54

@ebroto - I think you're right. I misunderstood the docs and didn't go too deeply into the code.

This problem is affecting a lot of mac users and I'd really like at least an ugly fix for now that doesn't cause too much trouble.

@zhangxp1998 - as a mac user, how does the tool behave for you if we remove this config? Can you quit easily with both ctrl-c and q? (if you can check under heavy traffic, eg. when downloading a linux distro that would be awesome). How about CPU utilization? iirc @ebroto used this to fix a situation where we were taking ~10-20% CPU.

EDIT: @zhangxp1998 - if you'd also be willing to check the above with the value brought down to 1s so we know more, that would be much appreciated.

Yes, I think that using 1 sec would be a better hotfix if it works as we will not block any thread (though responsiveness on q would be affected).

It would be important also to test without -i

With NO read timeout:

4MB/s download speed, taking ~14% CPU.

With 1s read timeout:

Download speed 8MB/s, taking ~14% CPU.

The download speed fluctuates a lot, I don't think the difference in download speed is caused by bandwhich. Bandwhich is taking a lot of CPU, but it does not appear that read timeout of 1s fixes that issue. In addition, with read timeout of 1s, bandwhich stops showing any traffic after ~1min.

EDIT:
I run bandwhich by typing: sudo bandwhich -I en0. Note that Mac users cannot listen on all interfaces, doing so will yield

Error: Failed to listen on network interface en5: flags=8863<UP,BROADCAST,MULTICAST>
      index: 4
      ether: ac:de:48:00:11:22
      inet6: fe80::aede:48ff:fe00:1122/64: Device not configured (os error 6)

@zhangxp1998 - thanks for the detailed report! Looks like for now we're headed for not having a read_timeout on a mac and having a 2s one on linux.

Just to make sure: with no read_timeout you get no issues closing the app with "ctrl+c" or "q", and data keeps showing up even after ~1min?

The all-interfaces issue has a fix here: #49
The bandwidth fluctuations will (I hope) be fixed by this: #14 (which is the only feature missing for version 1.0.0 - just sayin' :) ). If not, we'll get to the bottom of them.

Just to make sure: with no read_timeout you get no issues closing the app with "ctrl+c" or "q", and data keeps showing up even after ~1min?

With no read_timeout, I have can quit bandwhich through CTRL+C or q without any problem. I just kept bandwhich running for several minutes and it is still displaying traffic.

This LGTM - I'm going to merge this and release it along with #49 in the next few days. Thank you very much for all your work on this @zhangxp1998! And thanks @ebroto for your input. :)

@zhangxp1998 - could you revert the "Display 30 chars for process name" commit in this PR? I see you opened a different PR for it - let's discuss it there.

Thank you for all your work and troubleshooting help on this, @zhangxp1998 !