stty -hupcl
For more information, see stty in the QNX OS Utilities Reference.
This chapter includes the configuration information for:
There are two ways to connect to a SLIP server:
For both of these methods, we assume that Socket is started with the -s1 parameter. This creates the sl0 (first SLIP) device.
Compared to slattach, the sliplogin utility provides a more transparent method of setting up SLIP interfaces - it doesn't need to be told which specific device to use.
The sliplogin method is preferred, but to take advantage of it you must first specify correct information in your configuration files.
Let's look at an example. We'll assume the following files exist on your home and work machines.
#/etc/passwd -- home machine Swork::102:100:Paul Slip:/home/pk:/etc/sliplogin #/etc/passwd -- work machine Shome::103:100:Paul Slip:/home/pk:/etc/sliplogin
# Host Database 127.1 localhost 192.168.200.202 sliphome 192.168.200.200 slipwork
# login local-addr remote-addr mask opt1 opt2 Swork sliphome slipwork 255.255.255.0 compress Shome slipwork sliphome 255.255.255.0 compress
#!/bin/sh - This '/etc/slip.login' script is launched by # sliplogin # # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /etc/ifconfig sl$1 $4 $5 netmask $6 exit 0
To establish a SLIP connection from work to home:
qtalk -m /dev/ser1 ... login: Swork
This login invokes /etc/sliplogin Swork (from the password file), which will configure the line (i.e. slattach ttyname baudrate) and invoke the shell script slip.login.
sliplogin Shome </dev/ser1
If you want to talk to the network on the other side of a point-to-point link, see the sections on ``Routing'' and ``Debugging'' in the Basic Configuration chapter for more information.
To establish the SLIP connection between your machine and the server you could use slattach. This involves typing commands on both ends of the connection. In these examples, slipserv is the server and home is your machine - both are defined in the /etc/hosts file on both hosts. Note that instead of an alphanumeric name, you can use an IP address (e.g. 192.168.200.202)
Assuming both hosts are using /dev/ser1 and the serial connection is established, enter these commands on the server:
/etc/slattach /dev/ser1 38400 /etc/ifconfig sl0 slipserv home up
On your machine, enter these commands:
/etc/slattach /dev/ser1 38400 /etc/ifconfig sl0 home slipserv up
You can easily establish a serial connection by using qtalk and exiting without hanging up the line. For details, see sliplogin in this manual or qtalk in the QNX OS Utilities Reference.
|
To ensure that the line won't be hung up, use the
stty utility to set the hupcl line
control parameter off on both serial ports:
stty -hupcl For more information, see stty in the QNX OS Utilities Reference. |
PPP (Point-to-Point Protocol) is a link-level protocol used to transport IP packets over point-to-point media (usually a serial/telephone line). PPP is more flexible and more popular than SLIP.
To use PPP under QNX, you need to start the Socket manager with the -p option. You'll also need a serial device such as /dev/ser1 (which is typically managed by Dev.ser). And you'll need to start pppd with the appropriate configuration, which depends on what you're trying to accomplish and the security measures you want enforced.
PPP has a well-defined set of defaults, designed to work for various platforms. Although these defaults will always work, sometimes you'll want to stray from the defaults to increase performance or add security measures.
When a PPP link is initiated, each side of the link gets the opportunity to tell the other side of its capabilities and requirements, which are one way only. (For example, if server A tells client B it needs authentication, and client B agrees, then client B needs to authenticate itself to server A. But server A doesn't need to authenticate itself to client B.)
Either side has the opportunity to refuse the peer, and sometimes negotiations will fail. Depending on what option failed negotiation, the line might be dropped and the link terminated (usually this occurs only with authentication options or negotiating IP addresses).
To diagnose which option is causing the problem, run pppd with the debug option. The pppd daemon will send messages that usually indicate the point of failure to the syslogd daemon. Look for ``ConRej'' (configure reject) messages that contain the rejected option. Also look for ``TermReq'' (terminate request) messages to determine which side initiated the termination.
Here's an example from a logfile:
... pppd[6706]: sent [LCP ConfReq id=0x1 <mru 1500> <auth upap> ...] ... pppd[6706]: rcvd [LCP ConfRej id=0x1 <auth upap>]
This shows that the local pppd wants to use PAP (upap) but the remote side refused.
Note that you can specify options on the pppd command line as well as in configuration files (/etc/ppp/options; ~/.ppprc).
For these examples, we assume that:
You'll find four examples here, presented in order of complexity:
Note that since PPP is commonly used to connect to an ISP, you may find Example #2 the most useful.
The purpose of this example is to demonstrate some of the basic concepts of PPP while keeping the configuration simplified. In this example, we have two QNX nodes connected via a NULL-modem cable on /dev/ser1. Each node is running Socklet -p1, with hostnames of node1 (10.0.0.1) and node2 (10.0.0.2). Optional interface en1 has already been configured using /usr/ucb/ifconfig.
To make sure the two nodes are talking the same dialect, run the following on both nodes:
stty baud=115200 bits=8 stopb=1 par=none +raw < /dev/ser1
Now, on both nodes at the same time, run the following command:
/usr/ucb/pppd /dev/ser1
Wait a couple seconds for the link to be established.
At this point, run:
/usr/ucb/netstat -in
The output from node1 should look like this:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en1 1500 <Link> 699 0 1 0 0 en1 1500 10 10.0.0.1 699 0 1 0 0 ppp0 1500 <Link> 4 0 6 0 0 ppp0 1500 10 10.0.0.1 4 0 6 0 0 lo0 1536 <Link> 16 0 16 0 0 lo0 1536 127 127.0.0.1 16 0 16 0 0
Note that the ppp0 interface is now configured with the same IP address as the en1 interface. This is because neither side specified IP addresses to negotiate - each side chose the default, which is the IP address of the hostname specified on the Socket command line. In this example, Socket was started as:
/usr/ucb/Socket -p1 node1 &
where node1 is defined in /etc/hosts as: 10.0.0.1 node1.
|
Usually, the server side (the side that answers the phone) will negotiate both IP addresses of the PPP link. |
Now, node1 will be able to ping 10.0.0.2 using the PPP link.
This example is useful in demonstrating how to connect to a typical ISP over a telephone line. We assume you're using a modem connected to /dev/ser1.
Before trying to connect to an ISP, you'll need the following information:
If you know your ISP is going to provide Domain Name Service (DNS) for you (it most likely will), put the supplied IP address in your /etc/resolv.conf file. For example, the contents of /etc/resolv.conf when the ISP IP = 198.53.31.1 would be:
nameserver 198.53.31.1
If you'll always be assigned the same IP address (most likely not), you could enter that in your /etc/hosts file and use the associated name to start up Socklet.
To connect to the ISP:
/bin/stty baud=115200 bits=8 stopb=1 par=none -hupcl +raw < /dev/ser1
/usr/ucb/Socket -p1 node1 &
Once the ISP knows what service you want, quit qtalk using Ctrl -A to get to the menu and x to exit without dropping the line.
/usr/ucb/pppd defaultroute /dev/ser1
and wait a couple seconds for the link to be established. The defaultroute option tells pppd to set up a default route out the connection it establishes. See the ``Routing'' section in the Basic Configuration chapter for more information.
Using the netstat/ifconfig commands, you can find out what IP addresses were assigned to either end of the link. You should also be able to ping the remote end at this point.
This example shows how to configure PPP to answer the phone and allow clients to make a connection. As the server, there's a lot more to consider when deciding which configuration is best for your situation. And such configuration requires a better understanding of the ``administration'' aspects of QNX.
We assume that you're familiar with:
The first step is to get your system to answer the phone line when it rings. This is usually done with the tinit and modem commands. For example:
tinit -c /bin/modem -T /dev/ser1
By default, the modem process will start the login process. This will require the client to login successfully (adding a layer of authentication) before initiating the PPP link. Another benefit of the login procedure is that you can multiplex the phone line - it can service both regular login sessions as well as PPP sessions. All you need is to set up two user accounts:
For example, an /etc/passwd file might contain these two lines:
user1:x:315:300:User1 FullName:/home/user1:/bin/sh pppuser1:x:415:300:User1 FullName:/home/user1:/usr/ucb/pppd
The client would login as user1 when he wanted a regular login session, or as pppuser1 when he wanted a PPP session.
The client would need to know the appropriate passwords (if any) that will usually suffice for authentication. However, if such a client will be granted access to confidential material, you might consider using an authentication protocol (see Example #4 below).
You don't have to run login when a client connects. You can have pppd start immediately by changing the default of the modem utility. For example:
tinit -c "/bin/modem -c /usr/ucb/pppd" -T /dev/ser1
Either method will work as long as the client knows what he must do to initiate the PPP link.
The next issue to be considered is the matter of IP addresses. Usually the server is responsible for assigning the address of both ends of the PPP link. The reasoning behind this is that the client becomes part of the same network as the server. This will allow the client to use the server's name and routing services.
In assigning IP addresses, the server's local PPP address is almost always assigned the same address as its hostname's IP address. The address to be concerned about is the one assigned to the client's PPP interface. This address should be on the same IP network as that of the server's hostname's IP address.
For example, if the server accesses a router (or whatever to get Internet access) through interface en1 with IP address of 198.34.5.67, it should assign a remote PPP IP address (the client's local PPP IP address) belonging to IP network 198.34.5.
It's important to keep the client's IP address within the server's IP network because the server will typically need to become a proxy ARP server for the client. To clarify this, let's walk through a simple scenario:
To act as a proxy-server for the client, the server simply specifies the proxyarp option to pppd. For example, the pppd command line for the above scenario would look like this:
/usr/ucb/pppd proxyarp 10.0.0.1:10.0.0.5 /dev/ser1
The QNX PPP supports two authentication protocols:
PAP is widely considered less secure than CHAP. PAP authenticates once at startup, whereas CHAP randomly ``challenges'' the peer for authentication as long as the link is up.
Both protocols are configured using a secrets file:
Both secrets files are of the same format, which specifies one entry per line, with each entry made of at least three fields:
| This field: | Indicates: |
|---|---|
| first | the client (or authenticatee) |
| second | the server (or authenticator) |
| third | the secret |
The rest of the line can be an optional list (comma-separated) of IP addresses. The client/server fields are used to scan for a secret, which will be compared against what the peer offers as its secret.
For example, here's an authentication entry shared by both pppclient and pppserver:
pppclient pppserver pppsecret
By default, when the authenticator scans the secrets file for a secret, it looks for a match between its hostname and an entry's second field. At the time of this scanning, the client's name is not known. If the secrets file is ambiguous (because it specifies several secrets for several clients), you may need to specify the remotename option to pppd. This will cause the scan to match both the client and server fields, ensuring the proper secret is selected.
For example, when pppserver scans its secrets file, it just looks for its hostname (pppserver) in the second field of each entry. If there are multiple entries with ``pppserver'' in the second field, you may need to pass the remotename option so the scan will also require a match of remotename (in this case ``pppclient'') in the first field.
The authenticatee scans the secrets file in the same manner as the authenticator, except that it matches its hostname with the first field of each entry, and the optional remotename option with the second field.
In both the client and server side, you can specify the ``other side'' using the remotename option. Likewise, you can specify the ``local side'' (which defaults to the hostname) by using the name option to pppd. This option is usually needed only when multiple users use the same host as client (or when using PAP with the login option).
By default, pppd won't require the peer to authenticate itself, but will be ready to authenticate itself to the peer (if it has access to secrets files). Using either (but you can't use both!) the +pap or +chap options to pppd will require the remote side to authenticate itself. Usually, only the server (the side that answers the phone) will ask for authentication, but under certain circumstances, you might want both the server and client to require the peer to authenticate itself. Furthermore, each side may use a different protocol - the server may require CHAP, while the client may require PAP.
Let's assume the server is called pppserver and the client is called pppclient and that only the server is requesting authentication. Both the server's and the client's secrets file will need to contain at least the following entry:
pppclient pppserver secret1
Both the server and client will scan the secrets file and will use the ``secret1'' secret.
If both the server and client request authentication, another entry (in the appropriate secrets file - remember one may request CHAP, the other may request PAP) will be needed to describe the other secret. For example:
pppserver pppclient secret2
Again, when dealing with multiple clients/servers, you may need to specify either the remotename or name option (or both) to pppd to get rid of any ambiguity when selecting the secret.
Note that you can request PAP authentication without having a secrets file by specifying the login option to pppd. With this option, the client name and secret represent a user account and password in the system password database. From the above example, a user account of pppclient with a password of secret1 must exist on the server side for authentication to succeed.
If a pap-secrets file exists when using the login option, a match must exist in the pap-secrets file before the system database is checked.
|
Using the login option requires at least one side to keep a text-based user:passwd combination, which might be considered a security breach in itself! |