Mailing List Archive: OpenSSH: Dev

problem with tunnels

Index | Next | Previous | View Threaded

obb33 at verizon

Feb 25, 2011, 6:44 AM

Post #1 of 7 (597 views)
Permalink

problem with tunnels

I use ssh tunnels extensively. recently I upgraded my linux kernel from
2.6.18 to 2.6.37 and a problem with tunnels has resulted.

prior to the upgrade use of ssh tunN devices was rock solid.

the problem manifests as the tunnel from the initiator end ceasing to
transfer data to the remote after a quantity of data is sent. it is
necessary to create a new tunnel after destroying the old to get data to
flow again, which after time jams also.

i tested this with linux kernels back to 2.6.31 and they all have the
problem.however, tunnels opened TO systems using these kernels work fine
from the 2.6.18 kernel system, but if the initiator side is any of the above
kernels the data flow jam occurs.

what's weird about this is that the remote end can still send data that is
received on the initiator side after the jam occurs on the initiator side.

i have tested this on different hardware and the results are the same, only
the kernel version on the initiator end is relevant.

it's not clear that this is an openssh problem as opposed to a kernel
problem.

please tell me what additional information you need to resolve this and i
will send it.

TIA

B Stone

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

openssh-dev at kutek

Feb 25, 2011, 2:13 PM

Post #2 of 7 (584 views)
Permalink

problem with tunnels [In reply to]

I use ssh tunnels extensively. recently I upgraded my linux kernel from
2.6.18 to 2.6.37 and a problem with tunnels has resulted.

prior to the upgrade use of ssh tunN devices was rock solid.

the problem manifests as the tunnel, from the initiator end, ceasing to
transfer data to the remote after a quantity of data is sent. it is
necessary to create a new tunnel after destroying the old to get data to
flow again, which after time jams also.

i tested this with linux kernels back to 2.6.31 and they all have the
problem.however, tunnels opened TO systems using these kernels work fine
from the 2.6.18 kernel system, but if the initiator side is any of the above
kernels the data flow jam occurs.

what's weird about this is that the remote end can still send data to the
initiator side, after the jam occurs on the initiator side.

i have tested this on different hardware and the results are the same, only
the kernel version on the initiator end is relevant.

it's not clear that this is an openssh problem as opposed to a kernel
problem.

looking at the datastream on the network with tcpdump there are no packet frag
issues, and the tests were done with all firewalls turned off.

please tell me what additional information you need to help resolve this and i
will send it.i need to get this working again, fast

B Stone

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

gert at greenie

Feb 26, 2011, 2:47 AM

Post #3 of 7 (574 views)
Permalink

Re: problem with tunnels [In reply to]

Hi,

On Fri, Feb 25, 2011 at 05:13:40PM -0500, openssh-dev [at] kutek wrote:
> it's not clear that this is an openssh problem as opposed to a kernel
> problem.
>
> looking at the datastream on the network with tcpdump there are no packet frag
> issues, and the tests were done with all firewalls turned off.

Have you tried tcpdumping on the tun0 interface? Any difference between
"working" and "non-working" systems?

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

openssh-dev at kutek

Feb 26, 2011, 4:17 AM

Post #4 of 7 (581 views)
Permalink

Re: problem with tunnels [In reply to]

first, my apologies to the list for the dupe message, this list and it's user
control moves messages extremely slowly , and before i received
confirmation of the address confirmation i had already sent the second
message thinking the first was lost.

second, I neglected to mention that this problem happens with both 5.6p1 and
5.8p1, both of which otherwise work perfectly on the 2.6.18 kernel. i don't
think i have to regress any further.

third,a search has not turned up any complaints anywhere else of this problem
nor kernel developers addressing the issue except perhaps this:

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.34

search at that page on the word "undefinitely" (with that spelling) to see
the relevant comment

fourth, i compiled up the latest gdb intending to debug openssh at which
point i discovered i compiled glibc without the debugging libraries and it's
going to be a big production to do that

fifth, problem happens whether the tunnel is tun or tap.

sixth, i have now installed 2.6.37.2, and the situation is unchanged.

Gert, i will generate that data and post, and my intention is to install
VTUN also and see what happens, which is going to take a bit of time to
learn. by tun0 i am assumimg you mean the tunnel creation side.

this is very frustrating because the openssh tunnels worked so well
previously and were so easy to set up and use, i would hate to have to move
to ipsec.

however the linux tun/tap code has changed considerably since
2.6.18 as a diff on tun.c will show.

>On Sat, Feb 26, 2011 at 11:47:32AM +0100, Gert Doering wrote:
>
> Have you tried tcpdumping on the tun0 interface? Any difference between
> "working" and "non-working" systems?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

openssh-dev at kutek

Feb 26, 2011, 5:13 AM

Post #5 of 7 (571 views)
Permalink

Re: problem with tunnels [In reply to]

ok.

i have reconfigured my setup on the 2.6.37.2 kernel to use ethernet
tunnels instead of point-to-point and everything is working beautifully, i
may have been mistaken in my statement last message about tap on the
2.6.37.1 kernel.

this solves my immediate practical problem but not the p2p issue.

i will assist in resolving that, if in fact it is an issue with openssh or
the kernel.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Feb 27, 2011, 5:21 PM

Post #6 of 7 (565 views)
Permalink

Re: problem with tunnels [In reply to]

On Sat, 26 Feb 2011, openssh-dev [at] kutek wrote:

> search at that page on the word "undefinitely" (with that spelling) to see
> the relevant comment

Sounds perfectly cromulent to me
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

openssh-dev at kutek

Feb 27, 2011, 7:41 PM

Post #7 of 7 (557 views)
Permalink

Re: problem with tunnels [In reply to]

On Mon, Feb 28, 2011 at 12:21:36PM +1100, Damien Miller wrote:
> On Sat, 26 Feb 2011, openssh-dev [at] kutek wrote:
>
> > search at that page on the word "undefinitely" (with that spelling) to see
> > the relevant comment
>
> Sounds perfectly cromulent to me

i never devalue the unique in searching thru or specifying something in
the haystack, it actually makes things much much easier. ;-)

i have been experimenting further.

i have not sent the tcpdump traces because it turns out that no data flow on
the tunnel point-to-point interface has to occur at all for the interface to
stop functioning. just a variable period of time, about 25 seconds. after
that time passes, sending data to the client will not work, but data can
still be received from the client. apparently the keep alive messages alone
will trigger the interface freeze (i'm using both types).

the client does not notice anything and ssh does not die.

ssh ethernet tunnels,otoh, work perfectly. there is no other weirdness
on the system(s) happening. with either IF type.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads