All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arthur Paulino <arthurpaulino@great.ufc.br>
To: linux-ppp@vger.kernel.org
Subject: Re: PPP compression
Date: Fri, 19 Dec 2014 17:28:06 +0000	[thread overview]
Message-ID: <54946026.60005@great.ufc.br> (raw)
In-Reply-To: <3b4526880d737ed5094d632636e6fef8@great.ufc.br>

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

Hi,

I tried to use pppdump with -p and -d. The input file I used was the 
pcap file (packets.pcap) generated by tcpdump.
Unfortunately, pppdump prints almost the exact payload as the compressed 
ppp data, meaning it's not decompressing the payload when it should be.

I attached:
-the original pcap file (packets.pcap);
-a file containing the payload in hex (HEX_packets.txt);
-a readable text file containing the packets (packets.txt)
-and the pppdump_output.txt

I don't know what I'm doing wrong. Could you help me out?

On 18/12/2014 18:24, James Carlson wrote:
> On 12/18/14 15:49, arthurpaulino wrote:
>> We configured a PPTP VPN server with no encryption. The compression
>> algorithm negotiated during the connection phase is Deflate.
> The simplest method (of course) would be to disable compression and just
> avoid the issue.
>
> But assuming you don't want to do that, there are two other options:
>
> - If you're actually running pppd, you could use the "record" option
>    to record raw data and then dump using pppdump.  That tool has a
>    "-d" option to decompress this kind of data.
>
> - If you're not running pppd, and have just GRE-encapsulated data
>    captured off the network, then I suggest writing a small tool that
>    will extract the PPP frames (ff 03 ...) and rewrite them to a file
>    in the very simple format that pppdump expects so that you can use
>    pppdump to display them.
>
> The file format can be deduced by looking at the code in pppdump.c.
> For a really trivial converter (payload only), you can use:
>
>    01 LL LL ...   - sent data, where LLLL is the number of bytes in
>                     big endian (network byte order) format.
>    02 LL LL ...   - received data, same format.
>
> Note that pppdump expects the data to be AHDLC encoded (!) so you
> have to do that before doing the encoding above.  AHDLC is pretty
> simple; replace any instance of 7D or 7E in the data with 7D 5D or 7D 5E
> (respectively) and then end the frame with 7E.
>


[-- Attachment #2: packets.zip --]
[-- Type: application/x-zip-compressed, Size: 12722 bytes --]

  parent reply	other threads:[~2014-12-19 17:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 20:49 PPP compression arthurpaulino
2014-12-18 21:24 ` James Carlson
2014-12-19 17:28 ` Arthur Paulino [this message]
2014-12-20 21:24 ` James Carlson
2014-12-21 18:37 ` Michael Richardson
2014-12-22 12:34 ` James Carlson
2014-12-22 18:06 ` arthurpaulino
2014-12-22 19:09 ` James Carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54946026.60005@great.ufc.br \
    --to=arthurpaulino@great.ufc.br \
    --cc=linux-ppp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.