The line to add in /etc/passwd for IRIX SLIP looks like the following (because of a potential security hole, the home directory for a SLIP or PPP account should only be writable by root, for example creating the special directory /var/secure, with permissions 700):
Sclient::0:0:SLIP login client.sub.domain.foo.bar,,:/:/usr/etc/remoteslip
For IRIX PPP the /etc/passwd entry looks like:
Pclient::0:0:Irix PPP login client.sub.domain.foo.bar,,:/:/usr/etc/ppp
(Note that IRIX SLIP and PPP must run as root!)
For MST PPP the /etc/passwd entry looks like:
Pclient::0:0:MST PPP login client.sub.domain.foo.bar,,:/:/usr/etc/ppp/LoginThe password can be set by typing the following, for SLIP, PPP is similar:
% su # passwd Sclient Changing password for Sclient on server. New password: password Re-enter new password: password #The password is not echoed.
On an IRIX server, add a section like the following in /usr/etc/remoteslip for the client login:
Sclient) exec /usr/etc/slip -i -p cslip -r client.sub.domain.foo.bar ;; #
The servers can dialout to the clients. The IRIX SLIP client needs an entry in /usr/etc/remoteslip just like the server, however for IRIX4 routing is a royal pain. It is almost easiest to just login and manually add the route after the link comes up. For IRIX4, the entry in /usr/etc/remoteslip looks almost identical to the server case:
Sserver) exec /usr/etc/slip -i -p cslip -r server.sub.domain.foo.bar ;; #
For IRIX5 SLIP clients, routing on clients is easier because of the -R option, add the following section to the /usr/etc/remoteslip file:
Sserver) exec /usr/etc/slip -i -p cslip -R "" -r server.sub.domain.foo.bar ;; #Never use -R "" on a server! This advertises a default route, for which there can be only one on a network. Doing so will probably screw up routing on your whole net! At the very least, your network admins will be very annoyed.
The following section must remain the last one in the file:
*) exec /usr/etc/slip -i -r $USER ;; esac
rmt in remotehost=client.domain.foo.barWhere rmt is the login for the dialin-only clients (the remotehost=client.domain.foo.bar assigns the IP address to the dialin client). If this is the client, then you can use remotehost=0,0, but then the server must specify an IP address. It is vitally important that either the server or the client (or both) specifies an IP address to use. From a routing security point of view, the server should always specify the IP address.
If you are using PAP or CHAP authentication (CHAP is added in patch 517 for IRIX-5.3, and is in IRIX-6.2 and later), then you need to add the appropriate recv_name=Pclient and recv_passwd=password entries in /etc/ppp.conf, which might look like:
Pclient in remotehost=client.domain.foo.bar recv_chap recv_pap recv_name=Pclient recv_passwd=password
There are some PPP implementations that do not handle protocol negotiation correctly. The Windoze95 stack seems to be one of these. This will either cause the link to fail to come up, or to cause it to fail "randomly" after a short uptime. The solution is to tell SGI's ppp to not try to negotiate the offending (advanced) protocols. Add the following options to the /etc/ppp.conf entry:
#!/bin/sh arp -s client.domain.foo.bar ppp -r $USER arp -d client.domain.foo.barwhich won't work at all if you are running FlexFAX or HylaFAX software. Check out the faxd problem for more details.
The script above is unneccessary if the server is running IRIX-6.3 or later, as a new capability was added to the PPP daemon to support dynamic proxy-ARP configuration:
proxy_arp=ifname(see the ppp man page for details).
IRIX SLIP and PPP are not designed to handle this case. The degenerate case of one dialin modem per host is actually workable, though. Just assign the same IP address (in /etc/ppp.conf or /usr/etc/remoteslip) to all dialup accounts. Since only one dialup account can be in use at any one time, this solves the issue of determining which IP address to assign to the client when it logs in. Just make sure that each server host assigns a different IP address to it's client accounts. The accounts can be the same across multiple dialin servers, but they must have a different IP address on each server.
There is a hack to handle multiple modems on a server host and do server-assigned IP addressing. The two that have been tried (not by me, and I don't know details -- these are hints for your implementation!) are:
#!/bin/sh case `tty` in /dev/ttyf2) ipaddr=22.214.171.124 ;; /dev/ttyf3) ipaddr=126.96.36.199 ;; esac arp -s $ipaddr `netstat -ian | grep :` pub slip -i -p cslip -r $ipaddr arp -d $ipaddr exit 0For PPP, you would need to create a login script that might look something like:
#!/bin/sh port=`tty` USER=`echo $port | sed -e 's,/dev/,,'` arp -s $USER `netstat -ian | grep :` pub ppp -r $USER arp -d $USER exit 0and the real trick is that the IP addresses for the logins (and the entries in /etc/ppp.conf) are named after the ports, ie: ttyf2, ttyf3, ttyf44, etc. Note that you probably have to change /etc/resolv.conf to hostresorder local bind on the server to make this work. Example /etc/ppp.conf entries might look like:
ttyf2 in remotehost=ttyf2 ttyf3 in remotehost=ttyf3If you want to use PAP or CHAP authentication, you will have to get a lot more clever. You may be able to get away with using the reconfigure keyword to reduce your work. You'll have to experiment, since I haven't.
Even so, this will not give you the full capability of commercial terminal servers (like the Livingston Portmaster, which will (among other things) allow a client to negotiate a different IP address in the pool, if it is still available. (I used the Portmaster because I am familiar with it. Other Terminal servers behave similarly).
% /usr/etc/netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ec0 1500 192.82.281 server.sub.doma 16704753 2490 14890682 98 14870035 lo0 32880 loopback localhost 2142995 0 2142995 0 0 du0* 1500 (pt-to-pt) client.sub.doma 2364 0 106924 0 0 sl0* 512 (pt-to-pt) client.sub.doma 5 1 0 0 0 sl1* 1006 none none 0 0 0 0 0 sl2* 1006 none none 0 0 0 0 0 sl3* 1006 none none 0 0 0 0 0du0 and sl0 have the same address as the culprit in this example.
Note: This is fixed in IRIX-5.3 (and later).
Other Useful Information
A random selection of potentially useful WWW pages:
I hope and intend that this documentation can help you with your PPP connection problems. My other commitments (like work) permitting, I will attempt to help you on issues not covered, or that you are unclear on. Please make sure that you provide me a valid return email address! (I won't try to fix it).
Scott Henry <[email protected]>
Last modified: Sun Feb 1 14:37:09 1998