If I do sftp between some nodes that we installed it works fine i can list
directories and get files.
If I connect with sftp from the other side of a firewall (wich has port 22 open)
I can log in and cd to which ever direcory i want i can do pwd but when i do ls or get it hangs and the client never times out ( waited 30 minutes).
If i do ls in a empty directory it works but ls or get in a directory with files hangs.
I know that plain ftp use control and data port but sftp is just port 22 isnt it?
SSH to the same account and list files works fine.
MTU has to match your network's, or else you'll get problems like you had. I had to deal with a crazy and embedded DHCP server which kept giving MTU's of 600, and had to pin the value manually to something sane on all hosts...
Except, usually, MTU handles itself, via ICMP replies. When you send a packet that's too large and nothing on the way can fragment it, you get an ICMP reply about too-large packets, instructing the sending host to send smaller packets.
firewall or someone else's is improperly blocking ICMP, preventing this autocorrection measure from working, meaning you have to get the value of MTU exactly right or things may break.
Steps:
First I and the customer changed the mtu to1300
ifconfig e1000g1 mtu 1300
and that solved the problem.
Later workmates argued that changing MTU could have negative effects so I set the original mtu again and changed the tcp_mss_max parameter instead.
Code:
ndd -set /dev/tcp tcp_mss_maxipv4 1300 ndd -set /dev/tcp tcp_mss_maxipv6 1300
to see the value do
Code: ndd -get /dev/tcp tcp_mss_maxipv4
The tcp_mss_max value sets the max tcp packet size. (im not sure that its the correct term) and Im pretty sure that its not the same as changing MTU altough many people thinks so. End result seems to be the same.
This solved the problem for me.