Re: multiplex mode support

[Marcel Holtmann <marcel holtmann org>]

Hi Dan,

> > > > > Thanks, Dan! I have to deal with such a modem. Except the
> > > > > implementation in kernel. I am interest in the implementation on user
> > > > > space. The problem I may meet:
> > > > > 1. How to get the data from the modem before other module get? From my
> > > > > understanding, for ppp, after the link established, the data only flow
> > > > > in kernel.
> > > > > 2. How to feed the ppp packet into ppp module after decode the
> > > > > multiplexing data?
> > > > > 
> > > > > My first thought to resolve this is using a pty. PPPd seems support
> > > > > pty device. Multiplexing module get the modem data from modem device
> > > > > directly and decode the data and feed the decoded data(if itis  the
> > > > > ppp data) into the pty device which pppd opened.
> > > > > 
> > > > > This si practicable or not? Please give me some light.
> > > > 
> > > > we have done this in a nice library called GAtChat that implements the
> > > > multiplexer and also userspace PPP support. It does everything for you
> > > > including the AT command chat. Works pretty nicely. Just search for it.
> > > > 
> > > > It makes heavy use of GIOChannel and tries to pass data around as
> > > > efficient as possible, but PPP on top of multiplexer is just not really
> > > > a good idea in the first place. Too much encoding and decoding to do
> > > > before you get anything done. We do want to use the kernel support for
> > > > GSM MUX and PPP if possible, but so far we haven't gotten there yet.
> > > 
> > > Have you found the GAtChat PPP implementation (especially option
> > > negotiation) to work pretty well with the modems that Ofono supports at
> > > this time?  There's so many crappy device-side PPP implementations
> > > around, but pppd is also a large pile of code that while it works pretty
> > > well, has a few other issues...
> > 
> > with the set of modems with tested this with (Huawei, Novatel, Nokia and
> > some others) we had no problems. Main reason might be that we don't even
> > bother trying to negotiate any of the PPP options that are not basic.
> > 
> > Since the PPP link is just between the host and the modem, there is not
> > point in trying to be smart. We just get the LCP done and then move on
> > to IPCP to get the IP configuration and then that is it. There could be
> > some bugs in the configuration state machine for sure, but seems that
> > doesn't really matter. So what I am thinking is that pppd tries to
> > overdo it. Simplicity wins here.
> > 
> > If we actually do have a physical TTY underneath, we should not running
> > the packet processing in userspace. We should use the kernel PPP and its
> > control interface. That hasn't been implemented yet. In case we run
> > muxed in userspace we only have a GIOChannel and there we do have to run
> > even the IP packet processing in userspace. So here we have clearly room
> > for improvements.
> > 
> > I have never tested this, but I heard that CDMA/EVDO is running PPP over
> > the air and thus could make use of compression and other advanced
> > features. I couldn't confirm that yet, so no idea if that is true or
> > not.
> 
> Yeah, the PPP link is actually between pppd and the CDMA2000 network's
> PDSN and LCP is actually involved in allocating resources for the link.

in this case our PPP implementation is not really good. We are missing a
bunch of features to make that part efficient. Mainly just compression
for once. Our PPP works nicely for GSM where the endpoint is the modem,
but in the CDMA world, I have no idea. Feel free to give it a spin. The
source code contains a simple gsmdial example that you might can easily
modify into a cdmadial tool. If you do, let us now how we fail here ;)

I think the only way to make this work properly is to get the kernel PPP
integrated in our PPP implementation and negotiate the missing options.
I don't wanna implement compression in userspace. That is just
pointless. We currently use TUN/TAP since we need it if we run over a
virtual GIOChannel (multiplexed case) and it was so simple to do that it
was good enough.

Using the kernel PPP is not that complicated either. In the end it
pre-parses LCP, IPIP etc. for us and lets us handle this. It only takes
over when we reach a proper state. Just nobody has bothered so far.

Regards

Marcel