Subject: Re: Network blues.
To: Stefan Voss <voss@yoda.in-berlin.de>
From: Ib-Michael Martinsen <imm@nethotel.dk>
List: port-arm32
Date: 10/25/1998 16:07:27
Stefan Voss writes:

 > > /etc/resolv.conf
 > > domain	dk
 > 
 > Shouldn't this line read "domain nethotel.dk"? Is nethotel.dk the domain
 > of your provider or is it your own domain?

You are right, nethotel.dk is the domain of my provider, but I also
use it as my own domain. This was the easiest way to set up the
correct mail address in my outgoing mail. I suppose this could also
be setup by sendmail or my mailer, but I have not bothered to look.
Also I am not aware of my use of nethotel.dk as my own domain causes
any other troubles.

 > > lookup	file bind
 > > nameserver	193.162.146.9
 > > nameserver	193.162.153.131
 > > 
 > > and btw, I haven't got my nameserver running yet, does it mean that
 > > I should avoid 'lookup bind'?
 > 
 > No. /etc/resolv.conf is just the config file for the client part (e.g. the
 > gethostbyname() system call) of the name lookup service. The machines
 > 193.162.146.9 and 193.162.153.131 are running the server part
(named).

Yes. What I meant to say was: If I want to avoid the external
DNS-lookup, should I then drop the 'lookup bind' option or the
name-server addresses in resolv.conf?

 > > I have tried removing the bind option, but then I can not resolve any
 > > addresses not specified in /etc/hosts. According to the resolv.conf
 > > man-pages the order for name searching is specified with the lookup
 > > statement, but it does not appear to work as intended. It seems to
 > > me that my 'netstat -r' first makes a DNS-lookup, and when timed out
 > > it looks for the names in the /etc/hosts file. Shouldn't it have been
 > > the other way around?
 > > 
 > 
 > This might be caused by the domain entry in your /etc/resolv.conf. The
 > resolver routines append the domain to each name that is not fully
 > qualified. 

Should all names in /etc/hosts (and elsewhere) then be terminated with
the domain-name + "." (e.g nethotel.dk.)? or does it mean that any
name not ending with the (in resolv.conf) specified domain gets the
domain appended?

(trace excluded)

 > You are right. The above arp lines clearly show that you are connected to
 > the world. Two routers (192.168.80.254 and nethotel.dk) are asking for mac
 > addresses of attached machines. 192.160.80.254 is asking for mac addresses
 > for a bunch of machines and your machine (nethotel.dk) is asking for the
 > mac address of your gateway.
 > 
 > However there's something missing: There are no answers to the arp
 > requests. There should be lines saying "tt:vv:ww:xx:yy:zz is gateway". Can
 > you ping the address 192.168.80.254? If you can just use that address as
 > your gateway.

Unfortunately, I can not ping 192.168.80.254 either :-(

 > You could also try a different netmask. There are arp requests from
 > networks other than 192.168.89.0. The address part they have in common is
 > 192.168 so they might use a netmask 255.255.0.0 instead of 255.255.255.0.
 > Configure you ethernet card with netmask 255.255.0.0 and see if it makes
 > any difference. 

I tried that. It does not make any difference.

 > Apropos-help? Are you talking about makewhatis?

Yes, thanks a lot.

So I tried some (if not all) of your hints. This is a (short?) summary.
After boot of the system my routing table looked like

imm@riscpc: /home/imm => netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            gateway            UGS         0        0      -  em0
localhost          localhost          UH          0       26      -  lo0
192.168.89         link#1             UC          0        0      -  em0
riscpc             00:00:a4:11:57:d8  UHL         1       65      -  lo0
gateway            link#1             UHL         1        0      -  em0

AppleTalk:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
imm@riscpc: /home/imm => netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            192.168.89.254     UGS         0        0      -  em0
127.0.0.1          127.0.0.1          UH          0       40      -  lo0
192.168.89         link#1             UC          0        0      -  em0
192.168.89.234     00:00:a4:11:57:d8  UHL         1       65      -  lo0
192.168.89.254     link#1             UHL         1        0      -  em0

AppleTalk:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface

The arp cache was not complete, it showed:
root@riscpc:/root (14:04:58) => arp -a
riscpc.stofanet.dk (192.168.89.234) at 00:00:a4:11:57:d8 permanent
gateway (192.168.89.254) at (incomplete)

I noticed when doing an 'arp -a' from a PC that the cable modem has
two IP-addresses with the same Ethernet address. So to fill out the
cache I started 'routed -t' and executed a script containing:

arp -d 192.168.89.2
arp -s 192.168.89.2 52:54:ab:dd:2c:10 pub      (This is for a PC: pc.dk)
arp -d 192.168.89.234
arp -s 192.168.89.234 00:00:a4:11:57:d8 pub    (This is my RiscPC)
arp -d 192.168.89.254
arp -s 192.168.89.254 00:10:4b:6f:8d:b0 pub    (The official gateway)
arp -d 192.168.80.254
arp -s 192.168.80.254 00:10:4b:6f:8d:b0 pub    (The alternative gateway2)
arp -a

-- 14:05:42 --
ignore RTM_GET: 192.168.89.0
-- 14:05:53 --
ignore RTM_GET: 192.168.89.0
arp: delete: can't locate 192.168.89.2
-- 14:05:53 --
ignore RTM_GET: 192.168.89.0
-- 14:05:54 --
RTM_ADD from pid 8951: 192.168.89.2/32
routed: ignore RTM_ADD without gateway
-- 14:05:54 --
ignore RTM_GET: 192.168.89.234/32
-- 14:05:54 --
RTM_DELETE from pid 8952: 192.168.89.234/32
192.168.89.234 (192.168.89.234) deleted
-- 14:05:54 --
ignore RTM_GET: 192.168.89.0
-- 14:05:54 --
RTM_ADD from pid 8953: 192.168.89.234/32
routed: ignore RTM_ADD without gateway
-- 14:05:54 --
ignore RTM_GET: 192.168.89.254/32
-- 14:05:54 --
RTM_DELETE from pid 8954: 192.168.89.254/32
192.168.89.254 (192.168.89.254) deleted
-- 14:05:54 --
ignore RTM_GET: 192.168.89.0
-- 14:05:55 --
RTM_ADD from pid 8955: 192.168.89.254/32
routed: ignore RTM_ADD without gateway
-- 14:05:55 --
ignore RTM_GET: 0.0.0.0 --> 192.168.89.254
-- 14:05:55 --
ignore RTM_GET: 0.0.0.0 --> 192.168.89.254
arp: delete: can't locate 192.168.80.254
-- 14:05:55 --
ignore RTM_GET: 0.0.0.0 --> 192.168.89.254
cannot intuit interface index and type for 192.168.80.254
pc.dk (192.168.89.2) at 52:54:ab:dd:2c:10 permanent published
riscpc.stofanet.dk (192.168.89.234) at 00:00:a4:11:57:d8 permanent published
gateway (192.168.89.254) at 00:10:4b:6f:8d:b0 permanent published

Hereafter my routing table looked like:
root@riscpc:/root (14:05:56) => netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            gateway            UGS         1        3      -  em0
localhost          localhost          UH          0       42      -  lo0
192.168.89         link#1             UC          0        0      -  em0
192.168.89.2/32    52:54:ab:dd:2c:10  ULS2        0        0      -  em0
192.168.89.234/32  00:00:a4:11:57:d8  ULS2        0        0      -  lo0
192.168.89.254/32  00:10:4b:6f:8d:b0  ULS2        0        0      -  em0

AppleTalk:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface

What does the /32 after the IP-addresses mean?
And why are the names replaced with numbers?

Now pinging gateway once and logging IP-traffic with 'tcpdump host riscpc'
showed:

root@riscpc:/root (14:11:05) => ping -c 1 gateway
PING gateway (192.168.89.254): 56 data bytes

----gateway PING Statistics----
1 packets transmitted, 0 packets received, 100% packet loss

While pinging this message showed up at the xconsole (/var/log/messages):

Oct 25 14:36:42 riscpc /netbsd: arplookup: unable to enter address for c0a850fe

The tcpdump output showed:

14:36:42.339609 riscpc.stofanet.dk gateway2 ip 98: riscpc.stofanet.dk > gateway: icmp: echo request (ttl 255, id 6250)
			 4500 0054 186a 0000 ff01 6e05 c0a8 59ea
			 c0a8 59fe 0800 bf4b 1323 0000 6a29 3336
			 982e 0500 0809 0a0b 0c0d 0e0f 1011 1213
			 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
			 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
			 3435 3637
14:36:42.379616 gateway2 Broadcast arp 60: arp who-has riscpc.stofanet.dk tell gateway2
			 0001 0800 0604 0001 0010 4b6f 8db0 c0a8
			 50fe 0000 0000 0000 c0a8 59ea 0000 0000
			 0000 0000 0000 0000 0000 0000 0000
14:36:42.379617 riscpc.stofanet.dk gateway2 arp 60: arp reply riscpc.stofanet.dk is-at riscpc.stofanet.dk
			 0001 0800 0604 0002 0000 a411 57d8 c0a8
			 59ea 0010 4b6f 8db0 c0a8 50fe 0000 0000
			 0000 0000 0000 0000 0000 0000 0000
(The ARP-request/reply sequence repeats 2 times)

To me this indicates the routing table is ok, the ping reaches the
gateway, but for some unknown reason gateway2 has to reply and can
not do so, because it does not know the Ethernet address of the
riscpc, and it does not react on the ARP-reply from riscpc.

Before pinging gateway2 I would make sure that riscpc knows the
Ethernet address of gateway2 and did a new arp -s of gateway2,
it showed:

root@riscpc:/root (14:41:28) => arp -s 192.168.80.254 00:10:4b:6f:8d:b0 pub
-- 14:45:10 --
ignore RTM_GET: 0.0.0.0 --> 192.168.89.254
cannot intuit interface index and type for 192.168.80.254

Pinging gateway2 showed:

root@riscpc:/root (14:48:29) => ping -c 1 gateway2
PING gateway2 (192.168.80.254): 56 data bytes

----gateway2 PING Statistics----
1 packets transmitted, 0 packets received, 100% packet loss

And again while pinging the following message appeared on the
xconsole (/var/log/messages)

Oct 25 14:49:14 riscpc /netbsd: arplookup: unable to enter address for c0a850fe

Hence the tcpdump was more or less the same as when I pinged gateway:

14:49:14.059400 riscpc.stofanet.dk gateway2 ip 98: riscpc.stofanet.dk > gateway2: icmp: echo request (ttl 255, id 6295)
			 4500 0054 1897 0000 ff01 76d8 c0a8 59ea
			 c0a8 50fe 0800 bccc 2a23 0000 5a2c 3336
			 98aa 0000 0809 0a0b 0c0d 0e0f 1011 1213
			 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
			 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
			 3435 3637
14:49:14.072626 gateway2 Broadcast arp 60: arp who-has riscpc.stofanet.dk tell gateway2
			 0001 0800 0604 0001 0010 4b6f 8db0 c0a8
			 50fe 0000 0000 0000 c0a8 59ea 0000 0000
			 0000 0000 0000 0000 0000 0000 0000
14:49:14.072627 riscpc.stofanet.dk gateway2 arp 60: arp reply riscpc.stofanet.dk is-at riscpc.stofanet.dk
			 0001 0800 0604 0002 0000 a411 57d8 c0a8
			 59ea 0010 4b6f 8db0 c0a8 50fe 0000 0000
			 0000 0000 0000 0000 0000 0000 0000
(The ARP-request/reply sequence repeats 3 times)


I do not have the slightest idea of why gateway2 refuses to reply :-(

Best regards
   Ib-Michael
-- 
Ib-Michael Martinsen		Email at work: dtpimm@dsg.dk
Fidomail:      2:234/181.9	Email at home: imm@nethotel.dk

Running NetBSD/arm32 v1.3.2 on an Acorn RiscPC with a 202MHz StrongArm.