lwip-users
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]