@Sanzium Great to hear that, they are obviously using the same base for all of the devices.
Do you have a link to that site, so I can link it in the wiki as I have started documenting how to root.
@Ansuel Yeah, I already have all 3 FW releases for AX9000 downloaded locally including 1.0.82, but I think that this has not been fixed even in later versions.
Ok, so I documented the SSH jailbreak as best as I can as well as UART and some other stuff.
Note that this is not persistent by default, we will need something like xqrepack to edit the rootfs and make it pernament.
Also, I just tried on 1.0.108 as it apears to have updated itself to that version and reset the U-boot env and the method works.
I would assume/ guess that the ax3600 procedure for modifying bdata via the specially formatted crash partition would work here as well.
I have not seen that so far, how does that work?
I mean, xqrepack just needs to be updated to work with this.
All it takes is to enable dropbear by default, change the channel to debug and kill the nvram reset stuff.
Those magic bytes in the crash partition allow editing bdata, see https://www.5v13.com/mesh/26276.html for the details (google translate does a good enough job on it).
Ok,now I understand.
Those are read to recreate the default nvram(U-boot env in reality) if the bootloader is updated or fw updates decides to wipe config.
So editing them would make the changes pernament, good idea as I need UART to always work as that is easier then using the exploit.
Yes, exactly. There are two gotchas, as long crash contains a5 5a 00 00, wireless will be non-working - and the rewritten bdata will only be accepted as default ubootenv (after resets, upgrades, etc.) if the recalculated checksum is correct - so it's a little risky to try, but I hope it'll work.
Then it actually may really be easier to add support for AX9000 to xqrepack and then use those images, I dont plan to use Xiaomi FW anyway except when needed for development.
@Ansuel I can confirm that they actually use a full QCN9074 connected via PCIe Gen3 port for the 5.8G radio.
Bad news is that ath11k has some support for it since 5.13, but its disabled as it does not really work.
QCA9889 is connected via the Gen2 port which does not appear to work properly as it hangs the boot.
But heck, 2.5G port works.
don't tell me we are back again to pci patch and wlan-open.......
qsdk magic about 2.5?
I wish that its not that time again, I will check maybe my perst GPIO is wrong or something like that.
But QCN9074 wont work out of the box even with backporting as:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath11k/pci.c?h=v5.13-rc5&id=4e80946197a83a6115e308334618449b77696d6a
Geniouses merged support for the device that is broken, I mean even the commit message says so and then they disabled it.
wlan-open has some patch to get it working
Look on the bright side, USB works.
funny how usb would be the only reason to buy that router
would be really curious about usb speed
Its supposedly USB3.0 as Xiaomi even has a toggle in the WEB UI to change between 2.0 and 3.0 to reduce interference.
the faild looks to be memory releated... could be that if we are lucky we just need to port the wlan-open patch about memory... there are some about the pci support for the new wifi module so that could be the reason
i mean with most of the task offloaded and the big 4 core cpu... performance shouldn't be shit this time
Yeah, there is tons of memory and MHI related stuff in the HK14 QCA DTS and Xiaomi one.
It's actually connected like a USB3.0 port and has the pins in the connector.
usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
Yeah, maybe this time USB3.0 wont be slow as on IPQ40xx, there you couldnt even bottleneck USB2.0 port.
BTW, Xiaomi did not configure the U-boot DTS properly so the 2.5G port does not work in U-boot all.
well see the bright side... the router is actually accessible... and in theory all the problem should be fixable...
anyway for the future it think the right way to install openwrt on this is use initramfs first to format partition and then install an image from there...
AND WOW..... if you want to do this bad work at least leave the bootloader open....
Yeah, I am now looking at the bright sides since UART is enabled and actuall work can commence.
They are really lazy, like its so hard to define the PHY in DTS and have it working.
I have a somewhat working initramfs, but its time for sleep and I will push that tommorow.
I used the same one and it did not work for me, I also tried the script and it provided the same password.
So, no idea what was the issue, but password can be set to a desired one by passwd in the exploit string.
Hmm, this isn't working for, it always ends up with "code: 1643" like in your first attempt. I can see that the wifi connect is being setup.
there's no "&" between encryption and enctype in the connect string, is this intentionally?