Message-ID: <47C94750.8060006@katalix.com>
Date:	Sat, 01 Mar 2008 12:08:48 +0000
From:	James Chapman <jchapman@...alix.com>
To:	Kevin Lloyd <klloyd@...rrawireless.com>
CC:	Dan Williams <dcbw@...hat.com>, netdev@...r.kernel.org
Subject: Re: Network device driver with PPP

Kevin Lloyd wrote:
> James Chapman wrote:
>>> Actually we provide a method for the driver to obtain the
>>> username/password information needed for the CHAP authentication so
> in
>>> theory the driver has the information needed to create the
> connection.
>>> I'm not sure how it would go about setting the DNS and IP addresses,
> but
>>> 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.

>> 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.

>> 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
>> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists