🚀 go-pugleaf

(We were working to resolve this issue quietly in calm, pleasant,
private discussions with SCO's tech support and developer relations
folks.  But since Mr. Berry's question in these forums seems to be
getting generally misunderstood, and since our fair name was getting
dragged into the fray, I felt the need to clarify what's happening.
To any SCO folks who may be listening in, please accept my apology for
dragging this out even longer in public.)

In article <1993Jan26.235915.6378@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes:
   In article <1993Jan26.165229.12678@ennews.eas.asu.edu> berry@enuxha.eas.asu.edu (Joel R. Berry) writes:
      I have recently upgraded to 1.2 TCP/IP from SCO.  Much to my
      supprise when I installed ppp and tried to route our networks
      together it failed.  Apparently in the new release the routes
      can not route you from one net (or subnet) to another.  ...
      According to Morningstar the sco people say that it is a new
      FEATURE!

   Surprisingly, MorningStar is a little confused.

(Ummm, I think that's a compliment, right? :-)

   You can route, but this behavior is no longer enabled by default,
   in compliance with RFC 1122.  When you add a second interface the
   system will ask you if you want to enable gateway functionality.
   Tell it yes.

   If you've already done this but answered no, do the following:
	   /etc/conf/bin/idtune IPFORWARDING 1
	   /etc/conf/bin/idtune IPSENDREDIRECTS 1

He didn't ask how to turn his SCO TCP 1.2 system into a router, though
this is documented in the installation procedure for Morning Star PPP.
He wanted to add a route through the destination address of a
POINTOPOINT link, where the source and destination were not on the
same IP network or subnet.  This worked under SCO TCP 1.1.3, but no
longer works under SCO TCP 1.2.  I'll append an example below.

In article <1k4d6oINN4ph@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:	
   It's not only a feature -- any system that *does* route packets by
   default is in violation of the Host Requirements RFC.

Right, but he didn't ask how to enable his system to route packets.
He asked how to enable it to route packets through the destination of
a POINTOPOINT link where the destination address is on a different IP
(sub)network than the source address.

   At any rate, SCO does support routing/gatewaying packets, but it
   needs to be explicitly turned on.

Right.

   I've never used Morningstar PPP, so it may not ask this question.
   If it doesn't (and if it doesn't, you should complain to
   Morningstar, since this is arguably a bug),

Our installation procedure doesn't use netconfig, because (as I
recall) netconfig couldn't be persuaded to be flexible enough to
understand what we were trying to tell it to do.

   ...then you'll have to manually edit /etc/conf/pack.d/ip/space.c
   and change the lines that read
	   #define IPFORWARDING 0
	   #define IPSENDREDIRECTS 0
   to
	   #define IPFORWARDING 1
	   #define IPSENDREDIRECTS 1

All this is also discussed in our installation README, and Mr. Berry
(being an unusual user who actually RTFMs :-) had already done it.


Here's an example of what most users of dial-up IP services want to do
with their systems:

/* first, a link to someplace else within our organization */
# pppd 137.175.19.5:137.175.19.44 netmask 0xffffff00 auto
#
/* now, a link to another network */
# pppd 137.175.88.107:192.5.58.18 auto
#
#
/* everything looks normal */
# ifconfig du0
du0: flags=51<UP,POINTOPOINT,RUNNING>
        inet 137.175.19.5 --> 137.175.19.44 netmask ffffff00
# ifconfig du1
du1: flags=51<UP,POINTOPOINT,RUNNING>
        inet 137.175.88.107 --> 192.5.58.18 netmask ffff0000
# netstat -i
Name   Mtu   Network     Address       Ipkts   Ierrs Opkts   Oerrs Collis
wdn0   1500  137.175.2   conch         10232   0     5320    54    33
lo0    2048  loopback    localhost     754     0     754     0     0
du0    1500  137.175.19  137.175.19.5  0       0     0       0     0
du1    1500  137.175     137.175.88.10 0       0     0       0     0
# netstat -rn
Routing tables
Destination      Gateway            Flags    Refs     Use  Interface
127.0.0.1        127.0.0.1          UH          1        0 lo0
192.5.58.18      137.175.88.107     UH          0        0 du1
137.175.19.44    137.175.19.5       UH          0        0 du0
137.175.2        137.175.2.28       U           6     4364 wdn0
#
#
/* we can add a route through a link that stays within our subnet */
# route add default 137.175.19.44 1
add net default: gateway 137.175.19.44 flags 0x3
# route delete default 137.175.19.44
delete net default: gateway 137.175.19.44 flags 0x1
#
/* but we can't add a route through an IP vendor's connection point */
# route add default 192.5.58.18 1
add net default: gateway 192.5.58.18 flags 0x3: Network is unreachable
#

I can't point my default route through a router that's part of a
different network.  How else am I supposed to connect my network with
PSInet or AlterNet or BARRnet or any of the others?

A major part of the frustration is that, as Mr. Berry noted, this
worked fine under SCO TCP 1.1.3, as it does under every other UNIX and
UNIX-like operating system we've ever encountered.  My only solace is
that, since it's a problem in IP, this afflicts users of SCO's new PPP
product too, so maybe SCO will fix it for all of us :-)
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

In article <BOB.93Jan27184135@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>(We were working to resolve this issue quietly in calm, pleasant,
>private discussions with SCO's tech support and developer relations
>folks.  But since Mr. Berry's question in these forums seems to be
>getting generally misunderstood, and since our fair name was getting
>dragged into the fray, I felt the need to clarify what's happening.
>To any SCO folks who may be listening in, please accept my apology for
>dragging this out even longer in public.)

Thanks for the good explanation.  We'll pursue this via support as well.

>   Surprisingly, MorningStar is a little confused.
>
>(Ummm, I think that's a compliment, right? :-)

Absolutely.  I should have known there was more to the picture than met
the eye :->

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@isc.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

In article <BOB.93Jan27184135@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
      In article <1993Jan26.165229.12678@ennews.eas.asu.edu> berry@enuxha.eas.asu.edu (Joel R. Berry) writes:
	 I have recently upgraded to 1.2 TCP/IP from SCO.  Much to my
	 supprise when I installed ppp and tried to route our networks
	 together it failed.  Apparently in the new release the routes
	 can not route you from one net (or subnet) to another.

   He wanted to add a route through the destination address of a
   POINTOPOINT link, where the source and destination were not on the
   same IP network or subnet.  This worked under SCO TCP 1.1.3, but no
   longer works under SCO TCP 1.2.  ...  I can't point my default
   route through a router that's part of a different network.  How
   else am I supposed to connect my network with PSInet or AlterNet or
   BARRnet or any of the others?  ...  My only solace is that, since
   it's a problem in IP, this afflicts users of SCO's new PPP product
   too, so maybe SCO will fix it for all of us :-)

SCO has provided a fix for this problem.  Either contact them through
your normal support channels for "SLS net363", or get
ftp.morningstar.com:pub/tools/SCO-route-fix.  Thanks to SCO for their
prompt attention to this matter.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)