TCP thru UDP?

  • Thread starter Thread starter smerf
  • Start date Start date
S

smerf

I have a constant UDP connection from one office to another office. I use
it for an in-house application and it works just fine.

But, I want to add file transfer to my little app without requiring another
port be opened on the firewall and I don't want to reinvent the TCP wheel.

Is there a way to tunnel TCP through my existing UDP connection and take
advantage of the packet checks that TCP offers for transfering files?
 
Usually within LAN that be OK, TFTP ( UDP base ) work pretty nice for LANs,
but if you "reinvent the TCP wheel"
you need to use TCP, otherwise you can use 3-th party s/w which did that :)
Arkady
 
smerf said:
I have a constant UDP connection from one office to another office. I use
it for an in-house application and it works just fine.

But, I want to add file transfer to my little app without requiring another
port be opened on the firewall and I don't want to reinvent the TCP wheel.

Is there a way to tunnel TCP through my existing UDP connection and take
advantage of the packet checks that TCP offers for transfering files?
Click to expand...

How does this avoid opening another port on the firewall? You'll need
to open the port that's used for the TCP-over-UDP protocol, since it
will be different from whatever port you're using for your "constant UDP
connection" (I have no idea what you mean by that, BTW).
 
I have a constant UDP connection from one office to another office. I use
it for an in-house application and it works just fine.
Click to expand...
But, I want to add file transfer to my little app without requiring another
port be opened on the firewall and I don't want to reinvent the TCP wheel.
Click to expand...
Is there a way to tunnel TCP through my existing UDP connection and take
advantage of the packet checks that TCP offers for transfering files?
Click to expand...

Yeh, you could do it, but the bother would be relatively high.
You'd probably find it a lot easier to just adapt one of the old
modem file transfer protocols such as x-modem.
 
Barry Margolin said:
How does this avoid opening another port on the firewall? You'll need
to open the port that's used for the TCP-over-UDP protocol, since it
will be different from whatever port you're using for your "constant UDP
connection" (I have no idea what you mean by that, BTW).
Click to expand...

I simply mean that there is a UDP port open on PC1 and another UDP port open
on PC2 and that they are available and the apps hosting them are aware that
they are available for data transfer betwen the 2 PCs.

I don't have access to the other firewall, and may not be able to get the
admin to open an external TCP port without a tremendous gnashing of teeth
and perhaps some boils and a plague or two. So, I thought, why not tunnel
the TCP connections thru the UDP ports?

The idea here is similar to the Hamachi VPN solution (which LogMeIn
purchased and does not release the server code for). See
http://www.realvnc.com/pipermail/vnc-list/2006-January/053895.html for a
short description of how Hamachi encapsulated TCP in UDP.

I don't really understand all of what is needed to accomplish that. I
assume the Hamachi solution used an ethernet driver of some sort and simply
relayed the data sent to it to the other end of the tunnel via the UDP used
to get thru the firewalls and NATs.

Well, I can't code a device driver yet (no C++ skills), so I thought I might
be able to aim the TCP connections through my UDP tunnel.

Any ideas? I am looking into using WinPcap to sniff the packets on the
network and send them thru the UDP tunnel, but that may result in packets
being split (according to the referenced article) - and nobody wants split
packets.

The only WinPcap that I have found to use is wrapped in an activex control.
But, won't COM interop really screw with the speed if I do something like
this via an activex component from .Net?

Then there is the encrpytion of the data stream between the endpoints -
something I haven't even bothered to tackle at this point.

Does encryption + COM interop = too damned slow to bother with?
 
Thanks for the idea.

While researching it, the damndest thing happened. I thought of a simple
way to do file transfer via UDP. It involves my own little
protocol....small and simple but possibly more verbose than the TCP
protocols - so speed may suffer.

Now, I am on a hunt to enable other apps to work thru my little UDP tunnel -
like Remote Desktop or VNC or Video Conferencing etc..

To do this, I still need to find the best way to make my UDP connection on
each end act as a connecting point between the PCs. They would essentially
be TCP Proxies for any app that required a TCP connection.

Any ideas?
 
Now, I am on a hunt to enable other apps to work thru my little UDP tunnel -
like Remote Desktop or VNC or Video Conferencing etc..
Click to expand...
To do this, I still need to find the best way to make my UDP connection on
each end act as a connecting point between the PCs. They would essentially
be TCP Proxies for any app that required a TCP connection.
Click to expand...

It'd be a small modification to any gre encapsulator.
 
There is one problem that I just thought of with the WinPcap solution.....IP
resolution. You couldn't just send all packets for IP 192.168.1.101 (for
instance) from your network to the other network.

What of they weren't using the 192- range? Or what if they were and your
internal calls to the 192.168.1.101 PC on your network were sent to the same
IP on thier network?

No....the WinPcap solution is a little too simple.

Hamachi uses a Hamachi Network Interface to connect to the IPV4 5.0.0.0/8
VPN addresses. So, I guess I have to learn device driver coding in C++
now......yeah, right.

Hamachi also uses the 5.0.0.0/8 Ip range that is unassigned by ICANN, but is
routable over the internet.

The problem with this little scheme is that the 5.0.0.0/8 IP range will hold
only 16,000,000 IPs. That means that only 16,000,000 PCs can use the
Hamachi network. The 5.0.0.0/8 IP range is also reserved by ICANN for
future use. So, when the next Gates wannabe starts using the 5.0.0.0/8 IPs,
Hamachi users are in for a wild ride.

Sure, Hamachi could change to IPV6 and have plenty of IP adresses. In fact,
this is exactly (IMHO) what LogMeIn was thinkgin when they bought Hamachi.
Transfering the IPV4 addresses would be a nightmare. LogMeIn will simply
say that the IPV4 was a BETA and now you have to pay a monthly fee to use
Hamachi on the new IPV6 addresses assigned to them by ICANN.

It's coming...just wait. That's why we need a free version of just such a
tool.

There has to be a simpler way to connect PCs in a networked fashion than
using a device driver like Hamachi does.

Well......time to sleep on it.
 
Walter Roberson said:
It'd be a small modification to any gre encapsulator.
Click to expand...

Thanks for the pointer. hadn't heard of gre encapsulation before. The only
thing I'll have to look into is how to make sure the TCP packets aren't too
large when wrapped. This may not be a problem, but I'll have to look more
into it to be sure.

Well, bedtime for smerf. I'll be dreaming about this crap all night. :)

I'll continue with what I find tomorrow.
 
Hello,

smerf a écrit :
I have a constant UDP connection from one office to another office. I use
it for an in-house application and it works just fine.

But, I want to add file transfer to my little app without requiring another
port be opened on the firewall and I don't want to reinvent the TCP wheel.

Is there a way to tunnel TCP through my existing UDP connection and take
advantage of the packet checks that TCP offers for transfering files?
Click to expand...

Use a tunnel that runs over UDP, such as OpenVPN. Then you can tranport
any kind of IP traffic including TCP inside the tunnel.
 
OpenVPN requires Admin login to at least setup initially. My users may not
have that capability.
 
smerf said:
I simply mean that there is a UDP port open on PC1 and another UDP port open
on PC2 and that they are available and the apps hosting them are aware that
they are available for data transfer betwen the 2 PCs.
Click to expand...

I assume these ports are open through the firewall because you're
already running an application that uses them. If so, you can't use the
same port for your tunnel, because the PC's won't be able to tell
whether a packet is for the application or for the tunnel.
 
Barry Margolin said:
I assume these ports are open through the firewall because you're
already running an application that uses them. If so, you can't use the
same port for your tunnel, because the PC's won't be able to tell
whether a packet is for the application or for the tunnel.
Click to expand...

Another usenet user turned me on to a way that this can be accomplished.
Check out gre encapsulation at
http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation.

It's not exactly a VPN, but it'll do nicely for file transfers and such.
 
Back
Top