Re: multiplex mode support

[Dan Williams <dcbw redhat com>]

On Wed, 2010-10-06 at 23:33 +0200, Marcel Holtmann wrote:
> 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.

Dan