It was pointed out to me today that when using tcpdump, and the -i (interface) flag, you need to know (and specify) the (ethernet) interface identification. Different hardware have different ethernet designations. So you can use 'netstat -rn' to find the ethernet card identification, (ex: eth0, ln0...) and use that in the tcpdump command line parameters. 'tcpdump -i eth0 'port 22'' works fine for my linux box where the ethernet interface is defined as 'eth0', but on other systems, the id might be 'ln0' or something different. I've found it very frustrating on non-linux boxes to troubleshoot why an ssh connection attempt hangs at the 'event loop' stage, without a tool like tcpdump. Watching the traffic in and out of a system sure helps figure out where the problem is. (my router, the other sites router, my /etc/ssh2/sshd2_config file, or theirs...) The ssh 'client', the one requesting connect, will send out packets on an unpriviledged port, something usually above 1023. The packet is addressed to the server (the remote host) on port 22. But the server will negotiate the transactions with me, will send 'back' to me, packets addressed to the port I came in from. (ex: send back to port 1023 or higher) So if a security conscious router person has disallowed traffic *in* on certain higher ports, or if the the server box router won't allow traffic *out* on higher ports, the packets will be dropped. Hence, a hang and no connection. hope this helps, and any comments/corrections welcome, Tamara
