U-Boot Netconsole Input: A Large Paste Can Be Truncated Before the Command Parser

A missing suffix in a U-Boot netconsole command is not necessarily a
shell-parser problem. The v2025.01 netconsole receive path copies only
the bytes that fit in its input buffer. If an accepted UDP datagram
exceeds the currently available capacity, its remaining bytes are not
retained for later reading.

The important limit is free space at packet arrival, not merely the
configured total buffer size or the length of the command currently
visible on the host. Diagnose packet reception and input-buffer
consumption before changing quoting or command syntax.

Identify the input
path and its capacity

The network-console
guide explains that U-Boot can select network input and output
independently and uses UDP. It also identifies
CFG_NETCONSOLE_BUFFER_SIZE as the buffer-size override.
This bidirectional U-Boot console is different from Linux’s output-only
netconsole logging facility.

In the netconsole
driver, the input array defaults to 512 bytes when no override is
provided. input_size records occupied bytes, while
input_offset identifies the next byte to consume.

Before copying input, nc_input_packet() checks the
destination port, nonempty payload and applicable source-IP condition.
Only packets accepted by those checks reach the capacity logic. A
missing packet rejected there should not be classified as a
buffer-overflow symptom.

Follow the bounded-copy
branch

If the buffer is already full, the function returns without copying
more data. Otherwise it limits the datagram length to the remaining free
space. It then copies that prefix, splitting the copy if it wraps around
the end of the array, and increases input_size by the
copied amount.

There is no retained remainder in this function that the next
getc() can fetch. Wrapping provides circular storage for
bytes that fit; it does not expand capacity or preserve an oversized
packet’s suffix.

For a hypothetical buffer of 512 bytes with 100 bytes already queued,
a 450-byte accepted payload has room for only 412 bytes. The remaining
38 bytes are outside that copy. These values illustrate the arithmetic,
not a captured network experiment or a recommended console workload.

Do
not interpret the receive return as delivery acknowledgment

The driver’s handled-packet return value is not an application
acknowledgment sent to the host. In particular, the full-buffer branch
still reports the packet as handled. A successful local UDP send
therefore cannot establish that every character reached the command
parser.

The consumer path removes one byte per nc_stdio_getc()
call and wraps the read offset as needed. If no bytes are available, it
runs the network loop while waiting. Actual occupancy depends on when
packets arrive relative to this consumption, so dividing a paste into
packets does not by itself prove sufficient pacing.

The output routine’s packet chunking is a separate mechanism. It does
not provide input flow control or confirm that a pasted line was
received intact.

Test
transport capacity without executing an altered command

Use an authorized isolated fixture that records input bytes without
interpreting them as commands. Send harmless synthetic markers while
controlling initial occupancy, payload length and consumer progress.
Compare the received prefix with the source marker and inspect packet
traces separately from parser output.

Do not diagnose this by repeatedly pasting operational commands into
a live bootloader. A truncated line can leave an incomplete command
pending or alter the arguments eventually interpreted when more input
arrives. Establish the fixture’s input state before each case.

No packets or console commands were sent here. The practical result
should distinguish network loss, receive-filter rejection, capacity
truncation and parser behavior. Increasing a buffer changes one limit;
it does not turn UDP netconsole into a reliably acknowledged command
channel.