ppp and compression

ppp and compression

Post by Michael Nels » Thu, 11 Jan 1996 04:00:00



Running ppp 2.2.0e here with kernel 1.3.55.  I have recently switched over
to connecting to a Livingston IRX router via ppp, and am getting a
protocol reject in my log files.  Here's an example session:

Jan  7 20:43:44 seahunt pppd[2502]: sent [LCP ConfReq id=0x1 <mru 1500>
<asyncmap 0x0> <magic 0xc6561763> <pcomp> <accomp>]
Jan  7 20:43:44 seahunt pppd[2502]: rcvd [LCP ConfAck id=0x1 <mru 1500>
<asyncmap 0x0> <magic 0xc6561763> <pcomp> <accomp>]
Jan  7 20:43:46 seahunt pppd[2502]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0>
 <magic 0xd5c24ebc> <pcomp> <accomp>]
Jan  7 20:43:46 seahunt pppd[2502]: sent [LCP ConfAck id=0x2 <asyncmap 0x0>
 <magic 0xd5c24ebc> <pcomp> <accomp>]
Jan  7 20:43:46 seahunt pppd[2502]: sent [IPCP ConfReq id=0x1 <addr
140.174.70.10> <compress VJ 0f 01>]
Jan  7 20:43:46 seahunt pppd[2502]: sent [CCP ConfReq id=0x1 <bsd v1 15>]
Jan  7 20:43:46 seahunt pppd[2502]: rcvd [IPCP ConfReq id=0x1 <compress VJ
0f 00> <addr 140.174.70.250>]
Jan  7 20:43:46 seahunt pppd[2502]: sent [IPCP ConfAck id=0x1 <compress VJ
0f 00> <addr 140.174.70.250>]
Jan  7 20:43:46 seahunt pppd[2502]: rcvd [IPCP ConfAck id=0x1 <addr
140.174.70.10> <compress VJ 0f 01>]
Jan  7 20:43:46 seahunt pppd[2502]: local  IP address 140.174.70.10
Jan  7 20:43:46 seahunt pppd[2502]: remote IP address 140.174.70.250
Jan  7 20:43:46 seahunt pppd[2502]: rcvd [LCP ProtRej id=0x2 80 fd 01 01
00 07 15 03 2f]            

I _am_ loading bsdcomp as a module prior to starting the ppp session.  
"Compresssion" is enabled on the Livingston end, although I can't tell
from the Livingston documentation if it is vj header compression or the
bsd compression. When I run pppstats with the options to get it to show
compression stats, it appears as if compression is NOT happening:

/var/log # pppstats -v -r -c
 ubyte  upack  cbyte  cpack  ibyte  ipack  ratio |  ubyte  upack  cbyte  
cpack  ibyte  ipack  ratio
     0      0      0      0      0      0   0.00 |      0      0      0    
  0      0      0   0.00
     0      0      0      0      0      0   0.00 |      0      0      0    
  0      0      0   0.00       (sorry 'bout the wrap, but you can see it's
all zeros).

But when I run pppstats without switches:

    in   pack   comp uncomp    err  |    out   pack   comp uncomp     ip
1564938   4886   3137    503      0  | 309915   5479   1754   2837    888
  1446      6      4      2      0  |    330      7      2      5      0
    81      4      3      0      0  |    186      4      1      2      1  

... it DOES look like there is some compression going on.  I guess I am
very confused about this compression business.  Mind you, I _am_
connecting, and my ppp setup SEEMS to be working fine... but I'd like to
understand the ProtRej and the discrepancies between the two pppstats
outputs with regard to compression.

I do have bsd compression enabled in my /etc/ppp/options:

/dev/cua1
38400
crtscts
modem
defaultroute
lock
usehostname
netmask 255.255.255.0
asyncmap 0
debug
persist
bsdcomp 15,15      

I tried a "kill -SIGUSR2 (pid of pppd)" to try to get it to renegotiate
compression per the man page without any result at all:

/var/log # ps -ax | grep pppd
19863 s01 S     0:00 /usr/sbin/pppd connect /usr/sbin/chat -v -f
/etc/ppp/chatfi
26257 pp1 S     0:00 grep pppd

/var/log # kill -SIGUSR2 19863; tail -f debug
Jan  9 03:29:41 seahunt sendmail[25585]: DAA25585:

nrcpts=1, msgid=<"L0jmL.0.gI4.

Jan  9 03:29:43 seahunt sendmail[25586]: DAA25585:

mailer=local, stat=Sent
Jan  9 03:30:23 seahunt xntpd[19883]: time reset (step) -0.428338 s
Jan  9 03:30:23 seahunt xntpd[19883]: synchronisation lost
Jan  9 03:33:05 seahunt sendmail[25655]: DAA25655:

nrcpts=1, msgid=<"ivjz73.0.LK4

Jan  9 03:33:06 seahunt sendmail[25657]: DAA25655:

mailer=local, stat=Sent
Jan  9 03:35:28 seahunt xntpd[19883]: synchronized to 128.115.14.97,
stratum=1
Jan  9 03:35:29 seahunt xntpd[19883]: time reset (step) 0.473161 s
Jan  9 03:35:29 seahunt xntpd[19883]: synchronisation lost
Jan  9 03:40:51 seahunt xntpd[19883]: synchronized to 128.115.14.97,
stratum=1        
...so, I remain confused.

        Michael

PS:

Well, now I'm MORE confused.  I removed the bsd comp option, rmmod
bsd_comp, and killed and restarted pppd.  Now it does not show negotiating
for bsd comp, but I STILL get the same ProtRej in my logs...:

Jan  9 03:56:53 seahunt pppd[26684]: sent [LCP ConfReq id=0x1 <mru 1500>
<asyncmap 0x0> <magic 0xf8092854> <pcomp> <accomp>]
Jan  9 03:56:53 seahunt pppd[26684]: rcvd [LCP ConfAck id=0x1 <mru 1500>
<asyncmap 0x0> <magic 0xf8092854> <pcomp> <accomp>]
Jan  9 03:56:55 seahunt pppd[26684]: rcvd [LCP ConfReq id=0x2 <asyncmap
0x0> <magic 0x4032a0ba> <pcomp> <accomp>]
Jan  9 03:56:55 seahunt pppd[26684]: sent [LCP ConfAck id=0x2 <asyncmap
0x0> <magic 0x4032a0ba> <pcomp> <accomp>]
Jan  9 03:56:55 seahunt pppd[26684]: sent [IPCP ConfReq id=0x1 <addr
140.174.70.10> <compress VJ 0f 01>]
Jan  9 03:56:55 seahunt pppd[26684]: sent [CCP ConfReq id=0x1]
Jan  9 03:56:55 seahunt pppd[26684]: rcvd [IPCP ConfReq id=0x1 <compress
VJ 0f 00> <addr 140.174.70.250>]
Jan  9 03:56:55 seahunt pppd[26684]: sent [IPCP ConfAck id=0x1 <compress
VJ 0f 00> <addr 140.174.70.250>]
Jan  9 03:56:55 seahunt pppd[26684]: rcvd [IPCP ConfAck id=0x1 <addr
140.174.70.10> <compress VJ 0f 01>]
Jan  9 03:56:55 seahunt pppd[26684]: local  IP address 140.174.70.10
Jan  9 03:56:55 seahunt pppd[26684]: remote IP address 140.174.70.250
Jan  9 03:56:55 seahunt pppd[26684]: rcvd [LCP ProtRej id=0x2 80 fd 01 01
00 04]          

...so I guess it has nothing to do with bsd_comp after all.

--

San Francisco, CA

 
 
 

ppp and compression

Post by Harald Koen » Fri, 12 Jan 1996 04:00:00



Quote:> Running ppp 2.2.0e here with kernel 1.3.55.  I have recently switched over
> to connecting to a Livingston IRX router via ppp, and am getting a
> protocol reject in my log files.  Here's an example session:

I just started using PPP and my service provider has a Livingston router too.
not knowing too much about PPP I did the same investigations as you did
and was wondering why I don't the the "red line" how/if this compression stuff
is working and how to interpret the negotiation and pppstats outputs.

if you get any more hints or insights what's going on, please let me know!

Harald
--
All SCSI disks will from now on                     ___       _____
be required to send an email notice                0--,|    /OOOOOOO\
24 hours prior to complete hardware failure!      <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig,                                         \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik                              //  /     \\  \


 
 
 

ppp and compression

Post by Al Longyea » Fri, 12 Jan 1996 04:00:00



> Running ppp 2.2.0e here with kernel 1.3.55.  I have recently switched over
> to connecting to a Livingston IRX router via ppp, and am getting a
> protocol reject in my log files.  Here's an example session:

> Jan  7 20:43:44 seahunt pppd[2502]: sent [LCP ConfReq id=0x1 <mru 1500>
> <asyncmap 0x0> <magic 0xc6561763> <pcomp> <accomp>]
> Jan  7 20:43:44 seahunt pppd[2502]: rcvd [LCP ConfAck id=0x1 <mru 1500>
> <asyncmap 0x0> <magic 0xc6561763> <pcomp> <accomp>]
> Jan  7 20:43:46 seahunt pppd[2502]: sent [CCP ConfReq id=0x1 <bsd v1 15>]
> Jan  7 20:43:46 seahunt pppd[2502]: rcvd [IPCP ConfAck id=0x1 <addr
> 140.174.70.10> <compress VJ 0f 01>]
> Jan  7 20:43:46 seahunt pppd[2502]: local  IP address 140.174.70.10
> Jan  7 20:43:46 seahunt pppd[2502]: remote IP address 140.174.70.250
> Jan  7 20:43:46 seahunt pppd[2502]: rcvd [LCP ProtRej id=0x2 80 fd 01 01
> 00 07 15 03 2f]            

This last message indicates that the peer system does not known what CCP
is. That's ok. This connection wont use it and data will still flow.

Quote:> I _am_ loading bsdcomp as a module prior to starting the ppp session.

Yes. You did load the module. However, since the peer does not support CCP,
your memory for the module is 'wasted'. It simply wont be used.

Quote:> "Compresssion" is enabled on the Livingston end, although I can't tell
> from the Livingston documentation if it is vj header compression or the
> bsd compression. When I run pppstats with the options to get it to show
> compression stats, it appears as if compression is NOT happening:

> /var/log # pppstats -v -r -c

This command displays statistics for the CCP (Compression Control Protocol)
frames and their corresponding use.

Quote:>  ubyte  upack  cbyte  cpack  ibyte  ipack  ratio |  ubyte  upack  cbyte  
> cpack  ibyte  ipack  ratio
>      0      0      0      0      0      0   0.00 |      0      0      0    
>   0      0      0   0.00
>      0      0      0      0      0      0   0.00 |      0      0      0    
>   0      0      0   0.00       (sorry 'bout the wrap, but you can see it's
> all zeros).

> But when I run pppstats without switches:

Without the switches you will see the normal frame information showing
bytes received, frames received, VJ header compressed and non-compressed
frames, and frames received in error. Likewise the transmitter.

Quote:>     in   pack   comp uncomp    err  |    out   pack   comp uncomp     ip
> 1564938   4886   3137    503      0  | 309915   5479   1754   2837    888
>   1446      6      4      2      0  |    330      7      2      5      0
>     81      4      3      0      0  |    186      4      1      2      1  

> ... it DOES look like there is some compression going on.

Ah, yes, there answer is that there are TWO types of compression for PPP.
One is called VJ header compression and effects only the headers for TCP
frames. This is the same compression which is the "C" in what is commonly
(and erronouesly) called CSLIP.

The other type of compression is the result of compressing the entire PPP
frame, header and data. This is defined as the negotiated result of CCP.
However, for CCP to be used, *BOTH* ends must agree to the type of compression
which will be used. You must be able to send compressed frames and the peer must
be able to receive frames. It seems that the Livingston can not understand what
CCP is so it wont be used.

Note: It is totally valid to have compression flow in one direction and not the
other. It is also totally valid to send BSD compression in one direction and
Stacker or Predictor-1 or Predictor-2 or LZS in the other. All that is important
is that the receiver be able to receive what the transmitter wants to send.

Quote:> I guess I am
> very confused about this compression business.  Mind you, I _am_
> connecting, and my ppp setup SEEMS to be working fine... but I'd like to
> understand the ProtRej and the discrepancies between the two pppstats
> outputs with regard to compression.

> I tried a "kill -SIGUSR2 (pid of pppd)" to try to get it to renegotiate
> compression per the man page without any result at all:

Doing this signal wont do anything unless the peer understands CCP. Since
your Livingston terminal server doesn't, then it wont.
 
 
 

ppp and compression

Post by Michael Nels » Sat, 13 Jan 1996 04:00:00


        < a very good answer to my questions about compression >

        Thanks much, Al.  I understand now.

        Michael

--

San Francisco, CA

 
 
 

1. PPP compression vs. modem compression

In reading about modem operations, I learn (is this really true?) that
disabling modem compression will decrease latency.  Clearly though,
there is then a loss of speed when transferring large compressible
files.

If one enables PPP compression does one make up for this?  That is,
is it best to disable modem compression and enable PPP compression
in order to get lower latency but still appropriate compression?

        Hal Sadofsky

2. 386dx\40mhz system

3. ppp (Linux) to ppp (SCO Morningstar): no data compression

4. Hitachi storage soluitions

5. Matrox Mystique ands X.

6. How can I extract files from a file? I'm using linux.

7. Compression algorithm/compression consultant wanted (MD/USA)

8. Linux & Unix Oracle 7.3 Timeouts?

9. VJ compression & Modem compression ?

10. Compression via VMS Data Compression/Expansion (DCX) Routines

11. tape compression on hardware and compression via device ( /dev/rmt/1[m,c]n )

12. How to turn on VJ compression over PPP

13. ppp header compression