Cannot ssh out of NN to another machine on my LAN. Other direction works fine.

[Delbert Franz]

On Thu, 13 Sep 2012 10:39:50 +0200
David Kuehling <dvdkhlng at gmx.de> wrote:

> >>>>> "Delbert" == Delbert Franz <ddf at sonic.net> writes:
> 
> > Have another thing I cannot get to work on the NN.  I can ssh to the
> > NN from other computers in my network.  However, so far, I have not
> > been able to ssh from the NN to any other machine in the network.
> > Note: I am not using dropbear but openssh-server and openssh-client.
> > Those seem to work better with Git in my limited experience.  The
> > message I get back on the NN when I try to ssh to a host on my LAN is:
> 
> > ssh: connect to host <whatever> port 22: Connection timed out.
> 
> How is you usb0 network configured?  Is it bridged to the LAN?  Or is it
> merely routed?  How are your routing tables set up at the hosts in
> question?  Are you employing NAT somewhere on the route to/from the
> nanonote?  Can you ping the other hosts?  Have the other hosts an ssh
> server installed (and no firewall interfers)?
> 
> cheers,
> 
> David

David, 

Thanks for the quick reply.  I and my wife of nearly 46 years, took a 
day off yesterday and spent it on Angel Island in San Francisco Bay 
exploring the old Immigration Station which is partially restored.  It 
was active from 1910-1940 and has a rather sorry history, with its 
main purpose being to keep immigrants from China OUT, based on a law 
passed in 1882.  Different era, different issues and values.  Besides 
the weather here is gorgeous.  I enjoy working with computers but the 
outdoors is nice too:-)  

Anyway, I apologize for firing something off without the supporting 
information.  After sending out my "appeal" I switched back to my old 
micro SD install, VERSION: 2011-08-27, of more than one year ago ( I 
tend to wait a bit before upgrading to a new version.).  It did ssh to 
my other computers on the LAN  with no problems.  
 
So late last night, when I couldn't sleep, I started the process of 
finding out what was the cause of the failure now but success before.  
I first made sure that /etc/config/network was identical in both, then 
that /etc/ssh/ssh_config and /etc/ssh/sshd_config were also identical.  
Still no good: the latest image could not ssh nor scp but it could
ping to the names on my LAN.   
 
I then did some fiddling with updating the authorized_keys files on 
both computers but that made no difference.  Then, I noticed something 
that I had overlooked: when I pinged from the NN to my other LAN 
machines, the IP addresses were wrong.  They were all WAN addresses.  
Then my foggy grey matter recalled: "I have seen this before!" There 
is a problem with DNS in the /etc/config/network file!  

Here is that file, as I had it on both versions:

# Copyright (C) 2006 OpenWrt.org

config interface loopback
	option ifname	lo
	option proto	static
	option ipaddr	127.0.0.1
	option netmask	255.0.0.0

config interface lan
	option ifname	usb0
	option proto	static
	option ipaddr	192.168.254.101
	option netmask	255.255.255.0
	option gateway  192.168.254.100
#	option dns      "192.168.1.1"
	option dns      "192.168.1.1 208.67.222.222"

Notice that the active "option dns" line has two IP's: first a local 
DNS for my LAN and second a global DNS, opendns, for when I am not 
connected in my office.  
 
Under VERSION: 2011-08-27, DNS IP's would be accessed in order from 
left to right.  So, if I was in my office, 192.168.1.1 would give the 
proper addresses on my LAN.  Outside my office, 192.168.1.1, would 
fail to know anything about the machines on my LAN, and 208.67.222.222 
would be used.  

Here is the part that I overlooked earlier, that is, every one of my 
machine names yields a valid WAN address via 208.67.222.222!  One of 
my machines is named "ac" and on the latest image on the NN the above 
"option dns" will get some other machine somewhere in the world!  
Usually when I ping, I don't look at the IP address returned, I just 
look at there being a response.  That appears to be a bad idea.  

Then the task was to find out what was wrong in the latest image with 
the old "option dns" line.  I must say, the documentation for the 
network file has some points that should be expanded.  
http://wiki.openwrt.org/doc/uci/network, the most detailed discussion 
I found on my search, describes the "option dns" in this fashion: 

Name	 Type	                 Required	 Default	 Description
dns	 list of ip addresses	 no	       (none)	   DNS server(s)

However, I found no discussion of how the "list of ip addresses" 
should by set up.  It may be someplace else on the wiki but I could not 
find it.  I also could not find cases with more than one IP address in 
any example in the above wiki page or elsewhere on the web.  

After a bit of trial and error, it appears that just reversing the 
order of the IP addresses in the "option dns" gives me what works in 
the latest image.  So the network file that works for the latest image 
is: 

# Copyright (C) 2006 OpenWrt.org

config interface loopback
	option ifname	lo
	option proto	static
	option ipaddr	127.0.0.1
	option netmask	255.0.0.0

config interface lan
	option ifname	usb0
	option proto	static
	option ipaddr	192.168.254.101
	option netmask	255.255.255.0
	option gateway  192.168.254.100
#	option dns      "192.168.1.1"
	option 'dns'      '208.67.222.222 192.168.1.1'

Notice that I have used single quotes here: both double and single 
work.  Also, all the examples in the above references wiki page, show 
the use of single quotes for all responses.  For example, instead of 

option proto static

it would be

option 'proto'  'static'

However, I don't recall there being any quotes at all in the network 
file as it comes in the latest or any earlier version for the NN.  
Apparently they are optional.  

So the root cause of my problem was that the order of using DNS IP's has 
changed and the related cause, was my failure to notice that the ping 
responses to my LAN machines were giving WAN IP addresses and not my 
LAN IP addresses.  

Everything is working now-I can ssh to any machine on my LAN.  I also 
put in an invalid dns IP for my LAN and I could still ping to machines 
outside my LAN.  So it seems clear that the addresses are now used in 
right to left order.  

Hope this helps some one else, after all the dead ends I encountered.  
The major conclusion is: LOOK at the IP address returned by a PING.  
It just might have a WAN value instead of a LAN value.  I have no idea 
why a two letter machine name makes sense to a global DNS but it 
apparently does:-) 


   Delbert