fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-pcap/+/42835?usp=email )

Change subject: doc: clarify 'pcap snaplen' / 'max-snaplen' ......................................................................

doc: clarify 'pcap snaplen' / 'max-snaplen'

Change-Id: Ic2c82173c12814d61f0ee9f7454b9e5dcb0c13f4 Related: SYS#8099 --- M doc/manuals/chapters/client.adoc M doc/manuals/chapters/server.adoc 2 files changed, 15 insertions(+), 0 deletions(-)

git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/35/42835/1

diff --git a/doc/manuals/chapters/client.adoc b/doc/manuals/chapters/client.adoc index 1769b60..d9885d1 100644 --- a/doc/manuals/chapters/client.adoc +++ b/doc/manuals/chapters/client.adoc @@ -49,6 +49,7 @@ pcap device eth2 <3> pcap filter udp port 23000 <4> pcap detect-loop 1 <5> + pcap snaplen 9000 <6> ---- <1> Prepare records in pcapng format. <2> The network device from which to obtain a capture. @@ -57,6 +58,14 @@ <5> Instruct osmo-pcap-client to automatically add a filter that prevents capturing the traffic between osmo-pcap-client and osmo-pcap-server, which would create a loop. +<6> Maximum number of bytes captured per packet (snapshot length). + +Packets longer than the configured `snaplen` are captured truncated, and +osmo-pcap-client logs an error for each such packet. Note that kernel receive +offloading (GRO/LRO/GSO) can hand libpcap coalesced "super-frames" much larger +than the link MTU; either raise `snaplen` accordingly or disable offloading on +the captured interface (e.g. `ethtool -K <iface> gro off lro off gso off tso +off`).

Adding or removing new recording network devices during operation is not really supported, and a restart of osmo-pcap-client is expected for the new diff --git a/doc/manuals/chapters/server.adoc b/doc/manuals/chapters/server.adoc index e0d9ff4..5d6ed32 100644 --- a/doc/manuals/chapters/server.adoc +++ b/doc/manuals/chapters/server.adoc @@ -46,6 +46,12 @@ <3> TCP port number to which to bind/listen <4> maximum pcap snapshot length (per packet, in bytes; default: 9000)

+The `max-snaplen` value acts as an upper bound (ceiling) for all connected +clients: a client is accepted as long as its own configured `snaplen` does not +exceed the server's `max-snaplen`. It is therefore perfectly fine to configure a +larger `max-snaplen` on the server than the `snaplen` used by some clients; each +client's trace is recorded using that client's own snaplen. + The received packets are stored to a pcap file below the `base-path` using a filename encoding both the client name and the date/time at time of file creation.