Lines Matching full:to
16 * the interface to the networking code
19 * the interface to pppd, via a /dev/ppp character device
27 mechanism for transporting PPP frames from one machine to another. A
30 to be able to send PPP frames, receive PPP frames, and optionally
35 This architecture makes it possible to implement PPP multilink in a
36 natural and straightforward way, by allowing more than one channel to
37 be linked to each ppp network interface unit. The generic layer is
46 functions used to communicate between the generic PPP layer and PPP
49 Each channel has to provide two functions to the generic PPP layer,
52 * start_xmit() is called by the generic layer when it has a frame to
57 will then attempt to retransmit the rejected frame(s). If the frame
61 program to control aspects of the channel's behaviour. This
63 system call on an instance of /dev/ppp which is bound to the
66 The generic PPP layer provides seven functions to channels:
68 * ppp_register_channel() is called when a channel has been created, to
70 a serial port to the PPPDISC line discipline causes the ppp_async
71 channel code to call this function.
73 * ppp_unregister_channel() is called when a channel is to be
78 rejected a call to its start_xmit function, and can now accept more
89 generic layer to this channel. The channel should provide some way
90 (e.g. an ioctl) to transmit this back to user-space, as user-space
91 will need it to attach an instance of /dev/ppp to this channel.
94 interface to which this channel is connected, or -1 if the channel
97 Connecting a channel to the ppp generic layer is initiated from the
99 expected to have some way for a user-level process to control it
101 ppp_async channel, this is provided by the file descriptor to the
105 communications medium and prepare it to do PPP. For example, with an
108 remote system to invoke PPP service there. We refer to this process
109 as ``discovery``. Then the user-level process tells the medium to
111 The channel then has to report the channel number assigned to it back
112 to the user-level process. From that point, the PPP negotiation code
116 At the interface to the PPP generic layer, PPP frames are stored in
123 presented to the start_xmit() function contain only the 2-byte
124 protocol number and the data, and the skbuffs presented to ppp_input()
127 The channel must provide an instance of a ppp_channel struct to
128 represent the channel. The channel is free to use the ``private`` field
135 If the channel needs some headroom in the skbuffs presented to it for
138 ppp_channel struct to the amount of headroom required. The generic
139 PPP layer will attempt to provide that much headroom but the channel
144 headroom in the skbuffs presented to ppp_input(). The generic PPP
151 The generic PPP layer has been designed to minimize the amount of data
156 exceptions are when pppd sends packets by writing to /dev/ppp, and
161 is asked to transmit.
164 then subjected to TCP/IP header compression and packet compression
170 If multilink is not in use, this packet is then passed to the attached
171 channel's start_xmit() function. If the channel refuses to take
181 decides how many fragments to use based on the length of the packet
182 and the number of channels which are potentially able to accept a
183 fragment at the moment. A channel is potentially able to accept a
185 to transmit. The channel may still refuse a fragment; in this case
186 the fragment is queued up for the channel to transmit later. This
187 scheme has the effect that more fragments are given to higher-
189 layer will tend to fragment large packets across all the channels,
190 thus reducing latency, while under heavy load, packets will tend to be
198 The PPP generic layer has been designed to be SMP-safe. Locks are
199 used around accesses to the internal data structures where necessary
200 to ensure their integrity. As part of this, the generic layer
201 requires that the channels adhere to certain requirements and in turn
202 provides certain guarantees to the channels. Essentially the channels
203 are required to provide the appropriate locking on the ppp_channel
207 required to provide the guarantee that this storage exists and is
213 ppp_register_channel() is called until after the call to
216 * No thread may be in a call to any of ppp_input(), ppp_input_error(),
234 The generic layer provides these guarantees to the channels:
244 * By the time a call to ppp_unregister_channel() returns, no thread
245 will be executing in a call from the generic layer to that channel's
250 Interface to pppd
254 /dev/ppp. This is used by pppd to control PPP interface units and
256 /dev/ppp acts independently and can be attached either to a PPP unit
258 to point to a separate object for each open instance of /dev/ppp. In
259 this way an effect similar to Solaris' clone open is obtained,
260 allowing us to control an arbitrary number of PPP interfaces and
261 channels without having to fill up /dev with hundreds of device names.
264 unattached. Using an ioctl call, it can then be attached to an
265 existing unit, attached to a newly-created unit, or attached to an
266 existing channel. An instance attached to a unit can be used to send
269 attached to a channel can be used to send and receive PPP frames on
274 write to the unit (i.e., to an instance of /dev/ppp attached to the
275 unit) will be subject to bundle-level compression and to fragmentation
277 PPP frame sent by a write to the channel will be sent as-is on that
280 A channel is not initially attached to any unit. In this state it can
282 It can then be connected to a PPP unit with an ioctl call, which
283 makes it available to send and receive data packets for that unit.
286 on whether it is unattached, attached to a PPP interface, or attached
287 to a PPP channel. The ioctl calls which are available on an
291 instance the "owner" of the interface. The argument should point to
292 an int which is the desired unit number if >= 0, or -1 to assign the
297 * PPPIOCATTACH attaches this instance to an existing PPP interface.
298 The argument should point to an int containing the unit number.
301 * PPPIOCATTCHAN attaches this instance to an existing PPP channel.
302 The argument should point to an int containing the channel number.
304 The ioctl calls available on an instance of /dev/ppp attached to a
307 * PPPIOCCONNECT connects this channel to a PPP interface. The
308 argument should point to an int containing the interface unit
310 connected to an interface, or ENXIO if the requested interface does
314 it is connected to. It will return an EINVAL error if the channel
315 is not connected to an interface.
318 point to an int containing the channel number of the channel to bridge
319 to. Once two channels are bridged, frames presented to one channel by
320 ppp_input() are passed to the bridge instance for onward transmission.
321 This allows frames to be switched from one channel into another: for
322 example, to pass PPPoE frames into a PPPoL2TP session. Since channel
333 * All other ioctl commands are passed to the channel ioctl() function.
335 The ioctl calls that are available on an instance that is attached to
339 The argument should point to an int containing the new MRU value.
342 interface. The argument should be a pointer to an int containing
354 SC_LOOP_TRAFFIC send IP traffic to pppd
368 interface unit. The argument should point to an int where the ioctl
380 decompression. The argument should point to a ppp_option_data
388 * PPPIOCGUNIT returns, in the int pointed to by the argument, the unit
391 * PPPIOCSDEBUG sets the debug flags for the interface to the value in
392 the int pointed to by the argument. Only the least significant bit
399 pointed to by the argument.
402 packets were sent and received. The argument should point to a
405 the transmit and receive idle timers is restricted to those which
407 Two versions of this command exist, to deal with user space
412 decompressor. The lower 16 bits of the int pointed to by the
416 maximum connection-ID is set to 15.
419 protocol. The argument should point to an npioctl struct (defined
421 number for the protocol to be affected, and the ``mode`` field
422 specifies what to do with packets for that protocol:
436 protocol. The argument should point to an npioctl struct with the
437 ``protocol`` field set to the PPP protocol number for the protocol of
438 interest. On return the ``mode`` field will be set to the network-
443 option is selected. The argument should point to a sock_fprog
451 unit). The argument should point to an int containing the new MRRU