[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] PPP negotiation frame length and sio_read() incompatibility

From: Wilson, Clive
Subject: [lwip-users] PPP negotiation frame length and sio_read() incompatibility
Date: Tue, 16 May 2006 11:18:45 +0100


I'm trying to get LwIP working with the PPP link layer it is released with (instead of the more usually implemented Ethernet layer), and have run into what I see to be a serious problem with the PPP implementation. I can't see how anyone could have got PPP working without a change in the way in which data is retrieved from the sio port by pppMain(). BTW, I'm using the code in a multi-threaded environment, with only one network interface, i.e. PPP. I'm using PPP code from LwIP v1.1.0.

The problem as I see it is between the call pppMain() and the way that call retrieves incoming data from the physical interface, namely the call sio_read(). Now, one param that sio_read() takes is the size of data to retrieve. I understand from reading the LwIP message boards that sio_read should block and not return until it has accumulated the requested number of bytes.

In pppMain() where sio_read is being called, the requested read size is set as 1504 bytes (MRU of 1500 plus 4 byte header). This is all very well if we're up and running and transferring IP traffic frames. However, the same code has to handle incoming LCP, PAP and IPCP frames which are considerably shorter than the MRU!! So the result is that the first LCP Conf-Req frame get tx'ed, then because the read is blocking waiting for such a large frame, pppInProc never gets called, the peer keeps retransmitting its LCP Conf-Reg, as does the local end because of the block, and the connection never gets off first base.

Has anyone got this working? If so, I would be very grateful if you would tell me how. Can we service all incoming traffic (i.e. PPP startup frames, as well as IP frames) through one sio_read() call, or do we have to take a different approach? I can't see how the existing pppMain could work unmodified. Maybe the sio_read() should be spotting for HDLC frame flags (0x7E) and returning with whole HDLC frames instead?

Also, what should be contained in the linkStatusCB func - the func required to be called back to by pppOpen? I have it just printing out debug info about how far the link has got in being brought up. Is this OK, or is there more fundamental stuff I need to be doing in there that the raising of the PPP layer depends upon?

Thanks for reading this and I very muich hope someone could spend a few minutes helping me on my way with this.

Very many thanks in anticipation,

Clive Wilson

reply via email to

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