Awhile back, I did a pi-gen setup that would check the wifi setup and if it couldn’t connect to a wifi, it would bring the wifi adapter up as an access point. I was thinking about porting that over to the zynthian setup script for cases where you don’t have access to wifi and you’re using an external device to control your zynthian. Would there be any interest in me sharing that?
Hi @DragonForged, this feature is already implemented. You can enabled it from the UI or from webconf .
Anyway, thanks a lot for the offer.
@jofemodo I’ve used the hotspot feature before, and it works perfectly - yet another great thing to love in this magic box!
However, several months ago I ruined an SD card, burned a new image and noticed the hotspot wasn’t set by default, so I did have to get an ethernet cable to get things started. I wonder if this has changed since, and if not, if it would be useful for new Zynthianers?
The WIFI hotspot is disabled by default because it’s an open door and everybody have to be conscious of that and remember to disable it or change the password, that it’s not easy currently.
As we don’t want a lot of zynthians around the world with an open door by default, people wanting to use the hotspot have to enable, what is really easy, from the UI’s admin menu or from the webconf.
I know that it’s very convenient to have the hotspot enabled from the first boot, but it’s too risky and i’m pretty sure that many zynthian users, specially those with lower technical skills, will “forget” to disable the hotspot …
Anyway, i will study the possibility of enabling the hotspot when the error screen is shown and no wifi/wired network is configured/available. This is, probably, the best option without compromising security.
Not sure you can scan for wifi AP’s while the hotspot is on. If not you’re going to need a wired connection either way.
Not sure too
Anyway, we can wait for a while (~10-20 seconds) and if no network connections is up, change to hotspot mode. It should work in most of cases.
Good rationale indeed. As a home user only (i.e., not a stage performer) I’d never considered using an instrument without mastering/tweaking it first - but I can totally get behind a security-first point of view.
How easy would it be to detect a file in the SDcard boot directory on first boot, like the boot/ssh, but maybe boot/hotspot - that could then trigger the hotspot enabled on first boot. Still a user conscious decision, and people will need to have the card in a reader anyway, to burn the Zynthian image, right?
I like the idea of being able to configure the SD card before first boot to allow a fully configured unit to start rather than having to tweak the config in several places with webconf each time a new image is used. A single file which one could keep a copy and place on the boot partition before boot.
Me too. A couple of weeks ago I suggested at least the 4 values for kit, audio, display, wiring
The file you are looking for is:
You can configure almost everything on this file, and combined with the recently added “config-on-boot” service:
we get exactly what you are requesting
Note that not ALL the changes require to run the config script. For instance the variable that control the WIFI mode:
But most of hardware configuration changes require that the config script is run, so the general procedure would be:
- Mount the SD on your laptop/desktop computer
- Modify the config file “/zynthian/config/zynthian_envars.sh”, or copying from your saved config.
- Create the empty file “/zynthian_update_sys” (yes, on root directory!)
- Unmount ,insert on zynthian and boot
This procedure has not been tested yet, but it should work. Those testing it will have all my attention …
Of course, we would need to document every variable on the config file, including the allowed values, etc. Until this documentation is available, use webconf to change the values on this file. Also, webconf source files are very easy to read for extracting the values.
This only works if you can mount the ext4 file system which many normal people may struggle to do. The reason I suggested using the boot partition is because this is FAT32 (vfat) and hence will appear on pretty much any computing device when the SD card is plugged in.
OK! You are right … i will change everything to use the /boot partition
Anyway, could some of you test the procedure i’ve described to confirm it works OK?
It’s exactly because of what @riban said that I can’t try it until the weekend (I can access fat partitions but not the ext ones on the work machine). I’ll give it a go over the weekend!
Thanks, you’re a truly reactive team!
If security is a concern, have it create a random key an display it on the screen as well if the default key has not been changed.
i.e. If key = change_me, create a new key. If its been changed to anything but change_me leave it as is.
Why don’t you add a new file in boot that will be read from the existing? And will be deleted afterwards?
Problem with this is sometimes Zynthian’s screens need to be setup via webconf before they show something (that was my case). And that’s exactly the case (for me) why it’d be useful to have wifi on first boot
Yes - just like the wpa_supplicant, but… having the hotspot rather than the wifi configured (also, setting a blank file is much easier than googling for wpa_supplicant instructions and get it right - I’d much prefer to change this via webconf once i’m in via hotspot)
Just realized MacOS doesn’t have ext4 support out of the box! Googling alternatives, other than having a virtual machine, I see writeable partitions support isn’t as black and white as we’d think in 2020… anyone has experience on this and recommend a working solution, or is the VM way the best chance for now?
I may need more time to test this, was counting on it to be a quick burn image - mount - edit - go thing… On the bright side, I guess this adds to how value the /boot file solution can be
I just updated the “config-on-boot” script like that:
#!/bin/bash BOOT_CONFIG_FILE="/boot/zynthian_envars.sh" # If "zynthian_envars.sh" exist on "/boot" directory, replace zynthian config file with it ... if [ -f $BOOT_CONFIG_FILE ]; then mv -f $BOOT_CONFIG_FILE $ZYNTHIAN_CONFIG_DIR $ZYNTHIAN_SYS_DIR/scripts/zynthian_update_sys.sh exit fi UPDATE_SYS_FLAG_FILE="/zynthian_update_sys" # If flag-file does exist, call zynthian_update_sys.sh and remove flag ... if [ -f $UPDATE_SYS_FLAG_FILE ]; then $ZYNTHIAN_SYS_DIR/scripts/zynthian_update_sys.sh rm -f $UPDATE_SYS_FLAG_FILE exit fi
In other words, if you put a “zynthian_envars.sh” on the “/boot” directory, it will replace the zynthian config and will run the config script.
This is exactly what @riban was asking for, but can be dangerous, as it doesn’t check if the new config file is OK. A better solution would be to parse the file and merge the result with the system config.