по RFC на запрос CONNECT (cmd=1) прокси серверу следует отвечать так: Ver - 1 байт; REP - 1 байт; RSV -1; ATYP -1; BND.ADDR - ..; BND.PORT - 2 после чего идет обмен данными между клиентом и внешним хостом. Но похоже, что некоторые SOCKS 5 клиенты(например firefox) игнорируют BND.ADDR и BND.PORT, принимая их за данные от внешнего хоста. Это так и должно быть или я где-то что-то не так понял? Сервер возвращает айпишник(ATYP=1)
Почему не нужны ? Из rfc : "В ответ на CONNECT, BND.PORT содержит номер порта, который сервер назначает для соединения с указанным хостом". Если клиент не читает № порта , откуда ему знать , куда послать данные ? Только что прочел rfc . Не вкурю формат запроса . Каждый октет , его что , побитово собирать надо , или как ? И почему в rfc все значения выглядят как X`05`. Что это за X такой ? Может кто покажет пример запроса на CONNECT ?
Hmm как куда посылать данные? да клиент УЖЕ соединился с прокси, что ему еще думать куда их посылать, он используя это соединение и будет работать (если запрос не BIND, там чуток по другому, совсем чуть чуть =) ) sacredphoenix посылай, лишними не будут, но это все лишь доп. информация
Спасибствую за толику ясности TermoSINteZ . Хотя , если это hex , то судя по этому абзацу rfc : " * X`03` поле адреса содержит имя домена. Первый октет адресного поля содержит число октетов в последующем за ним имени, завершающий NUL-октет в конце строки не применяется." Выходит , что максимальная поддерживаемая длина домена == F символов . Маловато что-то . 2xh4ck: Возможно . Хотя по rfc это не так очевидно . А как он тогда должен его разрывать ?
2Hmm когда хочет тогда и разрывает =) ваще я когда то реализовывал сокс сервер, тестилось на многих клиентах, но все же я не могу сказать что код абсолютно верный
bind port и bind address нужны юзающей socks-сервер программе в случае если эти значения используются более "высокими" сетевыми протоколами. Например, они необходимы, когда ftp-клиент, используя socks-сервер, общается с ftp-сервером, находящемся в активном режиме(когда data-соединение идет с 20-го TCP порта сервера), т.е. ftp-серверу нужно знать с каким портом клиента устанавливать связь и клиент сообщает ему его посредством ftp-команды PORT.
Да, пример c активным ftp был для BIND. Для возвращаемых бинд-адреса и порта при CONNECT, на вскидку можно придумать, визуально-эстетическое применение, как в клиентах ICQ, где показываются "Внутренний" и "Внешний" IP адреса. Вот "Внешний" IP, при работе через socks, как раз и является тем самым возвращаемым значением(bnd.addr).
Вообще из опыта тестирования различных SOCKS клиентов могу сказать, что в большенстве случаев это поле игнорирутеся, но есть исключения . ПРимер: Total Commander 7.0pb2 ( на других TC не тестил ) требует что бы в ответ на CONNECT приходили эти поля пустые (точнее зануленые ), а в ответ на BIND первый пустой(зануленый) а второй содержал адресс и порт соединения
Я понял, почему возникала ошибка в работе с firefox. SOCKS 5 сервер, который я написал отвечал на команду CONNECT так: сначала(одним send) посылал сам ответ (5 0 0 1), после чего другим send посылался IP с которого прокси соединялся с внешним хостом и затем еще одним send посылался порт. В результате чего firefox принимал ответ на команду CONNECT а остальные 6 байт принимал уже за данные от внешнего хоста. Когда я переделал сервер так, чтобы ответ, IP и порт посылались одним send все заработало так как и надо. Из чего следует вывод, что в этом случае firefox неправильно работает с протоколом TCP. Он воспринимает данные, пришедшие к нему по-разному в зависимости от того, пришли они одним пакетом или несколькими. У меня версия 2.0.0.4
