Проблемы с ftp. Пропадает пакет с командой PORT.

так глубоко в пакеты не лезут

Тут ты ошибаешься. Если там Linux, проверь подгружен ли там модуль nf_conntrack_ftp. Если это маршрутизатор с web-интерфейсом - поврубай всё связанное с FTP(название опций могут варьироваться, от ALG Gateway до FTP Passthrough).

Модуль загружен, но разве он не нужен для того, чтобы корректно обрабатывалось фаерволом второе соединение для передачи данных? Тем более iptables пропускает весь трафик сетей 10.11 без каких либо NATов и других правил.

Тут смысл в том, что проблемы есть только если клиент - конкретная аппаратная ревизия свича(raisecom 2110ea RevB). Я пытаюсь выгрузить по ФТП конфиг, или залить на него прошивку и возникают проблемы. В целом с фтп проблем нет, а вот с эими свичами есть. Но и причем тут свич тоже не совсем понятно, если пакет, вроде на вид валидный, доходит до маршрутизатора, а вот он по каким-то причинам его дропает.

Отброс пакетов iptables-ом всегда можно увидеть. «iptables -t raw -A PREROUTING ... -j TRACE»

только ограничения не забудь поставить, иначе логи будут слишком быстро расти.

Кривые реализации tcp на таких устройствах не редкость. Если есть свежая прошивка, то попробуй обновить - возможно в ней что-то починили.

Я настолько был уверен, что это не iptables, так как только с этой версией свичей проблемы, что даже не смотрел.

Aug 28 17:46:29 isport kernel: [273800.358083] nf_ct_ftp: dropping packetIN=eth0.5 OUT= MAC=00:1b:21:cb:ac:89:00:0e:5e:2d:cd:49:08:00 SRC=10.1.1.2 DST=10.1.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=45514 DF PROTO=TCP SPT=58392 DPT=21 SEQ=2713967771 ACK=3625424058 WINDOW=10000 RES=0x00 ACK PSH URGP=0

Кривые реализации tcp на таких устройствах не редкость. Если есть свежая прошивка, то попробуй обновить - возможно в ней что-то починили.

Это на всех версиях прошивок на этой ревизии свичей

Глянул тут исходники nf_conntack_ftp

static int try_number(const char *data, size_t dlen, u_int32_t array[],
              int array_size, char sep, char term)
{
    u_int32_t i, len;

    memset(array, 0, sizeof(array[0])*array_size);

    /* Keep data pointing at next char. */
    for (i = 0, len = 0; len < dlen && i < array_size; len++, data++) {
        if (*data >= '0' && *data <= '9') {
            array[i] = array[i]*10 + *data - '0';
        }
        else if (*data == sep)
            i++;
        else {
            /* Unexpected character; true if it's the
               terminator and we're finished. */
            if (*data == term && i == array_size - 1)
                return len;

            pr_debug("Char %u (got %u nums) `%u' unexpected\n",
                 len, i, *data);
            return 0;
        }
    }
    pr_debug("Failed to fill %u numbers separated by %c\n",
         array_size, sep);
    return 0;
}

/* Returns 0, or length of numbers: 192,168,1,1,5,6 */
static int try_rfc959(const char *data, size_t dlen,
              struct nf_conntrack_man *cmd, char term)
{
    int length;
    u_int32_t array[6];

    length = try_number(data, dlen, array, 6, ',', term);
    if (length == 0)
        return 0;

    cmd->u3.ip =  htonl((array[0] << 24) | (array[1] << 16) |
                    (array[2] << 8) | array[3]);
    cmd->u.tcp.port = htons((array[4] << 8) | array[5]);
    return length;
}

Если посмотреть на команду PORT в моем дампе, то она выглядит так.

PORT 10,11,0,54,-35,183

5ое число у нас отрицательное, vsftpd и pyftplib ругаются на такую команду, что-то вроде illegal PORT, pyftplib я под это дело дело подправил, чтоб он вычислял порт. А вот модуль ядра не ждет в команде ничего кроме цифр, разделителя и конца строки. Поэтому модуль и дропал этот порт.

И ТП raisecom меня еще убеждают, что отрицательные числа там это нормально, раз к виндовому 3Com ftp он конектится.

Это в raisecom чудаки на букву му.

Тогда какого хрена они 183 как положительное число передают ?

Можно запретит conntrack для адресов таких свитчей через «iptables -t raw -A PREROUTING -p tcp -s X -j CT --notrack» «iptables -t raw -A PREROUTING -p tcp -d X -j CT --notrack»

А через tftp нет проблем ?