From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1007459186158249193==" MIME-Version: 1.0 From: Marcel Holtmann Subject: Re: About ppp_receive() Date: Wed, 25 Aug 2010 06:18:38 +0200 Message-ID: <1282709918.6841.43.camel@localhost.localdomain> In-Reply-To: <4C7492A8.8010902@neusoft.com> List-Id: To: ofono@ofono.org --===============1007459186158249193== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Steven, > >> NO, just as the above have said ,we only negotiate two options, it's ok > >> for our PPP stack and it runs correctly. > > = > > Then I'm confused. What is your concern here? :) > = > currently, we worked on a Qualcomm CDMA chip, and it worked on a Relay = > mode, just relay the air PPP packet to host, and in Ofono we should = > support PFC to satisfy the spec (Sprint Spec.), But Ofono does not = > support PFC, so comes this question. > = > From my personal point, Ofono should support PFC. as you might have clearly figured from Denis and my responses, our PPP code was designed to talk to a modem, not a network. We don't want to implement a full blown PPP stack with all nasty features. If this is needed for CDMA, because they push the PPP frames over the air, then actually getting the kernel PPP frame processing hooked up to our LCP and IPIP userspace code is the right thing to do here. At the moment we are not really putting additional energy into PPP since it is a dying protocol in the GSM world. The networks never required it and the modem hardware/firmware moves over to highspeed direct IP interfaces. Regards Marcel --===============1007459186158249193==--