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.

Regards

Marcel