Thanks.

MAC address there looks bad, so I tried to give it a go.

After changing the MACs to something which looks to be ok values, I still have no radio so it may not be all.
On a side note I'm not able to put example values from the ralink's SDK manual.
Script is blocking me from inputting specific values into the fields, so I had to use different set.

I'd still be glad if someone could PM me theirs full flash dump for their me wifi mini.

(Last edited by mike3e on 12 Jan 2016, 15:11)

Just a quick heads-up that I've posted an updated version of the patched OpenWrt/PandoraBox firmware. Also, the original post announcing it has been rewritten almost entirely and updated with all the latest details, so if you're interested, please read it and download here.

Barring some exceptional circumstances this will be the final version for the moment but please feel free to pick up where I left off. Patching and building just got much easier and faster with the shell scripts I wrote to do the job, and all of it can be easily done on the router itself, so hopefully this will encourage others to experiment with it.

Someone have 'fw_env.config'?

I just would like to ask if this function is reasonable, helpful and works properly. Everywhere is posted it might be needed for gigabit routers only and that it could bring some problems with port forwarding and etc. How is it by your experience, doesn't this acceleration cause any noticeable problems on Pandora ?

(Last edited by darkpsy on 14 Jan 2016, 23:50)

StrangeOrange, thanks so much for posting such clear and detailed documentation on your custom version! By the way, do you know if PandoraBox and/or your customized version supports USB Ethernet adapters, e.g. with the kmod-usb-net* modules? I didn't see them available as separate packages in the PandoraBox repository, but am hoping maybe support is already compiled into the kernel.

Thanks,
bdonkey

I switched it on it when I saw it was there and since I didn't notice any issues, I left it enabled. I didn't investigate what it exactly does on this particular device (or if it even does anything at all, besides taking up some memory), so can't really provide a thorough answer. From anecdotal evidence, you are certainly right that various implementations are said to cause some problems in some setups, so if I were getting any firewall-related issues, this would be the first thing I'd switch off.

In my setup, I didn't see any problems whatsoever, although I'm not doing anything fancy either. As for the performance, with a 100/40 Mbps Internet connection on the Ookla Speedtest I am getting something like 90-94/38-42 Mbps (connected through Wifi), while the theoretical limit with the Fast Ethernet switch, which is the bottleneck here, is 95.87 Mbps (Ethernet, PPPoE, IPv4 and TCP overhead - rough calculation, might be wrong), so I didn't do any further performance checks as I figured I'm already getting more than I expected with this hardware.

My customizations are really not that far-reaching, so it's going to be the same as for the "original" PandoraBox. You can see the list of what is being removed (and change it) in the patch source (the file rm_packages.txt). As far as I remember, I only removed the kernel modules related to tunneling, proprietary VPNs, and the Chinese codepage.

As for PandoraBox, I don't really know how to find out support for which hardware is compiled in, as there's neither /proc/config.gz nor /lib/modules/`uname -r`/modules.builtin and I can't see their .config either because we don't have the source code (there's one repository on GitHub, and another one at svn://svn.openwrt.org.cn/ but both seem to be outdated). If there's any particular command that would answer this question for you, let me know and I can run it on my router and paste the output here.

Hi StrangeOrange.

First thank you for all your efforts regarding the MiWifi router :) Appreciated...

I did try to load your firmware within the stock firmware 2.4.9 using the following command:

mtd -r write yourfirmware.bin OS1

And it did work (sort of), let me explain:

The router boot's up but 3/4 seconds after getting a stable "blue" light it reboots :(. I even get (during a split second access to LUCI https page) :)
Is this normal? We must load PandoraBox firmware first and only then running the commands you mentioned above?
Meaning that the procedure I use isn't compatible at all (at least running it on a stock firmware)?

Please advise,
Regards,

FJorgeR.

PS: I recovered the router by copying a development firmware from Xiaomi "miwifi_r1cm_firmware_ae8e6_0.8.39.bin" renamed as "miwifi.bin" to a USB disc, and using the Reset/Power trick to flash it.

(Last edited by fjorger on 15 Jan 2016, 15:50)

Well I did it again the way you specify:

Pandora first and then:

_________________________________________________________
Using username "root".

BusyBox v1.22.1 (2015-07-09 13:52:12 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
  _______________________________________________________________
|    ____                 _                 ____               |
|   |  _ \ __ _ _ __   __| | ___  _ __ __ _| __ )  _____  __   |
|   | |_) / _` | '_ \ / _` |/ _ \| '__/ _` |  _ \ / _ \ \/ /   |
|   |  __/ (_| | | | | (_| | (_) | | | (_| | |_) | (_) >  <    |
|   |_|   \__,_|_| |_|\__,_|\___/|_|  \__,_|____/ \___/_/\_\   |
|                                                              |
|                  PandoraBox SDK Platform                     |
|                  The Core of SmartRouter                     |
|       Copyright 2013-2015 D-Team Technology Co.,Ltd.SZ       |
|                http://www.pandorabox.org.cn                  |
|______________________________________________________________|
  Base on OpenWrt BARRIER BREAKER (14.09, r1216)
[root@PandoraBox_984D:/root]#cd /tmp
[root@PandoraBox_984D:/tmp]#jffs2reset -y
/dev/mtdblock7 is mounted as /overlay, only erasing files
[root@PandoraBox_984D:/tmp]#sysupgrade -n XMWiFiMini-OpenWRT-PandoraBox-14.09r12
16-StrangeOrange-Optimal-U1.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd netifd odhcpd ntpd uhttpd vsftpd smbd nmbd dnsmasq miniupnpd ubusd askfirst askfirst
Sending KILL to remaining processes ... askfirst askfirst
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...

Writing from <stdin> to firmware ...
_________________________________________________________

But the result is exactly the same :(

I'm going to try the minimum and see what happens ...

Nevermind...

Upon a few auto-reboots it's now stable :)

Strange right? Or is it normal?

Regards,

FJorgeR.

PS: Please confirm that the Stock to Optimal (directly) using the "mtd -r write firmware.bin OS1" shouldn't be used! I'm just wondering if I waited a few minutes (during the auto-reboots) the router eventually also recover.

(Last edited by fjorger on 15 Jan 2016, 16:56)

Hi FJorgeR,

Even though the Optimal version comes preloaded with config files, some of them still get overwritten during the first boot. This happens due to more than a couple of original scripts doing their stuff, not just in one place, so for practical reasons instead of making a lot of changes to a lot of files I included a custom /etc/rc.local script that runs last and copies over all those preloaded settings once again. Afterwards, doing a reboot is one way to make sure they are fully applied. This should only happen on first boot as the /etc/rc.local script deletes itself after its job is done.

To sum it up, if it only happens once, it's normal, and it should be over very fast. For the details of what it's all about, see the files /rom/etc/rc.local and /sbin/revert_config. This was the least invasive way to do it I could come up with, and believe me, I spent some time on it trying many things (admittedly mostly waiting for the filesystem to rebuild, and the router to reflash and reboot, etc.) I'm not completely satisfied with the way this is done now (a reboot should be avoidable) but it's progress compared to copying the settings over manually. (As usual, if anyone has a better idea, please feel free to share).

Flashing it from within the stock firmware should be fine the way you did it. What sysupgrade does on OpenWrt is basically the same. I didn't include it as an option because (1) I didn't test it this way myself, (2) stock partition layout has already changed once (the partition used to be "firmware" in older version, and now it's "OS1"), so it's possible it'll change again, and the instructions will no longer apply, which might confuse some people, and once I ditched stock I wouldn't even about it.

Note that there were some reports that going back to stock is not safe if you ever flashed a custom firmware larger than 8 MiB, as some people have been cut off from root access in the stock firmware due to the device losing the record of the serial number. Perhaps this hack by Santamanno would still work then but if not, it'd mean using a hardware programmer to flash any other firmware afterwards. For this reason it might be a good idea to change to a custom bootloader so that you don't need to go back to stock ever again if a situation like this happens.

Hope the new firmware works fine for you.

Thanks for the explanation.
Now it makes sense, just wondering why the first method did end up in a endless loop .
One reason could be the different stock layout?

dev:    size   erasesize  name
mtd0: 01000000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 00c80000 00010000 "OS1"
mtd5: 00b19ae9 00010000 "rootfs"
mtd6: 00200000 00010000 "OS2"
mtd7: 00100000 00010000 "overlay"
mtd8: 00010000 00010000 "crash"
mtd9: 00010000 00010000 "reserved"
mtd10: 00010000 00010000 "Bdata"

The OS1 instead of firmware? I don't think so, and like you mentioned the "firmware" was only present on older firmware's.
Maybe I will get back to Stock once again and repeat the procedure and "this time" wait more patiently for all to finish.
But one hypothesis come to my mind, you do (at a specific time) erase the script that is running at start up, right? What if it's not possible to erase it? It will do the changes again and again and again.

(Last edited by fjorger on 15 Jan 2016, 19:13)

Thanks once again,

So, you recommend this bootloader [https://forum.openwrt.org/viewtopic.php … 73#p304873] ?
Details here [https://forum.openwrt.org/viewtopic.php … 96#p303496] , but one thing we might lose is the USB fail safe mode? Right?

Regards,

FJorgeR.

From the partition layout you posted, "OS1" on stock firmware has the length of 0xc80000 or 13107200, while on PandoraBox it's:

% fgrep firmware < /proc/mtd
mtd4: 00f80000 00010000 "firmware"

Or 16252928, so there is some discrepancy. However OS1 is still larger than the firmware image file, so there issue is not here really.

I think you're onto something here. The /etc/rc.local script removes itself after it's done and before rebooting the system. But since it's in the ROM partition, it cannot really be deleted, so what happens is that a symbolic link is created on the /overlay partition with the target (overlay-whiteout) to mark it as deleted.

So if the /overlay partition were not mounted when it was trying to delete itself, it would just get an error saying something like rm: Read-only filesystem and then it would still be present upon the next boot.

One reason this could happen is if the JFFS2 (writeable) filesystem failed to be initialized because it didn't find its marker (0xDEADC0DE).

The JFFS2 initialization problem will usually appear when going from larger to smaller firmware and there is some leftover garbage in the partition that interferes with the supposedly empty space that is assigned to JFFS2. I think that's what likely happened here, especially as, if I recall correctly, Xiaomi stock images are in the neighborhood of 12MB. So I'd venture a guess that reflashing from stock would have probably worked if you first did an mtd erase OS1.

The firmware image includes the part called a padding to remedy that but I set the build script not to exceed 8MB in size when creating the padding, as I got the impression that it would break the flashing compatibility in some situations. Since the kernel and filesystem are already nearly 8MB by themselves that means the full padding is not appended. Perhaps the limit can be lifted so that the Optimal image includes the whole padding (about 150 kB). Then erasing the partition beforehand would not be necessary in such a scenario.

Still, no matter what it shouldn't end up with a boot loop. It's funny that when I wrote the script it didn't appear to me such a thing could happen (and in fact it just did). Now it seems obvious that, at the very least, the first line of /etc/rc.local should be something like:

fgrep -qs /overlay < /proc/mounts || exit 1

Thanks for bringing this interesting scenario to my attention.

Yeah, it worked great for me the couple of times I got to use it. Just be careful flashing it. There's no USB mode but instead you just plug in the Ethernet cable, get a DHCP lease automatically, point your browser to http://192.168.1.1, and flash whatever you want (even another bootloader). You can also run a program instead of pressing the Reset button on the router. Caveat: it's in Chinese only.

You are welcome :D. What you just presented isn't an hypothesis, and it explains what happened, so we should not use the command  mtd -r write firmware.bin OS1 , due to the possible implications.

Thanks for the confirmation. And yes, I'm going to try it out. it's really sad it's in Chinese though :(

Regards,

FJorgeR.

You can use normal u-boot.
https://mega.nz/#!koQFXQbJ!E2yCFVgNpDXb … kuAOE3fiaw https://mega.nz/#!o4YxkJDJ!OFMwegbZKsrG … 02EzFhgrFk
Sources https://bitbucket.org/padavan/rt-n56u

(Last edited by Althathwe on 15 Jan 2016, 20:49)

Thanks,

Is this the PandoraBox U-Boot? It doesn't have the same size.
It has the sames features of pepe2k u-boot great package (webpage loading for example like the Breed)? Or it does not?
If not what are the advantages of this over the Breed bootloader?

Regards,

FJorgeR.

Its not fork of uboot.

Posted an update (U2) to the patched OpenWrt/PandoraBox, fixing the issue spotted by FJorgeR - thank you for bringing this to my attention. Besides addressing the potential problem during the first boot, there are no other changes, so if the current version is working fine for you, there is no need to do anything. More information and downloads.

Thanks StrangeOrange for the very Quick Fix and for mention me :)

I'm going to test out your (U2) release using the "mtd" flash method, and then I will post my results :)

Have a great weekend.

Regards,

FJorgeR.

(Last edited by fjorger on 16 Jan 2016, 17:16)

That would be great, but I'm afraid Kernel diferencies will render this approach hard to achieve. Unless we do match PandoraBox Kernel (3.14.48).

Regards,

FJorgeR.

Hello,

I want to try OpenWRT in Xiaomi Router. Which fle must I install?

Best regards.

If you are still on Stock Firmware, use Santamanno trick [https://forum.openwrt.org/viewtopic.php … 37#p303437] and open a telnet session then:

Using your computer, copy StrangeOrange U2 firmware https://forum.openwrt.org/viewtopic.php … 78#p306678 [ XMWiFiMini-OpenWRT-PandoraBox-14.09r1216-StrangeOrange-Optimal-U2.bin or XMWiFiMini-OpenWRT-PandoraBox-14.09r1216-StrangeOrange-Minimal-U2.bin] to the root of an USB disc and rename it to firmware.bin

Then insert the USB disc on the Router port.
Run the following command:

cat /proc/mtd

You should get something like this:
dev:    size   erasesize  name
mtd0: 01000000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 00c80000 00010000 "OS1"
mtd5: 00b19ae9 00010000 "rootfs"
mtd6: 00200000 00010000 "OS2"
mtd7: 00100000 00010000 "overlay"
mtd8: 00010000 00010000 "crash"
mtd9: 00010000 00010000 "reserved"
mtd10: 00010000 00010000 "Bdata"

If you do have "OS1" then run:

mtd -r write /extdisks/sda1/firmware.bin OS1

If you get an error (your USB disc isn't "sda1"), then :

cd /extdisks
ls

and locate the right folder representing your USB disc and run the command again with the correct path:

mtd -r write /extdisks/<USBDISC>/firmware.bin OS1

And it's done.

Regards,

FJorgeR.

PS: You should read the entire thread carefully, because everything I said is there.

(Last edited by fjorger on 16 Jan 2016, 19:16)

@StrangeOrange : thanks for your work!

solved[when i flash the firmware the router does not save any changes and runs from ram all the time, is there any way to change that?]

edit : mtd erase rootfs_data + reflashing the image from within pandora solved the issue.

(Last edited by farake on 16 Jan 2016, 19:47)

Thanks all!

I enable the telnet and downloaded this image: http://downloads.openwrt.org/chaos_calm … pgrade.bin

And installed with this command: mtd -r write openwrt-15.05-ramips-mt7620-xiaomi-miwifi-mini-squashfs-sysupgrade.bin OS1

It reboot and now I have OpenWRT, the problem is that I have "Collecting data..." in the interface section. Need I configure something else to get it working?

Thanks for your help.

Regards.