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
<
plug-discussion@stcaz.net>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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST> 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.
>
> <<SNIPSNIPSNIP>>
> > 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.
> >
> <<SNIPSNIPSNIP>>
>
>
> ---------------------------------------------------
> 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
---------------------------------------------------
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
(text/plain)