rbj@icst-cmr.arpa (Root Boy Jim) (09/24/87)
It appears that the problem is that the Vax (and the PCs) have internet
addresses 126.1.0.*, whereas the Sun (and its client) have addresses
192.9.200.*. (These aren't properly assigned internet addresses, but we
aren't connected to the internet.) It appears that both the Sun and Vax
believe that all hosts on a single Ethernet have the first three parts of
their addresses the same. Thus, the Sun refuses to put packets on the net
for addresses other than 192.9.200.*, and the Vax refuses to put packets
on the net for addresses other than 126.1.0.*. Thus, the Sun and Vax
can't talk to each other, and a PC can talk to only one of the two at a
time (depending on the address that the PC is set to respond to).
There seem to be two possible solutions:
1. Change the addresses of the Sun (and its client diskless Sun) to
126.1.0.* addresses.
2. Get the Sun and the Vax to understand that both sets of addresses are
physically on the same Ethernet. (Since they are both BSD 4.2 versions,
the same fix should work for both.)
Well, that reminds me of a war story. We went from a Class C net
(192.12.119.xx) to a Class B net (129.6.xx.xx), subnet 48.
We have Vaxen running 4.2 and 4.3, a Sequent running Dynix V2.0.1, and
various Sun-2's and Sun-3's running anything from 2.0 to 3.2.
Only 4.3 has the `netmask' parameter, altho I think it appeared in Sunix 3.4.
Everything seemed to work, except the 4.2 Vaxen. My first clue was when
netstat -r left off the chars enclosed in <<<>>> below:
Routing tables
Destination Gateway Flags Refcnt Use Interface
127.0.0.1 127.0.0.1 UH 1 157 lo0
129.6.48.154 127.0.0.1 UH 0 3655 lo0
default 129.6.48.1 UG 0 10781 il0
129.6<<<.48>>> 129.6.48.154 U 2 151992 il0
I figured it had something to do with Marxism (class struggle :-), and
found the specific code, in /sys/netinet/in.c. Fortunately, all we had to
do was #ifdef out an `if' clause of two. Our changes are only the `#' lines.
#define FORCE_CLASS_C 1
/*
* Formulate an Internet address from network + host. Used in
* building addresses stored in the ifnet structure.
*/
struct in_addr
if_makeaddr(net, host)
int net, host;
{
u_long addr;
if (net < 128)
addr = (net << IN_CLASSA_NSHIFT) | host;
#ifndef FORCE_CLASS_C
else if (net < 65536)
addr = (net << IN_CLASSB_NSHIFT) | host;
#endif
else
addr = (net << IN_CLASSC_NSHIFT) | host;
addr = htonl(addr);
return (*(struct in_addr *)&addr);
}
/*
* Return the network number from an internet address.
*/
in_netof(in)
struct in_addr in;
{
register u_long i = ntohl(in.s_addr);
if (IN_CLASSA(i))
return (((i)&IN_CLASSA_NET) >> IN_CLASSA_NSHIFT);
#ifndef FORCE_CLASS_C
else if (IN_CLASSB(i))
return (((i)&IN_CLASSB_NET) >> IN_CLASSB_NSHIFT);
#endif
else
return (((i)&IN_CLASSC_NET) >> IN_CLASSC_NSHIFT);
}
/*
* Return the host portion of an internet address.
*/
in_lnaof(in)
struct in_addr in;
{
register u_long i = ntohl(in.s_addr);
if (IN_CLASSA(i))
return ((i)&IN_CLASSA_HOST);
#ifndef FORCE_CLASS_C
else if (IN_CLASSB(i))
return ((i)&IN_CLASSB_HOST);
#endif
else
return ((i)&IN_CLASSC_HOST);
}
Originally, we tried always forcing Class C, but it turns out there *is*
one Class A address we're interested in: 127.0.0.1, AKA localhost.
Interestingly enuf, it seems that Sunix and Dynix do this also (we don't
have Sun source; we do have Dynix, but it's offline so I can't check).
Thus, these systems DO THE RIGHT THING FOR THE WRONG REASON!!! They
seem to be FORCING CLASS C MODE!!! The reason it's the right thing to do
is that people seem to run on subnets anyway. I don't know what the
gateway does, or how it's set up, but it's a Vax 750 running 4.3.
But to get back to the original poster's question, my recommendation
would be to run your network on a Class C net. That is, the first
number should be 192 or higher, change the Vax and the PC's to use
the same network number as the Suns. Comments anyone?
Apologys to those of you who have to see this twice, but I wanted a wider
audience. Special apologys to Chris and my bro, who have to see it three
times, and to Bill Majurski (also of NBS), who had to live thru it.
Dale Worley Cullinet Software
ARPA: cullvax!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
I'll show you MY telex number if you show me YOURS...ron@topaz.rutgers.edu.UUCP (09/24/87)
The best bet is to change the address of one machine
to match the other. This is the way it normally is.
I'd avoid the use of the 126.xx.xx.xx number.
If you really need to have two different net numbers on
the same cable try...for example:
Machine A (address) 192.2.2.1
Machine B (address) 128.8.8.1
(both on the same cable)
on Machine A:
route add 128.8.8.0 192.2.2.1 0
and on machine B
route add 192.5.5.0 128.8.8.1 0ted@braggvax.arpa (09/25/87)
This works with two different class C nets on one ethernet, haven't tried it with a class C and a class B, but: Suppose you have two machines, one is 192.5.92.1, the other 192.5.121.1 Now, if you put these on the same physical ethernet, they will be unable to talk, unless you do on the 192.5.92.1 machine route add 192.5.121.0 192.5.92.1 0 and on the 192.5.121.1 machine route add 192.5.92.0 192.5.121.1 0 This works with SunOS 1.X and 2.X and 4.3BSD (presumably works on all BSD offshoots). Naturally you can use hostnames instead of numbers. It's nice for short vsitations of "foreign" machines to an ethernet, but in the long-run you probably want everything on the same logical net. Ted Nolan ted@braggvax.arpa
hedrick@topaz.rutgers.edu (Charles Hedrick) (09/27/87)
I'm not sure why people responded to this question again, since you just quoted it on order to make another point, but let me point out that the answers given by both ron and ted, although generally correct, would leave someone with an incorrect idea of how to cause his machine to talk to net 126. The correct way is route add 126.0.0.0 <youraddress> 0 where <youraddress> is your machine's own Internet address. Ron's example used route add 128.8.8.0 ... which treated a class B network (128.8) as if it were class C. Ted's message (1) gave examples only for class C nets, and (2) stated that 126 was a class B address, when it is actually class A. I assume this is all a matter of typos. I'm sure that these people all know what the classes are. But for those who don't: these is no network 0. Addresses beginning with 0 are reserved for use by machines that don't know their own address. networks 1 through 126 are "class A". They are designed for commerical networks or very large companies, who need 3 bytes to describe their internal networks. Addresses are of the form 10.1.0.89 where 10 is the network number, and 1.0.89 designates the specific host. (By the way, network number 126 is reserved for use by the Central University of Mars, for which reason packets that escape into the Arpanet with addresses on net 126 are referred to as "Martians". By analogy, this term is also used for all packets containing unauthorized or inappropriate addresses. A "Martian filter" is a software test for testing for and rejecting inappropriate addresses.) network 127 is also class A, but is reserved for use by the "loopback" interface. networks 128.1 through 191.254 [note that there is no 128.0, and I trust there will be no 191.255, to avoid confusion] are class B. They are typically used by fairly large universities and companies, who need 2 bytes to describe their internal networks. Addresses are of the form 128.6.4.194 where 128.6 is the network number and 4.194 designates the specific host on that network. networks 192.1.1 through 223.254.254 are class C. These are designed for single departments or small organizations, for which 254 possible addresses is enough. (As usual, 0 and 255 are not used.) Addresses are of the form 192.12.88.3 where 192.12.88 is the network number and 3 designates the specific host on that network. addresses beginning with 224 through 254 are reserved for "class D" and "class E", which are currently not defined. It is common for software to treat all addresses 192 and above as class C. Properly speaking, addresses between 224 and 254 should be treated as Martian. addresses beginning with 255 are reserved for use as broadcast addresses. In the "route add" command (or other commands), where a "network number" is wanted, you must give an address which has 0's filled in for the host portion. E.g. to specify network 128.6, you would use 128.6.0.0. For network 126, you must use 126.0.0.0. If you use 126.8.8.0, it will look like a specific host, and you will get a "host route", which is not at all what you want. These rules can be changed by using the "subnet mask" command in ifconfig, but I am assuming, based on the obvious unsophistication of the original question, that this was not being done.
forys@sigi.Colorado.EDU (Jeff Forys) (09/27/87)
> addresses beginning with 224 through 254 are reserved for "class D" > and "class E", which are currently not defined. It is common > for software to treat all addresses 192 and above as class C. I believe the "Class D" addresses (224-239) have been reserved for "host groups" (for hosts that support IP multicasting). If you dont support it, your host should silently discard these "Class D" IP datagrams. "Class D" addresses then, become dyamically `bound' to a set of interfaces, on a set of IP nets (the point is, that a "Class D" address isnt bound to a set of unicast IP addrs). For more information on IP multicast extensions, consult RFC 988 (Steve Deering/Stanford). He is also working on mods to 4.3BSD to support these extensions (currently ftp'able from "gregorio.stanford.edu"). --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991) forys@boulder.Colorado.EDU -or- ..!{hao|nbires}!boulder!forys