[pptp-server] rcvd [Compressed data] anyone?

Rob Fairchild rfairchi at gizzard.org
Sun Jun 18 18:33:04 CDT 2000


Hello all,
    Here's my setup
LinuxPptpClient(Home)
->linuxFireWall(seawall)->internet->firewall(unknown)->NtPptpServer (
work )

I can connect from the client to the NtServer, and then run an
ftp client into my network at work. Things look
ok until I start to upload/download data (i.e. I can do dir
listings and get/put small tiny files no problem).  Whenever I use
larger data in the get/put operations, I get the following messages


Jun 18 14:28:32 gizzard pppd[860]: rcvd [Compressed data] 90 4a 48 48 65
91 2f 46 ...
Jun 18 14:31:31 gizzard pppd[860]: rcvd [Compressed data] 90 51 92 06 7f
7a 8fce ...

I get the following kernel messages as well...
Jun 18 14:28:32 gizzard kernel: ppp0: decomp err -1
Jun 18 14:31:31 gizzard kernel: ppp0: decomp err -1

The linux ftp client  hangs after  512 bytes on a get operation and 2048
bytes
on a put.  I don't know if the numbers are significant,  but they are
consistent.

I've read  the list archives and there is lots of mention
of this same problem (especially a few months ago), but nobody
has ever posted a solution that I know of (and please correct me if I am
wrong).
The debug messages are getting generated in the ppp_mppe code in the
mppe_decompress function when (seq != state->ccount).

The problem looks similar to the excellent analysis Charles Duffy did so

I tried what eric at we-24-30-125-179.we.mediaone.net
suggested, i.e.
> If you're expieriencing lost/dropped packets, then there's another
> issue... The easiest fix is to use stateless encryption and in
ppp_mppe.c
> (under your usr/src/linux dir) in the decrypt/decompress function make
it
> loop through the update_count method until the count matches and NOT
> return an error (just continue)."
and that got rid of the 'decomp err' but  the client still hangs as
before.  Honestly,
I dont understand how eric's suggestion could have worked anyways,
because I think
at that point your already FUBAR.   In any case, was I supposed to do
the final
mppe_update_count() call after we had brought (seq == state->count) ?

I've been up many nights with this and have tried getting this to work
with all kinds of ppp patch and kernel version variations and
the failure is the same. Just for completion sakes, here is my current
setup...

 2.2.14-5.0smp , ppp-2.3.10 created from the mppe patch source rpms
(Thanks Adi!).
pptp client 1.02
/etc/ppp/options:
lock
debug
kdebug 7
noipdefault
noauth
+chapms
+chapms-v2
mppe-40
mppe-128
mppe-stateless

I'll skip dumping the full message logs unless anyone can really use
them to help out, I
think that it should be good enough to know that do I successfully
negotiate mppe-128 stateless
with the NT Server.  Also, I doubt that it is my firewall that is
causing the problem because I can
connect MS pptp clients to the destination just fine.


Any help here would be highly appreciated.  I'ts ultra frustrating
because I feel that I am almost
there.  If there are lurkers out there who who are seeing
similar problems or have a fix/suggestion/hint, _please_ do speak up!

Thanks in advance,
Rob.







More information about the pptp-server mailing list