Re: About ppp_receive()

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