Radiator Server Documentation — v10.34.2

captures

Captures are used for detailed logging of protocol messages. The capture allows dumping received and sent messages to an output specified by the capture configuration.

A Linux packet source can additionally capture operating-system traffic selected by BPF filters.

There are three capture output locations:

  • log - Structured log output with configurable format
  • memory - In-memory buffer accessible through API and Radiator UI.
  • file - PcapNG files for analysis with Wireshark

Examples

Example configuration of a captures clause with various capture types:

captures {
    capture "CAPTURE_TO_LOG" {
        log;
    }

    capture "CAPTURE_TO_MEMORY" {
        memory;
    }

    capture "CAPTURE_TO_LOG_AND_DIRECTORY" {
        log;
        file {
            directory "/var/lib/radiator/captures";
        }
    }

    capture "CAPTURE_TO_LOG_AND_FILE" {
        log {
            loglevel debug;
            format hex;
        }
        file {
            directory "/var/lib/radiator/captures";
            filename "radiator-server.pcap";
        }
    }

    capture "CAPTURE_TO_DIRECTORY" {
        file {
            directory "/var/lib/radiator/captures";
        }
    }

    capture "CAPTURE_TO_FILE" {
        file {
            directory "/var/lib/radiator/captures";
            filename "radiator-server.pcap";
        }
    }
}

A capture can be enabled, for example, within:

servers {
    radius "RADIUS" {
        listen {
            protocol udp;
            ip 0.0.0.0;
            port 1812;
        }
        capture "CAPTURE_TO_FILE";
    }
}

Capture scope

When a capture is configured on a server, it captures all messages associated with requests handled by that server, including:

  1. Incoming requests - Messages received from clients
  2. Outgoing replies - Messages sent back to clients
  3. Outgoing proxy requests - Messages sent to backend servers (when proxying)
  4. Incoming proxy replies - Messages received from backend servers

For example, for a proxied RADIUS authentication request, a single capture configuration will produce 4 packet captures:

FrameDirectionDescription
0IncomingAccess-Request from client to server
1OutgoingAccess-Request from server to backend
2IncomingAccess-Accept/Reject from backend
3OutgoingAccess-Accept/Reject from server to client

The capture context is propagated through the AAA pipeline, so backend proxy operations automatically inherit the capture configuration from the originating server.

Temporary captures

Captures can also be started at runtime through /api/v1/temporary-captures in the HTTP Management API without changing the configuration. A temporary capture taps the AAA packets of requests that match the lists in its aaa settings, for example {"aaa": {"servers": ["RADIUS_UDP_1812", "RADIUS_UDP_1813"], "clients": ["NAS-1"]}}. A request must match one value of every non-empty list of servers, clients and protocols; an empty or omitted list matches any request. Temporary captures keep packets in memory only, at most 16 MiB per capture and 64 MiB together, and discard their oldest packets at these limits.