71–80 of 86 posts
Earlier quoted context omitted.
You have to use the “with desktop” version, I once spent a few hours fighting to get the wifi set up because i was using the “lite” version. The lite version doesn’t react to the wpa_supplicant.conf file.
I don't believe that's true in the most recent versions. I just set up a headless pi with wpa_supplicant in the boot partition of a raspbian lite image that worked well a week or so ago.
Earlier quoted context omitted.
Unless I’m mistaken, /boot isn’t where any kind of network / ssh config would live.
Ssh can be enabled and wifi configured in /boot.
https://github.com/cimryan/teslausb
(Props to Cim and Ray who are doing a ton of work making the project go, also!)
The goals/advantages, vs just using a USB thumb drive:
- will connect to your wifi network (when detected) and copy off your saved dashcam files (over CIFS, SSH, others) - fixes any FAT filesystem errors on the virtual USB drive (presented to the host using g_mass_storage) automatically; some Tesla software versions had/have a bug that left the filesystem dirty on shutdown, rendering some thumb drives unreadable until formatted again
- (in process testing) uses BTRFS to keep the drive online while taking snapshots to do the file copies (and other neat things I have planned, like extending the 1-hour rolling buffer that Tesla uses by copying off files older than 1 hr into a secondary backing store on disk to be copied off later)
- automated (headless) setup by putting a configuration file in /boot (including wifi setup)
- quite a few more ideas to come; love to hear more brainstorms too. Maybe with a little more work it's worth its own Show HN? :)
I've learned a lot about how little I remembered about bash, how Raspbian images are built, setting up Jenkins for automated builds, even controlling the LED on the Pi to show progress of headless setup. (Sometimes it's the little things...)
On the to-do list was something exactly like this post: provide a way to get to the files if you are away from your home network, and/or don't have a computer with a USB or SD reader handy. Say, if you had just gotten in an accident and wanted to get to the files pronto. So, a way to trigger the Pi popping into AP mode was my next area of exploration; timely! I was actually exploring having your phone make a BT connection that would cause the host to switch configs (either automatically, or using BT PAN. (And a web UI to grab files, make settings changes, etc.) Good thoughts on security in some of the comments, and glad to see others have thought through this.
Thanks to OP and others; I think there's a solution one way or another in several of these project ideas! And, as customary, PR's welcome :)
Earlier quoted context omitted.
Hmm, using BLE to send your WPA2-PSK password? Isn't that insecure?
You probably want to encrypt it with a public key for which the raspi has the private key. You could validate the public key with a qr-code on the raspi, or some other pre-arranged scheme. This is a very similar situation to being able to access the device on the LAN over tcp/ip and needing to pass it a secret.
So GUI and displaying the IP at the end is nice. But. I do wonder: If you already have to write a special image, why not just write the network config directly to wpa_supplicant.conf?
I own a company and we are currently developing a hardware tool for attendance tracking at child care centres. We use the Pi and our plans for shipping these things was to ask our customer what their SSID and password were ahead of time and hard code them in. This tool could solve our problem. Additionally, if the user changes their SSID or password at any time, the Pi won't be able to connect. We use a tool called Dataplicity to remote into the Pi and could change the password ahead of time, however if the user changes the password before we can do that, we lose all ability to connect to the unit.
Typically I actually just mount the partitions and chroot with qemu-arm, upgrade packages, and do all of the setup before the SD card is ever inserted in a real Pi. proot[0] makes all this a walk in the park.
mount /dev/sdX2 /mnt
mount /dev/sdX1 /mnt/boot
proot -q qemu-arm -S /mnt
How the heck did we manage to use tech and computers before spy phone apps
https://github.com/jasbur/RaspiWiFi fairly stable light weight system that does the same thing, also comes as an etchable .img one advantage here is that if the Pi goes offline for extended period it will flip on its AP broadcast mode allowing wifi to be setup again. Code is highly modular and maintainable.
Just out of curiosity, but why doesn't Raspberry Pi 3B support simultaneous broadcasting and receiving of Wi-Fi? I've seen multiple apps that swap between these modes (e.g. using broadcast mode to set up a captive portal) and then swapping to receiver mode, but never both at the same time. I've tried many times to configure this, all unsuccessfully. Is there some fundamental limitation with the underlying hardware th…
https://blog.thewalr.us/2017/09/26/raspberry-pi-zero-w-simul...
[1] https://www.raspberrypi.org/documentation/configuration/wire...