Lines Matching refs:the
8 The generic PPP driver in linux-2.4 provides an implementation of the
11 * the network interface unit (ppp0 etc.)
12 * the interface to the networking code
15 * the interface to pppd, via a /dev/ppp character device
21 For sending and receiving PPP frames, the generic PPP driver calls on
22 the services of PPP `channels'. A PPP channel encapsulates a
25 has a very simple interface with the generic PPP code: it merely has
41 See include/linux/ppp_channel.h for the declaration of the types and
42 functions used to communicate between the generic PPP layer and PPP
45 Each channel has to provide two functions to the generic PPP layer,
46 via the ppp_channel.ops pointer:
48 * start_xmit() is called by the generic layer when it has a frame to
49 send. The channel has the option of rejecting the frame for
51 and the channel should call the ppp_output_wakeup() function at a
52 later time when it can accept frames again, and the generic layer
53 will then attempt to retransmit the rejected frame(s). If the frame
54 is accepted, the start_xmit() function should return 1.
57 program to control aspects of the channel's behaviour. This
59 system call on an instance of /dev/ppp which is bound to the
65 notify the PPP generic layer of its presence. For example, setting
66 a serial port to the PPPDISC line discipline causes the ppp_async
70 destroyed. For example, the ppp_async channel code calls this when
71 a hangup is detected on the serial port.
84 * ppp_channel_index() returns the channel index assigned by the PPP
89 * ppp_unit_number() returns the unit number of the ppp network
90 interface to which this channel is connected, or -1 if the channel
93 Connecting a channel to the ppp generic layer is initiated from the
94 channel code, rather than from the generic layer. The channel is
96 independently of the ppp generic layer. For example, with the
97 ppp_async channel, this is provided by the file descriptor to the
100 Generally a user-level process will initialize the underlying
102 async tty, this can involve setting the tty speed and modes, issuing
103 modem commands, and then going through some sort of dialog with the
105 as `discovery'. Then the user-level process tells the medium to
106 become a PPP channel and register itself with the generic PPP layer.
107 The channel then has to report the channel number assigned to it back
108 to the user-level process. From that point, the PPP negotiation code
109 in the PPP daemon (pppd) can take over and perform the PPP
110 negotiation, accessing the channel through the /dev/ppp interface.
112 At the interface to the PPP generic layer, PPP frames are stored in
113 skbuff structures and start with the two-byte PPP protocol number.
114 The frame does *not* include the 0xff `address' byte or the 0x03
117 characters included. That is all the responsibility of the channel
118 code, if it is needed for the particular medium. That is, the skbuffs
119 presented to the start_xmit() function contain only the 2-byte
120 protocol number and the data, and the skbuffs presented to ppp_input()
121 must be in the same format.
124 represent the channel. The channel is free to use the `private' field
125 however it wishes. The channel should initialize the `mtu' and
128 represents the maximum size of the data part of the PPP frames, that
129 is, it does not include the 2-byte protocol number.
131 If the channel needs some headroom in the skbuffs presented to it for
132 transmission (i.e., some space free in the skbuff data area before the
133 start of the PPP frame), it should set the `hdrlen' field of the
134 ppp_channel struct to the amount of headroom required. The generic
135 PPP layer will attempt to provide that much headroom but the channel
136 should still check if there is sufficient headroom and copy the skbuff
139 On the input side, channels should ideally provide at least 2 bytes of
140 headroom in the skbuffs presented to ppp_input(). The generic PPP
147 The generic PPP layer has been designed to minimize the amount of data
148 that it buffers in the transmit direction. It maintains a queue of
149 transmit packets for the PPP unit (network interface device) plus a
150 queue of transmit packets for each attached channel. Normally the
151 transmit queue for the unit will contain at most one packet; the
153 when the core networking code calls the generic layer's start_xmit()
154 function with the queue stopped, i.e. when the generic layer has
156 The start_xmit function always accepts and queues the packet which it
159 Transmit packets are dequeued from the PPP unit transmit queue and
162 point the packets can no longer be reordered, as the decompression
163 algorithms rely on receiving compressed packets in the same order that
166 If multilink is not in use, this packet is then passed to the attached
167 channel's start_xmit() function. If the channel refuses to take
168 the packet, the generic layer saves it for later transmission. The
169 generic layer will call the channel's start_xmit() function again
170 when the channel calls ppp_output_wakeup() or when the core
171 networking code calls the generic layer's start_xmit() function
173 logic; it relies on the core networking code for that.
175 If multilink is in use, the generic layer divides the packet into one
177 decides how many fragments to use based on the length of the packet
178 and the number of channels which are potentially able to accept a
179 fragment at the moment. A channel is potentially able to accept a
182 the fragment is queued up for the channel to transmit later. This
183 scheme has the effect that more fragments are given to higher-
184 bandwidth channels. It also means that under light load, the generic
185 layer will tend to fragment large packets across all the channels,
187 transmitted as single fragments, thus reducing the overhead of
195 used around accesses to the internal data structures where necessary
196 to ensure their integrity. As part of this, the generic layer
197 requires that the channels adhere to certain requirements and in turn
198 provides certain guarantees to the channels. Essentially the channels
199 are required to provide the appropriate locking on the ppp_channel
200 structures that form the basis of the communication between the
201 channel and the generic layer. This is because the channel provides
202 the storage for the ppp_channel structure, and so the channel is
203 required to provide the guarantee that this storage exists and is
204 valid at the appropriate times.
206 The generic layer requires these guarantees from the channel:
208 * The ppp_channel object must exist from the time that
209 ppp_register_channel() is called until after the call to
214 channel at the time that ppp_unregister_channel() is called for that
223 * The generic layer may call the channel start_xmit() function at
224 softirq/BH level but will not call it at interrupt level. Thus the
227 * The generic layer will only call the channel ioctl() function in
230 The generic layer provides these guarantees to the channels:
232 * The generic layer will not call the start_xmit() function for a
236 * The generic layer will not call the ioctl() function for a channel
240 * By the time a call to ppp_unregister_channel() returns, no thread
241 will be executing in a call from the generic layer to that channel's
242 start_xmit() or ioctl() function, and the generic layer will not
253 or a PPP channel. This is achieved using the file->private_data field
263 and receive PPP control frames, using the read() and write() system
268 In multilink terms, the unit represents the bundle, while the channels
269 represent the individual physical links. Thus, a PPP frame sent by a
270 write to the unit (i.e., to an instance of /dev/ppp attached to the
272 across the individual links (if multilink is in use). In contrast, a
273 PPP frame sent by a write to the channel will be sent as-is on that
277 be used for PPP negotiation but not for the transfer of data packets.
287 instance the "owner" of the interface. The argument should point to
288 an int which is the desired unit number if >= 0, or -1 to assign the
289 lowest unused unit number. Being the owner of the interface means
290 that the interface will be shut down if this instance of /dev/ppp is
294 The argument should point to an int containing the unit number.
295 This does not make this instance the owner of the PPP interface.
298 The argument should point to an int containing the channel number.
303 * PPPIOCDETACH detaches the instance from the channel. This ioctl is
304 deprecated since the same effect can be achieved by closing the
310 argument should point to an int containing the interface unit
311 number. It will return an EINVAL error if the channel is already
312 connected to an interface, or ENXIO if the requested interface does
315 * PPPIOCDISCONN disconnects this channel from the PPP interface that
316 it is connected to. It will return an EINVAL error if the channel
319 * All other ioctl commands are passed to the channel ioctl() function.
324 * PPPIOCSMRU sets the MRU (maximum receive unit) for the interface.
325 The argument should point to an int containing the new MRU value.
327 * PPPIOCSFLAGS sets flags which control the operation of the
329 the new flags value. The bits in the flags value that can be set
346 that the values of the SC_MULTILINK, SC_MP_SHORTSEQ and
347 SC_MP_XSHORTSEQ bits are ignored if the CONFIG_PPP_MULTILINK option
350 * PPPIOCGFLAGS returns the value of the status/control flags for the
351 interface unit. The argument should point to an int where the ioctl
352 will store the flags value. As well as the values listed above for
353 PPPIOCSFLAGS, the following bits may be set in the returned value:
359 * PPPIOCSCOMPRESS sets the parameters for packet compression or
365 field. If this is 0, the ioctl will affect the receive path,
366 otherwise the transmit path.
368 * PPPIOCGUNIT returns, in the int pointed to by the argument, the unit
371 * PPPIOCSDEBUG sets the debug flags for the interface to the value in
372 the int pointed to by the argument. Only the least significant bit
373 is used; if this is 1 the generic layer will print some debug
375 the generic PPP layer code; it is generally not helpful for working
378 * PPPIOCGDEBUG returns the debug flags for the interface in the int
379 pointed to by the argument.
381 * PPPIOCGIDLE returns the time, in seconds, since the last data
383 ppp_idle structure (defined in <linux/ppp_defs.h>). If the
384 CONFIG_PPP_FILTER option is enabled, the set of packets which reset
385 the transmit and receive idle timers is restricted to those which
386 pass the `active' packet filter.
388 * PPPIOCSMAXCID sets the maximum connection-ID parameter (and thus the
389 number of connection slots) for the TCP header compressor and
390 decompressor. The lower 16 bits of the int pointed to by the
391 argument specify the maximum connection-ID for the compressor. If
392 the upper 16 bits of that int are non-zero, they specify the maximum
393 connection-ID for the decompressor, otherwise the decompressor's
396 * PPPIOCSNPMODE sets the network-protocol mode for a given network
398 in <linux/ppp-ioctl.h>). The `protocol' field gives the PPP protocol
399 number for the protocol to be affected, and the `mode' field
408 At present NPMODE_ERROR and NPMODE_QUEUE have the same effect as
411 * PPPIOCGNPMODE returns the network-protocol mode for a given
412 protocol. The argument should point to an npioctl struct with the
413 `protocol' field set to the PPP protocol number for the protocol of
414 interest. On return the `mode' field will be set to the network-
417 * PPPIOCSPASS and PPPIOCSACTIVE set the `pass' and `active' packet
418 filters. These ioctls are only available if the CONFIG_PPP_FILTER
420 structure (defined in <linux/filter.h>) containing the compiled BPF
421 instructions for the filter. Packets are dropped if they fail the
422 `pass' filter; otherwise, if they fail the `active' filter they are
423 passed but they do not reset the transmit or receive idle timer.
426 packets and sets the multilink MRRU (maximum reconstructed receive
427 unit). The argument should point to an int containing the new MRRU
428 value. If the MRRU value is 0, processing of received multilink
429 fragments is disabled. This ioctl is only available if the