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