What causes "invalid packet. length: ${len} address: ${a} ${h} ${p}" in txthinking/brook?

Ensure client and server use the same (matching) brook version so packet framing (12-byte nonce + 4-byte timestamp + SOCKS5 address + payload + 16-byte tag) aligns.

txthinking/brook · error

invalid packet. length

Error message

invalid packet. length: ${len} address: ${a} ${h} ${p}

What it means

After parsing the SOCKS5 address from the decrypted packet, Handle validates that the declared address actually fits in the packet: if 12+4+1+len(host)+2 >= len(b)-16, the payload is too short/malformed to contain the address plus the 16-byte HMAC tail. The error includes packet length and the parsed address components in hex.

Solutions

Ensure client and server use the same (matching) brook version so packet framing (12-byte nonce + 4-byte timestamp + SOCKS5 address + payload + 16-byte tag) aligns.
Inspect the logged length and hex address values; rebuild the packet so the SOCKS5 address host length matches the actual bytes present.
Use the official brook client instead of a hand-rolled implementation to construct packets.
Check for middleboxes/tunneling layers truncating UDP payloads (MTU issues); reduce payload size.

Defensive patterns

Strategy: validation

Validate before calling

// before sending, verify framing: 12 nonce + 4 ts + socks5 addr + payload, and len(payload) >= 1
if len(packet) < 12+4+1+1+2+16 {
    return errors.New("packet too short to be valid")
}

Try / catch

if strings.HasPrefix(err.Error(), "invalid packet.") {
    log.Printf("malformed packet dropped: %v", err)
    // do not retry; rebuild packet with current library version
}

Prevention

Pin client and server to the same brook version.
Use the official client library to build packets, not hand-rolled serializers.
Keep UDP payloads under path MTU to avoid truncation.
Log the length/address fields from the error to diagnose framing drift.

When it happens

Trigger: Sending a truncated or corrupted UDP packet to the brook packet server; wrong protocol version/serialization so bytes do not line up; a packet where the host length byte claims more bytes than remain before the 16-byte authentication tag.

Common situations: Client and server running mismatched brook versions with different packet framing; bit-flips/corruption on the wire after MAC bypass due to layout change; hand-rolled clients constructing the packet incorrectly.

Understand the failure class

Background: "invalid response format", "malformed payload", "missing data field": when an API returns 200 but the response shape is wrong — this error's family across 23 libraries.

Related errors

AI-assisted analysis of txthinking/brook@5cd13ef3b1 (2026-09-06). Data as JSON: /api/errors/813d03b1725f7b93. Report an issue: GitHub.

Appendix: source

Thrown at packetserverconn.go:78

	}
	x.BP32.Put(ck)
	ca, err := cipher.NewGCM(cb)
	if err != nil {
		return nil, nil, err
	}
	if _, err := ca.Open(b[:12], b[:12], b[12:], nil); err != nil {
		return nil, nil, err
	}
	i := int64(binary.BigEndian.Uint32(b[12 : 12+4]))
	if time.Now().Unix()-i > 60 {
		return nil, nil, errors.New("Expired request")
	}
	a, h, p, err := socks5.ParseBytesAddress(b[12+4:])
	if err != nil {
		return nil, nil, err
	}
	if 12+4+1+len(h)+2 >= len(b)-16 {
		return nil, nil, errors.New(fmt.Sprintf("invalid packet. length: %d address: %#x %#x %#x", len(b), a, h, p))
	}
	dst := socks5.ToAddress(a, h, p)
	f.Lock.Lock()
	c, ok := f.Conns[addr.String()+dst]
	f.Lock.Unlock()
	if ok {
		_ = c.In(b[12+4+1+len(h)+2 : len(b)-16])
		return nil, nil, nil
	}
	f.Lock.Lock()
	c = NewPacketConn(b[12+4+1+len(h)+2:len(b)-16], w, timeout, func() {
		f.Lock.Lock()
		delete(f.Conns, addr.String()+dst)
		f.Lock.Unlock()
	})
	f.Conns[addr.String()+dst] = c
	f.Lock.Unlock()
	return c, b[12+4 : 12+4+1+len(h)+2], nil

View on GitHub (pinned to 5cd13ef3b1)