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

@pepe2k:

Weird ... I am not sure how the numbers on the bottom right of the window works. If I scroll to the message, it says "178/185" but if I click on sharing, the link has a "183" . Anyway, yes.

I think would be better to be able to use the wifi to set up the router. It is a lot more convent even for router with wired connection. All consumer routers comes with a WIFI password printed on the box to prevent people to have the user leave them open without a password.

Assuming that all Openwrt firmwares can access the original MAC address and the MAC is easily available to the user, a solution would be to create a default WIFI password based on the hash of the MAC address. People can even use a web page to get it. To avoid easy hacks, Openwrt can set the WIFI's MAC to a something different until a different password is set.

If you want to be more secure, you can just provide a command line tool to embed the first boot password in the firmware image before flashing.

The configuration on a file on media is easier to implement though.

FAT is enough. It can be created, read and written on pretty much any OS. It is also relatively small and for a device sold as "SD reader", it seems already a must have anyway.

What is the impact of having FAT filesystem support for generic on only the devices that need it?
Pros: More people can enjoy Openwrt on a device they own.
Cons: I do not see any. I could understand if adding support for the ZSUN would create problems for other devices but I do not see any. It looks like other devices already have it: https://github.com/openwrt/openwrt/search?utf8=✓&q=kmod-usb-storage . Am I missing something here?

I know a fair amount of people that do not have ethernet cables at all in their houses but everybody has a SD card or a USB drive.

At the moment, more people can use USB port and SD cards than a wired Ethernet connection. The previous generation of Apple laptop had a SD reader but not a Ethernet connection by default. Even on the latest models, the standard dongle that people buy has a old USB port, HDMI port and a SD reader but not an Ethernet connection. And even a few slim PCs do not have the a Ethernet port.

Last thing. You wrote:

anyway, you can always propose the idea on the mailing list, discuss it and try to convince others.

Is the mailing list better than https://forum.openwrt.org ?

1 Like

It depends on user preferences.
But for sure, another way for doing initial setup would be an advantage.

All? Based on my experience I would never say that :slight_smile:

Does this device has an unique WiFi password, printed on label and embedded somewhere, for example in flash?

IIRC, at some point there was a discussion about a generic way to setup default WiFi password/s in the same way as it's done in vendor firmware. One of the problems here is different SSID naming convention. Personally I can't imagine (I suppose that might even violate trademark conditions) OpenWrt setting WiFi passwords and SSIDs to the same values as in vendor firmware... "TP-LINK-ABCDEF"? Nope.

How a password which everyone could generate based on known MAC address and hash function is secure?

There is Image Builder for such modifications. Take generic ath79 kernel, append your custom dtb, include custom wireless config... swap bootloader, break two pieces, get really angry and at the end buy something which isn't that much broken and OpenWrt unfriendly? :wink:

One of the biggest advantages of the OpenWrt is writable filesystem and packages. General approach is to not force people to have embedded packages (you can't remove them from r/o SquashFS), which can be installed later, in generic image. What if user X doesn't want to use this device with SD card reader at all but requires almost whole flash space for whatever reason?

Generic OpenWrt image in general (key word here) contains only packages required to perform basic and dedicated functionality. If the device comes with SD card reader, required drivers will be included in device packages but file system/s support or other additional tools not (that's up to the user).

And I know fair amount of people who don't have any USB drive and SD cards but a lot of Ethernet cables... generalization based on own feelings or practical experience isn't a good argument in discussion.

You are doing it again, this is only your assumption based on your perspective.

If you want to reach decision-making people, mailing list is probably better place to ask such question and showing your ideas (hint: ideas without POC/patch might not get any feedback at all). Only few developers follow and use forum.

And please, don't get me wrong here, it's not that I don't want this device to be supported officially in OpenWrt (in fact, I'm using bunch of them myself with my custom image). But not every devices on the market have to be supported officially in OpenWrt - in some cases, it's just too hard (amount of work, hacks, custom tools, bootloader swap etc.) or even impossible (yeah, manufacturers do a lot to make it harder for all of us, encrypted/signed firmware is just another example). In such cases, users can always build a custom image and use.

Edit: I overlooked the fact that the MAC address is publicly visible to other devices. :sweat_smile: Is there some other way to use similar information to create a good, unique default password?

Isn't it possible to set the password to the MAC address dynamically at boot or am I being too naive?

Here's a proof of concept: I suppose you'd run this once at startup.

$PASSWORD=(cat /sys/class/net/wlan0/address);
uci set wireless.radio0.key=$PASSWORD;
uci commit;

Password is now 12:34:56:ab:cd:ef

An alternative without the colons is possible too, just pipe it through tr -d ":"

$PASSWORD=(cat /sys/class/net/wlan0/address | tr -d ":");
uci set wireless.radio0.key=$PASSWORD;

Password is now 123456abcdef

Let me repeat myself:

Hello,

Discard the option to set wifi password based on MAC.

It make no sense protect the wifi with information that is exposed (host AP announce his MAC addresses).

Salu2

@pepe2k:

another way for doing initial setup would be an advantage.
Completely in agreement =)

I was not suggesting to remove the wired setup. I am saying that the need for a no wired way to set up the router is becoming more and more necessary because more and more people cannot use a wired connection without buying some hardware that would not use otherwise.

Regarding setting a default password: what you need is a way to set a password that is only known to the owner of the router. They all need support from the Openwrt devs.

The MAC address way
The MAC address is a way, if it does not work we can come with something else. Let me clarify what I meant though.

I am assuming that most of the MAC addresses are written in some place in chips on the board but they can be spoof by the driver. Is that the case?

If that is the case, this what I was suggesting:

  1. DEFAULT_WIFI_PASSWORD = SHA1("OPENWrtSalt" + ORIGINAL_MAC_ADDRESS + "OpenWrtPepper"); (probably just the first 10 characters)
  2. DEFAULT_WIFI_NAME=SHA1($DEFAULT_WIFI_PASSWORD + 'LetMakeAName')
  3. On the fist boot we set WIFI_PASSWORD = $DEFAULT_WIFI_PASSWORD.
  4. if WIFI_password == $DEFAULT_WIFI_PASSWORD then SPOOF_MAC_ADDRESS=get_random_mac_address() else...
  5. if WIFI_password == $DEFAULT_WIFI_PASSWORD then "keep nagging the user to configure wifi and change the default WIFI password".

Who does not know how OpenWrt work will have no clue.
You could argue that if somebody was monitoring the wifi, they would have seen your MAC address before. You could add OPEN_WRT_VERSION or/and IMAGE_NAME to the argument of the SHA if you want to make it slightly better. But now the user will need to enter this info in the tool that give them the default password. You can just have a web page and calculate that with pure Javascript.

I am assuming that a user will have the default password only for the time to configure the wifi (probably few minutes). Your neighbors will not be able to log in. Maybe if you are at a hacker convention or you have malicious actors that have been actively trying to hack you, you may be hacked. But in these cases, you should not use wifi anyway.

If you are afraid of somebody leaving it not configured you can turn the wifi after 10 minutes automatically...

This is a lot more secure than just waiting to turn on wifi until you push a button like you wrote above is already happening on WIFI only routers. Once you push the button you are vulnerable to somebody logging in and configuring the router.

Image builder way
It depends on the device and how the factory image is built. I do not ave a good sense about different devices. I guess you could just append a string in clear with PA$$W*RD-PREFIX" + USER_INPUT_PASSWORD+ "PA$$W*RD-SUFFIX at the end. Then on first boot you can scan the flash for that and set it as default password. The support for this need to be added to "generic" though.

About the ZSUN and having FAT support on generic:
Why adding FAT is not a option for the ZSUN. Why these have it: https://github.com/openwrt/openwrt/search?q=kmod-fs-vfat&unscoped_q=kmod-fs-vfat ?

Adding official support on OpenWrt for ZSUN will let no too technical user to use OpenWrt. If you know how to compile and do not want to have FAT on your devices you can still create a custom image without. Again I do not see a problem. The only people that get screw are always who does not know or want to compile OpenWrt. I do not get why "no official support for this device" is better of "we have FAT support on generic on this device" for anybody?

Finally:

ideas without POC/patch might not get any feedback at all

I do not follow the mailing list so I do not know what is going on there. Are you saying that somebody should spend a weekend, or potentially a month of work for something complex, to get a POC that could be deemed as not mergeable by core devs when a conversation could have put that person on the right track early on and make them use their time in a more effective manner?

By the way, assuming you feel there is something good in this conversation, can you send a message to the mailing list with a link to this thread so it is a message coming from a person they already know =) ?

Where did I write that you are suggesting removing wire setup? OpenWrt installation isn't always trivial, there are devices officially supported where installation requires you to open the box and access UART to perform update over TFTP. How many average router users have UART hardware? AFAIK, so far nobody did a research about average OpenWrt user so any assumption here is... just an assumption.

Correct.

That looks ultra complicated and over engineered to me but this is only my personal opinion.

Please, try to read only what I wrote.
I've never said that rf kill button solution is safe, secure and preferred. It's only a workaround for the problem.

Maybe ask authors of these changes?
I wrote in general which doesn't mean that there are no exceptions.

You are missing a point here, no button and Ethernet isn't the biggest problem with this device.

I got confused here. You have some ideas but:

  • you didn't make a research about the topic (mailing list archive is publicly available, topic about default WiFi password was discussed before)
  • you got a hint from core developer that this topis should be discussed on the mailing list but you are still not following it and asking others to send mails there on your behalf
  • you don't want to spend any time on implementing them

Sorry but so far, I don't have such a feeling. This topis isn't trivial and I have a feeling that you won't just get everybody acks right away for implementing your ideas. And, as you are the author of the ideas, you should be the one asking others for comments/feedback about implementing them in code.

1 Like

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).

/J

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.

1 Like

It does appear that the ebay/ali listings have all disappeared. I found the manufacturer of these a while ago:

https://shop62776877.taobao.com/

Goonas had an indiegogo for this https://www.indiegogo.com/projects/ladrive-my-first-indenpendent-private-cloud-server#/

Which looks similar to the zsun on the inside https://fccid.io/2AKBN-LC180/Internal-Photos/03-internal-photos-3196265

The Eaget A50 is a rebrand for $13

This style are all over ebay but it could be different hardware. Likely the MT7688AN as with this device, who knows.

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

1 Like

I setup a 5 nodes OLSR mesh with my Zsun SD100 devices.

1 Like

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.

/J

Will it be too hard to offer oficial image builder with options for SSID and password?

I realise that Windol$ users would have a little trouble using it, but getting up a VM with minimalistic Linux is not that hard nowadays.

What should be the correct name? I mean:

As I see in source, the full name usually is something like this:

tplink,wr12345

Where tplink is the board and wr12345 is the boardname.

I think the boardname for ZSUN should be SD100, or A50 for the EAGATE.

However, they are exactly the same hardware. Which board name should we use for all of them? wifisd? :smile:

https://elinux.org/Device_Tree_Usage#Understanding_the_compatible_Property

1 Like

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 :wink:). If u-boot ignore that partition, nothing different should happen.

The mtd1 special partition: https://drive.google.com/open?id=1aV6Rl6mUzp5sD7baClN3uyEFPfUrcmyu

Please, use it at your own risk.

1 Like

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.

We are talking about modifying environment variables (u-boot-env), not the bootloader itself.

Tried the idea with no luck.

U-Boot 1.1.4 (May 16 2014 - 17:24:30)

AP121 (ar9331) U-boot

DRAM:  64 0
64 MB
Top of RAM usable for U-Boot at: 84000000
Reserving 140k for U-Boot at: 83fdc000
Reserving 192k for malloc() at: 83fac000
Reserving 44 Bytes for Board Info at: 83fabfd4
Reserving 36 Bytes for Global Data at: 83fabfb0
Reserving 128k for boot params() at: 83f8bfb0
Stack Pointer at: 83f8bf98
Now running in RAM - U-Boot at: 83fdc000
Flash Manuf Id 0xef, DeviceId0 0x60, DeviceId1 0x18
flash size 16777216, sector count = 256
Flash: 16 0
16 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ag7240_enet_initialize...
Fetching MAC Address from 0x83ff4138
Fetching MAC Address from 0x83ff4138
: cfg1 0x5 cfg2 0x7114
eth0: 00:03:7f:11:56:48
eth0 up
: cfg1 0xf cfg2 0x7214
eth1: 00:03:7f:11:56:49
athrs26_reg_init_lan
ATHRS26: resetting s26
ATHRS26: s26 reset done
eth1 up
eth0, eth1
Hit any key to stop autoboot:  0 
## Booting image at 9feb0000 ...
   Image Name:   Linux Kernel Image
   Created:      2014-12-27   2:50:53 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1071603 Bytes = 1 0
1 MB
   Load Address: 80002000
   Entry Point:  802398a0
   Verifying Checksum at 0x9feb0040 ...OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 802398a0) ...
## Giving linux memsize in bytes, 67108864

Starting kernel

Will research some other ways...