@@ -364,3 +364,95 @@ hexadecimal form.
364364As it turns out, several other packets also matched this pattern, but this
365365should give you a good idea of how to use hexadecimal patterns and the hex
366366output mode.
367+
368+ ## Container name resolution (Docker / Podman)
369+
370+ When running ngrep on a host that has Docker or Podman containers, raw IP
371+ addresses on a bridge network are essentially meaningless -- they're ephemeral
372+ and change on every `docker-compose up`. Pass `-r` to resolve container IPs to
373+ their names, making the output immediately readable.
374+
375+ Container resolution is compiled in by default (disable at build time with
376+ `--disable-container-resolution` if needed).
377+
378+ If the Docker (or Podman) socket is accessible, ngrep uses the Events API for
379+ real-time tracking -- new containers show up the instant they start, and dead
380+ ones are purged immediately. If the socket isn't available (e.g. rootless
381+ Podman, permission issues), it falls back to CLI-based polling with a
382+ 30-second cache TTL.
383+
384+ ### Debugging microservice traffic
385+
386+ Suppose you have a typical compose stack -- an API gateway, an auth service,
387+ and a Postgres database. Without container resolution, you'd see something
388+ like:
389+
390+ ```
391+ # ngrep -d docker0 -W byline port 5432
392+ T 172.18.0.4:48120 -> 172.18.0.2:5432 [ AP]
393+ ...
394+ T 172.18.0.2:5432 -> 172.18.0.4:48120 [ AP]
395+ ...
396+ ```
397+
398+ With `-r`, the same capture becomes:
399+
400+ ```
401+ # ngrep -r -d docker0 -W byline port 5432
402+ container: using docker socket for real-time events
403+ T api_gateway(172.18.0.4):48120 -> postgres_db(172.18.0.2):5432 [ AP]
404+ ...
405+ T postgres_db(172.18.0.2):5432 -> api_gateway(172.18.0.4):48120 [ AP]
406+ ...
407+ ```
408+
409+ No more cross-referencing `docker inspect` output.
410+
411+ ### Watching HTTP traffic across a compose stack
412+
413+ * `ngrep -r -d br-a1b2c3 -W byline -q 'GET|POST' port 80`
414+
415+ Monitor all HTTP traffic on a Docker Compose bridge network. Each request
416+ shows which container is talking to which, e.g.:
417+
418+ ```
419+ T frontend(172.20.0.3):39212 -> backend(172.20.0.5):80 [ AP]
420+ GET /api/users HTTP/1.1.
421+ Host: backend:80.
422+ ...
423+ ```
424+
425+ ### Filtering to a specific container's traffic
426+
427+ Container resolution annotates the display, but filtering still uses the
428+ underlying IP. To watch traffic for a specific container, find its IP and
429+ use a BPF host filter:
430+
431+ ```
432+ % docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' auth_service
433+ 172.20.0.4
434+
435+ % ngrep -r -d br-a1b2c3 -q '' host 172.20.0.4
436+ T auth_service(172.20.0.4):8080 -> redis(172.20.0.6):6379 [ AP]
437+ ...
438+ T redis(172.20.0.6):6379 -> auth_service(172.20.0.4):8080 [ AP]
439+ ...
440+ ```
441+
442+ Even though the BPF filter uses the raw IP, the output still shows you
443+ container names on both sides of the conversation.
444+
445+ ### Monitoring DNS resolution between containers
446+
447+ * `ngrep -r -d docker0 -q '' port 53`
448+
449+ This is especially useful for catching misconfigured service discovery --
450+ you'll see which container is looking up which hostname, and what the
451+ embedded DNS server responds with:
452+
453+ ```
454+ U frontend(172.18.0.3):42371 -> 127.0.0.11:53
455+ .............backend.mystack_default.....
456+ U 127.0.0.11:53 -> frontend(172.18.0.3):42371
457+ .............backend.mystack_default..............172.18.0.5...
458+ ```
0 commit comments