[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] [ppp-new] Problems connection on Windows7
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] [ppp-new] Problems connection on Windows7 |
Date: |
Tue, 14 Jan 2014 17:02:28 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi Felipe,
On Tue, Jan 14, 2014 at 01:06:12PM -0200, Felipe Provenzano wrote:
> Thank you Sylvain,
>
> Fortunately, yes, we have enough RAM/FLASH for the extra log \o/
>
> [...]
>
> [ 116:23: tcp] rcvd [proto=0x80fd] 01 02 00 0a 12 06 00 00 00 01
> [ 116:23: tcp] Unsupported protocol 0x80fd received
Everything is fine until this point, 0x80fd is CCP, Compression Control
Protocol which is not supported for lwIP.
> [ 116:23: tcp] sent [LCP ProtRej id=0x2 80 fd 01 02 00 0a 12 06 00 00 00 01]
> [ 116:23: tcp] ppp_write[1]: len=24
So, we are refusing it, everything still fine.
> [ 116:23: tcp] tcpip_thread: CALLBACK 6807cbf8
> [ 116:23: tcp] rcvd [LCP ProtRej id=0x3 80 21 01 01 00 1c 02 06 00 2d 0f 01
> 03 06 00 00 00 00 81 06 00 00 00 00 83 06 00 00 00 00]
> [ 116:23: tcp] Protocol-Reject for 0x8021 received
0x8021 is IPCP, we receive a frame telling us that IPCP is -not-
supported, this is weird. The windows host is rejecting our IPCP
request, wtf.
> [ 116:37: tcp] --------------- Received 35
> [ 116:37: tcp] pppos_input[1]: got 35 bytes
> [ 116:23: tcp] tcpip_thread: CALLBACK 6807cbf8
> [ 116:23: tcp] rcvd [LCP TermReq id=0x4
> "Z\37777777742\032\37777777651\000<\37777777715t\000\000\000\000"]
> [ 116:23: tcp] LCP terminated by peer
> (ZM-b^ZM-)^@<address@hidden@address@hidden@)
Packets looks corrupted, this might explain the previous behavior.
But this is strange... there is CRC16-CCITT on HDLC frames, parsing
corrupted frames is nearly-impossible.
Are they actually corrupted after low-level PPPoS checked the CRC and
before passing them to lwIP PPP stack ? If yes, this looks like a
driver corruption issue.
I am not saying that this isn't my fault, we don't know yet, this is
just what it looks like :)
> If you need more logs i believe i still having some space to include it.
I guess you are using a RS232 link between your Windows host and your
target using some kind of USB to Serial convertir, so, could you dump
the binary stream by sniffing the Rx + Tx wires using two additional USB
to Serial converters ? Or an oscilloscope with protocol decoding able to
export the Rx+Tx binary streams.
Sylvain
signature.asc
Description: Digital signature