HTTP server stops responding when a single WebSocket connection is running on Portenta H7

[Schlendrick]

I’m using a Portenta H7 with the Arduino Mbed framework and running the following simultaneously:

• HTTP server on port 80 over Wi-Fi
• WebSocket server on port 81 over Wi-Fi
• UDP communication over Ethernet

Observed behavior:

• Both servers start without errors.
• Each server works fine individually.
• When a single WebSocket client is connected, HTTP requests fail (WebSocket connections still work).

Request:
Is there a known limitation in the Arduino Mbed framework on Portenta H7 that prevents multiple TCP servers from accepting client connections simultaneously?

[megacct]

Hi @Schlendrick, I suspect you are hitting the ludicrously low limit set by Arduino for open sockets/servers in the lwip stack.
https://github.com/arduino/mbed-os/blob/ec7cc4e660b366364d8b11e4ee6480c41141ff04/connectivity/lwipstack/mbed_lib.json#L66
There have been numerous requests for these to be increased in the core build. I have my own build of libmbed.a and am running happily with 10 socket max on a GIGA board.

[Schlendrick]

Hi @megacct— thanks for the hint, that matches exactly what we're seeing.

Quick summary of our situation:

• Board: Portenta H7 (Arduino Mbed framework)
• Running simultaneously: HTTP server (TCP/80 over Wi‑Fi), WebSocket server (TCP/81 over Wi‑Fi), UDP over Ethernet
• Symptom: Both servers start; each works alone. But when one WebSocket client connects, HTTP requests begin to fail. Looks like we hit the lwIP socket limit.
• Build system: PlatformIO, small team (4 people) — we want a simple change that takes effect when anyone clones & builds the our repo.

Could you please share the simplest, team-friendly way to override the lwIP socket limit so it applies when we build the project (PlatformIO)? Ideally we want something we can commit to our repo so every developer gets the change automatically.

[megacct]

I'm not a PlatformIO user, does PIO use the libmbed.a from here https://github.com/arduino/ArduinoCore-mbed/tree/main/variants/PORTENTA_H7_M7/libs in its build? If so, you can follow the build docs here https://github.com/arduino/ArduinoCore-mbed/ having applied these changes #966 (comment) to your variants/PORTENTA_H7_M7/conf/mbed_app.json. If this isn't clear / need more help, I suggest copy/paste this exchange to the forum here https://forum.arduino.cc/c/official-hardware/portenta-family/portenta-h7/168 and we can continue, as this is tuning rather than a bug/issue.

[Schlendrick]

Thanks for the suggestion!

It looks like PlatformIO is using the same libmbed.a as the Arduino core:

I’ll try to rebuild libmbed.a with the changes of #966 (comment).

However, I honestly don’t understand why this limitation still exists — the Portenta H7 is quite an expensive and powerful board, so it’s surprising that it ships with such a low socket limit by default.

[Schlendrick]

I tried to rebuild the core on macOS, but unfortunately I wasn’t successful — I don’t know enough about this build process yet.
@megacct could you maybe push the built version of this change for the Portenta on your fork?

If this solves the issue, it would definitely be worth spending more time on it.
Otherwise, we might need to consider evaluating different hardware.

[megacct]

@Schlendrick I feel your pain Patrick, I had to build linux on an old laptop (1st timer) and then flounder through the build process, took many, many hours.

I don't actually use that fork of mine for the build but I've created a branch and uploaded the 3 files to a new folder.
https://github.com/megacct/ArduinoCore-mbed/tree/6bf093ddd61b3391e6e037d617812983b866d97a/variants/PORTENTA_H7_M7/for_Patrick

• The mbed_app.json is for reference (used in the building of the library) and includes the lwip additions. Lives in the conf folder
• The libmbed.a you know about
• The mbed_config.h contains defines for a bunch of stuff compiled along with your code. Lives in the PORTENTA_H7_M7 variants folder

Haven't been able to test, other than confirming it built the lib.a. Good luck and hope it does the job.

[Schlendrick]

Many, many thanks @megacct
Your build works exactly as you predicted. I can now easily make HTTP requests, use WebSockets and even listen to a UDP stream.

Here's the memory comparison with the modified version

Original:

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]  14.8% (used 77528 bytes from 523624 bytes)
Flash: [======    ]  61.5% (used 483504 bytes from 786432 bytes)

Modified:

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  16.3% (used 85432 bytes from 523624 bytes)
Flash: [======    ]  61.5% (used 483960 bytes from 786432 bytes)

Should we make a pull request for this change?

I think this adjustment would make sense to include in the standard for the Portenta, because it comes with both WiFi and an Ethernet port.

It would also make it easier for developers to quickly prototype networked applications — HTTP, WebSocket, TCP, UDP-based — using the default core. Considering that reliable network connectivity is a key feature of the Portenta line, it feels reasonable that this configuration should be part of the official build.

[megacct]

@Schlendrick So glad that moved you forward. It is definately worth getting to grips with the mbed core build process if you plan to continue with the Portenta H7, especially as mbed is EOL and it seems Arduino are only fixing bugs on these boards.

You could PR this (it's been tried) but I fear it will come to nought.

[manchoz]

Hi all,
Unfortunately, with MbedOS going EOL and platform-wide Python applications support being discouraged, compiling limbed.a on macOS has become very complicated.

First, you need to install the GCC ARM 10.3 toolchain on your Mac and add it to your path, at least temporarily, for the build.

Second, you need to create a Python 3.11 virtual environment to install mbed-cli and all its dependencies. I recommend doing it via uv.

Move inside the directory of this cloned repo and create the venv there

$ uv venv --python 3.11

Activate it:

$ source .venv/bin/activate

And install essential modules:

$ uv pip install pip
$ pip install mbed-cli

Clone the https://github.com/arduino/mbed-os repo on your Mac and double-check that the extrapatches-6.17.0 is checked out. Edit the requirements.txt file and remove the version constraints for the hidapi package.

Install the required packages:

$ pip install -r </path/to/cloned/mbed-os>/requirements.txt

Now you can execute the building script.

$ ./mbed-os-to-arduino-macos -r </path/to/cloned>/mbed-os PORTENTA_H7_M7:PORTENTA_H7_M7

Please let me know if this works for you.

[manchoz]

@pennam and @facchinm, several users reported rebuilding limbed.a to increase the number of supported TCP sockets, and their applications running without issues in real-life use cases. It is a recurring issue and question also on Opta, and, in general, in any Industrial Automation scenario involving Modbus TCP.

In my opinion, we can safely raise it to 16 or 32, at least for variants based on PORTENTA_H7_M7.

WDYT?