[lwip-users] Useful web server for Netconn API
Hi everyone, I'm wondering if anyone has had success getting an HTTP server working using the Netconn API. I know there is an example program using the Netconn API but it is too basic to be of much use for me. I do have it up and running but it doesn't include any support for POST, header decoding, etc. There was some communication on this mailing list a couple months ago and it was suggested then to try the contiki project HTTP server but from the looks of it it will take quite a bit of modification to get working. I'm not looking for anything too fancy, just similar to the RAW API example server. Does anyone have a suggestion? I should also say, I'm doing this for a commercial project and don't feel like purchasing code, so I'm looking for something open source/free commercial license. Thanks for the help! ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times
Thank you Sylvain. I'm not sure I'm comfortable with LWIP to make the changes that you mentioned but I'll look at it more closely. With the current implementation, if I wait in the sio_write() function until the data is transmitted, this is going to hold up the LWIP stack (which I'm guessing is not good). Let me explain my current implementation of sio_write() and you can tell me if it seems wrong. I have concerns with holding up LWIP but I don't see an easy way around it. No matter how many buffers I have LWIP could eventually fill them up I would think... then what should happen? My current sio_write() implementation: 1. I have a dedicated buffer to send sio serial data from. 2. When sio_write() is called, I check to see if the UART is available to send. 3. If the UART is available, I'm copying the data into my dedicated buffer and starting the UART write. I then return "len" 4. If the UART is NOT available, I'm waiting until it is free then I'm going back to step #3. So, basically, I can queue up one sio_write packet then I start having to wait... -Brian -Original Message- From: lwip-users-bounces+brian.stull=divelbiss@nongnu.org [mailto:lwip-users-bounces+brian.stull=divelbiss@nongnu.org] On Behalf Of Sylvain Rochet Sent: Thursday, October 29, 2015 3:24 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times Hi Brian, On Thu, Oct 29, 2015 at 11:55:50AM -0400, Brian Stull wrote: > > After a little more debugging this morning I'm thinking this problem > is related to some timeout/retry mechanisms of the PPP stack and how > I've implemented my sio_write function. > > In my sio_write function, if the UART is busy (sending previous > sio_write > data) when the function is called I am returning "0". Which, I believe > is the proper operation. If I put in a 1ms delay when this happens > instead of just returning "0" immediately I am seeing this problem go away. There is currently no tx queue in the PPP stack at the serial level, your sio_write() function MUST queue or write the data to the serial port. Worse, there is no framing information passed with sio_write() so you never know if it is safe to drop the data, which could be in a middle of a packet. Anyway, adding the feature would be very welcomed. Basically we'll need to keep a pbuf list of pbuf which are not completely sent (with a sio.h configurable value of how big the queue can grow) and wait for a call to pppos_"something_telling_the_uart_is_ready"(). Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times
To follow up: After a little more debugging this morning I'm thinking this problem is related to some timeout/retry mechanisms of the PPP stack and how I've implemented my sio_write function. In my sio_write function, if the UART is busy (sending previous sio_write data) when the function is called I am returning "0". Which, I believe is the proper operation. If I put in a 1ms delay when this happens instead of just returning "0" immediately I am seeing this problem go away. My understanding is that the LWIP PPP stack should be able to handle the retrys during the PPP negotiation phase so I'm not sure what is going on. It's almost like the PPP stack is trying to send data again too quickly after the transmission fails and this is causing some sort of problem. Any help is appreciated! -Brian From: lwip-users-bounces+brian.stull=divelbiss@nongnu.org [mailto:lwip-users-bounces+brian.stull=divelbiss....@nongnu.org] On Behalf Of Brian Stull Sent: Thursday, October 29, 2015 10:23 AM To: lwip-users@nongnu.org Subject: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times I've been using the LWIP PPP stack for a while to connect to a cellular modem. It's been working fine with one modem, but I've recently tried another modem (with another carrier) and the PPP sequence is not acting the same. Specifically, what I'm seeing is that the fsm_rconfack() function is being called multiple times during the PPP negotiation which is then calling my PPP link callback function. In fsm_rconfack(): case PPP_FSM_ACKSENT: UNTIMEOUT(fsm_timeout, f); /* Cancel timeout */ f->state = PPP_FSM_OPENED; f->retransmits = pcb->settings.fsm_max_conf_req_transmits; if (f->callbacks->up) (*f->callbacks->up)(f);/* Inform upper layers */ break; This case statement is being called which then tells my application that the PPP link is up. The problem is it is being called multiple times. Any ideas is this is valid to be called multiple times? -Brian ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times
I've been using the LWIP PPP stack for a while to connect to a cellular modem. It's been working fine with one modem, but I've recently tried another modem (with another carrier) and the PPP sequence is not acting the same. Specifically, what I'm seeing is that the fsm_rconfack() function is being called multiple times during the PPP negotiation which is then calling my PPP link callback function. In fsm_rconfack(): case PPP_FSM_ACKSENT: UNTIMEOUT(fsm_timeout, f); /* Cancel timeout */ f->state = PPP_FSM_OPENED; f->retransmits = pcb->settings.fsm_max_conf_req_transmits; if (f->callbacks->up) (*f->callbacks->up)(f);/* Inform upper layers */ break; This case statement is being called which then tells my application that the PPP link is up. The problem is it is being called multiple times. Any ideas is this is valid to be called multiple times? -Brian ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
