My view is this. Openwrt should officially support wifi only devices without or with limited buttons.
The easiest way to do this is obviously to start it with unprotected wifi at boot. If this for any of the previously stated reasons is deemed too unsafe (I think this is hilarious to even say about this kind of device, imho) then the next easiest solution need to be thought out.
A second alternative could be to use the sdcard and let the user insert a well formatted file that has the password of the wifi which is then brought up when that file is found and properly parsed.
Since there are other devices that has fat included generically, that should not be too big of a hurdle to overcome.
These are the two top alternatives if you ask me, one is easy but "unsafe" and one is slightly harder but safer.
This does not seem to be a scenario where you ask, get permission and then someone accepts your solution. If someone has the know how to make the second alternative a reality, then go for it. Then when its done and works, only then do we argue for that it should be included officially. Its much harder to argue against something that actually works and is safe(r).
I wonder if a suitable compromise would be to include this in the source but not build the images for distribution?
That way it could be “supported” but at the same time the issue of enabling WiFi by default on a WiFi only device could be up to the user who compiles the source to solve in a manner of their choosing.
I think starting with an open wifi network is unacceptable because you will likely be entering some password (to join an existing network as client or changing the AP password) and essentially be sending that password over an unencrypted channel.
Start with wifi disabled and pull the password from the SD card is the best solution IMO
From a safety stand point I absolutely agree.
From a possibility to eventually get it officially supported I absolutely agree.
It seems the Eaget 50 is a 1:1 copy, the other one is completely different hardware and a bit lower spec iirc.
There is at least one other interesting hardware package that, at least in my use case, would serve as a direct replacement of The zsun/eaget dongle. It is the zoomgo media stick. (Support for ZoomGo Media Stick). That is an entirely different discussion though.
Someone with serial access to zsun could try to flash a special u-boot-env? (Serial access in the case something goes wrong)
The idea
I was thinking about the u-boot-env partition. I supose that it could be used, but the OEM bootloader ignore it (thanks to @maurer for uploading the OEM mtd).
If is possible to set parameters to u-boot, It would be possible to boot kernel from a different location without replacing the bootloader. That mean, a simple way to install OpenWrt without kernel size limitation.
To make sure that it works, the special u-boot-env partitions contains only one parameter: bootdelay=45. If it works, zsun should spent a lot of more time to boot (yes, you right. 45sec. more ). If u-boot ignore that partition, nothing different should happen.
Serial console access will not help you with a broken bootloader, to fix that you need a full backup of your flash and a spi flasher (for spi-nor flash - NAND is way more complex) - and a soldering iron to remove the flash for reprogramming.
I assume you got serial access to your eaget, could you please post a picture or two about how you did that? I want to specifically know about how you solved it with the missing rx jumper (I have the later revision), did you need to solder anything, or were you able to connect the hooks straight to something without soldering...
It is "relatively" easy to solder a jumper made of one strand of copper wire with something like this https://www.amazon.com/Vastar-Soldering-Iron-Full-Welding/dp/B01712N5C4 but keep the heat low. Otherwise the pas will come out and then you will have to scratch the little track left with an utility knife and solder on that...