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

[pptp_list at gizzard.org]

Hi Eric,  Thanks much for your input.  Unfortunately I'm still scratching
the hiesenbug here and I think that I am actually going to have to read
the RFC you mentioned (gasp!).

> One thing I think you've got wrong: 'noauth' in your options file. I
> believe that lets clients connect without authentication, which will break
> mppe since it uses the authentication to generate it's keys for
> encryption.

I cant authenticate if I require 'auth' as a client.  If I require 'auth'
as a client, doesn't that simply force the WinNT server to authenticate
itself to me?  
I think that I read somewhere that this wasn't a good idea to
demand this on the client side except for unique situations.  But, like I
said before, I'm gonna have to read the docs out there and get more
intimate with all of this.

> 
> The 'fix' I sent is only for a specific case. Does it work ok if you only
> download from the pptp server? If so, then you may have the same problem I
> had. I wrote a fix for it, but I'm not certain how good it is... It does
> work for me though... (The idea was to make it work according to the RFC I
> included in the original message... Stateless is simple, it just
> supposed to update the counter and thus the key). The main problem is when
> DECOMP_ERROR is returned it disables 'compression' actually
> encryption/decryption, which is why you see the 'rcvd' lines in your log.
> After that point the session is useless... 

That makes sense and corresponds with what I've seen so far.  I get the
'rcvd' lines at the same moment I get the  'decomp err -1' kernel msg.

> A good way to check is by
> trying to connect without mppe, and seeing if transfers work fine (They
> did in my case).

Not really an option... It is the corporate lan so they aren't going to
lower their guard so I can run tests at night (paranoid bastards!)...
> 
> On Sun, 18 Jun 2000, Rob Fairchild wrote:
> 
> #=- 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
> (Actually according to the RFC I mentioned, this is ok...)
> 
> #=- the final
> #=- mppe_update_count() call after we had brought (seq == state->count) ?
> (I believe that extra update is not correct, but I never got in contact
> with the original coder, so I don't know for certain.)

Yeah, that extra mppe_update_count() looked smelly to me and thats why I
mentioned it.  Could be legit though, I'll be the first to admit that I
don't know what the hell is going on in there.

Once again thanks all for your help.
Sincerely,
Rob.