You are simply reading diagonally and that is your whole problem.
The devices are exactly the same in terms of hardware but completely different in terms of software.
Very good instructions that lead to 100% positive results when you read and follow them.
If you have AX6S, then the method of receiving telnet is the simplest and only one, or it is the default one.
If you have an AX3200, then there are 4 ways to get telnet. Choose whichever you like. Or is it there by default.
After you have turned on telnet or found out that it is there in any convenient way, start flashing the openWRT firmware.
If you can't read and execute, use the stock firmware.
Installation step1 gives the telnet checking method. It doesn't specify that this method only works for RB03 or RB01. So I assume that this method works for both versions.
Ok, I've checked my RB03 and found out that telnet is disabled. The instruction says that I can enable telnet by flashing stock âclosed betaâ firmware. It doesn't say that after flashing telnet checking method will stop working. Fine, I've flashed that firmware, checked again and got the same result as on original fw. What does it mean? "Closed beta" fw doesn't actually enable telnet or checking method doesn't work? Something else?
Instructions for using the toilet.
Do your thing)))
Wash off after yourself.
To wash hands.
This is bad instructions!!!))
Why?
I shit in my panties!!!))
For what?
The instructions don't say that I have to remove them!!!)))
And the problem with the instructions for the firmware is that it is too detailed and there will always be someone who, while reading it, will forget about what to do and why and then end up shitting themselves in their underwear)))
These are just thoughts, nothing personal)))
1 Like
And the problem with the instructions for the firmware is that it is too detailed and there will always be someone who, while reading it, will forget about what to do.
Ok. Tell me what I did wrong. I've checked telnet according to instruction, flashed workaround according to instruction and checked again. I expected that checking method will show that telnet was enabled after flashing "closed beta". But it did not. Yes, I've confessed that I tried connecting via SSH instead of telnet, so maybe telnet was actually enabled in "closed beta." But if it is so then why the suggested checking method showed fasle? If it shows wrong results then why is it still mentioned in the instructions?
These are just thoughts, nothing personal)))
It's definitely not so and you know it. Otherwise you would not have been posted all this stuff about toilet. And 16 ")"-s don't make it non-personal, IMHO they do exactly the opposite.
What was wrong was that the script for checking the operation of telnet written for the AX3200 firmware, was used for the AX6S firmware.
You yourself wrote that you read and understood that they are completely different in firmware, although they are completely identical in hardware.
Therefore, the software of one is not initially suitable for the software of the other))
As I understand it, you lack communication in real life and are you trying to compensate for this in virtual life?
Or are you just a level 1000 troll?))))
What you are saying is that I use a method which is incompatible with my device. But telnet status is checked by opening specific device url (h__p://192.168.31.1/cgi-bin/luci/api/xqsystem/fac_info). So as I understand, this script is located on the device side and therefore it is a part of firmware. It's not a 3d party code. How can it be incompatible?
1 Like
@Lexeyko you are funny guy 
@Jungle It is good you follow the instructions step by step, but maybe you see the things more complicated than they actually are. Xmir patcher works without any extra knowledge if telenet is enabled or whatever. It is way easier to install openwrt from linux, because patcher is written in python, also cloning from git is a matter of one command, but if you want to go harder way, on windows it should work too, there is this run.bat command in the git.
This is what worked for me (linux ubuntu):
- Download xmir patcher
cd ~/Downloads
git clone https://github.com/openwrt-xiaomi/xmir-patcher - install python
sudo apt install python3.10-venv - download xiaomi factory image (http://downloads.openwrt.org/releases/23.05.2/targets/mediatek/mt7622/openwrt-23.05.2-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-factory.bin) and place it into folder xmir-patcher/firmware
- run xmir patcher
cd xmir-patcher
./run.sh
menu 1 - Set IP-address (192.168.31.1)
menu 2 - Connect to device (install exploit)
menu 7 - Install firmware (from directory "firmware")
menu 9 - [[ Reboot device ]] - log in into openwrt
ssh root@192.168.1.1 (no password yet) and run mentioned commands to disable bricking after reboot:
fw_setenv boot_fw1 "run boot_rd_img;bootm"
fw_setenv flag_try_sys1_failed 8
fw_setenv flag_try_sys2_failed 8
fw_setenv flag_boot_rootfs 0
fw_setenv flag_boot_success 1
fw_setenv flag_last_success 1
And that was pretty much it, I hope I have not forgotten to remove my panties in some of the steps I have made like 10 reboots since and no brick yet, router works as my main router at home now, running snowflake proxy to help people workaround censorship and I still have a lot of free memory. If you don't have linux, just install live ubuntu onto flash disk and do it from there, because it is way easier to install openwrt from linux.
3 Likes
Everything is just as simple on Windows, since Python is already included in the kit.
Through OPKG you can install the luci-app-ttyd package and use it to do all this directly in the browser.
2 Likes
nozombian
Thanks, xmir-patcher is what I had to use. The problem is not that I was not able to use it, the problem is why I had to do it. Initially I just wanted to go "canonical" way. But as long as telnet-checker showed me false, I had to use xmir. And what I'm trying to find out is why telnet-checking gives false for the fw which is claimed to have telnet enabled. If I do something wrong, OK -- I'm able to confess my mistakes, just point me to what exactly I do wrong. But If I do everything right, it could probably mean that the instruction is incorrect at some degree.
1 Like
TL;DR: ^ Follow this mans advice
And here am I:
A first timer with openwrt, in 24h I've flashed openwrt to a Xiaomi AX3200, configured everything as I wanted until 3AM - and then I've unplugged it and turned it into a brick. Glorious victory!
How to recover from this? Will failsafe work? NO! DEBRICK TIME
And then I've noticed I cannot debrick it, because I have no ethernet port nor adapter (thank you Apple). So I've bought one. Now, what the hell is "dnsmasq"? Why is it not seeing the file? Hey Xiaomi-BOI - it is RIGHT THERE!
"No, it's not".
Fast-forward 2 hours: the "/" symbol. All works except.. it doesn't. dnsmasq does it's thing, but can't send the file and there is no error nowhere.
Fast-forward 2 hours I've prepared my Raspberry Pi Zero with my freshly bought ethernet adapter, though a USB-A to USB-C adapter - AND IT WORKS. But man,the flashbacks kick-in again.
"/tmp/debrick" is not the same as "tmp/debrick". And depending on how you write it, it may return an error message in debian.
Fast-froward 1 hour. ALL HAIL DNSMASQ, the blue LED is back!
...and here I am, looking for the folder where I cloned the xmir patcher, to flash openwrt to my Xiaomi AX3200. Man, you just can't get off this ride when you've ridden once, ey?
Maybe try with another power adapter ?
12V, at least 1.5A.
2 Likes
You were absolutely spot on, and I'm embarrassed to admit that I didn't even think to check it. I recently purchased a 12V 2A (24W) power adapter with a 5.5x2.1mm plug and a 5.5x2.1mm to 4.0x1.7mm adapter to replace the Xiaomi 12V 1.5A (18W) power adapter (which required a travel adapter which fit loosely within the power jack). I used a multimeter to test that it was outputting the correct voltage, but was unable to test the amperage. Since the router powered on successfully and seemed to otherwise be functioning normally, I assumed it was OK. Clearly, the power adapter is either faulty or doesn't meet the advertised specification. I've removed my original post to avoid derailing this topic with non-firmware related issues, but I sincerely appreciate your assistance, thanks!
2 Likes
Sorry for asking here (I can't send PMs). If you purchased them online, could you please provide the links? As I understand, original PA has 4.0x1.7mm connector (to the back side). So there were no PA with the appropriate connector and you had to purchase additional one?
I purchased the Xiaomi AX6S, which came with the Xiaomi AD-0181200151CN-3 power adapter (12V, 1.5A, 18W, Type A). I had to use a universal travel adapter to convert the power plug from Type A to Type I. However, the travel adapter fit loosely within the power jack, so I was worried that it might accidentally get knocked and power off the router, or worse, become a fire hazard. I was unable to find a suitable power adapter with both Type I and 4.0x1.7mm plugs. Since power adapters with 5.5x2.1mm and 5.5x2.5mm plugs (with the latter being compatible with the former if the inner diameter isn't a fixed width) are common, I opted for combining one with a 5.5x2.1mm to 4.0x1.7mm adapter. This approach works fine when the power adapter itself isn't faulty (which I've since confirmed with two alternate power adapters). I won't share any links (especially considering the power adapter was faulty), but the 5.5x2.1mm to 4.0x1.7mm adapter is generally classified/labelled as Type G by most sellers on eBay, etc. and should only cost a few dollars. I hope that helps!
3 Likes
@Karolsoon I hope you enjoyed your ride Apple sucks, it is expensive, yet they are not ashamed to save $10 for ethernet adapter, because people will buy it anyway. But it's not only apple, some cheap notebooks has 100mbit ethernet or none, but unlike apple they are cheap at least. Shame openwrt devs still think it is insecure to enable passwordless wifi by default, but they don't worry to use passwordless root. When someone goes over the troubled waters of installing openwrt, he should be capable of setting up passwords. I understand we can't have wifi in failsafe, but if everything works and openwrt boots, there should be wireless way too. I found myself in your situation too, when rather than trying all combinations of passwords I might have used, I used firstboot, but I forgot I have no ethernet cable and wan was conencted directly to a crimped ethernet cable without wall plug...
The router is good, but the power adapter is really strange. I don't know why they had to use different jack than all others like tp link, mikrotik, etc. It will be problem to find matching adapter, or it will be expensive, so I will probably solve it with pliers and soldering xiaomi plug to some standard adapter.
1 Like
Couldnât agree more about the power adapter!
Itâs tight as hell AND it actually sparks (!!!) when I plug the adapter in. Iâd say thatâs some poor design choices right there, even for the price.
And yes @nozombian , I do enjoy the ride! A bit bumpy at times, but enjoyable. So much to see, so much to do 
Probably gonna flash my Archer C6 too, but I wouldnât have any use for it thoughâŚ.
Bought new AX3200 RB01 EU/global version and flashed openwrt via Xmir patcher. Telnet was disabled in stock fw.
Stock fw was 1.0.83 but I don't know which uboot it has.
I have env print from the stock fw and the backup of all mtd blocks, made with xmir.
Using it for a dumb AP and would like to be sure it is not going to brick itself later
@remittor
In your post values of these flags are different for 2 uboot versions (0 vs 8):
This is my nvram values, restarted a couple of time and the above two counters do not increase.
Am I safe?
root@OpenWrt:~# fw_printenv | grep -E 'boot_fw|flag_|ssh|uart|boot_wait|success'
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img;bootm
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=1 uart_en=1
bootmenu_0=1. Load firmware 0 and bootup.=run boot_fw0
bootmenu_1=2. Load firmware 1 and bootup.=run boot_fw1
flag_boot_rootfs=1
flag_boot_success=1
flag_boot_type=2
flag_last_success=1
flag_ota_reboot=0
flag_try_sys1_failed=0
flag_try_sys2_failed=0
ssh_en=1
uart_en=1
Yes. You are safe. You have an old bootloader.
1 Like
Hi,
I'm experiencing weird latency peaks on while connected to the 5Ghz
as demonstrated in the ping below, above 100ms pretty frequently,
it really messes my online warzone gaming experience (it used to be messed only by my skills 
)
Any idea what to look for? how to debug?
I'm using SQM to improve the latency with common/default settings and getting A+ results on LAN,
Fiber 1G/100M,
It does not happens when connected via lan cable (Don't as why I'm not connected via cable, apparently there is some PS5 lan cable bug that I've started to experience: https://www.reddit.com/r/PS5/comments/kk3ypn/ps5_download_speed_significantly_slower_when/ )
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=10.481 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=55.852 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=99.772 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=142.897 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=188.003 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=3.568 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=3.156 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=5.386 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=3.777 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=3.595 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=3.690 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=8.944 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=24.533 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=68.534 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=112.993 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=116 time=3.508 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=116 time=3.047 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=116 time=4.571 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=116 time=4.668 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=3.196 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=3.500 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=116 time=3.910 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=116 time=3.327 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=116 time=3.150 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=116 time=40.503 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=116 time=84.444 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=116 time=6.154 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=116 time=46.855 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=116 time=88.794 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=116 time=4.658 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=116 time=2.973 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=116 time=2.945 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=116 time=68.870 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=116 time=19.055 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=116 time=30.951 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=116 time=6.829 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=116 time=51.814 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=116 time=94.186 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=116 time=139.528 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=116 time=3.055 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=116 time=2.965 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=116 time=3.115 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=116 time=21.960 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=116 time=4.321 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=116 time=3.143 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=116 time=3.778 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=116 time=4.654 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=116 time=15.667 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=116 time=60.119 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=116 time=111.565 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=116 time=150.171 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=116 time=8.578 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=116 time=3.133 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=116 time=3.381 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=116 time=3.703 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=116 time=3.439 ms
64 bytes from 8.8.8.8: icmp_seq=56 ttl=116 time=4.031 ms
64 bytes from 8.8.8.8: icmp_seq=57 ttl=116 time=3.571 ms
64 bytes from 8.8.8.8: icmp_seq=58 ttl=116 time=4.072 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=116 time=39.333 ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=116 time=79.364 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=116 time=3.721 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=116 time=4.331 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=116 time=3.148 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=116 time=3.517 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=116 time=2.874 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=116 time=3.476 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=116 time=3.357 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=116 time=3.352 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=116 time=4.208 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=116 time=4.047 ms
64 bytes from 8.8.8.8: icmp_seq=71 ttl=116 time=45.297 ms
64 bytes from 8.8.8.8: icmp_seq=72 ttl=116 time=92.409 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=116 time=138.184 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=116 time=182.080 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=116 time=418.868 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=116 time=6.183 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=116 time=4.073 ms
64 bytes from 8.8.8.8: icmp_seq=78 ttl=116 time=28.641 ms
64 bytes from 8.8.8.8: icmp_seq=79 ttl=116 time=73.186 ms
64 bytes from 8.8.8.8: icmp_seq=80 ttl=116 time=128.472 ms
64 bytes from 8.8.8.8: icmp_seq=81 ttl=116 time=163.271 ms
64 bytes from 8.8.8.8: icmp_seq=82 ttl=116 time=16.470 ms
64 bytes from 8.8.8.8: icmp_seq=83 ttl=116 time=65.216 ms
64 bytes from 8.8.8.8: icmp_seq=84 ttl=116 time=106.739 ms
64 bytes from 8.8.8.8: icmp_seq=85 ttl=116 time=152.933 ms
64 bytes from 8.8.8.8: icmp_seq=86 ttl=116 time=3.294 ms
64 bytes from 8.8.8.8: icmp_seq=87 ttl=116 time=4.128 ms
64 bytes from 8.8.8.8: icmp_seq=88 ttl=116 time=20.699 ms
64 bytes from 8.8.8.8: icmp_seq=89 ttl=116 time=3.805 ms
64 bytes from 8.8.8.8: icmp_seq=90 ttl=116 time=3.958 ms
64 bytes from 8.8.8.8: icmp_seq=91 ttl=116 time=8.199 ms