Erro de argumento inválido no cliente httptunnel

0

Estou tentando usar httptunnel para tunelar uma conexão como esta:
no servidor:

sudo hts -F localhost:10000 81
nc -l -p 10000

No cliente:

sudo htc -F 7777 server_ip_address:81
telnet 127.0.0.1 7777

mas o telnet falha:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.

syslog diz:

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

O que causa o http_write_request: write error: Invalid argument ?
Como posso encapsular minha conexão corretamente?
Tanto o servidor quanto o cliente são Ubuntu 14.04

Obrigado

    
por RYN 05.11.2015 / 23:28

1 resposta

1

Como posso encapsular minha conexão corretamente?

Corrija o httptunnel. Veja abaixo.

Note que você está usando nc com argumentos errados, mas ainda parece funcionar. De man nc :

% bl0ck_qu0te%


O que causa o erro http_write_request: write: argumento inválido?

Invalid argument é uma versão string do código de erro POSIX EINVAL .

O código de erro foi retornado da função write libc / kernel syscall que era indiretamente chamado pela função http_write_request do cliente httptunnel. EINVAL significa:

% bl0ck_qu0te%

Antes de write () ser chamado, o socket é configurado com várias opções usando o setsockopt libc / syscall do kernel. Uma dessas opções é SO_SNDLOWAT. Você pode ler sobre o que é suposto fazer aqui . Note que:

% bl0ck_qu0te%

então é uma chamada inútil para fazer no linux, pelo menos a partir de 2015.

Depois de executar o htc com o strace , notei uma inconsistência entre o código e os argumentos do syscall relatados pelo strace. O código na função tunnel_out_setsockopts está tentando definir a opção SO_SNDLOWAT, mas rastrear relatórios setsockopt(5, SOL_TCP, TCP_REPAIR, [1], 4) = 0 . Dê uma olhada mais de perto na página do manual soquete em que SO_SNDLOWAT é listado como uma opção e observe o seguinte:

% bl0ck_qu0te%

tunnel_out_setsockopts não usa SOL_SOCKET para a opção SO_SNDLOWAT; ele usa o resultado de outra função ( get_proto_number ). Isto é um bug. Isto pode ser devido a uma inconsistência com versões anteriores do kernel ou da API libc, mas suspeito que seja improvável.

Infelizmente, corrigir esse bug substituindo o argumento de nível de soquete por SOL_SOCKET não resulta em um túnel utilizável. A chamada de gravação que anteriormente estava falhando agora é bem-sucedida, mas o programa falha cerca de um segundo depois com ETIMEDOUT em uma chamada de leitura.

Existe outra função tunnel_in_setsockopts que tenta definir SO_RCVLOWAT com a saída de get_proto_numer em vez de SOL_SOCKET. Este é outro bug.

Corrigir estes dois faz com que o túnel funcione corretamente.

Servidor
nc -l 10000
sudo hts -F localhost: 10000 81

Cliente
htc -F 7777 localhost: 81
telnet localhost 7777

Este bug já foi reportado contra o Ubuntu 14.04 aqui . Eu sugiro que você marque isso como afetando você. Eu fiz upload de um patch como uma correção para o problema, mas ele ainda precisará ser aceito pelo Ubuntu.

    
por tweej 06.11.2015 / 04:04