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.
(Or just use diffie hellman to generate a symmetric key pair for communicating for the length of the session... you'd still want something to prevent MITM, but if you're not concerned about MITM attacks at session creation time, DH gets user effort down to about zero.)
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?
As evan__10 said, if you don't know the details ahead of time.
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.
Did you consider adding a password-changing webapp that connects via a smartphone's headphone jack? Or maybe even just with a _cheap_ piezo for bidirectional beeping to a smartphone? Consider the equalizer commonly used in the output path of a smartphone, but there should be existing work you might be able to build on.
I wrote exactly the same thing as a library, to allow user setup of the WiFi network from within an app as part of a hardware prototype - main difference being it was just a Go daemon running on the Pi. Didn’t end up using it or open-sourcing it but I will re-visit that, since it looks like there are a couple of use-cases.
Can you seriously put wpa_supplicant.conf in /boot and it’ll work? I have honestly never heard this in 2 years of doing Raspberry Pi, after looking at tons of documentation and web sites. This wouldn’t surprise me, but I feel like it should be much better documented, given that it’s pretty much the first and biggest hurdle to getting things to work on a new image.
I'd like to see one addition to that. On boot, it should also write a file, /boot/MAC-address, if it does not exist. This should be a text file containing the Pi's MAC address.
With that, those whose networks require whitelisting by MAC address who are trying to set up a headless Pi could boot it once to get it to write its MAC address to the SD card, whitelist that MAC address and assign it a static IP address, create /boot/wpa_supplicant.conf, and boot again to get the Pi on their network.
I know you're talking about Someone Else's Network (tm), but isn't whitelisting MAC kind of pointless? MAC can almost always be freely set to any value.
MAC whitelisting as a security measure against deliberate, reasonably knowledgeable attackers is indeed of questionable value. But that's not the only reason you might use MAC whitelisting.
Another use is to prevent accidents. Suppose you have multiple networks. For example, at work we have separate networks for machines that handle different kinds of sensitive data, with each network having the appropriate incoming and outgoing access rules to protect the kind of sensitive data on that network.
In such a situation, MAC whitelisting can protect against someone accidentally plugging a machine into the wrong network. Someone goofs and plugs a machine with customer financial data into a network that has unrestricted outside internet access? It's not on the whitelist for that network, doesn't get an IP address, and they quickly notice something is wrong.
In a home WiFi setting, MAC whitelisting could be used for partial sharing of your WiFi with people who don't know much about networking. Maybe I want to allow my neighbor, who has no idea what a MAC address is, to use my WiFi with his phone, but not to use it with his other devices. I could give him the access info and then use MAC whitelisting to just allow his phone on.
Finally, even if MAC whitelisting is not being used it would still be nice to be able to find out the Pi's MAC address easily, so that you can assign it a static IP address on your WiFi network.
Yes, you can find it out by letting it get a dynamic address on your network, going into the router settings and looking at the device table and figuring out which unexplained device is the Pi, and noting the MAC address.
Then you can configure the router to assign that MAC address a static IP address. In a world where consumer router firmware didn't often suck that would be fine. I've run into routers that once they have assigned a dynamic IP to a MAC address make it difficult to assign it a static IP address.
It's a lot easier if you can do the static IP assignment in the router before the Pi has ever connected to that network.
If you can mac-whitelist, you might also be able to use 802.1X in some form, and be it just locking to the TPM chip or some other crypto token your device has already.
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.
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.
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 that prevents this?
Pi Zero W, I was able to follow these instructions and get AP mode and receiver (client mode) running in parallel a while back. The instructions dont seem specific to hardware:
My understanding was that this always requires an entire second wifi module? On my big expensive desktop computer, I can only ever recieve or broadcast a wifi network, never both. Unless I install an additional wifi adapter.
My first thought was perhaps this could be done using 2.4 for one and 5ghz for the other, but while I was trying to find an example of configuring the radios independently, I came across DD-Wrt "Repeater Bridge" mode [1] so I don't see why that wouldn't be what the Pixel is doing.
This seems like it would be super useful prior to Raspbian Stretch for developers using Apple products.
Prior to stretch the wpa_supplicant.conf file needed to be modified in the main Raspbian partition which is inaccessible on the unix machine without setting up a virtual linux box and creating a vb disk image linked to the sd card. It was a bit of a pain.
With Stretch you can just add a wpa_supplicant.conf file and an empty ssh file to the boot partition which is accessible and you should be ready to go.
This still solves the pain point of there being lots of outdated headless instructions out there telling you to modify wpa_supplicant.conf in /etc/wpa_supplicant on the main partition. Would have saved me a ton of time that's for sure!
Even if you couldn't mount the boot partition on any common desktop OS and setup ssh + wpa_supplicant (it's FAT32), I would greatly prefer the simplicity of a local console session with a $2 USB-serial adapter (am I the only weirdo with dozens of these lying around?).
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
I'm building a gift for someone else that uses a RasPi internally, and thus needed a user friendly way for them to configure its WiFi connection. It's been ... quite the adventure (mostly because I'm dumb).
My first idea was to put an OLED and a rotary encoder on the box. That way they can do a special dance on the button to enter setup mode, scroll through a list of wifi networks, and then tediously scroll through letters to enter the wifi password. I found a 1" OLED for cheap, and already needed a button for other things, so this was a cheap, effective solution.
But having to tediously type out a password with a knob sounded very user unfriendly.
Then I realized I could bring out a USB port, and they could plug in a USB keyboard! So I worked on that for bit. It's a lot easier to use. And the whole keyboard + tiny OLED idea was kinda fun.
But then I remembered the idea of doing a WiFi AP dance. That's where the device broadcasts as an AP, you connect with your phone, browse to a webpage to tell the device your Wifi network's info, and done! It's a solution that doesn't require an OLED or for me to bring out a USB connection. Cheaper and less mechanical engineering.
To that end I found Mozilla's IoT project which, conveniently, has RasPi compatible code for doing just that dance: https://github.com/mozilla-iot/gateway-wifi-setup (By the way, Mozilla's IoT project is neat and worth checking out).
That setup is quite similar to OP, except it doesn't require a separate app. Its downside is requiring the user to mess with the wifi settings on their phone. Not a huge deal (for my target audience) but can be annoying. (Hence why OP's project uses the Bluetooth connection; Smart!)
I've been tinkering with this on and off for about two weeks. While I wasn't thrilled with the solution, it was at least usable, cheap, and easy. ... then I realized I was dumb.
I have a camera on the device. I could just have them go to a website, punch in their wifi info, encode that as a QR code, and have them show it to the camera... (It'd be a secure website I set up, so no security hygiene problems). Same benefits of being cheap and easy, while being easier to use. Using `pyzbar` to do real-time QR detection I had something working within an hour. Just hold your phone in front of the camera and it'll automatically detect, decode, and setup the wifi settings.
The only downside to this approach is that I can't conveniently display a list of nearby wifi networks; so they have to type their SSID manually.
Figured I'd share my comedy of errors in case someone is looking for ideas for wifi setup solutions. Obviously if you're just setting up a RasPi yourself it's easier to just pop a wpa_supplicant.conf on the SD card. (Though I wish Raspbian also had a way to configure hostname, authorized_keys, and disable ssh password authentication through boot files. Only way to do that today is by mounting the root filesystem which isn't convenient on, e.g., a Mac)
Raspbian defaults to being discoverable by bonjour so you can just `ssh [email protected]` and then modify the wifi config file (`/etc/network/interfaces`). You can script this bootstrap process pretty easily using Ansible etc. Downside is you do have to have a machine on the same ethernet network as the rpi for a short time. So fewer "cool project" points but ends up being quite simple.
Aside from the simpler method of dropping wpa_supplicant.conf in /boot as has already been said, mdns support in Android is terrible/non-existent. I've had no end of users struggling because of that, I 100% do not suggest relying on it.
This looks very cool but you should think twice before you use it. If a hacker wanted to infiltrate your LAN, there would be no better way to do it than to provide a tool like this.
> You could make the same argument for other assisted headless installations: speakers, smart plugs, etc.
That's true, but in those devices can be isolated from the internet by a firewall. Berrylan can't be, or it loses its utility. In order to talk to the app, Berrylan has to send packets to and receive packets from the internet. Also, even after the setup, most RaspPi applications entail having the computer continue to have access to the internet. So the situation is much risker with the RaspPi.
That looks useful. Does it delete itself and the extra repo configuration after setup? If not, while convenient I'm not convinced the increased attack surface is worth it.
I must say it's silly we can't be trusted with a simple way to drop in a shell script on the SD card that runs at boot as root in rasbian.
I don't even understand the idea that it could be bad for newbies to maybe mess up. The whole point of the RPi was to give students a small, cheap, easy to repair computer with low-level features to learn with.
Funny enough, I've been about to embark on something similar, for a project I contribute to that makes a Raspi Zero W into a "smart USB drive" for the built-in Tesla dashcam:
(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 :)
Super cool! That being said, Raspbian latest update have been killing my wifi cards...for some reason none of my old realtek usb wifi dongle works anymore. I had to flash one of the older images (June). Anyone else have this problem?
403 for me, i’m in shanghai. but reading the comments, i think i know where you’re going with this. one question i have is, if you have a lot of devices in the same area, how do you make certain the ip address space doesnt collide?
Just started using rpi with my underwater robots. Obviously the wifi cuts off when they dive, but doesn't reconnect always when they come back. Will definitely try this out.
you can just put a wpa_supplicant.conf file on the USB stick partition and it will automatically connect to your wifi[1]. This seems like an overengineered approach that is far more complicated...
My hassle is usually: Where do I dig up that keyboard and spare HDMI video source to bootstrap the Pi. Currently the MAME cabinet does that well, but not everyone has a MAME cabinet.
But you can’t do that from a raspbian image, and if you want me to mod my file system post install that only works assuming I can mount it (eg I have another Linux box with keyboard).
I’ve had this problem multiple times and find this approach really nice (and wish it shipped with raspbian!)
It's an interesting way to do it, but I would personally prefer wifi-based:
* Allows usage from laptops
* No app to install
This could be integrated to several stock pi images from other projects, and I think that's where this really has potential. There's WiFiManager [1] for the esp8266, but this is the first time I came across something similar for the pi.
I don't recall my RasPis having Bluetooth built in. Maybe it's the newer models.
Just saying perhaps including the word "Bluetooth" once in the description would help. Looking at this page the first time it wasn't so obvious what was going on or what it does.
Long story short:
1. RPi broadcasts via BLE the wifi networks it can see
2. A ReactNative App lets the user choose the wifi network to connect to, pre-selected is the wifi network which the mobile is connected to
3. User enters wifi password
4. App sends it to RPI, still via BLE
5. RPi responds with IP address when successfully connected or with an error, all via BLE.
6. App can now talk to Pi via IP
7. BLE server on Pi shuts down. Done.
Advantage: user never needs to mess with changing to any ad-hoc wifi. Awesome UX.