Ib-Michael Martinsen writes:
 > 
 > Recently I decided to switch ISP from a telephone to a cable-network
 > based ISP, allthough I knew that the new ISP do not offer support
 > for anything else than PC's and Macs (just as the old one do).
 > 
 > The connection takes place through a black box labeled COM21,
 > modelno. CP1100D. I do not know what kind of device it is, my
 > ISP calls it a cable modem.

And there's no configuration needed for this device? If it's running
e.g. PPP over some lower level protocol configuration might be
neccessary for authentication and dialing (if there is some sort of
dialing). There should also be some way of configuring the ethernet
interface of the cable modem. I assume this cable modem works like a
ISDN router. I.e. it has an ethernet interface and an interface to
your provider. The interface to your provider can be set up
dynamically but the ethernet side needs to be configured statically
because it is your RiscPC's default gateway.

 > 
 > I was given the following IP-information:
 > ip-address:		192.168.89.234
 > network-address:	192.168.89.0
 > gateway:		192.168.89.254

No address for a name server?

 > 
 > so I made the following network configuration:
 > 
 > /etc/myname:
 > riscpc.stofanet.dk
 > 
 > /etc/defaultdomain:
 > stofanet.dk
 > 
 > /etc/mygate:
 > gateway

You could try using the ip address (192.168.89.254) instead of a name here.

 > 
 > /etc/hosts:
 > 127.0.0.1		localhost localhost.stofanet.dk
 > 192.168.89.234		riscpc.stofanet.dk	riscpc
 > 192.168.89.254		gateway
 > 
 > /etc/ifconfig.em0:
 > inet riscpc.stofanet.dk  

Likewise. Try using an ip address.

 > 
 > 
 > After booting NetBSD/arm32 v1.3a I can issue some commands:
 > 
 > 1998-10-15 19:12:53 # ifconfig -a
 > 1998-10-15 19:12:53 em0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 > 1998-10-15 19:12:53 address: 00:00:a4:11:57:d8
 > 1998-10-15 19:12:53 inet 192.168.89.234 netmask 0xffffff00 broadcast 192.168.89.255
 > 1998-10-15 19:12:53 lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32976
 > 1998-10-15 19:12:53 inet 127.0.0.1 netmask 0xff000000 
 > [...]
 > 
 > The next command executes very fast:
 > 1998-10-15 19:12:54 # route -vn show
 > 1998-10-15 19:12:54 Routing tables
 > 1998-10-15 19:12:55 
 > 1998-10-15 19:12:55 Internet:
 > 1998-10-15 19:12:55 Destination      Gateway            Flags 
 > 1998-10-15 19:12:55 default          192.168.89.254     UG     
 > 1998-10-15 19:12:55 127.0.0.1        127.0.0.1          UH     
 > 1998-10-15 19:12:55 192.168.89.0     link#1             U      
 > 1998-10-15 19:12:55 192.168.89.234   0:0:a4:11:57:d8    UH     
 > 1998-10-15 19:12:55 192.168.89.254   link#1             UH     
 > 
 > [...]
 > 
 > Likewise this command is pretty fast:
 > 1998-10-15 19:13:36 # netstat -rn
 > 1998-10-15 19:13:37 Routing tables
 > 1998-10-15 19:13:37 
 > 1998-10-15 19:13:37 Internet:
 > 1998-10-15 19:13:37 Destination        Gateway            Flags     Refs     Use    Mtu  Interface
 > 1998-10-15 19:13:37 default            192.168.89.254     UGS         0       46      -  em0
 > 1998-10-15 19:13:37 127.0.0.1          127.0.0.1          UH          0        0      -  lo0
 > 1998-10-15 19:13:37 192.168.89         link#1             UC          0        0      -  em0
 > 1998-10-15 19:13:38 192.168.89.234     00:00:a4:11:57:d8  UHL         1       89      -  lo0
 > 1998-10-15 19:13:38 192.168.89.254     link#1             UHRL        1       29      -  em0
 > 1998-10-15 19:13:38 
 > 1998-10-15 19:13:38 AppleTalk:
 > 1998-10-15 19:13:38 Destination        Gateway            Flags     Refs     Use    Mtu  Interface
 > 
 > but this one has a delay of more than 2 minutes after the 6th line:
 > 1998-10-15 19:13:38 # netstat -r
 > 1998-10-15 19:13:38 Routing tables
 > 1998-10-15 19:13:39 
 > 1998-10-15 19:13:39 Internet:
 > 1998-10-15 19:13:39 Destination        Gateway            Flags     Refs     Use    Mtu  Interface
 > 1998-10-15 19:13:39 default            gateway            UGS         0       46      -  em0
 > 1998-10-15 19:13:39 localhost          localhost          UH          0        0      -  lo0
 > 1998-10-15 19:16:19 192.168.89         link#1             UC          0        0      -  em0
 > 1998-10-15 19:16:19 riscpc             00:00:a4:11:57:d8  UHL         1       89      -  lo0
 > 1998-10-15 19:16:19 gateway            link#1             UHRL        1       29      -  em0
 > 1998-10-15 19:16:19 
 > 1998-10-15 19:16:19 AppleTalk:
 > 1998-10-15 19:16:19 Destination        Gateway            Flags     Refs     Use    Mtu  Interface
 > 
 > In the above listing I can decipher the 1st line (default) as the the default
 > route, the 2nd line as the standard loopback definition and the 4th as my host
 > definition.
 > 
 > But why are the 3rd and 5th line present?
 > I did not define any net or gateway routes.

This done during the interface configuration at boot time. I think
there's at least one route for every interface that is defined. Have a 
look at /etc/netstart (or is it /etc/network)

 > 
 > Why is the gateway definition marked as unreachable (flag=R)?

Your etherm card probably has no connection to the cable modem's
interface. The cable modem's interface could e.g. be configured for a
different ip address. What output do you get when doing an

   arp -a


 > 
 > What does the link#1 mean?
 > 
 > And why does it take so long to display a netstat -r by names?

My guess is that the name lookup tries to contact your name server,
runs on a timeout and then tries a name lookup by using /etc/hosts.

I am not at my NetBSD box atm so I cannot have a look (nor can I
remember) how the lookup order is handled in NetBSD. Isn't there an
"order" keyword in /etc/resolv.conf or /etc/host.conf? At least
that's how lookups are handled under Linux. The default order without
an order directive is

1. name server
2. /etc/hosts

To use /etc/hosts first (which makes sense during network
configuration when a connection to a name server isn't available)
there should be the following line in /etc/resolv.conf or /etc/host.conf

   order files,bind
or
   order files bind

"man gethostbyname" or "man resolv.conf" should give to a hint about
the exact syntax and file.


 > Do I have a loop-definition somewhere?

I don't think so. The above looks ok for me.

 > 
 > 
 > Appearently I have made a setup-blunder somewhere as I cannot ping the
 > gateway nor any other addresses on the Internet (the net on the other
 > side of the cable modem).

Can you ping your own interface (192.168.89.234)?
>From the output of the above commands I'd expect it to work. If your
own interface actually works then the next step is to try to ping the
gateway.

 > 
 > The ping gateway returns:
 > 1998-10-15 19:16:20 # ping gateway
 > 1998-10-15 19:16:20 PING gateway (192.168.89.254): 56 data bytes
 > 1998-10-15 19:16:27 ping: sendto: Host is down
 > 1998-10-15 19:16:28 ping: sendto: Host is down
 > 1998-10-15 19:16:29 ping: sendto: Host is down
 > 1998-10-15 19:16:30 ping: sendto: Host is down
 > 1998-10-15 19:16:31 ping: sendto: Host is down
 > 1998-10-15 19:16:31 ^C
 > 1998-10-15 19:16:32 ----gateway PING Statistics----
 > 1998-10-15 19:16:32 11 packets transmitted, 0 packets received, 100% packet loss

So the name lookup works but it looks like your gateway is down.

 > 
 > 
 > Before anyone suggest my hardware may be faulty I can say that I tested
 > the cable modem with a PC, and it worked flawlessly. But during boot of
 > NetBSD/arm32 I have noticed, that when booting and the RiscPC is 
 > connected to a PC the boot messages show:
 > 
 > Oct  8 18:02:02 nethotel /netbsd: em0 at podulebus0 [ netslot 0 ]:
 > Oct  8 18:02:02 nethotel /netbsd: em0: Ethernet address 00:00:a4:11:57:d8
 > Oct  8 18:02:02 nethotel /netbsd: em0: 16KB buffer memory, UTP
 > 
 > OK, the PC might have been turned off at time of NetBSD boot. But when
 > booting with the RiscPC connected to the cable modem, I get:
 > 
 > Oct 17 13:31:32 riscpc /netbsd: em0 at podulebus0 [ netslot 0 ]:
 > Oct 17 13:31:32 riscpc /netbsd: em0: Ethernet address 00:00:a4:11:57:d8
 > Oct 17 13:31:32 riscpc /netbsd: em0: 16KB buffer memory, UTP reverse polarity, link OK, UTP
 > 
 > Is the reverse polarity the cause of the troubles?
 > I am using an Atomwide RiscPC EtherM card.

I don't think so. It seems that the arm32 driver is just a little
more verbose that the i386 driver.

 > 
 > If anybody cares to answer then please do so by email, as it is
 > currently impossibly for me to download news using my current
 > telephone-based ISP.
 > 
 > Best regards
 >    Ib-Michael

Regards,
   Stefan Voss

-- 
Stefan Voss
(voss@yoda.in-berlin.de)