About ppp_receive()

About ppp_receive()

[Steven]

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

Hi,

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?

In CDMA 2000 environment, just as the Sprint Network, PPP should support 
  a compressed protocol field. Is there anything difference between GSM 
and CDMA?

B.R

Steven

---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

Re: About ppp_receive()

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 894 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?
> 
> In CDMA 2000 environment, just as the Sprint Network, PPP should support 
>   a compressed protocol field. Is there anything difference between GSM 
> and CDMA?

in GSM we are not using PPP over the air interface. The PPP session is
only between oFono and the modem hardware. If CDMA also talks PPP over
the air interface then that would be really sad :(

Regards

Marcel

RE: About ppp_receive()

[Zhang, Zhenhua]

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

Hi Steven,

Steven wrote:
> Hi,
> 
> 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?

Thanks.
Zhenhua

> In CDMA 2000 environment, just as the Sprint Network, PPP should
>   support a compressed protocol field. Is there anything difference
> between GSM 
> and CDMA?
> 
> B.R
> 
> Steven
> 
> ---------------------------------------------------------------------------------------------------
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

Re: About ppp_receive()

[Steven]

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

Hi Zhenhua

Zhang, Zhenhua wrote:
> Hi Steven,
> 
> Steven wrote:
>> Hi,
>>
>> 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().

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.

First byte of PPP protocol field may be compressed, if the LS bit is 1 
then this indicates that the upper protocol us compressed, because the 
upper byte should be even, the lower byte should be odd.

>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>   support a compressed protocol field. Is there anything difference
>> between GSM 
>> and CDMA?
>>
>> B.R
>>
>> Steven

B.R

Steven
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

RE: About ppp_receive()

[Zhang, Zhenhua]

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

Hi Steven,

Steven wrote:
> Hi Zhenhua
> 
> Zhang, Zhenhua wrote:
>> Hi Steven,
>> 
>> Steven wrote:
>>> Hi,
>>> 
>>> 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.

Yes. It's handled in the LCP layer. The code is majorly implemented by Kristen and Denis. Maybe they could have more comments on that.

> 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().

Agree, we don't have pcompress, accompression like pppd yet. So patches are welcome to improve that part.

Btw, I do see some code related with MAGIC_NUMBER in ppp_lcp.c.

> 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.

I don't understand why having such policy at all. Your code defintely won't leak any IP since we all follow with the standard spec.

> First byte of PPP protocol field may be compressed, if the LS bit is 1
> then this indicates that the upper protocol us compressed, because the
> upper byte should be even, the lower byte should be odd.
> 
>>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>>   support a compressed protocol field. Is there anything difference
>>> between GSM and CDMA?
>>> 
>>> B.R
>>> 
>>> Steven
> 
> B.R
> 
> Steven
> ---------------------------------------------------------------------------------------------------
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

Re: About ppp_receive()

[Steven]

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

Hi Zhenhua,

Zhang, Zhenhua wrote:
> Hi Steven,
> 
> Steven wrote:
>> Hi Zhenhua
>>
>> Zhang, Zhenhua wrote:
>>> Hi Steven,
>>>
>>> Steven wrote:
>>>> Hi,
>>>>
>>>> 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.
> 
> Yes. It's handled in the LCP layer. The code is majorly implemented by Kristen and Denis. Maybe they could have more comments on that.
> 
>> 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().
> 
> Agree, we don't have pcompress, accompression like pppd yet. So patches are welcome to improve that part.
> 
> Btw, I do see some code related with MAGIC_NUMBER in ppp_lcp.c.
> 

I will check it.

>> 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.
> 
> I don't understand why having such policy at all. Your code defintely won't leak any IP since we all follow with the standard spec.
>


In my company, i can't using git, usb or any other thing which contact 
with the outer world, but the only thing i can use to contact with the 
outer world is MY THUNDERBIRD!!!:(, It's a awful thing.

Maybe i can commit my patch when i go home:), if my son doesn't annoy me.

>> First byte of PPP protocol field may be compressed, if the LS bit is 1
>> then this indicates that the upper protocol us compressed, because the
>> upper byte should be even, the lower byte should be odd.
>>
>>>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>>>   support a compressed protocol field. Is there anything difference
>>>> between GSM and CDMA?
>>>>
>>>> B.R
>>>>
>>>> Steven
>> B.R
>>
>> Steven


---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

Re: About ppp_receive()

[Steven]

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

Hi Zhenhua,

Zhang, Zhenhua wrote:
> Hi Steven,
> 
> Steven wrote:
>> Hi Zhenhua
>>
>> Zhang, Zhenhua wrote:
>>> Hi Steven,
>>>
>>> Steven wrote:
>>>> Hi,
>>>>
>>>> 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.
> 
> Yes. It's handled in the LCP layer. The code is majorly implemented by Kristen and Denis. Maybe they could have more comments on that.
> 
>> 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().
> 
> Agree, we don't have pcompress, accompression like pppd yet. So patches are welcome to improve that part.
> 
> Btw, I do see some code related with MAGIC_NUMBER in ppp_lcp.c.

Yes, it has come code about MAGIC_NUMBER, but just placeholder, not 
processing anything, if you interested this, you can reference to the 
corresponding part of RFC 1661.

anyway, if we want to implement a full PPP stack, we have a long way to go.


>> 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.
> 
> I don't understand why having such policy at all. Your code defintely won't leak any IP since we all follow with the standard spec.
> 
>> First byte of PPP protocol field may be compressed, if the LS bit is 1
>> then this indicates that the upper protocol us compressed, because the
>> upper byte should be even, the lower byte should be odd.
>>
>>>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>>>   support a compressed protocol field. Is there anything difference
>>>> between GSM and CDMA?
>>>>
>>>> B.R
>>>>
>>>> Steven
>> B.R
>>
>> Steven

> 

---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

RE: About ppp_receive()

[Zhang, Zhenhua]

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

Hi Steven,

Steven wrote:
> Hi Zhenhua,
> 
> Zhang, Zhenhua wrote:
>> Hi Steven,
>> 
>> Steven wrote:
>>> Hi Zhenhua
>>> 
>>> Zhang, Zhenhua wrote:
>>>> Hi Steven,
>>>> 
>>>> Steven wrote:
>>>>> Hi,
>>>>> 
>>>>> 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.
>> 
>> Yes. It's handled in the LCP layer. The code is majorly implemented
>> by Kristen and Denis. Maybe they could have more comments on that. 
>> 
>>> 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(). 
>> 
>> Agree, we don't have pcompress, accompression like pppd yet. So
>> patches are welcome to improve that part. 
>> 
>> Btw, I do see some code related with MAGIC_NUMBER in ppp_lcp.c.
>> 
> 
> I will check it.
> 
>>> 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.
>> 
>> I don't understand why having such policy at all. Your code
>> defintely won't leak any IP since we all follow with the standard
>> spec.  
>> 
> 
> 
> In my company, i can't using git, usb or any other thing which contact
> with the outer world, but the only thing i can use to contact with the
> outer world is MY THUNDERBIRD!!!:(, It's a awful thing.
> 
> Maybe i can commit my patch when i go home:), if my son doesn't annoy
> me. 

Sure. Git is so powerful that you can definitely work any place you like to. You only need the network when you do 'git pull' and 'git send-email'. ;-)

>>> First byte of PPP protocol field may be compressed, if the LS bit
>>> is 1 then this indicates that the upper protocol us compressed,
>>> because the upper byte should be even, the lower byte should be odd.
>>> 
>>>>> In CDMA 2000 environment, just as the Sprint Network, PPP should
>>>>>   support a compressed protocol field. Is there anything
>>>>> difference between GSM and CDMA? 
>>>>> 
>>>>> B.R
>>>>> 
>>>>> Steven
>>> B.R
>>> 
>>> Steven
> 
> 
> ---------------------------------------------------------------------------------------------------
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader of this communication is not the intended recipient,
> unauthorized use, forwarding, printing,  storing, disclosure or
> copying is strictly prohibited, and may be unlawful.If you have
> received this communication in error,please immediately notify the
> sender by return e-mail, and delete the original message and all
> copies from your system. Thank you.
> ---------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono


Regards,
Zhenhua

Re: About ppp_receive()

[Denis Kenzior]

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

Hi Steven,

>>> 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().
>>

We explicitly do not advertise capability to receive PFC or ACFC
packets.  If the remote peer PPP stack is compliant it should not be
sending such packets in the first place.

Are you saying you're working with a PPP stack that is not compliant and
not honoring our request not to send ACFC or PFC packets?

> 
> anyway, if we want to implement a full PPP stack, we have a long way to go.
> 

That's the point, we actually do not want to implement a full PPP stack.
 Only enough to talk to the relatively unsophisticated PPP stacks
running inside the modem firmware.  Remember, PPP is simply used host to
modem.  It is not used over the air.

Regards,
-Denis

Re: About ppp_receive()

[Steven]

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

Denis Kenzior wrote:
> Hi Steven,
> 
>>>> 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().
> 
> We explicitly do not advertise capability to receive PFC or ACFC
> packets.  If the remote peer PPP stack is compliant it should not be
> sending such packets in the first place.

Yes,We do not advertise capability to receive PFC or ACFC, just like i 
have said

 >>>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.

> 
> Are you saying you're working with a PPP stack that is not compliant and
> not honoring our request not to send ACFC or PFC packets?
> 

NO, just as the above have said ,we only negotiate two options, it's ok 
for our PPP stack and it runs correctly.

>> anyway, if we want to implement a full PPP stack, we have a long way to go.
>>
> 
> That's the point, we actually do not want to implement a full PPP stack.
>  Only enough to talk to the relatively unsophisticated PPP stacks
> running inside the modem firmware.  Remember, PPP is simply used host to
> modem.  It is not used over the air.

yes, i got it.

B.R

Steven
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

Re: About ppp_receive()

[Denis Kenzior]

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

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? :)

Regards,
-Denis

Re: About ppp_receive()

[Steven]

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

Hi Denis,

Denis Kenzior wrote:
> 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.

B.R

Steven



---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

Re: About ppp_receive()

[Marcel Holtmann]

[-- 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

Re: About ppp_receive()

[Marcel Holtmann]

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

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

Re: About ppp_receive()

[Steven]

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

Marcel Holtmann wrote:
> 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

I got it.

> and the modem hardware/firmware moves over to highspeed direct IP
> interfaces.

I like to know this tech, is there any spec on this topic?

B.R

Steven
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

Re: About ppp_receive()

[Marcel Holtmann]

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

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
> 
> I got it.
> 
> > and the modem hardware/firmware moves over to highspeed direct IP
> > interfaces.
> 
> I like to know this tech, is there any spec on this topic?

check oFono's Ericsson MBM or Option HSO support. Or Google for it.

Regards

Marcel

Re: About ppp_receive()

[Steven]

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

Hi Marcel,

Marcel Holtmann wrote:
> 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
>> I got it.
>>
>>> and the modem hardware/firmware moves over to highspeed direct IP
>>> interfaces.
>> I like to know this tech, is there any spec on this topic?
> 
> check oFono's Ericsson MBM or Option HSO support. Or Google for it.

  Thanks for your sharing. I will dig it.

Regards

Steven
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------

Re: About ppp_receive()

[Steven]

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

Hi Marcel,

Steven wrote:
> Hi Marcel,
> 
> Marcel Holtmann wrote:
>> 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
>>> I got it.
>>>
>>>> and the modem hardware/firmware moves over to highspeed direct IP
>>>> interfaces.
>>> I like to know this tech, is there any spec on this topic?
>>
>> check oFono's Ericsson MBM or Option HSO support. Or Google for it.
> 
>  Thanks for your sharing. I will dig it.


This time, I'm totally understand why to implement this PPP stack in 
Ofono in GSM world.
Thanks.

Regards

Steven


---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------