Well I need to bring up the setup for both data and header compression.. Below are the logs, obtained I can see there is CCP-protocol negotiation initiated and got rejected. 1) Not sure where is wrong ..... is client is up with CCP here? 2) Can we use PPPoE test to do CCP negotiaoin successfully ? Here i provide the logs i got in the test... Regs, Arun LOGS: Plugin pppoatm.so loaded. using channel 1 Using interface ppp0 Connect: ppp0 <--> 8.48 sent [LCP ConfReq id=0x1 <magic 0x9197cda1>] rcvd [LCP ConfAck id=0x1 <magic 0x9197cda1>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... rcvd [LCP ConfReq id=0x9 <auth chap MD5> <magic 0xffe16db>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... sent [LCP ConfAck id=0x9 <auth chap MD5> <magic 0xffe16db>] sent [LCP EchoReq id=0x0 magic=0x9197cda1] rcvd [CHAP Challenge id=0x1 <0ca36321bddd80756467d9f49a764ad3>, name = "ASAMRouter"] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Warning - secret file /etc/ppp/chap-secrets has world and/or group access sent [CHAP Response id=0x1 <31dc4c7b43023d4691446131a9248418>, name = "test"] rcvd [LCP EchoRep id=0x0 magic=0xffe16db] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... rcvd [CHAP Success id=0x1 ""] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... CHAP authentication succeeded CHAP authentication succeeded kernel does not support PPP filtering sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfReq id=0x1 <addr 19.0.0.1>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... sent [IPCP ConfAck id=0x1 <addr 19.0.0.1>] rcvd [LCP ProtRej id=0xa 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... Protocol-Reject for 'Compression Control Protocol' (0x80fd) received rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x2 <addr 13.0.0.20>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... sent [IPCP ConfReq id=0x3 <addr 13.0.0.20>] rcvd [IPCP ConfAck id=0x3 <addr 13.0.0.20>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... local IP address 13.0.0.20 remote IP address 19.0.0.1 Script /etc/ppp/ip-up started (pid 780) Script /etc/ppp/ip-up finished (pid 780), status = 0x1 On Wed, Jun 23, 2010 at 11:47 PM, James Carlson <carlsonj@xxxxxxxxxxxxxxx> wrote: > > arun b wrote: > > Hi James., > > > > Thank you as usual to respond me quick..! > > Well I wanted to validate rfc-1662. > > I see in ppp source deflate, bsd, compression are these covers > > rfc-1662 if so please provide me further info on this > > I'm afraid I still don't really understand. > > RFC 1662 describes AHDLC, which is the low-level framing on async lines, > as well as the other mappings of PPP to octet-synchronous HDLC (read: > SONET/SDH) and bit-stuffed HDLC (read: ISDN and other telecom). It > doesn't really describe much about "compression" except a few header > compression bits. > > Are you really asking about PPP header compression? If so, why? What > could you be testing that would require a specific test for this? > > If you need such a low-level PPP-specific test, I strongly recommend > getting a protocol validation device or employing a service. IXIA's > ixANVL tester can verify low-level details of protocol operation. > Another place to turn would be UNH's IOL. > > If you actually have your own independent implementation (and wanting to > test this low-level detail on your own suggests that you do), then I > really recommend getting the right tools for the job. > > If you don't want to do either of those, then you're probably on your > own. You could perhaps make do by using the existing options described > in pppd(1M) along with either an external analyzer or (perhaps) using > either the pppdump(1M) tool or even kdebug 3. > > But, again, this is just header compression, not data compression. It's > really pretty boring stuff. > > Did you mean RFC 1962 instead? If so, then that's just what > _negotiates_ compression. The actual compression takes place using the > compression algorithms, and these are controlled by the documented > pppd(1M) options and the kernel modules, as I mentioned in my first reply. > > -- > James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
