Open Source Telephony
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: About ppp_receive()
Date: Wed, 25 Aug 2010 06:12:10 +0200	[thread overview]
Message-ID: <1282709530.6841.38.camel@localhost.localdomain> (raw)
In-Reply-To: <4C747268.3020300@neusoft.com>

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

Hi Steven,

> >> In function ppp_receive, we first check the protocol type of this
> >> frame 
> >> like:
> >>
> >>   guint16 protocol = ppp_proto(buf);
> >>
> >> and here we assumed the length of the protocol field is 16 bits, but
> >> in 
> >> RFC 1661, the protocol field should be one or two octets.
> >>
> >> "The Protocol field is one or two octets, and its value identifies
> >> the datagram encapsulated in the Information field of the packet."
> >>
> >> why we given the assumption that protocol field is 16 bit length?
> > 
> > First I am not ppp expert. :-).
> > 
> > If you take look at pppd source code, main.c, get_input() also always fetch two bytes 'protocol' for struct protent as well.
> > 
> > Can you give a case we failed in our ppp stack?
> 
> If you interested in this topic, you can reference RFC 1661 Section 6.5, 
> which said
> 
> --------------
> This Configuration Option provides a method to negotiate the
> compression of the PPP Protocol field. By default, all
> implementations MUST transmit packets with two octet PPP Protocol
> fields.
> PPP Protocol field numbers are chosen such that some values may be
> compressed into a single octet form which is clearly
> distinguishable from the two octet form. This Configuration
> Option is sent to inform the peer that the implementation can
> receive such single octet Protocol fields.
> -------------
> 
> In our current source code, because we only negotiate two configuration 
> options - REQ_OPTION_MRU and REQ_OPTION_ACCM. so it's okey for our PPP 
> stack.
> 
> But some carriers, like China Telecom or Sprint Network etc, will 
> support the full configuration 
> options(Magic-Number,Protocol-Field-Compression,Address-and-Control-Field-Compression),
> So if PFC option is used ,our code will got wrong with ppp_receive().

in the GSM world, the PPP is between the oFono and the modem hardware.
Not between oFono and the network. So for GSM we don't even care single
bit what the networks wants since it never sees PPP.

I asked this before, CDMA talks PPP over the air to the network? That
would be rather stupid and a big waste.

> We should first check if PPP protocol field is compressed or not, and 
> then get the right protocol value to form a 16 bits protocol field, and 
>   pass this value to the rest functions.
> 
> Because of my company's security policy ,I can't provide a patch for 
> this issue. But i can provide a method for doing this. Here it is.

To be quite blunt with you, this is an open source project. If you have
an itch to scratch then we expect you to send a patch. Telling us what
we have to do or should do is not helping here.

Regards

Marcel



      parent reply	other threads:[~2010-08-25  4:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23  5:42 About ppp_receive() Steven
2010-08-23  9:12 ` Marcel Holtmann
2010-08-24 10:17 ` Zhang, Zhenhua
2010-08-25  1:31   ` Steven
2010-08-25  1:56     ` Zhang, Zhenhua
2010-08-25  2:04       ` Steven
2010-08-25  2:17         ` Zhang, Zhenhua
2010-08-25  2:17       ` Steven
2010-08-25  2:56         ` Denis Kenzior
2010-08-25  3:22           ` Steven
2010-08-25  3:26             ` Denis Kenzior
2010-08-25  3:48               ` Steven
2010-08-25  4:18                 ` Marcel Holtmann
2010-08-25  4:22                   ` Steven
2010-08-25  5:07                     ` Marcel Holtmann
2010-08-25  5:36                       ` Steven
2010-08-25  5:49                         ` Steven
2010-08-25  4:12     ` Marcel Holtmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1282709530.6841.38.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox