netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Network device driver with PPP
@ 2008-02-28  1:28 Kevin Lloyd
  2008-02-28  2:15 ` Dan Williams
  0 siblings, 1 reply; 7+ messages in thread
From: Kevin Lloyd @ 2008-02-28  1:28 UTC (permalink / raw)
  To: netdev

Hi all,

I have a device that is currently supported via a combination of loading the device with usb-serial (drivers/usb/serial/sierra) to expose the serial ports and connecting by manually launching pppd.
I would like to support this device in a network driver as opposed to a serial driver in an effort to offer a seamless always-on device, such as an Ethernet device.

From what I understand the ppp support in the kernel is only for ppp framing and that all control (e.g., IPCP) is done in user-space via pppd. Are there any network drivers that currently manage the ppp connection (entirely, IPCP included) internally to the driver and expose either a raw ip or ethernet stream to the user-space?

Thank you,
 -Kevin


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Network device driver with PPP
  2008-02-28  1:28 Network device driver with PPP Kevin Lloyd
@ 2008-02-28  2:15 ` Dan Williams
  2008-02-28  9:27   ` James Chapman
  0 siblings, 1 reply; 7+ messages in thread
From: Dan Williams @ 2008-02-28  2:15 UTC (permalink / raw)
  To: Kevin Lloyd; +Cc: netdev

On Wed, 2008-02-27 at 17:28 -0800, Kevin Lloyd wrote:
> Hi all,
> 
> I have a device that is currently supported via a combination of loading the device with usb-serial (drivers/usb/serial/sierra) to expose the serial ports and connecting by manually launching pppd.
> I would like to support this device in a network driver as opposed to a serial driver in an effort to offer a seamless always-on device, such as an Ethernet device.
> 
> From what I understand the ppp support in the kernel is only for ppp framing and that all control (e.g., IPCP) is done in user-space via pppd. Are there any network drivers that currently manage the ppp connection (entirely, IPCP included) internally to the driver and expose either a raw ip or ethernet stream to the user-space?

That seems quite icky to do all in kernel space and a pile of code
running in the kernel.  What's so wrong with userspace?  Don't you need
to push values to the driver like username/password and get IP config
out of it (which would involve userspace anyway)?  It just seems like
there's a different solution to your actual problem here than stuff all
off pppd into kernel space.

Dan




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Network device driver with PPP
  2008-02-28  2:15 ` Dan Williams
@ 2008-02-28  9:27   ` James Chapman
  2008-02-28 16:19     ` Kevin Lloyd
  0 siblings, 1 reply; 7+ messages in thread
From: James Chapman @ 2008-02-28  9:27 UTC (permalink / raw)
  To: Dan Williams; +Cc: Kevin Lloyd, netdev

Dan Williams wrote:
> On Wed, 2008-02-27 at 17:28 -0800, Kevin Lloyd wrote:
>> Hi all,
>>
>> I have a device that is currently supported via a combination of loading the device with usb-serial (drivers/usb/serial/sierra) to expose the serial ports and connecting by manually launching pppd.
>> I would like to support this device in a network driver as opposed to a serial driver in an effort to offer a seamless always-on device, such as an Ethernet device.
>>
>> From what I understand the ppp support in the kernel is only for ppp framing and that all control (e.g., IPCP) is done in user-space via pppd. Are there any network drivers that currently manage the ppp connection (entirely, IPCP included) internally to the driver and expose either a raw ip or ethernet stream to the user-space?
> 
> That seems quite icky to do all in kernel space and a pile of code
> running in the kernel.  What's so wrong with userspace?  Don't you need
> to push values to the driver like username/password and get IP config
> out of it (which would involve userspace anyway)?  It just seems like
> there's a different solution to your actual problem here than stuff all
> off pppd into kernel space.

I agree.

Kevin mentions manually launching pppd and the desire for a seamless 
always-on device. I think this could be done using udev/hotplug rules to 
launch/stop pppd automatically when the usb device is hot-plugged. No 
additional kernel support needed.

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Network device driver with PPP
  2008-02-28  9:27   ` James Chapman
@ 2008-02-28 16:19     ` Kevin Lloyd
  2008-02-29 15:02       ` James Chapman
  0 siblings, 1 reply; 7+ messages in thread
From: Kevin Lloyd @ 2008-02-28 16:19 UTC (permalink / raw)
  To: James Chapman, Dan Williams; +Cc: netdev

> That seems quite icky to do all in kernel space and a pile of code
> running in the kernel.  What's so wrong with userspace?  Don't you
need
> to push values to the driver like username/password and get IP config
> out of it (which would involve userspace anyway)?  It just seems like
> there's a different solution to your actual problem here than stuff
all
> off pppd into kernel space.

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.

I understand that typical implementation is to deal with ppp
negotiations in the userspace however are there no devices that have
attempted this in the kernel space / no kernel space modules to aid with
this? Just trying to do a full investigation of all available options,
even if they aren't the best ones.
If not, is there a method for the network driver to launch pppd with a
given set of parameters (not using udev) since the driver would be
determining username/password runtime.

Thanks your help,
-Kevin

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Network device driver with PPP
  2008-02-28 16:19     ` Kevin Lloyd
@ 2008-02-29 15:02       ` James Chapman
  2008-03-01  1:41         ` Kevin Lloyd
  0 siblings, 1 reply; 7+ messages in thread
From: James Chapman @ 2008-02-29 15:02 UTC (permalink / raw)
  To: Kevin Lloyd; +Cc: Dan Williams, netdev

Kevin Lloyd wrote:
>> That seems quite icky to do all in kernel space and a pile of code
>> running in the kernel.  What's so wrong with userspace?  Don't you
> need
>> to push values to the driver like username/password and get IP config
>> out of it (which would involve userspace anyway)?  It just seems like
>> there's a different solution to your actual problem here than stuff
> all
>> off pppd into kernel space.
> 
> 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 understand that typical implementation is to deal with ppp
> negotiations in the userspace however are there no devices that have
> attempted this in the kernel space / no kernel space modules to aid with
> this? 

No.

Control protocols live in userspace, datapath in the kernel.

> Just trying to do a full investigation of all available options,
> even if they aren't the best ones.

> If not, is there a method for the network driver to launch pppd with a
> given set of parameters (not using udev) since the driver would be
> determining username/password runtime.

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?


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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Network device driver with PPP
  2008-02-29 15:02       ` James Chapman
@ 2008-03-01  1:41         ` Kevin Lloyd
  2008-03-01 12:08           ` James Chapman
  0 siblings, 1 reply; 7+ messages in thread
From: Kevin Lloyd @ 2008-03-01  1:41 UTC (permalink / raw)
  To: James Chapman; +Cc: Dan Williams, netdev

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

> 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? Also is it pppd that directly sets
up the network interface in ifconfig? I'm a little confused/lost here...

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

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

Thanks for your help,
-Kevin

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Network device driver with PPP
  2008-03-01  1:41         ` Kevin Lloyd
@ 2008-03-01 12:08           ` James Chapman
  0 siblings, 0 replies; 7+ messages in thread
From: James Chapman @ 2008-03-01 12:08 UTC (permalink / raw)
  To: Kevin Lloyd; +Cc: Dan Williams, netdev

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-03-01 12:08 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-28  1:28 Network device driver with PPP Kevin Lloyd
2008-02-28  2:15 ` Dan Williams
2008-02-28  9:27   ` James Chapman
2008-02-28 16:19     ` Kevin Lloyd
2008-02-29 15:02       ` James Chapman
2008-03-01  1:41         ` Kevin Lloyd
2008-03-01 12:08           ` James Chapman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).