On Sat, 4 Sep 1999, Miles Lane wrote:
> Am I correct in interpretting the following PPP debug output?
> I think it shows my client requesting first Compress compression
> and then Deflate compression. It appears that Compress is
> being rejected. There is no message stating whether the
> deflate compression was accepted. Is Deflate active on my
> connection? What does the line ("LCP ProtRej") indicate?
> Lastly, what does the line ("deflate(old#) 15") mean?
> Do I need to update my Deflate module?
>
...
> sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
> sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
> rcvd [IPCP ConfReq id=0xf5 <addr xxx.xxx.xxx.xxx>]
> sent [IPCP ConfAck id=0xf5 <addr xxx.xxx.xxx.xxx>]
> rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
> sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
> rcvd [LCP ProtRej id=0x19 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15
> 03 2f]
....
I moved this from linux-net to linux-ppp.
<compress VJ ...> is for Van Jacobson TCP/IP header compression, not
packet compression. See the pppd man page. Not a biggie. The dial-up
system just doesn't allow it for whatever reason.
As for the CCP (compression protocol) requests, I didn't see a CCP ConfAck
or ConfRej response in your output. Your system is just listing the
acceptable protocols (current deflate, old deflate, and BSD-Compress).
Nothing wrong here, either. I don't know what the diff is between the old
and current deflate methods, but the source reveals all.
It is rare for an ISP to support packet compression. There is probably no
significant advantage unless you are using a direct connect or a modem
without built-in compression protocols. The software compression does
have somewhat better performance, but you also have additional memory and
CPU overhead.
Geof Goodrum
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
