My app is accepting connections on port 80 and handling them, as it is a minimal web server.
I am able to take the incoming data on the connection, and get the request (such as "GET / HTTP/1.1", as well as collecting and parsing the headers, such as "Host", "User-Agent" and the like.
Where I am just sending back a 200 response and the appropriate data (fixed content pages, or templated pages), it all works quite well.
I send a response using tcp_write(), see a call to my tcp_sent callback, send the headers, see another call to the callback, and send the data, in packet-sized chunks, and once everything has been sent, on the final callback, I close the connection.
I can repeatedly get the same pages successfully.
However, I need slightly more functionality.
One page displays a list of available networks - and this side of it (filling in the templated data) works fine. It contains a form with an action '/save.cgi' and a button with an <a> where the href is '/refresh.cgi'.
The intention is that the 'cgi' requests are handled by doing triggering some action in the server (saving the configuration values, or refreshing the available network list), and then redirecting to another page.
Using wget to test, I issueOn the picoW I see the accept, and then the data forming the request arrives. This is successfully processed, and some debugging prints tell me that the correct target '/refresh.cgi' is being requested (which I can see from a dump of the received data).
This is then processed, and I see that the handler for this page is called, which triggers a scan, and waits for it to complete.
A response consisting ofis sent back, and I see in my callback that the same size data was acknowleged (tcp_sent). I close the connection.
wget sees the redirection, and issues a request for the new location (/wifi.html). I see the accept, and again, I see the request and headers arrive. As usual, I send the response back, and things at this point should be driven by the callback for tcp_sent to await that, then send the outgoing headers and data, which works for that templated page.
However, I don't see this; instead, I see the fact that the response is being queued by tcp_write, and then the next thing isI have looked in the lwip source, and this seems to be in tcp_in.c/tcp_free_acked_segments, at which point I go "huh?" and wonder what I have done wrong.
Within my tcp_recv handler, I am calling tcp_recved with the pcb and data length, as well as calling pbuf_free with the pbuf parameter.
Since I can repeatedly request either static or templated HTML pages without issues, it must be something I am doing in terms of redirecting, but I cannot see what might be causing it.
The reason for sending a redirect, rather than just internally replacing the URI and handing back the relevant data is so that if the user refreshes the page, it doesn't unintentionally call the additional code a second (or subsequent time). Is there another way to say "I am sending your request, but it is actually at this location" ?
EDIT: I commented out the call to perform a wifi scan, and it works as expected, so I assume that the scan is doing something that interacts badly with lwip. This is using the lwipopts from the pico-examples, and also using the scan code from the examples.
I'm assuming that it may be because I am in a callback when I perform the scan, so I may have to handle this differently; one issue is that I don't want the scan to cause the connection to timeout, so that might not be easy.... any ideas?
I am able to take the incoming data on the connection, and get the request (such as "GET / HTTP/1.1", as well as collecting and parsing the headers, such as "Host", "User-Agent" and the like.
Where I am just sending back a 200 response and the appropriate data (fixed content pages, or templated pages), it all works quite well.
I send a response using tcp_write(), see a call to my tcp_sent callback, send the headers, see another call to the callback, and send the data, in packet-sized chunks, and once everything has been sent, on the final callback, I close the connection.
I can repeatedly get the same pages successfully.
However, I need slightly more functionality.
One page displays a list of available networks - and this side of it (filling in the templated data) works fine. It contains a form with an action '/save.cgi' and a button with an <a> where the href is '/refresh.cgi'.
The intention is that the 'cgi' requests are handled by doing triggering some action in the server (saving the configuration values, or refreshing the available network list), and then redirecting to another page.
Using wget to test, I issue
Code:
wget --tries=1 'http://server/refresh.cgi'This is then processed, and I see that the handler for this page is called, which triggers a scan, and waits for it to complete.
A response consisting of
Code:
HTTP/1.1 302 RedirectLocation: /wifi.htmlConnection: Closewget sees the redirection, and issues a request for the new location (/wifi.html). I see the accept, and again, I see the request and headers arrive. As usual, I send the response back, and things at this point should be driven by the callback for tcp_sent to await that, then send the outgoing headers and data, which works for that templated page.
However, I don't see this; instead, I see the fact that the response is being queued by tcp_write, and then the next thing is
Code:
*** PANIC ***pcb->snd_queuelen >= pbuf_clen(next->p)Within my tcp_recv handler, I am calling tcp_recved with the pcb and data length, as well as calling pbuf_free with the pbuf parameter.
Since I can repeatedly request either static or templated HTML pages without issues, it must be something I am doing in terms of redirecting, but I cannot see what might be causing it.
The reason for sending a redirect, rather than just internally replacing the URI and handing back the relevant data is so that if the user refreshes the page, it doesn't unintentionally call the additional code a second (or subsequent time). Is there another way to say "I am sending your request, but it is actually at this location" ?
EDIT: I commented out the call to perform a wifi scan, and it works as expected, so I assume that the scan is doing something that interacts badly with lwip. This is using the lwipopts from the pico-examples, and also using the scan code from the examples.
I'm assuming that it may be because I am in a callback when I perform the scan, so I may have to handle this differently; one issue is that I don't want the scan to cause the connection to timeout, so that might not be easy.... any ideas?
Statistics: Posted by SteveSpencer — Mon Dec 15, 2025 1:18 pm