[lwip-users] Re: PPP build inconsistency

[hajot]

There is a my delayed response to your questions, sorry. I hope you did not waste to much time and my response is still welcome.

> Im' trying to build the lwip stack with PPPOS_SUPPORT enabled and
> PPPOE_SUPPORT disabled (gprs connection).

> When building the latest cvs snapshot code there is a build error on
>line 507 of the ppp.c file. The code is trying to reference a member of
> the PPPControl_s structure (pc->ethif= NULL;). On line 141 of the same
> file, this member is not compiled due to the PPPOE_SUPPORT definition
> being 0 in my case.

Never met this defines you are mentioning, nor did I encounter such compiling problems (I checked out lwip 1.2.0). However I did not use the sequential API.

> Once I build the ppp code I have no idea how to initialize and setup a
> PPP connection. Which is the order of api calls from ppp.c that I should
> I invoke ?

I dont use the netconn or sequential API of the lwip. I use the stack with NO_SYS = 1. Therefore I "broke" the infinite while loop in the pppMain()-Thread and made it an ordinary function, called frequently from my application.

However my initialization should cover yours as well:
- I first call pppInit() and then call pppOpen().

- My application then has to call frequently pppMain(). But as you use the sequential API, pppOpen() will start your pppMain() thread. The ppp Stack will register some callback functions to the tcpip thread, I guess you have to start and initialize the tcpip Thread prior to the ppp initialization.

Setting up a PPP connection starts the same way as you did with the SLIP connection (I guess the peer was a windows PC?): On Windows, an incoming PPP connection request has to be announced by this braindead proprietary "CLIENTCLIENT", "CLIENTSERVER" handshake. Once your application received the "CLIENTSERVER" token, it has to initialize and start the ppp-Stack

BTW: This book will help you debugging LCP and IPCP negotiation (Clive, a member of this mailing list recommended it to me.  It was of great help):

PPP Design Implementation and Debugging,
James Carlson,
Addison-Wesley Pearson Education
ISBN 0-201-70053-0

Normaly you should not be urged to dig in the deepest internals of the PPP negotiation phases. However the file lpc.c and fsm.c is your debugging area in this case:

- As soon as your tcp_ip thread calls tcpip_callback(pppStartCB), the lcp_lowerup will trigger the LCP state machine to start negotiation.

- Each configuration request or configuration acknowledge from your peer is handled by the lcp_input() function which passes the LCP state machine handle to fsm_input(). fsm_input() then handles the state transitions.

- Each configuration request or configuration acknowledge from your ppp stack is sent by fsm_sconfreq()

- Each serial I/O from your ppp Stack has to be passed to your serial interface (normaly sio_write) this is done by nPut() in ppp.c. As I dont have a common sio_write() on my target, I completely had to recode nPut. If you had an sio_write for your SLIP connection, you should be able to use the same.

- I had to do a hack to set the default route to the peer, as I found no other solution. At a certain point after a sucessfull IPCP negotiation sifup() in ppp.c gets called. In this function, I call netif_set_default(&pc->netif) after netif_setup(). But I am not sure, if you will encounter the same routing problems with the sequential API.

- If you wonder about the black magic, how the tcpip thread passes payload to the ppp stack: sifup() adds a network interface by calling netif_add(). netif_add() calls pppifNetifInit() as callback function. pppifNetifInit() registers pppifOutput() as the output function for the ppp Network Interface. The black magic for data receive: after sio_read() pppInProc() is called. pppInProc() calls pppInput() (by a tcpip_callback). pppInput() calls pppControl[pd].netif.input(). The protocol input function netif.input() was registered by netif_add() and is ip_input() in this case. The use of function pointers for input and output routines within structures is a very elegant object oriented approach in my opinion.

- If you want your peer to start negotiation, you should set wo->silent = 0 (want options in lcp.c). Im not sure but I think this were my settings.

- Normally you should consider timeouts and repetitions during negotiation (at least for a stable product). However for the first steps I left null implementations for the TIMEOUT and UNTIMEOUT macros in ppp.h and it worked. For your sequential API you have to provide sys_timeout and sys_untimeout. As for my NO_SYS implemetation I had to use my own timeout functions.

As you already set up a SLIP connection, I guess you know to set up an incoming PPP connection on windows. Please let me know if I am wrong.

As I already mentioned to you, Windows will negotiate the MPCC compression protocol. LWIP does not support this protocol and reject it. Therefore the peer will not start its ppp Stack. Fortunately there is a workaround: - Start the netsh (netshell) in windows. - type in ras (switches to the RAS context) - type in show link - if you find the MPCC in the list, type in del link swc (dont forget to enable it for other windows network application, if you get in troubles).

To analyze negotiation use the wireshark (former Ethereal). However as long as there is no initial ppp connection you wont be able to select the PPP/SLIP interface. You have to capture the negotiation with the netcap.exe and load the captured file with wireshark and anlyze it offline. If there is no negotiation, then already netcap wont help you, then you need portmon (a windows sysutil, hardly to find in the microsoft web jungle, ask me if you dont find it). With portmon you will be able to trace serial port I/O on the windows pc.

Remark to all jump starting with lwip ppp: Do it as Marko and I did, begin with SLIP instead of PPP. It is much, much easier and you wont be frustrated by a huge bounch of details.

Hope this will help you and others

Cheers

____________________________________
Hans-Joerg Wagner  B.Sc. EE / PGDip. SE
Truninger AG
R&D
4513 Langendorf/Switzerland
Phone: +41 32 617 37 49
Web: www.truninger.com
_____________________________________