Kevin Lloyd wrote:

James Chapman wrote:

quoted

quoted

Actually we provide a method for the driver to obtain the
username/password information needed for the CHAP authentication so

in

quoted

quoted

theory the driver has the information needed to create the

connection.

quoted

quoted

I'm not sure how it would go about setting the DNS and IP addresses,

but

quoted

quoted

that's a separate issue further down the road.

Can you explain why you need the driver to be involved in any of this?

I'm trying to evaluate what level of consistency can be maintained for
our drivers across operating systems and whether there is precedence for
such a design. Looking like it's not going to happen...

If your goal is to have your driver submitted upstream, it needs to fit 
the Linux infrastructure. Use existing kernel subsystems where they 
exist. Avoid OS abstraction wrappers too.

quoted

Control protocols live in userspace, datapath in the kernel.

Okay. I have a question about the datapath actually: If I have a serial
device and I establish a connection with pppd does it configure the
generic ppp driver to talk to the ttyUSBx port and then route the
control (e.g. NCP and LCP) packets to /dev/ppp for control by pppd and
the data (IP) packets somewhere else? 

It depends.

pppd creates a ppp network interface. This is exactly the same as all 
other network interfaces in the system (eth0 etc) in that data packets 
pass from/to the device to/from the kernel network subsystems. Data 
packets arriving on your PPP interface can be delivered without any 
involvement from pppd.

If the PPP packet is to be encapsulated (e.g. PPPoATM, PPPoE) then 
things are more complicated. A kernel device driver does the 
encapsulation (drivers/net/pppoatm.c, drivers/net/pppoe.c) and a pppd 
plugin interfaces with that driver in order to send/receive PPP control 
packets. The kernel's ppp core separates PPP control and data packets.

However, some protocols don't have a pppox driver or corresponding 
userspace pppd plugin (e.g. PPTP). In these cases, pppd uses pseudo tty 
devices and copies data packets to/from it in userspace. Data packets 
are delivered to a pppd "data pump" which inserts or removes the 
encapsulation before passing it on. This can be quicker to implement but 
is obviously suboptimal because userspace copies all data and does all 
the protocol encapsulation/decapsulation work.

Also is it pppd that directly sets
up the network interface in ifconfig? I'm a little confused/lost here...

Yes. Though ifconfig is just one userspace app that can list network 
devices.

quoted

Can't you implement a private interface to your kernel driver so that
userspace can ask it for the username/password and userspace then

starts

quoted

pppd with those parameters?

Yes I suppose I could do that, how would you recommend approaching this,
ioctl?

It depends on your device driver. If it can have a private driver ioctl 
handler, ioctl is simplest.

Also, is Documentation\networking\ppp_generic.txt up-to-date (says
edited 2002) or is there a better resource explaining ppp architecture
on Linux?

The PPP APIs have been stable for a long time.


-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development