Brume 3 lock up / request timed out

Hello GLinet team,
Last weekend I woke up with no internet at home and LAN was also down. Having installed the Brume 3 a few weeks ago this had never happend with any of the previous Brume routers I had. Also my home automation wallpanels were down which are served over LAN. Tried to login to the Brume but it was not responding well and although I could reach the UI, requests were timing out (see screenshot). Looked like it was running out of resources / memory which then brought my network down? I had to unplug the power to reboot and everything was back up again.

It's a bit scary as it happened out of the blue and I rely on my VPN when not at home, plus my house relies on the router (security cameras access, home automation, vpn, etc.). I'm using my AppleTV as tailscale node as backup but when internet doesn't work..

Context:

  • FW: v4.8.4
  • Connected via WAN to my ONT, DHCP at VLAN 20 to my ISP (1Gb symmetrical fibre)
  • It's serving as my central DHCP server
  • Wireguard server on
  • AdGuard on
  • No DPI etc
  • Glinet dynamic dns on
  • LuCi not installed, no other packages installed

Tried to point Claude Code at the logs but most logs were gone after reboot, it only said AdGuard using 1.3G virtual memory.. but it's virtual memory so it shouldn't have made a difference.

Any known bugs? I never had reliability issues with previous Brumes (one Brume 2 bricked after firmware upgraded with the blue light of death but it it never failed randomly and I could always access the webui..)

Thanks!

Hi,

Please try SSH-ing into the router and running the following commands:

  • Save logs to Flash so they won’t be lost after a reboot:

    uci set system.@system[0].log_size='512'
    uci set system.@system[0].log_file='/root/system.log'
    uci commit system
    /etc/init.d/log restart
    
  • Periodically log memory usage to help determine if the issue is related to memory consumption:

    1. Run the following command to edit the scheduled tasks:
    crontab -e
    
    1. Add the following line to log memory usage every minute:
    * * * * * free | grep Mem | awk '{printf "Memory Usage: Used: %sKB, Free: %sKB, Usage: %.2f%%", $3, $4, $3/$2*100}' | logger -t "MEM_CHECK"
    

If the issue occurs again, please export the logs and send them to us via private message.

How to export logs:

How to send private messages:

Ok, will do!

Just did a regular memory check now..

 CPU: Basically idle — 4% user, 95% idle, load average 0.16. No issues there.

  Memory (real):
  - Total: ~992 MB (~1 GB)
  - Used: ~544 MB (55%)
  - Available: ~390 MB (38%)
  - Free: ~259 MB
  - Buff/cache: ~189 MB
  - Swap: None configured

But then on what's using most memory it pointed at netifyd? It's enabled by default I have not enabled any DPI features?

AdGuardHome: Only 68 MB RSS actual memory. The 1.3GB VSZ is mostly virtual/mapped — nothing to worry about.

netifyd: 368 MB RSS — this is the real memory hog! That's over a third of your 1GB RAM.

netifyd is a deep packet inspection (DPI) / network intelligence daemon by Netify. GL.iNet bundles it for app-level traffic identification (knowing which apps/devices are using bandwidth). It's used by GL.iNet's "Internet Threat Intelligence" and traffic analytics features.

Do you need it? If you're not using GL.iNet's DPI/traffic analytics features in the admin panel, you can safely disable it and reclaim ~370MB of RAM. To disable:

/etc/init.d/netifyd stop
/etc/init.d/netifyd disable

Should this be enabled by default or not?

Yes, netifyd is currently enabled by default in the firmware. However, if no DPI-related features are in use, it does not actually run.
We’re planning to improve this in a future firmware release, possibly in v4.9.

For now, you can use the commands provided by the your AI to stop the service and disable it from starting at boot.

/etc/init.d/netifyd stop
/etc/init.d/netifyd disable