Where to find LwIP incoming payload data for webserver?

[Raymond Buck]

STM32CubeIDE Version: 1.12.0
Build: 14980_20230301_1550 (UTC)

I have a STM32F407 Discovery board running a web server.  I have a simple webpage with a single button that when clicked, displays a text message below the button. I had issues with the server at first due to the const keywords that were in the fsdata.c file, but it is working fine now.

Where is the buffer for the incoming button click and the text message located? Is there a weak callback function somewhere that handles incoming data? I want to intercept the message and take action based on the incoming data.

I used STM32CubeIDE to create the server and accepted all of the default settings.

[Pavel A.]

Is there any incoming data due to the button click? You have not provided enough details on your "simple web page".

For example the button click can be completely handled on the client side (in your browser) so nothing is sent back to the server on click.  If you don't feel confident in web programming and client-server communication, look for a consultant?

[Raymond Buck]

When the button is clicked, this is the data I send out:

button_request?data=test4,button_4,ON

In Wireshark I see this data: GET /button_request?data=test4%2Cbutton_4%2CON HTTP/1.1

I can make it work using UDP and I know where that data comes in. I am looking for the function (probably a weak one) that handles the TCP data coming in.

I am not using an OS and don't want to use one.

[LCE]

Check http_parse_request() in httpd.c in ..\Middlewares\Third_Party\LwIP\src\apps\http\httpd.c

At least that's a starting point... As all else in lwip, it's totally "nested" in bazillions of functions with crazy pbuf pointering (I renamed many of these from "p" to "pPbufIn", "pPbufWork" .... to keep better control).

But that's where incoming data is checked for GET, I put the PUT option in there. 

Data in the incoming p->payload.

[Andrew Neil]

Have you tried the LwIP User mailing List?

https://savannah.nongnu.org/mail/?group=lwip

[Raymond Buck · Accepted solution]

LCE, thank you for pointing me to the correct place to get the data. I see the button request data at line 2021 in the http_parse_request function. The statements at that point are these:

if (!strncmp(data, "GET ", 4)) {
sp1 = data + 3;

spi has the message that the button click sends. It looks exactly like the data that Wireshark logs. Unfortunately, there are no sections for user code to be placed there. I will make a note in my main.c file to remind me that I had to put code there to retrieve the incoming data. Out of curiosity, I ran the IOC tool to regenerate code and it did overwrite my code at that point. So I will have to include the code that I added in the note that I make.

Problem solved. Thank you again. I had spent a few hours searching and not finding the solution..

[Raymond Buck]

Andrew, No I did not check there as I felt this was the first place to ask for help. I'm sure ST heavily modifies the LwIP code to match their development environment. If I didn't get answers here, I would have checked there next.

[Pavel A.]

> In Wireshark I see this data: GET /button_request?data=test4%2Cbutton_4%2CON HTTP/1.1

Then it looks like your web page does a new http get request, with the parameters encoded in the URL. There's a standard for this: the parameters start with ? after the URL and are separated by & and there can be something else. Then, the httpd "core" will call the handler function and pass the parsed parameters to it. It supports few kinds of handlers, called via user-provided  httpd_cgi_handler(). So you likely need to implement this to get the URL-encoded parameters.

Sending another page request is not an efficient way to communicate with a server, as it causes complete reloading the entire page in both server and client.

[Pavel A.]

>  I'm sure ST heavily modifies the LwIP code to match their development environment.

Hm, not quite so. They modify only the low level ethernetif code related to the STM32 ETH controller, its capabilities, supported offloads and so on. They also provide complete working examples, including the http server/client. The examples are very simple, with the only purpose to demonstrate the hardware operation. ST also has to touch the FreeRTOS related glue code in LwIP/system/arch, LwIP/system/OS. And the mandatory SSL support & crypto. Nothing other fancy in the software. 

[LCE]

@Raymond Buck I recommend to stop using CubeMX after the initial setup, because of overwriting stuff.

I always start a 2nd project with the same settings, and if there's a new peripheral I need, I copy stuff from the new 2nd project.

When I started with CubeMX that really cost me some time and nerves...

lwIP: as @Pavel A. said, I think ST doesn't touch the lwip files in ..\Middlewares\Third_Party\LwIP/.
All the STM32 specific stuff is done in the  in the lower "LWIP" /App and /Target folders, e.g. with lwipopts.h making the "regular" opts.h kinda weak file or so.

I actually had to edit the lwip files for my application:
- PUT method into httpd
- some extra pbuf ACK handling in the TCP files

Feels somehow bad, but I couldn't handle some stuff with external functions.