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