2dust/v2rayN · error · ArgumentException

Invalid SOCKS5 UDP packet: IPv4 address incomplete

Error message

Invalid SOCKS5 UDP packet: IPv4 address incomplete

What it means

Thrown when ATYP indicates IPv4 (0x01) but fewer than 4 bytes remain in the packet for the address. The parser needs exactly 4 octets for an IPv4 address and refuses to read past the buffer.

Source

Thrown at v2rayN/ServiceLib.UdpTest/Socks5UdpChannel.cs:131

        var frag = packet[offset++];
        if (frag != 0x00)
        {
            throw new NotSupportedException("SOCKS5 UDP fragmentation is not supported");
        }

        // ATYP (1 byte) - Address type
        var addressType = packet[offset++];

        string host;
        int addressLength;
        bool isDomain;

        switch (addressType)
        {
            case Socks5AddressData.AddrTypeIPv4:
                if (packet.Length < offset + 4)
                {
                    throw new ArgumentException("Invalid SOCKS5 UDP packet: IPv4 address incomplete");
                }

                var ipv4Bytes = new byte[4];
                Array.Copy(packet, offset, ipv4Bytes, 0, 4);
                host = new IPAddress(ipv4Bytes).ToString();
                addressLength = 4;
                isDomain = false;
                break;

            case Socks5AddressData.AddrTypeIPv6:
                if (packet.Length < offset + 16)
                {
                    throw new ArgumentException("Invalid SOCKS5 UDP packet: IPv6 address incomplete");
                }

                var ipv6Bytes = new byte[16];
                Array.Copy(packet, offset, ipv6Bytes, 0, 16);
                host = new IPAddress(ipv6Bytes).ToString();

View on GitHub (pinned to e01717d832)

Solutions

  1. Treat as a failed attempt: catch ArgumentException in the per-attempt loop and continue rather than aborting the whole test.
  2. Verify the SOCKS5 server builds UDP headers per RFC 1928 (ATYP 0x01 followed by exactly 4 IPv4 octets).
  3. Log offset and total length at failure to confirm the truncation point.
  4. Test against a known-good SOCKS5 server to isolate whether the proxy or the target is the source of malformed packets.

Example fix

// before - parsing throws ArgumentException mid-test, aborting
var (remote, receiveResult) = ParseSocks5UdpPacket(packet);

// after - guard the parse per attempt
try
{
    var (remote, receiveResult) = ParseSocks5UdpPacket(packet);
    udpReceiveResult = receiveResult;
}
catch (ArgumentException)
{
    // malformed packet from proxy; counts as a failed attempt
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check IPv4 address availability
static bool HasFullIPv4(byte[] p, int offset) => p != null && p.Length >= offset + 4;
// combined with ATYP==0x01 at offset 3

Type guard

static bool IsCompleteIPv4Packet(byte[] packet, int offset) => packet != null && offset + 4 + 2 <= packet.Length;

Try / catch

try
{
    var (remote, data) = ParseSocks5UdpPacket(packet);
}
catch (ArgumentException ex) when (ex.Message.Contains("IPv4 address incomplete"))
{
    // truncated relay packet; retry or mark attempt failed
}

Prevention

When it happens

Trigger: ParseSocks5UdpPacket reads ATYP == AddrTypeIPv4 then finds packet.Length < offset + 4; i.e. the header claimed IPv4 but the datagram was truncated inside the address field.

Common situations: Corrupted/truncated relay packet; proxy that mis-encodes the address length; packet loss on an unreliable relay leaving a short datagram.

Related errors


AI-assisted analysis of 2dust/v2rayN@e01717d832 (2026-08-13). Data as JSON: /api/errors/41e8bcab489ee25c. Report an issue: GitHub.