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 _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
