Netconsole Crash Capture: Verify the Receiver Path Before Depending on UDP Logs
Qualify netconsole as a complete sender-to-collector path before using its silence as evidence about a crash. Confirm the network device, destination addressing, receiver socket, capture format and loss accounting under an ordinary workload first. Then state which of those components can still operate during the failure being investigated.
This guide uses upstream Linux v6.12. Netconsole sends kernel console messages over UDP; it is not a reliable-delivery protocol or a substitute for a working NIC and driver. No panic, network-disconnect test or collector benchmark was executed here. Configuration strings and experiments are proposed for an authorized, isolated diagnostic network.
Draw the actual transport path
The v6.12 netconsole reference defines source port, source IP, interface, target port, target IP and target Ethernet address. Record every field explicitly. Avoid relying on an assumed interface name or the default broadcast destination when qualifying a repeatable capture.
On one Ethernet segment, the destination MAC belongs to the receiver. With a routed path, the required next-hop MAC can instead belong to the gateway. Validate the selected topology on the test network; copying the receiver’s MAC across a router does not create a valid next-hop path. Link changes and replacement collectors require revalidation.
A fictional format example is +6665@192.0.2.10/eth0,6666@192.0.2.20/02:00:00:00:00:20. The addresses and interface are placeholders, not a deployable configuration. The leading plus requests extended records. Verify actual interface and approved destination details rather than sending diagnostic data to an arbitrary host.
Make the collector observable
Confirm that the receiver listens on the intended UDP port and address, that local firewall rules admit the packets, and that the process writes to a persistent destination with sufficient space. Receiver tools differ in their listening syntax. Test the installed implementation rather than copying a netcat command from another distribution.
Capture the raw datagrams or preserve their boundaries alongside rendered text when possible. Record collector restarts, file rotation and socket-drop evidence. An output file ending at a particular line can mean the sender stopped, the network failed, the receiver dropped data, or storage stopped accepting writes.
Use a unique run identifier and an innocuous ordered marker series from an approved kernel-log test path. Keep the same series in an independent local or serial record when available. Avoid secrets or application payloads in test messages. The point is transport qualification, not generating a huge volume of output.
Interpret extended records correctly
The extended format carries log level, sequence number, timestamp and continuation information. Long records can be split into fragments with an ncfrag offset and total length. The tagged sender implementation supplies those extended-message and fragment paths.
Reassemble by sender/run identity, record sequence and fragment offsets. Flag missing ranges and conflicting duplicate fragments instead of quietly joining every nearby line. A record is complete only when its required byte ranges are present. Preserve malformed or incomplete records for analysis rather than dropping them from loss statistics.
A sequence gap is a prompt to investigate missing eligible records, not automatic proof of network packet loss. Console selection, message production, initialization time and collection coverage also matter. Compare the known marker series and the actual output policy. A sequence identifies kernel log records; it is not a universal count of network packets.
Keep sender timestamps separate from receiver arrival time. Without a justified clock relationship, subtracting them does not measure one-way network latency. Packet reordering can also change arrival order while the embedded record sequence preserves the sender’s record identity.
Validate ordinary operation before fault conditions
- Start the collector, record its settings and verify writable capture storage.
- Enable the reviewed sender target and read back the effective configuration where the chosen setup exposes it.
- Generate a bounded marker series and confirm identity, ordering, complete fragments and expected count.
- Repeat under representative message and application traffic, recording receiver drops and any timing disturbance.
- In an isolated test, interrupt only the diagnostic link or receiver, restore it and verify that the collector makes the missing interval visible.
Netconsole does not replay an unreceived interval simply because the collector returns. A successful reconnect test should show resumed capture and an explicitly incomplete interval. Do not report continuous evidence when the collector silently starts a new file or resets its own counters.
Check the panic-time assumptions separately
List the components whose failure would defeat capture: the configured interface, its netpoll-compatible transmit path, link partner, routing hop, receiver and storage. A driver lockup in the same network path may remove the observation channel at exactly the interesting moment. A different failure can leave that channel usable.
Built-in netconsole still initializes after required networking support and cannot promise coverage of the earliest boot failures. A module adds its own load-time boundary. Correlate registration and first-marker evidence with the failure phase instead of treating “enabled in the image” as complete boot coverage.
The mechanism can operate in demanding interrupt contexts, but that design goal does not guarantee successful transmission after arbitrary corruption. If a controlled panic qualification is justified, it is a separate approved test with recovery access and an independent observer. This article neither supplies a panic trigger nor infers panic reliability from an ordinary UDP success.
Preserve configuration and close with bounded claims
Dynamic targets require CONFIG_NETCONSOLE_DYNAMIC and use configfs. In v6.12, target parameters generally require disabling the target before changing them; newly created targets start disabled. Save the intended configuration and restore the diagnostic session’s changes deliberately.
The useful deliverable is a capability checklist plus a capture-loss manifest: exact sender build, target fields, collector version, eligible marker policy, complete and incomplete records, receiver interruptions and untested failure classes. Keep independent serial or persistent evidence where the product’s consequences justify it.
Accept netconsole for the failure classes whose transport prerequisites were actually demonstrated. An empty collector file remains “no received evidence” until the path’s state is known; it does not establish that the kernel emitted no useful message.
