Yoy should push firmware to /tmp folder first you can use wget for that. Btw you must be on OpenWRT for using firmware I shared because it is sysupgrade package. sysupgrade -v /tmp/<image>.bin this command will work. After upgrading I suggest you to reset all settings. Btw before upgrading don't forget to turn on wifi. You can enable it from /etc/config
NOTE: YOU MUST BE AT OPENWRT FIRMWARE TO USE THIS IMAGE. You cannot use this at process of bootloader hacking.
Yes I'm already on OpenWRT as I said above.
Before I do this though, I was using the snapshots from https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/ as of a few days which should be at least somewhat stable right?
For me it drops it's in a constant cycle of dropping network connectivity (holding the internet connection for about 3 seconds, then it has no outgoing connectivity for about 30 seconds).
I'm currently using it as a DHCP client for another combined modem/router, any logs I should look at for this as it's extremely unstable for me at the moment?
If the binaries were built from master I assumed they should be at least somewhat stable.
Edit : to clarify, this is with a direct ethernet connection and not a wifi issue, the SSH session itself is stable but network connectivity is not.
The firmware I shared with you is not based to master branch. It is based to latest stable 19.07 which Openwrt team doesn't provide to you. Thanks to @ilyas he is helped soo much. Actually he did all job. I just played with lan/wan ports. And master snapshots shouldn't be stable. They are under active development without actual bugfixing process. Maybe your other router can cause that kinda issue. You can try to switch old modem to bridge mode without dhcp. Maybe it helps. Ilyas's openwrt is works fine for me than other's except padavan.
This... is much easier. Assuming we have the same endpoint. It's a little hard to tell under the mountain of obfuscation.
Looks like I went with the harrrrrrd option. (Well it was a fun home isolation task to make)
Someone run along and test this. I would but I'm running mine in production now. (Which turns out ain't the greatest idea between patchy 2.4ghz connectivity and the occasional warning from the switch and 5ghz that disrupts traffic)
I did a backport to 19.07.3 from the new commit for the master branch. Everything is working fine (in contradiction to ilyas I left mt76 in place in the dts file and I didn't replace it by pci14c3). I also tried more unusual stuff like 802.11s mesh with sae encryption and it's working without any issues.
Sadly I'm experiencing a strange issue with the mt7530 switch. I can only reach 100 Mbit/s instead of 1 Gbit/s. I can remember that there were some mdio issues in the past so maybe it has some correlation with these issues.
Those of you who tried ilyas firmware version 19.07: Do you also experience the same issue?
@ilyas : I could also upload a staging tree with my modifications for the 19.07 tree. Maybe we can continue testing your or my backport and then doing a PR to get this integrated into 19.07 officially.
Hi, I upddated with firmware from https://github.com/iscilyas/openwrt/releases and it broke all networking. To restore, I connected via UART to it and I got root shell. It seems thet there is config conflicts betwean master snapshort I used before and 19.07. I made few fixes in /etc/config/network and I was able to up link (I see packets on ethernet level) However TCP/IP is not working at all. WAN can not connect to the internet. And router is not accessible via ethernet. Finally I runed firstboot that made settings reset. But it did not fix networking.
I stuck In that state that I can not copy other firmware without networking. It would be really nice if anybody can give me a hint how to fix it.
root@OpenWrt:/# umount /overlay
This will erase all settings and remove any installed packages. Are you sure? [N/y]
/dev/ubi0_1 is n[ 119.440936] ubi0 error: ubi_open_volume.part.3: cannot open device 0, volume 1, error -16
/dev/ubi0_1 will be erased on next mount
writing /dev/ubi0_1 failed: Bad file descriptor
if you're already using openwrt, keep in mind that the partition names are different (vs stock xiaomi)... kernel1 in stock becomes kernel in openwrt, and rootfs0 in stock becomes ubi in openwrt.... so the commands above would become:
mtd write xiaomi-router-kernel1.bin kernel
mtd -r write xiaomi-router-rootfs0.bin ubi
I know, that I am doing it on my own risk.
Thanks for hint. But currently I have issues with delivery new binaries, as far as standard ssh, scp, wget etc... doesn't work for me. I tried to copy it as base64 over UART but it was unsuccessful.
Just as an idea: If the network ports aren't working (maybe due to switch issues as you downgraded from DSA to swconfig) did you try just to create a wifi network and check if TCP/IP is working via wifi?
Then you could upload the fresh install files via SCP and write it to mtd.