ppp

ppp

[Ryan Raasch]

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

Hello,

We need a ppp interface for our modem. I was told on the chat forum that 
a tap/tun device was to be used. Has anyone else started with this or 
thought how to implement this?

After reading briefly the code from pppd, the implementation, for a 
first draft, is pretty straight forward (w/o encryption, etc. in 
userspace). "Just" dial the apn, and hand over the tty fd to ppp via ioctl.

Steps (borrowed from pppd):

1. Dial the apn (in ofonod).
2. Some synchronization code.
3. hand over tty fd to ppp driver via ioctl. the IP.

I know i am simplifying the process.

Is this the way to go?


Regards,
Ryan

Re: ppp

[Denis Kenzior]

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

Hi Ryan,

> Hello,
>
> We need a ppp interface for our modem. I was told on the chat forum that
> a tap/tun device was to be used. Has anyone else started with this or
> thought how to implement this?

We're currently working on a userspace ppp implementation that will integrate 
with GAtChat.  The goal here is to make it integrate well with the current 
multiplexed channel capability in GAtMux/GatChat and not need to involve an 
external daemon.

>
> After reading briefly the code from pppd, the implementation, for a
> first draft, is pretty straight forward (w/o encryption, etc. in
> userspace). "Just" dial the apn, and hand over the tty fd to ppp via ioctl.
>

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.

Regards,
-Denis

Re: ppp

[Ryan Raasch]

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



Denis Kenzior wrote:
> Hi Ryan,
> 
>> Hello,
>>
>> We need a ppp interface for our modem. I was told on the chat forum that
>> a tap/tun device was to be used. Has anyone else started with this or
>> thought how to implement this?
> 
> We're currently working on a userspace ppp implementation that will integrate 
> with GAtChat.  The goal here is to make it integrate well with the current 
> multiplexed channel capability in GAtMux/GatChat and not need to involve an 
> external daemon.
> 

Wow. So ofono will not use the kernel space ppp and implement the ppp 
stack in userspace?

>> After reading briefly the code from pppd, the implementation, for a
>> first draft, is pretty straight forward (w/o encryption, etc. in
>> userspace). "Just" dial the apn, and hand over the tty fd to ppp via ioctl.
>>
> 
> 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.
> 

Yea. That's right.

> Regards,
> -Denis
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Re: ppp

[Chris Pitchford]

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


On Thu, 12 Nov 2009, Denis Kenzior wrote:

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

I'll see if I can drag the code out to see what it actually did.. and 
even better see if I can get it to work on a 2.6 kernel!!

Re: ppp

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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


On Thu, 12 Nov 2009 12:37:30 -0600, Denis Kenzior <denkenz@gmail.com>
wrote:
> 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. 

You _could_ create a PTS/PTY pair though...

> Hence why we can't reuse the kernel implementation.

...But I am not sure if the PPP line discipline works correctly on top of
/dev/pts.

-- 
Rémi Denis-Courmont

Re: ppp

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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


On Thu, 12 Nov 2009 19:39:40 +0000 (GMT), Chris Pitchford
<ofono@intrepid.cx> wrote:
> 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?

In my understanding, PPP is a line discipline, meaning it can only run on a
TTY character device device, not just any character device, and definitely
not any random file descriptor.

-- 
Rémi Denis-Courmont

Re: ppp

[Chris Pitchford]

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


Quoting Rémi Denis-Courmont <remi@remlab.net>:

>
> On Thu, 12 Nov 2009 19:39:40 +0000 (GMT), Chris Pitchford
> <ofono@intrepid.cx> wrote:
>> 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?
>
> In my understanding, PPP is a line discipline, meaning it can only run on a
> TTY character device device, not just any character device, and definitely
> not any random file descriptor.

turns out that the software I mentioned (virtmodem from 1995) does  
indeed use a pty pair. Although I've not had time during the week to  
get it running again, I suspect it would probably work on a recent  
kernel/pppd.

Is the line discipline so much of an issue when using ppp connected to  
a fake tty? could that not be handed on the proxy side inside ofono?

Re: ppp

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2133 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.

Regards

Marcel

Re: ppp

[Chris Pitchford]

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


Quoting Marcel Holtmann <marcel@holtmann.org>:

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

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?

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.

I guess there are downsides to both approaches..

Re: ppp

[Marcel Holtmann]

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

Re: ppp

[Andrzej Zaborowski]

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

Hi,

2009/11/13 Chris Pitchford <ofono@intrepid.cx>:
> Is the line discipline so much of an issue when using ppp connected to a
> fake tty? could that not be handed on the proxy side inside ofono?

I've not tried it on a non-tty but it definitely should work modulo
potential bugs that need to be squashed.  It's supposed to work.

However by using a separate process to do ppp you add overhead.  The
original idea in ofono as well as in other projects (think OpenMoko)
was to have both ppp and multiplexing in the kernel to avoid the
context switches when a lot of data is being sent, but this is not
very portable and causes lots of other problems.  Having both in a
single non-kernel process is going to be almost as fast and much more
portable at the expense of reimplementing part of pppd.

Regards

Re: ppp

[Chris Pitchford]

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


> Hi,
>
> 2009/11/13 Chris Pitchford <ofono@intrepid.cx>:
>> Is the line discipline so much of an issue when using ppp connected to a
>> fake tty? could that not be handed on the proxy side inside ofono?
>
> I've not tried it on a non-tty but it definitely should work modulo
> potential bugs that need to be squashed.  It's supposed to work.
>
> However by using a separate process to do ppp you add overhead.  The
> original idea in ofono as well as in other projects (think OpenMoko)
> was to have both ppp and multiplexing in the kernel to avoid the
> context switches when a lot of data is being sent, but this is not
> very portable and causes lots of other problems.  Having both in a
> single non-kernel process is going to be almost as fast and much more
> portable at the expense of reimplementing part of pppd.
>

I've had another thought.. and it doesn't push for pppd, but it introduces 
another idea.

When connecting to an APN for MMS services, there is the possibility of a 
clash of IP addresses both with other APN connections and with other 
internet connections (for example wifi)..


For example: wlan0 192.168.1.20/24 default gw 192.168.1.250

ppp0/tun0: 10.1.1.1 <=> 10.255.255.255

and the MMSC (to which the phone will need to communicate to send/receive 
MMS) is 192.168.1.20

bam.. it clashes with a locally assigned IP address and therefore no 
policy routing will allow a process to reach 192.168.1.20 via the MMS 
interface (or atleast not with excessive engineering)

Other clashes may cause problems too..

To solve the problem, the MMS environment could be run in its own kernel 
network name space. This means the ppp/tun interface would be separate 
from the other interfaces.. this removes the clashing IP address space 
problem.

If pppd were used, it could be "wrapped" in a different address space 
meaning the ppp interface would be localised to an environment that 
carried out all of the MMS communications. What's more, the work would 
require no change to the existing global address space.. it very neatly 
keeps the main environment seperate from the MMS environment that requires 
its own gateway and IP address space..

I appreciate the chances of a clash are slim, but with telcos using 
RFC-1918 and home users mainly using the same the chances of a clash are 
far above zero (and I hear it is a problem for iphone users.. no dig at 
iphones but a colleage reports seeing MMS traffic over his wireless 
connection.. not confirmed but still)

So, if ofonod is responsible for creating tun interfaces, I'm not sure it 
would be possible to isolate them within their own name space and 
therefore allow concurrent "internet" and "mms" access via two different 
connections..

I'm still formulating my thoughts on this one, but I hope it is food for 
thought!

cp

Re: ppp

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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

Le samedi 14 novembre 2009 21:26:38 Chris Pitchford, vous avez écrit :
> When connecting to an APN for MMS services, there is the possibility of a
> clash of IP addresses both with other APN connections and with other
> internet connections (for example wifi)..

You'd have to implement TCP/IP in userspace also, which wouldn't be too nice. 
With recent kernels (2.6.29 and up), you'd rather want to create a new network 
kernel namespace, containing the MMS interface and the one or few processes 
sending or receiving MMS.

That avoids the IP range conflicts while not needing to reimplement TCP/IP. It 
also still works if the modem exposes GPRS through sone kernel driver such 
that you cannot cleanly send and receive IP packets in userspace anyway. 
Currently, there aren't any in oFono, as both PPP and Phonet can provide IP 
packets to userspace. But that does not mean there won't ever be any.

-- 
Rémi Denis-Courmont
http://www.remlab.net/