tcptrack(1)
π tcptrack β bestie's guide to watching your TCP connections π
okay so this is the tcptrack manual page from the General Commands Manual section, and honestly? it's giving network-nerd main character energy. let's get into it π«Ά
β¨ NAME β¨
tcptrack β monitor TCP connections on the network π
πΈ SYNOPSIS πΈ
tcptrack [ -dfhvp ] [ -r seconds ] -i interface
[ filter expression ]
like, that's the whole vibe. one interface, some optional little flags, and optionally a filter expression if you're feeling fancy π
π¦ DESCRIPTION π¦
tcptrack shows you the status of the TCP connections it can see on a given network interface. it keeps an eye on their state and shows you stuff like the state, the source/destination addresses, and how much bandwidth each one is using β all in a sorted list that keeps updating, very much like the top(1) command. basically top but for connections, no cap π₯
the filter expression is a standard pcap filter expression β literally identical to the expressions used by tcpdump(8) β and you can use it to filter down the characteristics of the TCP connections that tcptrack will see. wanna know the syntax? go read tcpdump(8), bestie π
π OPTIONS π
-dβ only track connections that were started aftertcptrackwas started. it will not try to detect connections that already existed. fresh starts only, periodt β¨-fβ enable fast average recalculation π₯.tcptrackwill calculate the average speeds of connections by using a running average. this means it'll use more memory and CPU time, but the averages will seem closer to real time, will be updated more than once per second, and may be more accurate under heavy load. the number of times per second that averages get recalculated in fast mode is a compile-time setting that defaults to 10 times per second β-hβ display command line help π-i[interface]β sniff packets from the specified network interface. this is the one you actually need π-T[pcap file]β read packets from the specified file instead of sniffing from the network. super useful for testing π§ͺ-pβ do not put the interface being sniffed into promiscuous mode π-r[seconds]β wait this many seconds before removing a closed connection from the display. defaults to 2 seconds. see also the pause interactive command down below π-vβ displaytcptrackversion π
π INTERACTIVE COMMANDS π
these keys can be pressed while tcptrack is running to change runtime options, iykyk:
pβ pause/unpause display. no new connections will be added to the display, and all currently displayed connections will remain in the display βΈοΈqβ quittcptrackπsβ cycle through the sorting options: unsorted, sorted by rate, sorted by total bytes π
the options for pausing and toggling sorting are useful if you're watching a very busy network and want to look at the display without connections jumping around (due to sorting and new connections being added) and disappearing (due to being closed for a certain time). we love a stable display π
when paused (via the p command) no new connections will be displayed, however tcptrack will still monitor and track all connections it sees as usual. this option affects the display only, not internals. when you unpause, the display will be updated with all the current information that tcptrack has been gathering all along π
π EXAMPLES π
tcptrack requires only one parameter to run: the -i flag followed by an interface name that you want tcptrack to monitor. this is the most basic way to run it:
# tcptrack -i eth0
tcptrack can also take a pcap filter expression as an argument. the format of this filter expression is the same as that of tcpdump(8) and other libpcap-based sniffers. the following example will only show connections from host 10.45.165.2:
# tcptrack -i eth0 src or dst 10.45.165.2
the next example will only show web traffic (ie, traffic on port 80):
# tcptrack -i eth0 port 80
π SEE ALSO π
tcpdump(8), pcap(3), http://www.rhythm.cx/~steve/devel/tcptrack
π BUGS π
when picking up a connection that was already running before tcptrack was started, there is no way tcptrack can know for sure which end of the connection is the client (ie, which peer started the connection) and which is the server (ie, which peer was listening). tcptrack makes a crude guess at which is which by looking at the port numbers; whichever end has the lower port number is considered the server side. this isn't always accurate of course, but future versions may have better heuristics to figure out which end is which π
currently the interface is not very flexible. display timing settings (such as the refresh interval) can only be changed by editing the source code (defs.h in particular). see the TODO file included with the source distribution for further bugs π
and that's the whole page, bestie π«Ά this was the tcptrack(1) page, straight out of the General Commands Manual β go monitor something and slay π
β¨
π¦ where this page comes from
- debian bookworm: tcptrack 1.4.3-1+b1 Β· LGPL-2.1-only
- debian trixie: tcptrack 1.4.3-2 Β· LGPL-2.1-only
- epel 10: tcptrack 1.4.3-15.el10_0 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: tcptrack 1.4.3-17.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: tcptrack 1.4.3-17.fc43 Β· LicenseRef-Callaway-LGPLv2+
- nixos 26.05: tcptrack-unstable 2017-04-29
- ubuntu jammy: tcptrack 1.4.3-1 Β· LGPL-2.1-only
- ubuntu noble: tcptrack 1.4.3-1build2 Β· LGPL-2.1-only
- ubuntu questing: tcptrack 1.4.3-2
- ubuntu resolute: tcptrack 1.4.3-2build1 Β· LGPL-2.1-only
- ubuntu stonking: tcptrack 1.4.3-3 Β· LGPL-2.1-only
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms