PPP comression and extension info required...

Yes, it supports data compression, and it's enabled by default. See the pppd(1M) man page for details. Note that compression schemes need to be built into your kernel, so what's _actually_ supported depends on what kernel modules you have.

The debug log messages will be helpful here as well, as they indicate which compression algorithms are being negotiated.

I'm not sure what sort of testing you want to do with it, though, so you'll need to be more specific. For what it's worth, I find that passing large amounts of highly-compressible data (such as the letter "A" repeated a few million times in a file) is one good stress test, and passing incompressible data (such as a large bzip2'd file) is another. Each explores a different end in the usual string-based data compression algorithm. The Canterbury Corpus is another fairly well-known test, and is probably a good middle-of-the-road test for passing compressible data.

But there are other forms of "testing" that are possible here, including performance and interoperability, and those may require other sorts of testing schemes and other considerations, so I'm not really sure what it is you're after.

James Carlson         42.703N 71.076W         <[email protected]>

HI,
I wanted to know PPP -extension support , compression ... does it available in the ppp-2.4.4. ? if so how do we test it.? Any info you know to share would be appreciated..

Regards,
Arun

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

Regs,
Arun

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         <[email protected]>

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

Yes, according to your log, the peer (not the host) rejected CCP. That probably means the peer is not capable of processing CCP.

To prevent the host from trying CCP, add the noccp option to the host pppd configuration.

According to manual page for pppd, noccp means "Disable CCP (Compression Control Protocol) negotiation. This option should only be required if the peer is buggy and gets confused by requests from pppd for CCP negotiation."

You will need to fix the peer then. On the evidence provided, it does not support this.

James Cameron
http://quozl.linux.org.au/

HI,
Ok thanks, To agree it is a peer-issue (server ). few things to know..
1) In the logs it shows deflate , bsd is that mean is PPPD tries for
multiple types of encryption and fails? 2)can we run this test for PPPoE?
3) what is shlc ?

Regards,
Arun

HI,
Ok thanks, To agree it is a peer-issue (server ). few things to know..
1) In the logs it shows deflate , bsd is that mean is PPPD tries for
multiple types of encryption and fails? 2)can we run this test for PPPoE?
3) what is shlc ?

Regards,
Arun

Those are some of the supported data compression algorithms that can be negotiated by pppd using CCP. On a good day, it'll try to negotiate all of them and use whatever is in common between the peers. You can see it offering all that it supports at once here:

sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

RFC 1962 specifies that if you ask for multiple types, and if the peer agrees to the list, then what you actually use is the first one on the list ("deflate 15" above). Thus, asking for them all at once is the most reasonable thing to do.

However, if the peer refuses CCP, then it doesn't matter what types of algorithms pppd implements. Refusing CCP is the peer's way of saying "I don't want to talk about data compression at all." It likely means that the peer doesn't implement any sort of data compression, because if it implemented other methods, it would more likely offer some with a Configure-Nak rather than a flat-out rejection. You can see the peer refusing to negotiate data compression here:

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

In PPP, you can refuse to negotiate any protocol or mechanism you want.
If it's refused, there's really nothing pppd can do about it, but
either decide to plow ahead without the requested feature (as is done for CCP) or terminate the link (as might be done for something like CHAP).

Nit: those aren't encryption mechanisms. They're data compression only.

Sure. PPPoE is merely a low-level transport and tunneling mechanism. It has nothing much to do with the PPP options and protocols.

I see nothing called "shlc" in any of your logs, nor do I know of anything by that name. If you have a question about a particular log message or feature, I recommend quoting the actual message or documentation you're reading in order to be clear.

James Carlson         42.703N 71.076W         <[email protected]>

Is it possible you're asking about "slhc?"

If so, then that's the name of the kernel module on Linux that implements VJ header compression. That's yet another header compression mechanism, and is specific to IPv4 TCP. It was basically designed to make the usual 40 byte highly-predictable TCP header squeeze down to two or three bytes, so that interactive data (think: "telnet" or "rlogin") is usable over a slow serial link (think: "modems").

Again, pppd(1M) is your friend. It documents the options for turning VJ header compression on and off and adjusting the number of slots available.

Header compression does not compress the data itself, and is not in any way related to CCP. Instead, VJ header compression is negotiated by IPCP.

(The "slhc" module is Linux-specific, and isn't a generic PPP term. On other OSes, you'll see VJ compression implemented in other ways.)

James Carlson         42.703N 71.076W         <[email protected]>

Ok,
as you said i can verify all compression types on PPPoE test... So i have pppoe-server available at my pc, if you have come across related server configuration for this .... pls do know me. and running PPPoA - test running is not just easy to me as unavailability of the device.

Regs,
Arun

I don't know what you're asking about, but pppd generally enables all available compression modes by default (regardless of the underlying communication mechanism), and will disable a compression mode either if the peer disagrees with the request or if you specify one of the documented options to turn off that mode (or to turn off compression completely).

In other words, if your "server" is actually pppd, then there's nothing that you need to do to enable compression. If it's something other than pppd, then this might not be the right mailing list. You should consult your server's documentation to find out what features it offers.

As for selectively turning off available compression types in pppd, I still urge you to read the pppd man page. It's pretty important. For data compression options, you'll find the following:

noccp, bsdcomp, nobsdcomp, deflate, nodeflate, predictor1, nopredictor1

For header compression (again, _not_ data compression), you'll find:

noaccomp, novj, novjccomp, vj-max-slots

There are also two that are sort of special -- mpshortseq and nompshortseq -- that have to do with header compression when using MP. You haven't mentioned MP yet, so I'll assume you're not using it.

The really short answer is this: PPP negotiates for everything. If both sides support something, then, great, it'll be enabled. If either or both sides don't support something, then it won't be enabled. That's pretty much the whole story.

James Carlson         42.703N 71.076W         <[email protected]>

Ok ,
let me explore on the server side ....!

Could you please guide me thru ppp-extension support ....!

Regs,
Arun

Only if you can be more specific in what sort of guidance you need, and if you've already read through the existing documentation and still have questions. Otherwise, and no offense really intended, it's likely not to be a useful way for either of us to spend time.

What "ppp-extension" are you talking about? Are you talking about the configuration options? The various basic PPP control features? The system-specific kernel modules and features? The possible add-on features? Or something else?

As with other questions, and as I mentioned before, if you have a question about the documentation or about some error or debug message you're seeing, __please__ include a copy of that source material with your question. Providing more context would help.

Based on the messages you've posted to the list so far, and my experience in the area, I suspect you need a different kind of assistance than I think you'll find available for free on mailing lists.
I strongly recommend (as I did in a previous message) searching out
organizations and products that can simplify your job. Surely, your time is worth something to you, and spending it on a reinvention of someone else's wheel can't be a good thing.

The UNH IOL has both interoperability and conformance tests available for vendors at a very reasonable rate. I highly recommend them, and I know some of the folks there if you need pointers. In addition to the IOL, there are also commercial devices available that will do validation tests, such as IxANVL. They're by no means "simple" to operate and interpret, but they're much simpler and more effective than attempting to roll your own tests.

James Carlson         42.703N 71.076W         <[email protected]>

HI James...
Let me understand on extensions.. and revert you...

I just found the features ppp-extension and as you have explained there were multiple concepts in it...!
Thanks,
Arun