Beryl AX (MT3000) keeps crashing - kernel oops and SER Step 0x05 errors. Help?

Hi everyone,

I’m reaching out here as support seems to be away from office, beryl has been crashing for about two weeks, now and I’m at a complete loss. My Beryl AX (GL-MT3000) has become totally unstable, and I’m pretty sure it’s a hardware issue, but I wanted to see if anyone (or the devs) has seen this before I give up on it.

I’m using it as a repeater (5GHz station mode) connecting to an Asus router, i do have a seperate wan access in the shop but it occurs when using it as wan as well. I’ve tried to rule out every possible environmental factor:

  • Pinned the upstream to a static non-DFS channel 157 (tried other channels).

  • Set bandwidth to 80/40MHz and used variations of wpa2/wpa3.

  • Disabled all local AP radios (2.4 and 5GHz, guest) to reduce heat/interference.

  • Disabled Network Acceleration entirely.

  • Even did a full U-Boot flash to the latest 4.8.2/3 Beta (from 4.8.1 stable) to see if a fresh start would help.

Nothing works. It stays up for a bit and then the logs just explode with errors that don't make sense for a healthy unit.

Here is the weird stuff I’m seeing in the logs:

  1. Physical Errors: Constant header_packet_process(): CheckRxError! even though the signal is perfect. It’s like the radio is just receiving garbage. This happens on both of my networks and any other network i try to repeat after an hour or so.

  2. MCU Hangs: I’m getting HcGetEdca() hobj is not ready! and AsicSetMacTxRx failed!. When this happens, the WiFi just dies and the router becomes non-responsive. sometimes after 30 minutes it straightens itself out. others times i have to manually reboot the device

  3. The Loop: The kernel tries to recover but gets stuck in a loop: SER_HOST_STEP = 0x00000005.

  4. The Crash: Finally, I found a full Kernel Oops in the crash log after it rebooted itself on one occurence: pc : mtf_txdone_handle+0x13c0/0x1438 [mt_wifi] Call trace: mtf_txdone_handle -> asic_txdone_handle -> mt_rx_pkt_process

  5. Logic Leak: Most recently, it started doing something really strange—trying to serve LAN DHCP requests out through the WAN (apclix0) interface.

I’ve spent days troubleshooting this, but if the driver is hitting a Null Pointer Dereference (mtf_txdone_handle), I don't think there's any setting I can change to fix it.

No plugins, no vpn, no adguard, isp provided dns and or google dns, dhcp for most request but a few static ips (NAS, PROXMOX, PC). during failures i cant ping 8.8.8.8, 1.1.1.1, or 10.10.10.1(the beryl) and i can access the UI. I bought a brand new 5v 3a switching powersupply, and later even used the type c power that runs my gmktek (same rating), to no change.

here are some of the most worrisome lines from logs, but i can provide a full sys log whenever, as it crashes every hour so i consistent access to the errors

    1. pc : mtf_txdone_handle+0x13c0/0x1438 [mt_wifi]
    2. 7981@C02L1,mt7981_dump_ser_stat() 6681: ::E R , SER_HOST_STEP = 0x00000005
    3. 7981@C00L1,AsicSetMacTxRx() 1788: SetMacTxRx failed!
    4. 7981@C02L1,HcGetEdca() 1252: wdev=0, hobj is not ready!
    5. 7981@C11L1,header_packet_process() 7261: header_packet_process(): CheckRxError!
    6. 7981@C03L1,AndesSendCmdMsg() 754: Could not send in band command due to diablefRTMP_ADAPTER_MCU_SEND_IN_BAND_CMD
    7. warp_msg_process(): module id(0), wed_idx(0), something wrong(ret = -1)
    8. nf_conntrack: nf_conntrack: table full, dropping packet
    9. daemon.warn dnsmasq-dhcp[11748]: no address range available for DHCP request via apclix0
    10. 7981@C15L1,WPAParseEapolKeyData() 4838: the Group reinstall attack, skip install key (1)
    11. 7981@C09L2,sta_peer_deauth_action() 352: AUTH_RSP - receive DE-AUTH from our AP (Reason=16)
    12. 7981@C08L1,UpdateBeaconHandler() 2047: wdev(2) bss not ready (state:2, caller:HwRecoveryFromError)

Is there a dev here who can look at these logs? I really need an RMA at this point because I can't trust this unit for my home lab anymore.

Thanks for any help.


Hi

Sorry, we just got back from vacation.

We noticed that you have already reached out to us by email regarding this issue.
Please continue working with our support team through the ticket system so we can assist you more effectively.

This post will remain open in case other users wish to share additional suggestions.