[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] PPP: IPCP bad fcs issue
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] PPP: IPCP bad fcs issue |
Date: |
Wed, 15 Aug 2018 22:19:11 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hi,
On Wed, Aug 15, 2018 at 03:40:22PM -0400, Patrick Klos wrote:
> On 8/15/2018 11:25 AM, Axel Lin wrote:
> >Hi list,
> >
> >I'm testing a LTE module with lwIP and found always got bad fcs as below.
> >I dump the received data below:
> >Is there anything wrong in the received data?
> >
> >sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2
> >0.0.0.0>]␍␊
> >pppos_write[0]: len=26␍␊
> >pppos_input[0]: got 17 bytes␍␊
> >7e ff 3 80 21 1 1 16 3 6 81 6 83 6 6e db 7e ␍␍␊
> >pppos_input[0]: Dropping bad fcs 0x4114 proto=0x8021␍␊
>
> That doesn't look like a good PPP packet.
>
> ff 3 80 21 1 1 16 3 6 81 6 83 6 6e db
>
> ff 03 = address and control field
> 80 21 = IPCP protocol ID
> 01 = Configure request
> 01 = Identifier
> 16 03 = SHOULD BE PACKET LENGTH
Added to that, there is something very wrong here, HDLC checksum
(polynomial 0x1021, init 0xffff, xor final 0xffff, reflected input,
reflected result, network byte order result) for "0xff 0x03 0x80 0x21
0x01 0x01 0x16 0x03 0x6 0x81 0x6 0x83 0x06" is 0x19 0x17 which is
obviously not 0x6e 0xdb.
But what is very strange is that checksum including checksum itself for
comparison purpose for "0x01 0x01 0x16 0x03 0x6 0x81 0x6 0x83 0x06 0x6e
0xdb" is 0xeb 0xbe, which is not 0x4114 (nor 0x1441 with byte swap) as
displayed in your "Dropping bad fcs" debug print, how is that even
possible ?
I just tested on good packets and the debug print actually print 0xf0b8
for FCS which is the PPP_GOODFCS value.
Sylvain
signature.asc
Description: Digital signature