mprota / udptunnel Goto Github PK

What steps will reproduce the problem?
1. on the server side, run tinyproxy on port 8080
2. run udptunnel server
3. run udptunnel client, point to 127.0.0.1:8080
4. Configure Firefox to use udptunnel as http proxy. 
5. Firefox will get an empty page on all web site browsing.

What is the expected output? What do you see instead?
--expected to see web browsing working in firefox


What version of the product are you using? On what operating system?
--latest version: r18

Please provide any additional information below.

There should be a way to support passive mode where the SERVER starts the 
connection to the client.
Scenario: RSYNC server not reachable behind a NAT; RSYNC client reachable. The 
UDP proxy would server side would make a request to the proxy client side so 
that the UDP channel opens. A that point the client can communicate normally 
with the server.

This issue is not well described, but I hope that you could guess the reason of 
this problem.

I don't seem to be able to get HTTPS traffic to go through the UDP tunnel, is 
there some fundamental reason I'm missing why this wouldn't work? 

I'm using a windows VM running the udptunnel in server mode as well as a XAMP 
server to test it out and another Windows VM acting as the client. I can access 
the XAMP site over http, but can't access the secure https site. 

This is a feature request: is it possible to add a udp buffer for each udp link 
so that multiple udp packets can be transmitted and acked instead of waiting 
for ACK on the first packet before sending the second one?

What steps will reproduce the problem?
1. Launch udptunnel client "udptunnel.exe -c 127.0.0.1 8888
IP_UDPTUNNEL_SERVER 12345 127.0.0.1 80" . And the udptunnel server
./udptunnel -s 12345 (this server MUST have a httpd process running)
2. Open the browser and enter the url http://127.0.0.1:8888 : nothing
displayed.

What is the expected output? What do you see instead?
The expected output should be the web page. But here we see nothing

What version of the product are you using? On what operating system?
Latest version, r9

Please provide any additional information below.
This problem occurred due to the http protocol that has a multiple small
TCP request simultaneously and it seems that your program doesn't like that.
Thank a lot for providing an amazing program. ALl the best 

What steps will reproduce the problem?
1. start the sever on remotehost "./udptunnel -s 5050 -vv
2. start squid sever on the remote-host which would list on localhost:3128
3. start the client ./udptunnel -c 4455 remote-host 5050 localhost 3128
4. Now setup a http proxy on the browser as localhost:4455
5. Try to browse. It should fetch the webpage.
6. Stop squid server
7. Try to browse.

Now the sever sends the following output few lines and exits.
       recv: Transport endpoint is not connected

What is the expected output? What do you see instead?
      There server not should NOT exit when the tcp endpoint is closed.

What version of the product are you using? On what operating system?
        udptunnel-r13 on Linux - 2.6.33.3-85.fc13.i686.PAE


Please provide any additional information below.

There is already an existing project named 'udptunnel':
<http://www1.cs.columbia.edu/~lennox/udptunnel/> (which incidentally
tunnels UDP over TCP :-)) and it is already packaged for Debian. I think it
would make sense to think about a new name to avoid confusion, especially
once someone might want to add _this_ udptunnel to Debian.

I don't have any suggestions for the new name, but want to add that
'utunnel' is also already taken: <http://thebends.org/~allen/utunnel/>.

When I start udptunnel, and then close it, and run it again, I sometimes get 
this error.

$ udptunnel -vv -c 127.0.0.1 44444 192.168.1.1 44444 127.0.0.1 22
bind: Address already in use
Error: Error creating TCP socket.
Cleaning up...
Goodbye.

I have attached a patch that corrects this problem using setsockopt() and 
SO_REUSEADDR as referenced here 
http://beej.us/guide/bgnet/output/html/multipage/setsockoptman.html

It would be nice if udptunnel allowed to start the server such that the
destination host and port is fixed. The usecase for this is providing
access to a single service over UDP as well as TCP. For example to work
around your ISPs firewall rules that forbid incoming TCP connections.

Without that feature, udptunnel unnecessarily tears a big hole into your
network's security.