# Patched Lua binary for GL.iNet 5800 - Memleak Fix

**URL:** <https://forum.gl-inet.com/t/patched-lua-binary-for-gl-inet-5800-memleak-fix/72569>\
**Category:** Router\
**Created:** [November 3, 2026, 8:36pm UTC](https://forum.gl-inet.com/t/patched-lua-binary-for-gl-inet-5800-memleak-fix/72569 "2026-11-03T20:36:45Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![linkstations](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/l/a4c791/32.png) [@linkstations](https://forum.gl-inet.com/u/linkstations)\
**Post date:** [November 3, 2026, 8:36pm UTC](https://forum.gl-inet.com/t/patched-lua-binary-for-gl-inet-5800-memleak-fix/72569/1 "2026-11-03T20:36:45Z")

</div>

Hi,

Not sure if this would be useful for anyone , also never just copy paste binaries in your router unless you know what you do and what IT does!

Recently I bought a GL.iNet 5800 travel router, my FTTH is really bad and sometimes it disconnects all together to my goal was to have ethernet connected to this router with a sim card with data so it would switch automatically when ethernet (FTTH) is down, happily I did the setup , tested , all works but after a few days I see that I can't login to the 5800 router anymore , internet does work but super slow. I understood something is wrong and I did a bit of search and saw other people had the same issue.  
ssh'd to the router and checked a few things and immediately I noticed that the gl\_clients keeps growing in ram, set a script to output the ram usage and in the morning I saw that it took over the whole memory and again it's not accessible, took the binary out and analyzed it a bit and saw that it's a lua script , I do dabble in programming but I have no clue about LUA so I gave it to claude to analyze it and once he found the source of the mem leak I asked him to patch it, I will attach the patched file here which goes to /etc/init.d/ and replaces the original file (take a backup first if you want to)  
once you have replaced the binary better restart the router once to make sure the new binary gets loaded properly although you can use " etc/init.d/gl\_clients stop && sleep 3 && /etc/init.d/gl\_clients enable"

> **[GitHub - greatarsa/GL.iNet-5800-Client-Update: A patched version of client update binary for...](https://github.com/greatarsa/GL.iNet-5800-Client-Update)**
>
> A patched version of client update binary for GL.iNet 5800

here is also the claude notes:

Identified Leak Sources

**1. `clients` table grows unbounded (PRIMARY LEAK)**

- Clients are added on discovery (update\_cache, every `update_cache_interval`)
- `clean_offline_clients` (proto#2) only deletes from SQLite DB
- No evidence the `clients[mac] = nil` cleanup happens in the Lua table
- Lua 5.1 hash tables don't shrink when keys are set to nil

**2. `clients_ip_map` never cleaned**

- Built during each cache update cycle
- Maps IP → client MAC
- Old IPs from disconnected/reconnected devices accumulate
- No cleanup function references this table

**3. No explicit garbage collection**

- No `collectgarbage()` calls detected in string constants
- Lua 5.1 GC on embedded systems may not run aggressively enough
- Each timer cycle allocates temporary tables, strings, closures

**4. SQLite open/close churn**

- `update_db` opens and closes SQLite on every cycle
- Creates Lua userdata for DB handle each time
- If GC doesn't collect old handles fast enough → handle accumulation

**5. `cjson.encode(filtered_clients)` on socket requests**

- Each web UI poll creates a full JSON copy of all client data
- Large string allocation freed only by GC
- Admin panel polls every few seconds

**6. `assoclists` rebuilt each cycle**

- Full WiFi association list queried via ubus
- Previous table not explicitly freed, relies on GC

### Timer Functions (all running concurrently)

| Timer | Function | What it does |
| --- | --- | --- |
| timer\_cache | update\_cache | Scans /proc/oui-tertf/term, adds clients |
| timer\_db | update\_db | Opens SQLite, writes client stats, closes |
| timer\_rate | update\_rate | Calculates speed per client |
| timer\_assoclist | check\_assoclist | Queries WiFi associations |
| timer\_wan\_traffic | update\_wan\_traffic | Reads /sys/class/net/\*/statistics |
| timer\_mtk | update\_mtk\_hwnat | Reads MediaTek HNAT offload stats |

### Fix Feasibility

- **Cannot easily recompile** — needs GL.iNet's custom Lua 5.1 build with type 9 integers
- **Could write a wrapper** that restarts the daemon every N hours as a crude fix
- **Best approach:** keep disabled, write lightweight on-demand replacement if client list is needed
- **Upload method:** netcat via screen session (same as download), target `/usr/bin/gl_clients_update`
- **Persistence:** file survives reboots but NOT firmware upgrades (`sysupgrade` may overwrite `/usr/bin/`)

---

<div class="post-metadata">

**Author:** ![will.qiu](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/w/b38774/32.png) [@will.qiu](https://forum.gl-inet.com/u/will.qiu)\
**Post date:** [November 6, 2026, 1:47am UTC](https://forum.gl-inet.com/t/patched-lua-binary-for-gl-inet-5800-memleak-fix/72569/3 "2026-11-06T01:47:20Z")

</div>

Hi,

Thanks for sharing your findings. We compared the Lua file in your repository with the stock file on our test device and found them to be identical.

We also investigated the client-cache behavior. With a fixed default /24 LAN subnet, the retained entries should remain bounded, so this behavior alone is unlikely to exhaust memory. We have not reproduced the slowdown or login failure you described.

Could you please provide:

1. Your full firmware version.
2. Approximately how many devices connect to the E5800, including historical devices. You can check the online and offline entries under **Admin Panel → Clients**.

To help capture the next occurrence, please run these commands over SSH to save a size-limited system log to internal storage:

```sh
uci set system.@system[0].log_file='/root/syslog.log'
uci set system.@system[0].log_size='10240'
uci set system.@system[0].log_buffer_size='64'
uci commit system
/etc/init.d/log restart
logger -t gl-clients-debug 'persistent logging enabled'

```

If the issue happens again and you need to reboot, please download `/root/syslog.log` and `/root/syslog.log.old` (if present) as soon as possible afterward, and send them to us by private message along with the approximate time of the issue. These logs may capture kernel out-of-memory events.

To send a private message, click our technical-support avatar and select **Message**.

 ![image](https://forum-static.gl-inet.com/original/3X/1/0/10705d4a12191adc9fba880b69bfea7853d44efe.png)