[NCLUG] setting up wireless to use dns

[Bob Proulx]

Daniel Herrington wrote:
> Also, you mentioned Stephen, but I never saw his post. Maybe my spam
> filter is a little too aggressive.

Stephen, myself and Sean were talking about tcpdump.

> Here's my /etc/network/interfaces file (with the key X'ed out):
> 
> # Configure Loopback
> auto lo
> iface lo inet loopback
> 
> iface wlan0 inet dhcp
>         wireless_essid mywifi
>         wireless_key [1] XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XX
> 
> iface eth0 inet dhcp

Looks okay.

> Here's my /etc/hosts (only one line):
> 
> 127.0.0.1       localhost

I think it is also useful to have the following:

127.0.0.1       localhost
127.0.1.1       yourhostname.yourdomainname	yourhostname

But that is probably not related at the moment.

> Here's the result of the ping command:

I would have believed you if you had simply said that it worked. :-)

> >Can you from another host on the network look up domain names using
> >that dns server?

This would have proved that there really was a dns server on that
address.

> I didn't have the "host" command, so after copying that from my  
> desktop machine to the embedded one (and the necessary libraries), I  
> get the following:

You could have simply run it from your desktop.  As I said, "another
host on the network", and that would have shown that the IP address
was responding as a dns server.

> ~]# host www.google.com 192.168.1.1
> Using domain server:
> Name: 192.168.1.1
> Address: 192.168.1.1#53
> Aliases:
> 
> www.google.com is an alias for www.l.google.com.
> www.l.google.com has address 72.14.253.147
> www.l.google.com has address 72.14.253.99
> www.l.google.com has address 72.14.253.103
> www.l.google.com has address 72.14.253.104

Looks good.  It appears taht it is responding.  So there really is a
dns server on 192.168.1.1 and it is answering queries.

I did not expect you to copy that over from your desktop to the
embedded system.  But now that you have try it in the simple way
without targetting the dns server.  Have it read the nameserver from
/etc/resolv.conf like a normal program.

  host www.example.com

If that works then really dns is working on your system.

> >  dig example.com @192.168.1.1 +short
> 
> Again, I didn't have "dig" installed, so after installing it, I get  
> the following:

The host command showed everything that was important.  As I said "Or
you may need to use one of the other ways" meaning that only one of
those were needed.  All of those commands basically provide the same
information.  Only one of them was needed.

Darn I was really hoping that running that command from your desktop
would show that it was not running a dns server and since it was from
your desktop it would also disprove that there was anything wrong with
your embedded system.  Oh well.  Nothing ventured, nothing gained.

> >  nslookup example.com 192.168.1.1
> 
> My "nslookup" and "ping" are both just links to busybox (v1.2.2).  
> Could that be my problem? How does busybox know to use a DNS server?
> 
> ~]# nslookup www.google.com 192.168.1.1
> *** Unknown host
> 
> nslookup: www.google.com: Unknown server error

Now that is interesting.  I would expect that busybox would read
/etc/resolv.conf the same as any other program.  (However the libc
resolver library code only reads it once when the program starts up.
If the file is changed after the program gets going this is not
detected.)  Could it be that busybox is not getting the nameserver
from /etc/resolv.conf as we are expecting?  Not sure but the above
info does not fit.

> I tried "wget" with the following result:

wget is no different from ping.  Both programs do dns lookups and then
perform other actions.

Unfortunately at this point I don't know what else to suggest.  The
best lead that I see here is that busybox's ping and nslookup both
fail while it appears that other commands successfully perform dns
lookups.  There may be a problem with busybox.

Bob