Proposal: New Modem Firmware Upgrade Module Integration in OpenWISP
Rahul Bhagwat
My Self Rahul Bhagwat, Lead Engineer at Softdel Systems Pvt. Ltd. We are working on behalf of Railhead Corporation for one of proposal of integration of new module in OpenWISP.
We are exploring the possibility of contributing a new module to the OpenWISP ecosystem, focused on firmware upgrade management for 5G modems connected to OpenWrt-based devices. The intent is to design a module similar to existing openwisp-firmware-upgrader that can handle detection, version tracking, and remote firmware upgrade of cellular modems.
The idea is to design a new module that allows OpenWISP to host 5G/LTE modem firmware binaries (from any vendor) and push them to OpenWRT-based devices, where a modem-specific script will execute the actual upgrade on the modem. The modem-specific script/tool must be installed on device by the customer, and it will differ for each modem vendor.
For the initial implementation, we are focusing on supporting the Telit FN990A modem firmware upgrade. As customers begin using this module, they can install their own vendor-specific scripts/tools and validate the upgrade process for other modem models.
To begin with, I would like to understand the recommended approach for proposing and developing new modules intended for inclusion in the core OpenWISP ecosystem. I’m looking for guidance on the preferred process such as architectural discussions, design reviews, and the expected steps before starting development to ensure the contribution aligns well with OpenWISP’s long-term direction.Looking forward to your guidance and queries / suggestions.
Federico Capoano
Hello Rahul,
Thank you for the detailed message and for your interest in contributing to OpenWISP.
At the moment there is no formal or predefined procedure for proposing and accepting new core modules. Inclusion in the OpenWISP ecosystem IMHO depends mainly on two factors:
-
whether the proposed functionality aligns with OpenWISP’s long term scope and there's enough interest from the community to use it
-
whether the project has sufficient resources and active maintainers to sustainably maintain the additional code over time
For this reason, new functionality is usually developed and validated first as an extension of OpenWISP: the core team also does this: we first implement what we need for our own deployments and after an initial period of validation the feature is proposed for inclusion.
Our general recommendation is to focus initially on making your specific use case work for your use case and :
-
design and implement the module in a way that can be integrated with existing OpenWISP deployments
-
document your code, making sure there's instructions on how to install it and use it
-
publish the code publicly and share it on the OpenWISP mailing list
If the module gains adoption, proves useful to a broader audience, and there are contributors willing to maintain it long term, inclusion as an official OpenWISP module can be evaluated at a later stage.
In the worst case, the module remains a third party extension maintained by your team, which is perfectly acceptable and still valuable to the community.
Feel free to share design details or early drafts on the mailing list if you would like feedback while you are working on it.
--
You received this message because you are subscribed to the Google Groups "OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwisp+u...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openwisp/78f07992-da85-430e-abf7-9cca4cc297b5n%40googlegroups.com.
Rahul Bhagwat
Rahul Bhagwat
We have prepared one high level architecture document for new modem upgrader module. We are still in designing and implementation phase.
Let me know if you need it in another standard format.
PFA
Federico Capoano
To view this discussion, visit https://groups.google.com/d/msgid/openwisp/2ebd6e8f-cb8c-4d50-a873-ca4e8a18e526n%40googlegroups.com.