Supporting ZSUN Wifi Card Reader (16MB Flash, 64MB RAM, AR9331)

Hello everybody!

I wonder if there is planed support for this highlight of portable hardware.

The ZSUN Wifi Card Reader (technically a router!):

*Architecture: MIPS
*Vendor: Atheros/Qualcomm
*System-On-Chip: Atheros/Qualcomm AR9331 WiSoC
*Flash size: 16MiB SPI
*RAM: 64MiB (32MiB version possibly out there)
*Ethernet port: yes, via external PHY, TX/RX pairs on testpoints
*Serial: yes, on testpoints, 115200 8N1
*Bootloader: u-boot
*Extras: GL827L card reader controller, WAS7227Q USB switch

Information from the openwrt wiki: https://wiki.openwrt.org/toh/zsun/wifi-card-reader
Information from the hackerpsace warsaw: https://wiki.hackerspace.pl/projects:zsun-wifi-card-reader
Github openwrt-zsun fork: https://github.com/Emeryth/openwrt-zsun/issues/
Github upstream merge: https://github.com/openwrt/openwrt/pull/312#issuecomment-276746483

1 Like

I would like to see this device officially supported, I have bunch of them running my custom LEDE build.

But the current problem is that there is no general approval/agreement for having images where Wi-Fi is enabled (and unencrypted) by default. For other devices, which also include only Wi-Fi interface, you can enable Wi-Fi after flash with button - with this particular device it wouldn't be possible as it doesn't have any buttons (I know about SD card detect signal connected to one of GPIOs).

1 Like

Can you distribute your custom build? Does it work and perform like it should?

Can this be really the only problem that there is no release yet? No joke?

That's true. The ZSUN only has one trigger (mechanical sd-card trigger) which should be exclusive reserved for a reset. Otherwise the device can be bricked easily without the possibility of recovering!

Looking forward for a general approval/agreement of handling wifi only devices for LEDE. Wierd world! :stuck_out_tongue_winking_eye:

1 Like

I too would like to see support for this product based on a release build with a stable repository.

It appears a precedent may have been set. There is already one device with similar functionality, the Kingston MLW221 (wireless only, no Ethernet)

https://lede-project.org/toh/hwdata/kingston/kingston_mlw221
https://wiki.openwrt.org/toh/hwdata/kingston/kingston_mlw221

From the OpenWrt wiki

The OpenWrt Image has NO Password set!
It has LuCI installed the WiFi is ENABLED by default and is set to "OpenWrt".

https://wiki.openwrt.org/toh/kingston/mlw221

I do not think that the wireless LAN needs to be delivered as secure, but just enabled by default. As there would be no WWAN, I see no real exposure. The user can secure the device on first boot as desired and then add the WWAN.

There is an OpenWrt ZSun page, but it does not appear to have made it into the ToH.
https://wiki.openwrt.org/toh/zsun/wifi-card-reader

For reference:
https://forum.openwrt.org/viewtopic.php?id=62555
https://wiki.hackerspace.pl/projects:zsun-wifi-card-reader

HI,
me too. I also would be interested to use your custom build for the zsun. Can you make it available for download? Currently I am run the openwrt image from the polish group with an installed travelmate package. Gread stuff!

Regards

I can't, it's private project, sorry guys.

Yes, it's not a joke and I'm pretty sure it's the only one thing which makes this board (and other, similar) officially supported a no-go.

I'm really not that convinced about this solution, but if this is the only one way, then I won't complain.

No, there are no officially supported devices in LEDE with Wi-Fi enabled by default (or if there is any, I don't know about it). Take a look here: https://github.com/lede-project/source/commit/bcfbeae79f799cf1087d692e4869589eb20d2080

Others have different opinion about this subject and to be honest, I agree with them - unencrypted Wi-Fi, enabled by default is not a good idea in these days, especially with well known SSID name and password-less root access...

Others have different opinion about this subject and to be honest, I agree with them - unencrypted Wi-Fi, enabled by default is not a good idea in these days, especially with well known SSID name and password-less root access...

given that this wouldn't let you access anything else, just this device, I don't
see it as being too horrible. When initially imaged, it wouldn't have any of
your data on it.

The vulnerability would be that a bad guy could race you to getting into the
device and put malware on the device that would let them come back later after
you change the password.

Given that the architecture here is that you have a read-only compressed
filesystem and then a read-write filesystem, it seems like you should be able to
have a 'set the password the first time' script that also erased the read-write
filesystem, eliminating anything the bad guy put there (agreed, this doesn't
cover all holes, but it gets pretty close)

Either that, or have a way for the sd card to be mounted to a computer to
edit/create a file that contains the password before loading it.

I'll also point out that anyone who builds an image themselves (probably the
normal case for these devices given the limited functionality they have), can
set the password and wifi parameters. The only vulnerability is people using a
downloaded image.

It's still worth having these as suppored devices with a pre-generated
configuration, even if you end up compiling your own image.

David Lang

1 Like

Like your explanation very much.
Hope this can be accepted, and the device will be officially supported.

Cheers

Really, do you think that the malware is the worse which can happen here? So tell me then, what will happen if that bad guy wins the race and issue mtd firmware partition erase before you connect to the device? :fearful:

What defines "official"? There is a LEDE sysupgrade for the MLW221 that can be found from the ToH page: https://downloads.lede-project.org/releases/17.01.0/targets/ramips/mt7620/lede-17.01.0-r3205-59508e3-ramips-mt7620-mlw221-squashfs-sysupgrade.bin . I can only assume that the config that was available in OpenWrt was brought over to LEDE with little or no review.

I do not understand what the link is trying to tell me.

It appears we are hinging the discussion of supporting these devices based on a highly improbably scenario. Post a warning on the (future) WIKI page and I think that should cover it from a practical perspective. How do we escalate this config issue?

In the mean time is anybody willing\capable of building a sysupgrade image based on 17.01 with wireless enabled? (secured or not, don't care) and just enough to cover the HW features: USB for the card reader and support the functionality tied to the SD card detect pin for factory reset. At least then one can upgrade from CC15.05 and have a supported repository. Unfortunately not in my skill set.

1 Like

I'm using the ZSUN device right now with OpenWRT.

Like told in some posts before the openwrt-image is shipped with an unencrypted/open wifi network with the ssid: openwrt.

The only way to connect to this device (and devices like this - without ethernet) is with a wifi connection.

If the LEDE-developers doesn't want to ship images with open wifi that's OK. But the wifi needs to be enabled and the password needs to be documented. Maybe one way would be to do use different stock-passwords per device.

For example this one coud have the SSID: LEDE and a WPA2-PASSPHRASE: ZSUNwifCARDreaderLOVESledeORnot?

or something like this...
It's for sure everybody changes this after connecting to the device. I really don't see a big problem in this. People don't care would never do the work of flashing LEDE...

My skillset is also limited that I'm not able to build my own software - so I'm not able to use LEDE on this device if there is no image released with wifi enabled. Sad :worried:

It tells you about a change which removed unencrypted Wi-Fi enabled by default and switched to different approach (you can turn on Wi-Fi after flash using a button). In simple words: Wi-Fi is not enabled by default in MLW221.

What is difference between no password at all and well known password? IMHO, there is no difference at all.

The good way to make it would be prepare some mechanism for generating default Wi-Fi passwords based on data which only the user has access to, like WPS PIN in TP-Link devices (stored in FLASH and printed on label).

This maybe work on some TP-Link devices but not on the ZSUN (the device mentioned in this thread). This device has Wifi only and beside the trigger (mechanical sd-card swapping - again: pls reserve this for a reset) there is no button/switch or anything else.

Therefore you suggestions works in theory for a couple devices - but it doesn't solve it for this device.

Sad to see my most powerful device still locked to openWRT... :confused:

PS.: No one overtook my ZSUN even it was with open wifi directly after flashing openwrt! Lucky me! :hushed:

Maybe someone could take a look at this https://wiki.openwrt.org/doc/howto/obtain.firmware.generate Tool to modify images without building?
My Idea would be to make it possible to set a wifi name and password by using a txt-file on the SD, or to autorestore a backup from the SD. What about utilizing rc.local with a command like "find out the uuid of the SD and mount it" + "restore the Wifi-Data on the SD" + "restart Wifi". This way the Zsun would not broadcast unencrypted in a default setting.
I don't know if it works like this. For this we would need someone with the guts to solder an Ethernet Port to the Zsun. Any volunteers?

First things first, please. The first step would be to establish principal support for this particular device in the LEDE tree.

Enabling Wifi after sysupgrade is relatively trivial then. Either through a configuration file injected at build time or, when upgrading, even more easily through an /etc/config/wireless supplied with sysupgrade -f.

Whether or not devices without physical ports and buttons should have Wifi enabled by default is a fundamental discussion that should be had with the whole community, not buried in a thread of a relatively obscure device.

1 Like

Here's my quick port: https://github.com/Emeryth/source/tree/zsun
Without the helping scripts for enabling wifi, factory reset etc. so you need a serial port connection to use it.

Everything seems to be working, most importantly USB device now works (after a bit of soldering) thanks to the recent chipidea patches.
Sysupgrade from openwrt works, but I have not tried it with preserving config.

One problem is that the default LEDE kernel is too big for the original kernel partition (0x130000 bytes).
Disabling kernel debug and symbol table information is enough to make it fit.

1 Like

Glad to see your post here in @Emeryth
actually, glad to see you and your team work with this device
Your openwrt port is very very nice

To beginner user like me it will be awesome if we can get upstream to zsun
it was either official openwrt or official lede. so we can opkg install thing

maybe we can adopt @Kopfpalme idea, adding optional wifi script in image generation
since this is only optional for user that dont want to lockup-with-only-connection-remain-open-is-serial-that-must-be-soldered-first after flashing lede in zsun. (and dont supply default lede firmware image with those option turned on, or just dont supply default zsun firmware image at all)

And maybe you can view this PR in openwrt: https://github.com/openwrt/openwrt/pull/312
Apparently someone want to integrate your port to upstream
but somehow he stuck at image generation

i still learning toward nix and openwrt, with very small undestanding about this ecosystem
i can only hope we can ejoy zsun at its peak. thank you

I would like to see it upstream...

And meanwhile to see links to a working image (wifi enabled by default)... dreaming :smile_cat:

Thank's anybody (special @Emeryth) for the work they did!

Hi everybody,

following this topic and I can understand the concerns regarding the WiFi but as already mentioned the zsun cardreader only has WiFi and nothing else. I would like to see the device becoming officially supported in LEDE but unfortuantely I am no developer. The only thing i can be help of is testing and I find dirlede's idea great. Maybe someone could share an image of Emeryth's source with WiFi enabled for us noobies?

Greetings


modifed your patch with parts of your original openwrt patch, put a binary in too

2 Likes