lwIP ERR_CONN -13: Troubleshooting Remote TCP Connect

Interpret ERR_CONN -13 Correctly

In the supplied lwIP error definitions, ERR_CONN is -13 and means “Not connected.” It does not identify an ACK timeout by itself. The reported PCB state, SYN_SENT, shows that the TCP handshake has not completed when the application attempts to write.

Capture the Actual Connect Result

The current code discards the return value from tcp_connect(). Record that value before diagnosing the later write failure. An immediate result can distinguish ERR_RTE -4, ERR_USE -8, ERR_ISCONN -9, ERR_CONN -13, ERR_ARG -14, or ERR_IF -15 from a connection that enters SYN_SENT.

err_t connect_err;
connect_err = tcp_connect(echo_pcb, &DestIPaddr, 7, echo_accept);
DEBUGOUT("tcp_connect returned %d\r\n", connect_err);

The configured destination is 192.168.1.39 on TCP port 7. The client also calls tcp_bind(echo_pcb, IP_ADDR_ANY, 7), so record the bind result separately and confirm that deliberately using local port 7 is required.

Gate Writes on Handshake Completion

Do not treat a successful call to tcp_connect() as proof that the remote connection is already established. Queue application data only after the supplied connection callback reports successful completion. If the PCB is still in SYN_SENT, defer tcp_write(); otherwise, ERR_CONN -13 is the expected diagnostic for the observed state.

The write loop also evaluates tcp_sndbuf(echo_pcb) before checking whether echo_pcb is non-null. Reverse that order. The test echo_pcb->unacked != NULL indicates that unacknowledged data exists; it does not prove that data was acknowledged, so the message labeled “Acknowledged” is misleading.

Verify the Failure at Each Boundary

1. Log the results of tcp_new(), tcp_bind(), and tcp_connect() separately.
2. Record when the connection callback runs and whether the PCB leaves SYN_SENT before calling Enet_Write().
3. Capture traffic at the device side and remote-server side to determine whether the SYN leaves the device and whether the response returns. The available evidence does not establish whether the loss occurs in lwIP, the network path, or the remote endpoint.
4. Repeat the same logging for a successful local connection and the intermittent remote connection, then compare the first point where their behavior differs.

FAQ