[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] PPP
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] PPP |
Date: |
Sat, 23 Jun 2012 20:13:23 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi Nick,
On Sat, Jun 23, 2012 at 08:38:04PM +0300, N.Karakotas wrote:
> Hi Sylvain,
>
> The uart is a circular buffer and is protected by a lock. Im looking at the
> dump:
>
> dump_packet("sent", (unsigned char *)nb->payload+2, nb->len-2);
>
> Maybe that's why you are not seeing the 0xff 0x03?
dump_packet() takes as argument a PPP payload without the "HDLC" 2 byte
header, because this is meaningless to display and above all because
PPPoE don't have it.
What I tried to explain is that in the dump you sent, we can extract:
sent [proto=0x237d] c0 21 7d 21 7d 21 7d 20 7d 34 7d 22 7d 26 7d 20 ....
^^^^^^^
HDLC Framing
^^^^^
LCP header
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
HDLC Framing
A 2 byte offset packet would look like:
[proto=0xff03] c0 21 ... LCP payload ...
This is why I said that even the PPP "HDLC" header seem corrupted if it
was only an offset issue.
> I commented it out but got jargon: 0x07 0x23
Looks like HDLC framing as well.
The dump_packet() function is called just after PPP created a control
packet, at least in the latest revision of the ppp-new branch, that was
not ever the case.
The PPP control stack do not know anything about PPPoS HDLC-like
Framing, so this is impossible, except memory corruption, to get HDLC
Framing there.
Sylvain
signature.asc
Description: Digital signature