[Solved] Lua MQTT dependency issue

Installing and Using OpenWrt
1

I'm trying to report some system health measurements as well some specific details about the clients connected to AP that's only relevant to me.

For a bizarre reason, my overlay filesystem is tiny but my temp is huge:

Filesystem                Size      Used Available Use% Mounted on
/dev/root                10.8M     10.8M         0 100% /rom
tmpfs                    59.4M      1.9M     57.5M   3% /tmp
/dev/mtdblock6            2.5M    912.0K      1.6M  36% /overlay
overlayfs:/overlay        2.5M    912.0K      1.6M  36% /
tmpfs                   512.0K         0    512.0K   0% /dev

As a result I don't have enough space to install python3-light and I am forced to use the lua interpreter already on the system. Is there an easy way to fix this remotely? If after this the device doesn't come back online I'm in big trouble, so I am hesitant.
I have the following packages installed:

  • lua-mosquitto
  • libmosquitto-ssl
  • mosquitto-client-ssl

On the Lua interpreter I run:
local mosquitto = require("mosquitto") successfully but then the variable mosquitto says it's null, so it seems I can't actually do anything.

Could someone suggest what might be the issue? How else do I verify if an import was successful?

2

tmpfs is RAM based, whereas the overlay is the flash storage. It is what is left over after you flash OpenWrt.

What device are you using?

ubus call system board
1 Like
3 
        "kernel": "5.10.176",
        "hostname": "GL-X300B",
        "system": "Qualcomm Atheros QCA9533 ver 2 rev 0",
        "model": "GL.iNet GL-X300B (NOR)",
        "board_name": "glinet,gl-x300b-nor",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.4",
                "revision": "r20123-38ccc47687",
                "target": "ath79/nand",
                "description": "OpenWrt 22.03.4 r20123-38ccc47687"
        }
}
4

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

1 Like
5

And as far as your original question...

Your device has 16MB flash memory... of that, more than half is consumed by the firmware. The rest is available for installing packages and the like. This storage is not intended for frequent writes -- it will fail if you are constantly writing data (i.e. logs/health data, etc.) to it.

There is a128MB RAM on your board, half of which is used for tmpfs, that's why you see ~60MB in tmpfs. This is not persistent storage, so you can't keep anything there that needs to survive a reboot. But this is fine for temporary data and logs.

Since this unit doesn't have a USB port, there is no opportunity to use external storage. But you can send data to an external server (for example, a syslog server) if you have one availabe.

And as far as "fixing" stuff -- there's nothing to fix, except maybe installing official OpenWrt (I would recommend doing that in person or having some 'boots on the ground' who can help... especially important because it will need to be reconfigured from scratch if you migrate from the GL-inet firmware to official OpenWrt.

As long as you're using GL-inet's firmware, you'll need to ask on their support channels for help, though.

1 Like
6

Thanks Peter. I can understand why OpenWrt forum contributors might take this position. It's hard to diagnose something that could differ in arbitrary and unknown ways. And the insights are not likely to help others.

I've decided to pursue a more standard approach and use Ash + mosquitto_pub to do all my MQTT emission.

The compute and memory on this device are really limiting. My R7800 is a supercomputer computer to this.

7

Makes perfect sense. Yes, this device is a bit limited, although plenty for running OpenWrt in general.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

1 Like