Sampsa Laine wrote:
Gentlemen, anyone happen to have softcopy documentation for the above?
Just got one off Ebay, will wire it up sooner or later.
Sampsa
If you'll take a reply from a non-gentleman ... I found this :
http://vt100.net/mirror/antonio/d200cin1.pdf
;-)
Chrissie
On Wed, May 13, 2009 at 11:57:01AM +0100, Sampsa Laine wrote:
I agree, reliability could definitely be an issue. Of course the SSH
tunnel has the advantage of not really requiring any additional
software to be installed or configured.
While that's certainly a valid point, it's not like it's hard to install.
Setting it up on the other hand, well, if you've never done that before, it
can be a bit daunting.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Fri, May 15, 2009 at 01:27:25PM +0200, Johnny Billquist wrote:
But in addition, for this to work, you need to allow the remote users to
get ssh access to your local machine, otherwise ssh can't set up tunneling.
And for me, that's not something I'll do for all you guys... :-)
After we get moved and get settled in, the two VAX 4000 boxes are going to
bet setup again. I'll also setup a cisco router or two to go along with them.
At that point I'd be willing to do GRE/OpenVPN/SSH/etc for people.
Also, within the next two to three weeks I'll be upgrading my colocated box.
It's got great bandwidth (100MB+) and I'd be more than willing to setup OpenVPN
for HECnet. I think for our purposes OpenVPN in bridging mode would work best.
Hmmm, I wonder how hard it would be to get DECnet support rolled into something
like OpenVPN?
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Sampsa Laine wrote:
Came across this whilst looking for some SSH stuff and realized this could be used to either securely transmit HECnet data between two hosts or enable a host with a dynamic IP to run the bridge/MULTINET UDP thing:
http://24.97.150.195/nstwiki/index.php/Tunnelling_UDP_Traffic_Through_An_SS… Basically, they use a combination of SSH port forwarding (which is TCP only) and nc to create a secure UDP tunnel between two sites. Setting this up would be trivial on a standard Unix box and if we use public key authentication we don't even need to store passwords anywhere. Also, we would of course benefit from the authentication and cryptographic features that SSH brings to the table.
The main disadvantage I can see is that SSH runs over TCP so any dropped packets might cause more delays than using straight UDP.
Yes, tunneling through something would always work. It will cost a lot in overhead, but for some that may be okay.
Also, as you note, it might cause retransmits at several levels, which also cost some.
And of course, you also risk additional delays.
But in addition, for this to work, you need to allow the remote users to get ssh access to your local machine, otherwise ssh can't set up tunneling.
And for me, that's not something I'll do for all you guys... :-)
There are other aspects to this as well, but I'll leave it at this. I've also read the other comments. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
What I was referring to is the cascading time-out problems you can sometimes get tunnelling one TCP connection over another, e.g. HTTP over a PPP over SSH connection:
3. HTTP (TCP)
2. IP
1. PPP
0. SSH (TCP)
Sometimes if a time-out occurs and layers 0 and 3 have different retransmission timers, the retransmissions kill the whole shebang.
More details can be found at: http://sites.inka.de/~W1011/devel/tcp-tcp.html
Not sure if this will be a problem with NSP over TCP however, but I can imagine it might be (if the NSP retransmission timer is faster than the underlying TCP timers).
Sampsa
On 13 May 2009, at 15:25, Paul Koning wrote:
"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
Sampsa> The main disadvantage I can see is that SSH runs over TCP so
Sampsa> any dropped packets might cause more delays than using
Sampsa> straight UDP.
That isn't actually a disadvantage when you travel all the way to the
top of the stack. Yes, the DECnet network layer (just like IP) uses,
and provides, a datagram service. But it also uses retransmit
internally for stuff that has to get through, and of course the
transport layer (NSP) makes a reliable service through timeout and
retry.
So a tunnel over TCP is just fine. It means you have a lossless
network (ignoring congestion in the DECnet nodes). So instead of
having delays due to timeout and retransmit in NSP, you have the same
delay (or, quite possibly, a shorter delay) due to timeout and
retransmit in TCP. The overall application performance should come
out essentially the same.
paul
"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
Sampsa> The main disadvantage I can see is that SSH runs over TCP so
Sampsa> any dropped packets might cause more delays than using
Sampsa> straight UDP.
That isn't actually a disadvantage when you travel all the way to the
top of the stack. Yes, the DECnet network layer (just like IP) uses,
and provides, a datagram service. But it also uses retransmit
internally for stuff that has to get through, and of course the
transport layer (NSP) makes a reliable service through timeout and
retry.
So a tunnel over TCP is just fine. It means you have a lossless
network (ignoring congestion in the DECnet nodes). So instead of
having delays due to timeout and retransmit in NSP, you have the same
delay (or, quite possibly, a shorter delay) due to timeout and
retransmit in TCP. The overall application performance should come
out essentially the same.
paul
I agree, reliability could definitely be an issue. Of course the SSH tunnel has the advantage of not really requiring any additional software to be installed or configured.
Sampsa
On 13 May 2009, at 11:52, Brian Hechinger wrote:
On Wed, May 13, 2009 at 11:39:19AM +0100, Sampsa Laine wrote:
The main disadvantage I can see is that SSH runs over TCP so any
dropped packets might cause more delays than using straight UDP.
Having done various SSH tunnels over the years another disadvantage is
that they are a complete pain to deal with. Honestly, I would find it
considerably easier to setup something like OpenVPN which would solve
both the UDP and the dynamic IP problems and give you everything you
wanted ssh to do for you except with less pain and suffering attached.
Don't get me wrong, ssh tunnels are a FANTASTIC tool, but they've only
ever caused me grief when I expected them to be a "permenent" tunneling
solution.
Just my $0.02
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Wed, May 13, 2009 at 11:39:19AM +0100, Sampsa Laine wrote:
The main disadvantage I can see is that SSH runs over TCP so any
dropped packets might cause more delays than using straight UDP.
Having done various SSH tunnels over the years another disadvantage is
that they are a complete pain to deal with. Honestly, I would find it
considerably easier to setup something like OpenVPN which would solve
both the UDP and the dynamic IP problems and give you everything you
wanted ssh to do for you except with less pain and suffering attached.
Don't get me wrong, ssh tunnels are a FANTASTIC tool, but they've only
ever caused me grief when I expected them to be a "permenent" tunneling
solution.
Just my $0.02
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Came across this whilst looking for some SSH stuff and realized this could be used to either securely transmit HECnet data between two hosts or enable a host with a dynamic IP to run the bridge/MULTINET UDP thing:
http://24.97.150.195/nstwiki/index.php/Tunnelling_UDP_Traffic_Through_An_SS…
Basically, they use a combination of SSH port forwarding (which is TCP only) and nc to create a secure UDP tunnel between two sites. Setting this up would be trivial on a standard Unix box and if we use public key authentication we don't even need to store passwords anywhere. Also, we would of course benefit from the authentication and cryptographic features that SSH brings to the table.
The main disadvantage I can see is that SSH runs over TCP so any dropped packets might cause more delays than using straight UDP.
Sampsa