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
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
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.