problem with tunnels

[openssh-dev at kutek.info]

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?