The AX6000 guide unlocks SSH through a virtual OpenWrt, not a flash

A README with nine steps and a video link, nothing else

It helps to be clear about what this repository is, because the shape of it is unusual. The top level contains a single file, README.md, and there is no source tree, no package manifest and no build. The content is a procedural tutorial in Chinese with an accompanying video tutorial linked from YouTube for the unlock portion. The description says it covers unlocking SSH on the AX6000, flashing OpenWrt firmware, and the ShellCrash proxy client, and the README itself opens by saying the procedure does not require another software router and warning at length that the tutorial is long and should be followed carefully. There is also no licence file in the tree and no licence that GitHub can classify, so treat the text and the linked archives as having unclear reuse terms. The last push was on 2026-08-13, and the release list shows three tagged items, be10000, BE6500Pro and ROM, which are tutorial bundles for other Xiaomi routers rather than releases of software.

The router hotspot is repurposed as a bridge to the virtual machine

The first step sets the mobile hotspot on the router to a known configuration: the network name is changed to OpenWrt, the password to 12345678 and the band to 2.4GHz. The channel matters too, and the guide says to check it, typically 1, using another computer or a phone app that can see the WiFi channel. Everything after this depends on those values being exactly right, because the hotspot becomes the transport between the Xiaomi router and the OpenWrt instance running in VMware. Steps two and three then cover flashing firmware and downgrading the router, and installing VMware with OpenWrt inside it. The OpenWrt instance is reachable at 192.168.5.1 with the username root and the password password, which are the values the guide expects you to use in the virtual machine. Step six has you turn the hotspot back on, set its network connection, and remove Internet Protocol Version 4 from the adapter, and step seven has you edit the virtual network editor for the VM to bridge the connection. The whole arrangement is a network layering exercise before any SSH is involved.

Uploading xqsystem.lua and moving the LAN address to 169.254.31.1

Two file operations carry the unlock. First, WinSCP is used to upload xqsystem.lua into the OpenWrt instance, into the directory /usr/lib/lua/luci/controller/admin/. That placement is what lets the LuCI interface serve the extra endpoint the unlock relies on. Second, and this is the step people miss, the LAN IPv4 address of OpenWrt is changed to 169.254.31.1 in step five. The reason is the link local range. Once the adapter no longer speaks IPv4 and the VM is bridged, the router and the guest have to talk over an address that does not conflict with the existing 192.168.31.1 network the Xiaomi admin interface uses, and 169.254.31.1 is what the guide settles on. The consequences of skipping or mis-ordering these steps show up later as the inability to log in to OpenWrt, which the troubleshooting section treats as a separate problem.

The stok code changes on every login and the unlock leaves no message

Step eight is the unlock request itself, sent to the Xiaomi LuCI endpoint with the SSID, password, encryption, channel and admin credentials of the OpenWrt hotspot:

http://192.168.31.1/cgi-bin/luci/;stok=XXXXXX/api/xqsystem/extendwifi_connect_inited_router?ssid=OpenWrt&password=12345678&encryption=WPA2PSKenctype=CCMP&channel=1&band=2g&admin_username=root&admin_password=admin&admin_nonce=xxx

The stok code is the session token of the Xiaomi admin interface, and the FAQ is explicit that it changes every time you log in, so the value must be taken from the most recent login. If the first attempt fails, the instruction is to log in again, copy the new stok and try once more. The success signal is quiet rather than loud. The guide notes that a successful unlock may produce no message at all, and that you confirm it by connecting with putty and looking for the text ARE U OK. Step nine covers the remaining credential piece: the SN code on the bottom of the router, or visible at 192.168.31.1, is used with the miwifi.dev/ssh page to obtain the default root password, and a downloadable SN.zip archive is offered as an offline fallback if that site cannot be opened.

The 1643 error and the empty dhcp config that fixes it

The troubleshooting section documents the failure modes that the procedure produces. The main one is a JSON response reading a message about a failure requesting the peer interface during the one click device switch, with code 1643. The fix given is destructive on purpose: open /etc/config/dhcp in the VM with vim, hold the d key to delete all of the content, press ESC, type :wq and press enter, then reboot the VM. Truncating the DHCP configuration removes the stale definitions that the router's takeover procedure trips over. A second group of symptoms covers being unable to log in to OpenWrt at 192.168.5.1, with five remedies: reboot OpenWrt by hand or with the reboot command, confirm the OpenWrt address really is 169.254.31.1 and use that one if so, change the local connection IP range to match the OpenWrt network, restore the defaults in the VMware virtual network editor, and then try the OpenWrt address in a browser. The order of those steps matters, since each one rules out a different layer of the setup.

ShellCrash is installed with curl and a mirror list

The proxy client portion is a single command followed by a list of mirrors. The primary install line pulls the installer from a jsdelivr hosted path and runs it in a shell:

export url='https://testingcf.jsdelivr.net/gh/juewuy/ShellCrash@master' && sh -c "$(curl -kfsSl $url/install.sh)" && . /etc/profile &> /dev/null

The README then lists six fallback sources in case the primary one is unreachable, including a raw.githubusercontent.com path, a fastly.jsdelivr.net path, a gh.jwsc.eu.org path, and two variants that download the script to /tmp/install.sh with wget before running it. One of them uses plain http for the URL, and several disable certificate checking with curl -k or wget --no-check-certificate. That is worth naming plainly: the command pipes a remote script straight into a shell with certificate verification turned off, so the mirror you choose is part of your trust boundary. The web interface of the client is then reachable at http://192.168.31.1:9999/ui, and the README links the subscription service it uses along with a putty archive and a Telegram channel.

Bridge through a VM versus reflashing the router itself

The alternative approach is visible inside the same guide rather than outside it, and it is worth separating. The route this README takes keeps the AX6000 on its stock firmware and never reflashes it. OpenWrt lives in a VMware virtual machine on your own PC, and the router is reached through the hotspot bridge, which is why the procedure needs a Windows host, WinSCP, putty and a large sequence of network fiddling. The other route is the one step two alludes to, flashing OpenWrt firmware onto the router directly, using the ROM archive published as a release for older Xiaomi and Redmi firmware. That approach produces a router that is OpenWrt on its own hardware, with no VM and no bridge, but it is a different procedure with different failure modes and it is not written out in this repository. The tradeoff is straightforward. The VM route keeps the router recoverable and reversible, at the cost of a long manual procedure every time the router is rebooted. The flash route gives you a standalone device and removes the VM, at the cost of a firmware write.

Third-party archives and the maintenance question

Everything this tutorial depends on lives outside the repository. The tool bundle is a zip release hosted on another account, the AX6000-SSH.zip download, and the SN.zip archive is hosted there too, along with putty.zip. The unlock script itself is xqsystem.lua, uploaded into the OpenWrt instance rather than fetched from the repository. The README points to the miwifi.dev/ssh page for deriving the default root password and to a YouTube video for the unlock steps. The repository itself carries the README, the release assets, and nothing else, and the release tags are dated bundles for other router models: BE10000 on 2026-08-13, BE6500Pro on 2024-06-18 and ROM on 2024-05-03. So the practical maintenance signal is the last push date rather than a version history, and the practical risk is that any of the external archives or the miwifi.dev page can change or disappear without the repository recording it. A reader who wants to reproduce the procedure in a year should download the linked archives first and keep them locally.

Editorial conclusion

AX6000 suits an owner of a Xiaomi AX6000 who wants a shell on the device and a proxy client on it, and who is prepared to run a VMware OpenWrt instance to reach that goal. It is the wrong guide for anyone wanting a clean OpenWrt installation, because the router itself is never reflashed in this procedure and the unlock relies on the stock admin interface. Verify first that you can reach the router at 192.168.31.1 and the virtual machine at 169.254.31.1, that the xqsystem.lua file from the linked AX6000-SSH.zip is the one matching your firmware, and that the ShellCrash mirror you pick still resolves, since the repository holds only a README and the binaries live elsewhere.

Frequently asked questions

Official sources

1. Issues
2. kjfx/AX6000 on GitHub
3. README
4. Releases