Re: [lwip-users] pppos sent packets optionally start with 0x7e, why?

[Sylvain Rochet]

Hi,

On Mon, Jun 07, 2021 at 04:19:45PM +0200, Bas Prins wrote:
> Dear,
> 
> I was looking at the data being sent/received over uart when ppp is being
> negotiated. I was surprised to see that the received byte stream is always
> wrapped in 0x7e bytes (leading + trailing).
> 
> But for some reason this is not the case for the bytes lwip sends
> (/provides to my sio_write function). Even stronger, sometimes it does
> start with a leading 0x7e, sometimes it doesn't.
> 
> On the wiki I read:
> 
> "PPP packets all start and end with 0x7E. If you don't see these, something
> is wrong with your low level driver"

This is not wrong per se, but added to that the end of a frame can also 
be the start of the next frame. That is, the following sequence are two 
valid frames:

0x7e ........ 0x7e ........ 0x7e

What is also usually done is to prepend a 0x7e if the serial link as 
been idle for a while to clear any received noise. We do so in lwIP.


> When I look at fsm.c where the PPP header is created, I don't see 0x7e
> being added as part of the opening header.

HDLC flags and byte stuffing are processed in pppos.c. You are mixing up 
PPP and HDLC but I agree the border between them is blurry ! :)


> pppos works, lwip works, I can open sockets, download from FTP, etc. So
> what's the deal with this? Should I investigate further and is there a bug
> sitting in my code? Or is this "perfectly normal" behavior and is the wiki
> wrong?

This is normal!


Sylvain

signature.asc
Description: Digital signature