All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: ppp
Date: Fri, 13 Nov 2009 13:23:28 +0100	[thread overview]
Message-ID: <1258115008.3299.19.camel@violet> (raw)
In-Reply-To: <20091113121338.168862sljn41kiw4@boatman.intrepid.co.uk>

[-- Attachment #1: Type: text/plain, Size: 3583 bytes --]

Hi Chris,

> >> > Unfortunately it is not that simple.  pppd requires a proper kernel file
> >> > descriptor to hand off to the kernel ppp line discipline.  In our  
> >> userspace
> >> > implementation that is not the case.  1 kernel file descriptor is  
> >> shared by
> >> > potentially many GAtChat channels using a multiplexing protocol.   
> >> Hence why we
> >> > can't reuse the kernel implementation.
> >> >
> >>
> >> Not sure how relevant this is, but many many years ago (1997) I used a
> >> "telnet modem" to circumvent a firewall. It was a user land process that
> >> presented a fake /dev/modem which I used using pppd and chat..
> >>
> >> My machine was behind a firewall with a telnet proxy.. Using the software
> >> + pppd + chat, it was set up along the lines:
> >>
> >> start telnet modem which presented a /dev/modem.. start pppd using
> >> /dev/modem:
> >>
> >> ATDT 1.2.3.4
> >> CONNECT 1.2.3.4
> >> the-telnet-proxy>
> >> telnet my.host 23
> >> connected to my.host:23
> >> login:
> >> mypppuser
> >> password:
> >> mypassword
> >> end of chat script... start pppd
> >>
> >> In this situation, pppd and the kernel device would have been
> >> communicating with a local userland process. The TCP connection to 1.2.3.4
> >> created by the telnet modem could not have been used by the ppp interface
> >> as the telnet modem was passing the streams in either direction
> >> essentially joining the fd of the telnet connection and fd used by pppd..
> >>
> >> I'm not sure if the requirements of ppp in the kernel have chagned, but
> >> couldn't something like this be repeated in this situation.. allowing pppd
> >> to speak to a local socket/fifo/pair of pipes that is terminated in user
> >> space?
> >
> > yes we could do that, but why bother with a PTY to push the data packets
> > into the kernel. At that point we can also run PPP in userspace and use
> > a TUN/TAP device to create our network interface. The question is when
> > do we wanna move the data from userspace into the kernel.
> >
> > Also pppd does the whole setup of PPP session. The ppp_generic in the
> > kernel only das the data packets transport. Meaning the PPP session
> > setup needs to be done in userspace anyway.
> >
> 
> I understand your point about the setup being done in user space, but  
> would it not be faster to present a vanilla pppd with a pty and allow  
> it to setup the connection and pass data to the kernel interface  
> rather than providing a new implementation? I mean from the point of  
> view of reusing software that is already available and very well tested?

if you look at the pppd code and tell us how to control it properly from
within another daemon, then we can talk. That is just stupid to the end
and would require massive extension of pppd. Also it ends up setting IP,
routing and DNS details and some other magic. It works as a quick hack,
but in the long run needs to be replaced.

> On the down side I see the "eeeew" factor of creating a pty pair just  
> to pass data about, but if it means that far less code needs to be  
> written (and much less code that is to interpret line traffic) I  
> thought it might be safer solution. For example, if pppd is used, it  
> already supports a wealth of authentication and feature negotiation.

And the authentication etc. is not really that much with GSM cards. They
are fairly limited in what they support. Especially since PPP only run
between the card and the host. It doesn't go over the network.

Regards

Marcel



  reply	other threads:[~2009-11-13 12:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12 13:58 ppp Ryan Raasch
2009-11-12 18:37 ` ppp Denis Kenzior
2009-11-12 18:42   ` ppp Ryan Raasch
2009-11-12 19:39   ` ppp Chris Pitchford
2009-11-13 11:31     ` ppp =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-11-13 11:53       ` ppp Chris Pitchford
2009-11-14 18:50         ` ppp Andrzej Zaborowski
2009-11-14 19:26           ` ppp Chris Pitchford
2009-11-15  9:09             ` ppp =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
2009-11-13 12:02     ` ppp Marcel Holtmann
2009-11-13 12:13       ` ppp Chris Pitchford
2009-11-13 12:23         ` Marcel Holtmann [this message]
2009-11-13 11:30   ` ppp =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont
  -- strict thread matches above, loose matches on Subject: below --
2002-10-22 16:17 PPP Pooja Nagpal
2002-10-23 12:18 ` PPP Harry Kalogirou
2002-05-06 22:23 ppp Russell Coker
2002-05-07  3:43 ` ppp John Summerfield
2002-05-07  4:57   ` ppp Russell Coker
2002-05-07 14:22 ` ppp Stephen Smalley
2002-05-08  0:28   ` ppp Russell Coker
2002-05-08 13:13     ` ppp Stephen Smalley
2002-05-09  4:41       ` ppp Russell Coker
2002-05-09 13:48         ` ppp Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1258115008.3299.19.camel@violet \
    --to=marcel@holtmann.org \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.