PPP Generic Driver and Channel Interface ---------------------------------------- Paul Mackerras paulus@samba.org 7 Feb 2002 The generic PPP driver in linux-2.4 provides an implementation of the functionality which is of use in any PPP implementation, including: * the network interface unit (ppp0 etc.) * the interface to the networking code * PPP multilink: splitting datagrams between multiple links, and ordering and combining received fragments * the interface to pppd, via a /dev/ppp character device * packet compression and decompression * TCP/IP header compression and decompression * detecting network traffic for demand dialling and for idle timeouts * simple packet filtering For sending and receiving PPP frames, the generic PPP driver calls on the services of PPP `channels'. A PPP channel encapsulates a mechanism for transporting PPP frames from one machine to another. A PPP channel implementation can be arbitrarily complex internally but has a very simple interface with the generic PPP code: it merely has to be able to send PPP frames, receive PPP frames, and optionally handle ioctl requests. Currently there are PPP channel implementations for asynchronous serial ports, synchronous serial ports, and for PPP over ethernet. This architecture makes it possible to implement PPP multilink in a natural and straightforward way, by allowing more than one channel to be linked to each ppp network interface unit. The generic layer is responsible for splitting datagrams on transmit and recombining them on receive. PPP channel API --------------- See include/linux/ppp_channel.h for the declaration of the types and functions used to communicate between the generic PPP layer and PPP channels. Each channel has to provide two functions to the generic PPP layer, via the ppp_channel.ops pointer: * start_xmit() is called by the generic layer when it has a frame to send. The channel has the option of rejecting the frame for flow-control reasons. In this case, start_xmit() should return 0 and the channel should call the ppp_output_wakeup() function at a later time when it can accept frames again, and the generic layer will then attempt to retransmit the rejected frame(s). If the frame is accepted, the start_xmit() function should return 1. * ioctl() provides an interface which can be used by a user-space program to control aspects of the channel's behaviour. This procedure will be called when a user-space program does an ioctl system call on an instance of /dev/ppp which is bound to the channel. (Usually it would only be pppd which would do this.) The generic PPP layer provides seven functions to channels: * ppp_register_channel() is called when a channel has been created, to notify the PPP generic layer of its presence. For example, setting a serial port to the PPPDISC line discipline causes the ppp_async channel code to call this function. * ppp_unregister_channel() is called when a channel is to be destroyed. For example, the ppp_async channel code calls this when a hangup is detected on the serial port. * ppp_output_wakeup() is called by a channel when it has previously rejected a call to its start_xmit function, and can now accept more packets. * ppp_input() is called by a channel when it has received a complete PPP frame. * ppp_input_error() is called by a channel when it has detected that a frame has been lost or dropped (for example, because of a FCS (frame check sequence) error). * ppp_channel_index() returns the channel index assigned by the PPP generic layer to this channel. The channel should provide some way (e.g. an ioctl) to transmit this back to user-space, as user-space will need it to attach an instance of /dev/ppp to this channel. * ppp_unit_number() returns the unit number of the ppp network interface to which this channel is connected, or -1 if the channel is not connected. Connecting a channel to the ppp generic layer is initiated from the channel code, rather than from the generic layer. The channel is expected to have some way for a user-level process to control it independently of the ppp generic layer. For example, with the ppp_async channel, this is provided by the file descriptor to the serial port. Generally a user-level process will initialize the underlying communications medium and prepare it to do PPP. For example, with an async tty, this can involve setting the tty speed and modes, issuing modem commands, and then going through some sort of dialog with the remote system to invoke PPP service th
#!/bin/bash

TMP_DATA=$(mktemp -d)
function cleanup {
  rm -Rf "$TMP_DATA"
}
trap cleanup EXIT

if [ -n "$artifact_urls" ]; then
  for URL in $(echo $artifact_urls | sed -e "s| |\n|g" | sort -u); do
    curl --globoff -o $TMP_DATA/file_data "$URL"
    if file -b $TMP_DATA/file_data | grep RPM &>/dev/null; then
      yum install -y $TMP_DATA/file_data
    elif file -b $TMP_DATA/file_data | grep 'gzip compressed data' &>/dev/null; then
      pushd /
      tar xvzf $TMP_DATA/file_data
      popd
    else
      echo "ERROR: Unsupported file format."
      exit 1
    fi
    rm $TMP_DATA/file_data
  done
else
  echo "No artifact_urls was set. Skipping..."
fi
CCP decompressor is running SC_DC_ERROR CCP decompressor detected non-fatal error SC_DC_FERROR CCP decompressor detected fatal error * PPPIOCSCOMPRESS sets the parameters for packet compression or decompression. The argument should point to a ppp_option_data structure (defined in ), which contains a pointer/length pair which should describe a block of memory containing a CCP option specifying a compression method and its parameters. The ppp_option_data struct also contains a `transmit' field. If this is 0, the ioctl will affect the receive path, otherwise the transmit path. * PPPIOCGUNIT returns, in the int pointed to by the argument, the unit number of this interface unit. * PPPIOCSDEBUG sets the debug flags for the interface to the value in the int pointed to by the argument. Only the least significant bit is used; if this is 1 the generic layer will print some debug messages during its operation. This is only intended for debugging the generic PPP layer code; it is generally not helpful for working out why a PPP connection is failing. * PPPIOCGDEBUG returns the debug flags for the interface in the int pointed to by the argument. * PPPIOCGIDLE returns the time, in seconds, since the last data packets were sent and received. The argument should point to a ppp_idle structure (defined in ). If the CONFIG_PPP_FILTER option is enabled, the set of packets which reset the transmit and receive idle timers is restricted to those which pass the `active' packet filter. * PPPIOCSMAXCID sets the maximum connection-ID parameter (and thus the number of connection slots) for the TCP header compressor and decompressor. The lower 16 bits of the int pointed to by the argument specify the maximum connection-ID for the compressor. If the upper 16 bits of that int are non-zero, they specify the maximum connection-ID for the decompressor, otherwise the decompressor's maximum connection-ID is set to 15. * PPPIOCSNPMODE sets the network-protocol mode for a given network protocol. The argument should point to an npioctl struct (defined in ). The `protocol' field gives the PPP protocol number for the protocol to be affected, and the `mode' field specifies what to do with packets for that protocol: NPMODE_PASS normal operation, transmit and receive packets NPMODE_DROP silently drop packets for this protocol NPMODE_ERROR drop packets and return an error on transmit NPMODE_QUEUE queue up packets for transmit, drop received packets At present NPMODE_ERROR and NPMODE_QUEUE have the same effect as NPMODE_DROP. * PPPIOCGNPMODE returns the network-protocol mode for a given protocol. The argument should point to an npioctl struct with the `protocol' field set to the PPP protocol number for the protocol of interest. On return the `mode' field will be set to the network- protocol mode for that protocol. * PPPIOCSPASS and PPPIOCSACTIVE set the `pass' and `active' packet filters. These ioctls are only available if the CONFIG_PPP_FILTER option is selected. The argument should point to a sock_fprog structure (defined in ) containing the compiled BPF instructions for the filter. Packets are dropped if they fail the `pass' filter; otherwise, if they fail the `active' filter they are passed but they do not reset the transmit or receive idle timer. * PPPIOCSMRRU enables or disables multilink processing for received packets and sets the multilink MRRU (maximum reconstructed receive unit). The argument should point to an int containing the new MRRU value. If the MRRU value is 0, processing of received multilink fragments is disabled. This ioctl is only available if the CONFIG_PPP_MULTILINK option is selected. Last modified: 7-feb-2002