aaron@hkco.ahkcus.org (Aaron Y.T. Cheung) (01/10/91)
In article <1991Jan10.042828.29389@uniwa.uwa.oz> johng@uniwa.uwa.oz (John Gibbins) writes: | 1) When building, the make depend failed because slcompress defines | BCOPY ... Same thing encountered here (on a 3/160 running 4.1) but not much of a problem. | 2) Greg mentioned that the test for __sys_types_h in | <pixrect/pr_impl_util.h> is wrong. I agree, but I haven't been able to | connect this with ppp.c. From the name, "pixrect" sounds like it is | part of sunview. If so, why should it have anything to do with data | comms (especially as I don't even have a graphics monitor!). For those who didn't have /usr/include/pixrect installed, then instead of patch2's suggestion of + #ifdef sun + /* + * Get definition of SUNOS + */ + #include <pixrect/pr_impl_util.h> + #endif + you could replace the above lines by (assuming you're using SunOS 4.1): #define SUNOS 41 (ie, put it before the line #include "magic.h" in ppp.c.) /ac.
earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) (01/13/91)
In comp.protocols.tcp-ip, John Gibbins writes: >1) When building, the make depend failed because slcompress defines >BCOPY which has already been defined by machine/param.h (via >sys/param.h) because I am on a 3/260 running 4.1. Greg Earle >(earle@poseur.JPL.NASA.GOV) said he had run it on a 3/260 also running >4.1. (Did you have this problem Greg?) >The simple solution would seem to be to just #undef BCOPY before the >#define BCOPY in slcompress.c. Does this seem reasonable? Yes, I had this problem (see below). I did an #ifdef BCOPY #undef BCOPY #endif >2) Greg mentioned that the test for __sys_types_h in ><pixrect/pr_impl_util.h> is wrong. I agree, but I haven't been able to >connect this with ppp.c. From the name, "pixrect" sounds like it is >part of sunview. If so, why should it have anything to do with data >comms (especially as I don't even have a graphics monitor!). (a) "pixrect" may be the underlying graphics model that SunView is based on, but that is not germane here. (b) Where this file comes into play is that it contains a test which attempts to grok whether you're running under SunOS 3.x, 4.0.x, or 4.1/4.1.1. It just so happens that this file happens to be an include file which has to do with the pixrect code. It could be anything, really. >3) Are there any other things I should watch for during the installation >like adding #include "ppp.h" to str_conf.c (thanks to Robert McLay et al >for that warning)? Here's some additional data points, in addition to the overlap mentioned above Some of this has since been mentioned/dealt with: ------------------------------------------------------------------------------ Here's a quick executive summary of what to look out for once you've installed those 2 files (the original Clarkson PPP code and the OSU patches and extra scripts & goodies): (1) The Readme.streams file (instructions for installing under SunOS 4.x) neglects to mention in step (3) that one needs to put a `#include "ppp.h"' in /sys/sun/str_conf.c. (2) slcompress.c (which gets compiled into the kernel) contains a macro BCOPY definition (#define BCOPY ... ). If you have a Sun-3/260, some include file somewhere does a "#ifdef SUN3_260 ... #define BCOPY ... #endif" (so that some kernel code somewhere will notice that this machine has hardware bcopy assist). This causes a clash during the kernel build. (3) ppp.c has the following hack to get the SunOS release level: #ifdef sun /* * Get definition of SUNOS */ #include <pixrect/pr_impl_util.h> #endif ... # if defined(sun) && defined(SUNOS) && SUNOS >= 41 if (setsid() < 0) { perror("ppp: setsid()"); exit(1); } # else if (ioctl(fd, TIOCSPGRP, &pid) < 0) { perror("ppp: ioctl(TIOCSPGRP)"); exit(1); } # endif The trouble is, the <pixrect/pr_impl_util.h> include file is wrong - it sets SUNOS to "41" iff it sees "_sys_types_h" defined (<sys/types.h> is previously included). But <sys/types.h> defines "__sys_types_h" (note the additional underscore prepended), so as supplied, the test will fail and the setsid() code will not get compiled. ppp will then exit with the ` perror("ppp: ioctl(TIOCSPGRP)") ' message under 4.1 or 4.1.1. The fix is to change the 3 instances of "_sys_types_h" in that include file ( <pixrect/pr_impl_util.h> ) to "__sys_types_h". Also, the chat.c file provided in the OSU patches chooses a lock file directory (/usr/spool/locks vs. /usr/spool/uucp) based on whether the "HDB" symbol is defined; once you've fixed the above include file, you can add this snippet right above the "# ifndef LOCK_DIR" (line 44 or so): /* Hack to get OS release level */ #include <pixrect/pr_impl_util.h> #if defined(sun) && defined(SUNOS) && SUNOS >= 41 #define HDB #endif (4) The OSU code supplies some scripts - fix-cua, ppp-on, unlock - that diddle with lock files; in their default form they all assume SunOS 4.0.x (i.e., they embed "/usr/spool/uucp"). They should be changed to test for the existance ("if [ -d /usr/spool/locks ] ... ") of the 4.1/4.1.1 HDB lock directory, and use if appropriate. (5) In Karl's README file for his "how-to-use" document, he shows a script he uses as the login shell for a PPP login: #!/bin/sh /usr/bin/mesg n stty -tostop exec /usr/local/etc/ppp 137.175.6.2: It is my opinion that ppp should be started with the `-p' option (passive), since it is on the target side (PPP `server' if you will). ppp can be run without the `-p' on the initiating side. He later says that the ppp command can be run from the `ppp-on' script via something like ppp -v 137.175.6.3: /dev/cua & There is no "-v" option to `ppp'. (I use "ppp -d 128.149.1.95: /dev/cua0 &" for debugging, or just plain "ppp 128.149.1.95: /dev/cua0 &") (6) Finally, remember to turn off XON/XOFF flow control (S58) on *both* modems (ideally, set them to use RTS/CTS flow control - and set the serial ports on each end to use hardware Carrier Detect via the zs flags field in the kernel config file, and change "local" to "modem" in /etc/ttytab for those ports, so that "ttysoftcar -n" can do its thing). In the `chat' program I remembered to turn XON/XOFF off for the local modem, but the remote office modem still had it turned on. Auuggh! Weirdness ensued. Also, though most of the routing stuff in Karl's README is correct, he fails to mention the ARP hack. My office machine is this one (poseur), 128.149.1.97. The home SPARCstation-1+ (spunky) I have configured to be 128.149.1.95. On `poseur' (as in Karl's README) the link is configured to have the *same* IP address as the Ethernet interface: ie0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> inet 128.149.1.97 netmask ffffff00 broadcast 128.149.1.0 ether 8:0:20:1:b0:65 ppp0: flags=51<UP,POINTOPOINT,RUNNING> inet 128.149.1.97 --> 128.149.1.95 netmask ffffff00 lo0: flags=49<UP,LOOPBACK,RUNNING> inet 127.0.0.1 netmask ff000000 So, to make routing totally transparent (I run `in.routed -q' on `poseur') I toss the arp hack into /etc/rc.local: if [ -f /usr/etc/arp ]; then arp -s spunky 8:0:20:1:b0:65 pub fi (Where, of course, "8:0:20:1:b0:65" is poseur's Ethernet address) One last thing about routing - if you don't declare the PPP interface to be PRIVATE (a SunOS extension) on the "server" end, the point-to-point route will be advertised to the world unless you are either running "in.routed -q" or running "gated" with a configuration file that is set up to not announce that interface. Some people may not like to have that route advertised. Caveat actor. (7) One final thing; to use Karl's scripts, you need to build the `xlogout' program (he didn't mention that). That comes with X11 R4 in the directory contrib/clients/xlogout. That's all you need to know! Snarf the 2 files from tut.CIS.Ohio-State.EDU, unbundle them, apply the 2 patch files, read this message again, and start installing with the Readme.streams file (being aware of (1) and (2) above). - Greg Earle Sun Microsystems, Inc. earle@poseur.JPL.NASA.GOV earle@Sun.COM