Subject: Re: SLIP packet routing problems
To: Brett Lymn <blymn@awadi.com.AU>
From: Stephen Champion <steve@herb.kuru.com>
List: netbsd-help
Date: 03/17/1995 01:20:03
> According to Steven Vetzal:
>
> >For example, from the SL/IP'd system (I'll say remote host) I can ping 
> >204.191.16.2 (my NetBSD Box), 204.191.16.9 (the NetBSD end of the SL/IP), 
> >but that's about it. I can't ping the router at 204.191.16.1 or the bridge
> >at 204.191.16.253. The netmasks are all set for 255.255.255.0...
> 
> OK now we are getting somewhere.  The next thing to check is if the
> routers know that to get to your NetBSD box they need to use
> 204.191.16.9 as the gateway.  I would guess that the router just sees
> the machine 204.191.16.2 on the same subnet and blasts the packet out
> the correct interface when it should be forwarding the packet to
> 204.191.16.9 to be sent down the SL/IP interface.  What you need to do
> is:
> 
>  a) update the router's routing tables to define 204.191.16.9 to be
>     the gateway for 204.191.16.2 
> 
> OR b) put 204.191.16.2 on an unallocated
>       subnet and tell the router that 204.191.16.9 is the gateway for
>       that subnet.
> 
> If you do not have control of the router then you are more or less
> stuck :-(
>
> -- 
> Brett Lymn, Computer Systems Administrator, AWA Defence Industries

	Something being completely misunderstood here is that in this case, 
the NetBSD-i386 is the SLIP server and is on the local net, and the slip 
client is Windows.

	Still, the idea is correct - to get to the SLIP host, the 
router(s) must know that the client's gateway is the server, and this 
can be achieved by changing tables or subnetting and changing tables.  I 
missed that part when I was trying to help earlier.

	What I'm wondering about is that in the scripts Steven posted 
earlier, slattach was missing.  Is slattach not needed on the server 
side of a SLIP link?
	If it wasn't there, and it is needed, how did he get so 
far as to ping the NetBSD server from the client without it?

-- 
//  Stephen Champion                   Software Eng, *ix Admin, OS Design
//  schampion@hampshire.edu            Hampshire College - Amherst, MA
//  steve@herb.kuru.com                Amiga 3000/25    NetBSD 1.0
#define Disclaimer "This product is completely without warranty."