Supplemental information. I have now done this in two locations (home and at UAT) using 3 machines in each location (lapdog2 in both) and different routers in each. I can ssh from lapdog2 to any other with one exception (see next paragraph). I can also ssh from other machine to any other except lapdog2 and the same exception. The exception is damselfish which is a netbook running ubuntu 11.04 like lapdog2 (a laptop). Ubuntu 11.04 does not seem to be the common thread as hammerhead works both ways and it is a desktop running 11.04. Its hard to imaging laptops being the common thread but ... On Sat, Jun 18, 2011 at 1:02 PM, Joseph Sinclair wrote: > Based on what you're seeing below, I'd suggest looking at the IP setup on > the machines and any router/gateway between the two machines. > It looks like something is allowing the ICMP traffic but blocking or > loosing the TCP connect for port 22. > > It might help to run the following commands on each machine to look for > inconsistencies or errors: > ifconfig -a > ip addr list > ip neigh > ip route > larry@lapdog2:~$ ifconfig -a eth0 Link encap:Ethernet HWaddr 00:16:36:e6:1b:b9 inet addr:192.168.2.124 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::216:36ff:fee6:1bb9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4187 errors:0 dropped:0 overruns:0 frame:0 TX packets:4369 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1349793 (1.3 MB) TX bytes:621589 (621.5 KB) Interrupt:18 Memory:da000000-da020000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:720 (720.0 B) TX bytes:720 (720.0 B) wlan0 Link encap:Ethernet HWaddr 00:19:d2:37:3c:33 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) larry@lapdog2:~$ ip addr list 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:36:e6:1b:b9 brd ff:ff:ff:ff:ff:ff inet 192.168.2.124/24 brd 192.168.2.255 scope global eth0 inet6 fe80::216:36ff:fee6:1bb9/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:19:d2:37:3c:33 brd ff:ff:ff:ff:ff:ff larry@lapdog2:~$ ip neigh 192.168.2.1 dev eth0 lladdr 00:18:f8:3e:19:c1 REACHABLE larry@lapdog2:~$ ip route 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.124 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 192.168.2.1 dev eth0 proto static larry@lapdog2:~$ > > Some *possible* causes: > 1) More than one machine thinks it has IP 192.168.2.124 and there is an ARP > conflict. > Verified not true > > 2) You have VLAN's setup on the router and the tagging is off or the router > isn't passing TCP traffic between the VLAN's. > No VLANs > 3) The two machines have subnet masks that make them think they're on > different networks (e.g. 255.255.255.0 and 255.255.255.252 or /24 and /30) > All subnet masks are 255.255.255.0 > > If the machines are DHCP, have both release and renew their lease (and make > sure there's only one DHCP server on the network!). > Verified only one dhcp server > If they're static configured, check /etc/network/interfaces and make sure > the subnet mask is the same on both. > Only one machine (fogtest) is staticly configured )on both routers) as a static IP issued by DHCP > Dig through your router configuration (I assume you only have one router, > if not temporarily remove all but one router) to make sure you don't have > VLAN's setup or that they're properly configured > Only one router in each loaction and they seem correct > Check the ARP tables on the machines and the router ("ip neigh" at the > command line on each machine, router depends on it's interface) to make sure > you don't have duplicates and the MAC address matches for each IP address on > the different machines > I'll have to research how to do that. > example (you may see many more entries than this) (Note that 10.23.124.104 > is visible on both and the MAC value matches): > Machine 1 > 10.23.124.104 dev eth0 lladdr 02:49:5a:9e:e2:6c STALE > 10.23.124.123 dev eth0 lladdr 03:1d:7f:7f:4d:2d STALE > > Machine 2 > 10.23.124.104 dev eth0 lladdr 02:49:5a:9e:e2:6c STALE > 10.23.124.125 dev eth0 lladdr 03:1e:4f:73:29:10 STALE > > There should be only one entry for each IP address in the list on each > machine; for a given IP address, all machines should see the same MAC > address. > > Hopefully that helps. Inconsistent network issues like this are always > difficult to track down. > > <> > > Again, name/ip resolution is not a problem and is always working > correctly. > > BTW, here is an attempt from today: > > larry@fogtest:~$ ssh -v lapdog2 > > OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Applying options for * > > debug1: Connecting to lapdog2 [192.168.2.124] port 22. > > debug1: connect to address 192.168.2.124 port 22: Connection timed out > > ssh: connect to host lapdog2 port 22: Connection timed out > > larry@fogtest:~$ ping -c 3 lapdog2 > > PING lapdog2 (192.168.2.124) 56(84) bytes of data. > > 64 bytes from lapdog2 (192.168.2.124): icmp_seq=1 ttl=64 time=0.587 ms > > 64 bytes from lapdog2 (192.168.2.124): icmp_seq=2 ttl=64 time=0.856 ms > > 64 bytes from lapdog2 (192.168.2.124): icmp_seq=3 ttl=64 time=0.996 ms > > > > --- lapdog2 ping statistics --- > > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > > rtt min/avg/max/mdev = 0.587/0.813/0.996/0.169 ms > > larry@fogtest:~$ > > > > Clearly the issue seems to be what is blocking communication to port 22 > even > > though sshd is listening on it, iptables seems to allow it and ufw was > > disabled yesterday and being enabled today seems to change nothing. > > > <> > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -- Dazed_75 a.k.a. Larry The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive. - Thomas Jefferson