lwip-users
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

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