Ошибка недействительного аргумента в httptunnel клиенте
Я пытаюсь использовать httptunnel для туннеля соединение как это:
на Сервере:
sudo hts -F localhost:10000 81
nc -l -p 10000
На клиенте:
sudo htc -F 7777 server_ip_address:81
telnet 127.0.0.1 7777
но сбои telnet:
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
в системном журнале говорится:
Nov 6 01:41:37 r1y4n-PC htc[1695]: htc (httptunnel) 3.3 started with arguments:
Nov 6 01:41:37 r1y4n-PC htc[1695]: me = htc
Nov 6 01:41:37 r1y4n-PC htc[1695]: device = (null)
Nov 6 01:41:37 r1y4n-PC htc[1695]: host_name = server_ip_address
Nov 6 01:41:37 r1y4n-PC htc[1695]: host_port = 81
Nov 6 01:41:37 r1y4n-PC htc[1695]: proxy_name = (null)
Nov 6 01:41:37 r1y4n-PC htc[1695]: proxy_port = 8080
Nov 6 01:41:37 r1y4n-PC htc[1695]: proxy_buffer_size = 0
Nov 6 01:41:37 r1y4n-PC htc[1695]: proxy_buffer_timeout = -1
Nov 6 01:41:37 r1y4n-PC htc[1695]: content_length = 102400
Nov 6 01:41:37 r1y4n-PC htc[1695]: forward_port = 7777
Nov 6 01:41:37 r1y4n-PC htc[1695]: max_connection_age = 300
Nov 6 01:41:37 r1y4n-PC htc[1695]: use_std = 0
Nov 6 01:41:37 r1y4n-PC htc[1695]: strict_content_length = 0
Nov 6 01:41:37 r1y4n-PC htc[1695]: keep_alive = 5
Nov 6 01:41:37 r1y4n-PC htc[1695]: proxy_authorization = (null)
Nov 6 01:41:37 r1y4n-PC htc[1695]: user_agent = (null)
Nov 6 01:41:37 r1y4n-PC htc[1695]: debug_level = 0
Nov 6 01:41:49 r1y4n-PC htc[1695]: http_write_request: write error: Invalid argument
Nov 6 01:41:49 r1y4n-PC htc[1695]: couldn't open tunnel: Invalid argument
Nov 6 01:41:49 r1y4n-PC htc[1695]: exit with status = 1
Что вызывает http_write_request: write error: Invalid argument ?
Как я могу туннелировать свое соединение правильно?
И сервер и клиент Ubuntu 14.04
Спасибо
1 ответ
Как я могу туннелировать свое соединение правильно?
Зафиксируйте httptunnel. Посмотрите ниже.
Обратите внимание использование nc с ошибочными аргументами но это все еще, кажется, работает. От man nc:
- l Используемый, чтобы указать, что nc должен прислушаться к входящему соединению, а не инициировать соединение с удаленным хостом. Это - ошибка использовать эту опцию в сочетании с-p,-s, или-z опции.
Что вызывает http_write_request: ошибка при записи: Недействительный аргумент?
Invalid argument stringified версия кода ошибки POSIX EINVAL.
Код ошибки был возвращен из записи libc функция/ядро syscall, который косвенно назвала http_write_request функция httptunnel клиента. Средства EINVAL:
fd присоединен к объекту, который является неподходящим для записи; или файл был открыт с флагом O_DIRECT, и или адрес, указанный в buf, значение, указанное в количестве, или текущее файловое смещение не соответственно выровненное.
Прежде чем запись () называют, сокет настроен с различными вариантами с помощью setsockopt libc функция / ядро syscall. Одна из этих опций является SO_SNDLOWAT. Можно читать, о каком это, как предполагается, делает здесь. Обратите внимание что:
SO_SNDLOWAT не изменяем на Linux (setsockopt (2) сбои с ошибкой ENOPROTOOPT)
таким образом, это - бесполезный вызов для создания на Linux во-первых, по крайней мере, по состоянию на 2015.
После рабочего htc с strace я заметил несоответствие между кодом и syscall аргументами, о которых сообщает strace. Код в tunnel_out_setsockopts функция пытается установить опцию SO_SNDLOWAT, но отчеты о strace setsockopt(5, SOL_TCP, TCP_REPAIR, [1], 4) = 0. Более тщательно изучите страницу справочника сокета, где SO_SNDLOWAT перечислен как опция, и отметьте следующее:
Упомянутые ниже опции сокета могут быть установлены при помощи setsockopt (2) и считаны с getsockopt (2) с набором уровня сокета к SOL_SOCKET для всех сокетов.
tunnel_out_setsockopts не использует SOL_SOCKET для опции SO_SNDLOWAT; это использует результат другой функции (get_proto_number) вместо этого. Это - ошибка. Это может произойти из-за несоответствия с предыдущими версиями ядра или libc API, но я подозреваю, что это маловероятно.
К сожалению, исправление этой ошибки путем замены аргумента level сокета SOL_SOCKET не приводит к применимому туннелю. Вызов записи, который ранее перестал работать теперь, успешно выполняется, но программа перестала работать приблизительно секунду спустя с ETIMEDOUT на вызове чтения.
Существует другая функция tunnel_in_setsockopts который пытается установить SO_RCVLOWAT с выводом get_proto_numer вместо SOL_SOCKET. Это - другая ошибка.
Фиксация этих двух причин туннель для работы правильно.
Сервер
nc-l 10000
sudo hts-F localhost:10000 81
Клиент
htc-F 7777 localhost:81
telnet localhost 7777
Об этой ошибке уже сообщили против Ubuntu 14.04 здесь. Я предлагаю, чтобы Вы отметили его как влияние на Вас. Я загрузил патч как фиксацию для проблемы, но она должна будет все еще быть принята Ubuntu.