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).
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!
The OpenWrt Image has NO Password set!
It has LuCI installed the WiFi is ENABLED by default and is set to "OpenWrt".
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.
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!
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.
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?
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.
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
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...
PS.: No one overtook my ZSUN even it was with open wifi directly after flashing openwrt! Lucky me!
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.
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.
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
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?
