openssh-dev at kutek
Feb 26, 2011, 4:17 AM
Post #4 of 7
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:
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 18.104.22.168, 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
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