# Mesh compatibility with newer morselib / firmware **URL:** \ **Category:** Embedded\ **Created:** [October 5, 2026, 11:39am UTC](https://community.morsemicro.com/t/mesh-compatibility-with-newer-morselib-firmware/2065 "2026-10-05T11:39:52Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ChiTam](https://avatars.discourse-cdn.com/v4/letter/c/5e9695/32.png) [@ChiTam](https://community.morsemicro.com/u/ChiTam)\ **Post date:** [October 5, 2026, 11:39am UTC](https://community.morsemicro.com/t/mesh-compatibility-with-newer-morselib-firmware/2065/1 "2026-10-05T11:39:52Z")
Hi Morse Micro team, I’m looking at the ESP32-S3 802.11s mesh implementation that was tested with roughly: - morselib 2.12.3 - firmware 1.17.8 - MM6108 > [@Halow Mesh client for ESP32S3 (Heltec HT-HC33)](https://community.morsemicro.com/t/halow-mesh-client-for-esp32s3-heltec-ht-hc33/1554): > > We are developing Wi-Fi Halow based infrastructure, but found direct AP/STA cannot reliably cover large area. So we decided to implement the mesh protocol on the end device. Thanks to mm-iot-esp32 2.10.4 start open source mac layer. After a week vide coding, I make it work with my mix setup MM8108-EKH19 + Heltec HT-H7608 + Heltec HT-HC33 My current project already uses **morselib 2.13.1 + firmware 2.0.0 on MM8108** , so I’d prefer to port only the mesh code instead of downgrading the whole stack. Could you please clarify: 1. Is the mesh implementation mainly host-side, or does it depend on specific firmware support? 2. Are there any changes in **morselib 2.13.1 / firmware 2.0.0** that would break the existing mesh code? 3. Does firmware 2.0.0 still provide the low-level functionality required for mesh? 4. Are there any MM6108-specific assumptions that need changes for MM8108? Would you recommend porting the mesh code forward to the latest stack, or staying with the older versions? Thanks! ---
**Author:** ![jasonhao](https://avatars.discourse-cdn.com/v4/letter/j/ad7895/32.png) [@jasonhao](https://community.morsemicro.com/u/jasonhao)\ **Post date:** [October 5, 2026, 12:02pm UTC](https://community.morsemicro.com/t/mesh-compatibility-with-newer-morselib-firmware/2065/2 "2026-10-05T12:02:21Z")
Hi ChiTam, Sorry for the misleading, I’m not from Morse Micro team. I’m from a startup in Sweden, specialized for wifi halow mesh network. So this ESP32S3 mesh implementation is our customization based on official esp32 sdk. the mature one is based on mm-iot-esp32, now we are migrating to latest esp-halow. Now our solution works seemlessly accross openwrt, ESP32S3/ESP32P4, nRF54L15 with batman-adv to support mutiple route and gateway at same time. and that can be easily integate into a working IoT solution. Here we have an all in one template for live stocking usecase demo. [GitHub - edgez-ai/template-live-stocking: a full stack live stocking example with appwrite and iot hardware · GitHub](https://github.com/edgez-ai/template-live-stocking) Best Regards! Jason ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [October 6, 2026, 10:12pm UTC](https://community.morsemicro.com/t/mesh-compatibility-with-newer-morselib-firmware/2065/3 "2026-10-06T22:12:23Z")
Hi @ChiTam As Jason said, that 802.11s mesh implementation is not an official offering and is not supported by Morse Micro. Depending on what problem you’re trying to solve, we do have Relay Mode - where nodes operate as repeaters to extend the range of a gateway. This works great if you’re looking to have a single gateway as the root of the network, and are looking for a range extending topology. If you’re instead looking for a decentralised network then we don’t have any offerings in the IoT SDK and point you towards our Linux platforms. We have a bunch of great improvements and an overhaul of the API to simplify the bring-up a relay aware device, which should be released before the end of the month. Cheers