Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!hplabs!cae780!leadsv!excelan!chuck
From: chuck@excelan.UUCP (Chuck Kollars)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: connecting Internets?
Message-ID: <359@lalk.excelan.UUCP>
Date: 24 May 88 18:15:36 GMT
References: <8805210151.AA09745@ucbvax.Berkeley.EDU> <44@stanton.TCC.COM>
Reply-To: chuck@lalk.UUCP (Chuck Kollars)
Organization: Excelan Inc., San Jose, CA
Lines: 33

In <44@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes:
> ... The problem I have run into on a continuous basis is the situation 
>where, even though the packets are capable of being seen by all parties, 
>a host rejects a connection because (I think) the destination/source 
>pair are in a different 'subnet' ... Is there any way under legal TCP/IP 
>to get these blasted devices to talk to each other without buying a 
>hardware device such as a gateway or router? ...

If I understand your configuration correctly, you have one Class B
network running on one (very large MAC-bridged) cable, with no need of
subnetworking.  Yet some of your nodes act like they have
subnetworking enabled.  Just disable subnetworking on all your nodes.
Find the "address mask" or "subnetwork mask" or other such
configuration value on each node, and be sure it's set to the value 
that means 'no subnetworking' (probably all zeros).  
[ex:  ifconfig ie0 netmask 0]

Or, maybe you are intentionally using subnetworking and have some
subnetwork routers in your configuration.  But sometimes two different 
subnetworks in fact ride on the same cable.  In which case your 
question is how to have two IP networks on one cable.  For BSD and 
most BSD-derived implementations, the answer is to add a route entry 
for the "other" subnetwork with a metric of 0 hops.  Do this to every 
node.  The metric value 0 hops is interpreted to mean 'on the same 
cable'.  
[ex:  route add 129.253.2.0 129.253.0.99 0]

(Of course, the purist rule is "ONE IP (sub)network <-> ONE cable".  
So convince yourself that you don't have an address administration 
problem before you start hacking.)
-- 
Chuck Kollars,  Excelan, Inc.	mtxinu!excelan!chuck@ucbvax.Berkeley.COM
(chuck@excelan.UUCP)		...!{mtxinu,leadsv,cae780}!excelan!chuck