|Subject:||RE: [lwip-users] PPP negotiation frame length and sio_read() inco mpatibility|
|Date:||Wed, 17 May 2006 14:50:28 +0100|
Thanks for your reply. Actually, this morning I took a fresh look at the PPP code and realised that the only way the sio_read() call in pppMain() could possibly work was if it was non blocking. So I changed my implementation of sio_read() so that it returns immediately, irrespective of how much data it has retrieved. The good news is that an LCP dialogue of sorts is happening - however, the peers get as far as agreeing the Auth type, then the process repeats with the original ID number again. Ultimately one end gives up and the process fails. I also find that throughput is very slow - this may be the reason for the above problem?
Did you find you had to change any PPP code (LCP, Auth, IPCP etc) in order to get the whole thing working? I'm not at all confident that the PPP code as shipped will work OK - I figure that very few people are actively using it. Either that or their not prepared to merge their findings into the current LwIP development 8-)
Bye for now,
> -----Original Message-----
> From: Guillermo Prandi [mailto:address@hidden]
> Sent: 17 May 2006 14:35
> To: 'address@hidden'
> Subject: RE: [lwip-users] PPP negotiation frame length and
> sio_read() inco mpatibility
> Hi, Wilson. I got it working in my Windows test implementation by not
> returning unless at least one byte was read. >From the source code I
> interpreted that sio_read should return AT MOST the specified
> number of
> characters. Additionally, Windows lets you specify an inter-character
> timeout for the read operation, so you can keep reading if
> more characters
> keep coming and thus reduce the processing overhead. You
> could implement
> something alike (some UARTs implement such timeout too).
> lwip-users mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|