Hey @thepacketgeek, this looks like a good direction.

Currently, there's no timeout so Sniffer.next() is called in rapid succession. I used a timeout of 10 ms here as it's a good middle ground for keeping sniffing real-time and not spinning too much on a quiet interface.

I think this would work well, seeing as it will only sleep if the network interface becomes unavailable. I think this is a relatively rare occurrence all-in-all.

There's no more CPU spike @ 100% after an interface is disconnected. The thread will silently continue to re-establish the channel for that interface. Should this be handled silently and should bandwhich periodically attempt to reconnect (currently at the same 1 second interval of display updates)

I think handling it silently is fine. Maybe in the future we can develop a warning box, interface status line or some such, but right now I feel this is out-of-scope information for the tool.

As for the PR itself:
I glanced over it briefly, and it seems to me we're doing some extra work because we're handling the sleep in main. I feel this change can be much smaller if we handle it in sniffer.rs. Then we can still return an option and sleep within the iterator (with a while loop or some such maybe?). The only thing we'd then have to find a solution for is the case of quitting the app and closing the thread while the interface is still unavailable. Unless I'm missing something of course. :) What do you think?

Thanks for the feedback @imsnif! I changed Sniffer::next() back to returning an Option<Segment> with one tradeoff from the prior commit:

The thread is parked prior to returning None. This works as the thread will call Sniffer::next() immediately after this function returns None.

Err(err) => match err.kind() {
    std::io::ErrorKind::TimedOut => {
        park_timeout(PACKET_WAIT_TIMEOUT);
        return None;
    }
    _ => {
        park_timeout(CHANNEL_RESET_DELAY);
        self.reset_channel().ok();
        return None;
    }
},

@thepacketgeek - I saw your fixes, my apologies for not getting to them yet. I'm going to take a look tomorrow.

Thanks for the review @imsnif!

Awesome, thanks for this @thepacketgeek!