About ppp_receive()

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?

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

_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono

Hi Steven,

Quoted 15 lines · Steven

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

Quoted 1 line

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?

Quoted 8 lines

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

Hi Zhenhua

Quoted 16 lines · Zhenhua

Hi Steven,

Quoted 13 lines · Steven

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

Quoted 8 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 7 lines

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

Hi Steven,

Quoted 42 lines · Steven

Hi Zhenhua

Quoted 16 lines · Zhenhua

Hi Steven,

Quoted 13 lines · Steven

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

Quoted 7 lines

Quoted 1 line

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

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

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.

Quoted 8 lines

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.

Quoted 4 lines

Quoted 4 lines

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

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

B.R

Steven

B.R

Steven

Hi Zhenhua,

Quoted 57 lines · Zhenhua

Hi Steven,

Quoted 41 lines · Steven

Hi Zhenhua

Quoted 16 lines · Zhenhua

Hi Steven,

Quoted 13 lines · Steven

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

Quoted 7 lines

Quoted 1 line

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

Quoted 3 lines

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.

Quoted 5 lines

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

Quoted 5 lines

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.

Quoted 11 lines

Quoted 6 lines

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.

Quoted 8 lines

Quoted 8 lines

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.

Quoted 4 lines

Quoted 4 lines

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

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

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

Hi Steven,

Quoted 42 lines · Steven

Hi Zhenhua

Quoted 16 lines · Zhenhua

Hi Steven,

Quoted 13 lines · Steven

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

Quoted 7 lines

Quoted 1 line

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

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 14 lines

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.

Quoted 7 lines

Quoted 7 lines

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

Quoted 6 lines

Quoted 5 lines

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

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

Hi Steven,

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 3 lines

Quoted 3 lines

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?

Quoted 2 lines

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.

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

Hi Steven,

Quoted 2 lines

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

Quoted 4 lines

Quoted 2 lines

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.

Hi Steven,

Quoted 9 lines

Quoted 3 lines

Quoted 2 lines

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.

Quoted 13 lines

Quoted 9 lines

Quoted 3 lines

Quoted 2 lines

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.

Quoted 8 lines

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.

Quoted 2 lines

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?

Hi Steven,

Quoted 20 lines

Quoted 20 lines

Quoted 9 lines

Quoted 3 lines

Quoted 2 lines

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

Quoted 5 lines

I got it.

Quoted 2 lines

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.

Hi Marcel,

Quoted 26 lines · Marcel Holtmann

Hi Steven,

Quoted 24 lines

Quoted 19 lines

Quoted 10 lines

Quoted 4 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

Quoted 2 lines

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.

Quoted 13 lines

Quoted 13 lines

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

Quoted 7 lines

Quoted 1 line

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.