imsnif/bandwhich

Feature: Promiscuous mode

Open

#141 opened on Jan 21, 2020

View on GitHub
 (0 comments) (4 reactions) (0 assignees)Rust (7,686 stars) (237 forks)batch import
enhancementhelp wanted

Description

On network interfaces, promiscuous mode would indicate a situation where traffic sent to the interface might not necessarily be addressed to it. An example of such a use case would be to connect a sniffer to a switch port that mirrors the traffic of a different switch port.

In such a situation, bandwhich cannot rely on information regarding system processes, because there is no guarantee the traffic originates at or is intended for processes on the system. It also cannot ascertain the "direction" of the traffic (using pcap as we do), because it cannot match any of the source or destination addresses (IPs or MAC addresses) to anything on the system. The only valuable information bandwhich can display in this case is the "connections" table.

If we start bandwhich with --promiscuous, we would only be displaying the connections table. On each connection, instead of showing the network card, we would be showing the source ip.

When started in promiscuous mode, we should:

  • Store both the source and destination IP of each packet
  • Store network utilization by connection rather than by local socket (identifying upload and download by the direction of the packet, indicated by its source and destination).
  • Render only the connections table
  • Stringify connections as "[IP/HOST 1]:[PORT 1] <=> [IP/HOST 2]:[PORT 2] (tcp/udp/icmp)"
  • Allow network interfaces that are down or have no IPs.

This follows a conversation here: https://github.com/imsnif/bandwhich/issues/140

Contributor guide

Tech stack
rust
Domain
clibackend
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
basic Rustnetwork packet concepts
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Start by examining the current packet capture and connection tracking logic, likely in the src/ directory. The issue describes changes needed in how packets are stored (both source and destination IPs) and how the UI renders (only connections table). Look for existing CLI flag handling to add promiscuous. Also check the linked issue #140 for additional context. The key challenge is modifying the connection display to show source/destination IPs instead of local sockets.