mongoose.c:24184:mg_tcpip_driv No free descriptors in MG_VERSION "7.19" latest commits

[Juggler-5]

Hello. I used MG_VERSION "7.19" from the near to it`s release date, and today I updated it to last commit (Merge pull request #3307 from cesanta/openssl). I use stm32f42(3)9 nucleo. After update I get errors like: "mongoose.c:24184:mg_tcpip_driv No free descriptors", and when I roll back to earlier 7.19 it all backs to normal.
Just letting you know. If you aware about the reasons already, please let me know as well.

[Juggler-5]

Finally I got it, and eventhough nobody asks my opinion here, I'd like to express myself as humble as possible :)
Instead of
#ifndef MG_ETH_RAM
..
#define MG_ETH_RAM attribute((section(".eth_ram")))
..
#endif
that would be more user friendly to surprise the audience with focus like:
#if !defined MG_ETH_RAM
#error "Please provide RAM section for bla-bla-bla"
#endif
Seriously It is not funny at all to loose remote control of your device after upgrade with such a mute build rearrangement.

[scaprile]

That is compiler dependent.
All our examples use the same compiler (and linker), and all our examples provide a linker script with that section defined (if actually needed).
Where a different environment is used, we change that definition to accomodate the linker definitions in place (Cube, Xpresso, ...)
If you go through our code by yourself, and you know how building C code works, you'll understand that and change accordingly. If you don't, and just copy code, it won't. It is not our fault, so we won't change what is not an error of us.
Thank you.

[scaprile]

On a side note, HEAD is where we develop. It is not good practice to blindly upload to a remote device without lab testing development code.
If you need rock steady rock solid code, don't use development versions and if you have a working network of devices, don't remotely reflash without prior lab tests and a deployment procedure.
How to upgrade from 7.19 to 7.20 will come accompanied with a release note, that release note will introduce the change to our customers and comment on how to deal with any possible link script changes on their side. That will happen when 7.20 gets released.

Your suggestion, btw, would cause other code to fail, because that was introduced for a reason. We don't just wake up and throw changes in, we discuss support for a new environment, see how it will impact, come to an agreement, do the mods, update the examples, test, and then we push. That, then, is tested on a CI/CD pipeline at push time, at merge time, and nightly builds and runs on actual embedded systems.
Sometimes, we make mistakes, and sometimes nightly builds are checked days later. Development branches are development branches, and HEAD is a development branch. I'll go through the tests as soon as I'm able to, and see if there's something we missed.

[Juggler-5]

Alrighty then, you are the boss. Just letting you know, that commit of 2 weeks ago (13.10.2025 15:41:52)
"Merge pull request #3304 from cesanta/uniram uniformize memory attributes" ruined the stm32Fs. Previous commits work fine not to say perfect. Doublecheck when have time.

[scaprile]

If you don't know how to change your linker script, just build with MG_ETH_RAM= (define MG_ETH_RAM as an empty macro)

[scaprile]

#3326