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.

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.

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

Hi, 2009/11/13 Chris Pitchford <ofono(a)intrepid.cx&gt;: > 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.

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

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

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.