Giter VIP home page Giter VIP logo

iotwifi's Introduction

If you are interested in contributing to this project please use the https://github.com/txn2/txwifi fork. This version is archived for refrence.

Update 2018-12-01. I am archiving this project. The original use case was to enable the configuration of wifi, over wifi, like many IOT devices on the market. It has worked well for me for this purpose. However, many of the issues people have been reporting as bugs are simply other opinions on how it should work for them, and outside of the original use case. Unfortunately, I don't have the personal resources to help in these requests. If others are willing to be contributors I would be grateful; until then, this project is for reference only.

Update: Looking for contributors / maintainers.

NOTICE: This project is intended to aid in developing "configure wifi over wifi" solutions for IOT projects using the Raspberry Pi. The main use case for this project is to reproduce functionality common to devices like Nest or Echo, where the user turns on the device, connects to it and configures it for wifi. I have over 800 devices running this software in production and all have had their wifi configured using it.

This is not a captive portal project. While I have personaly used it for this, it requires additional networking and can be unstable. I don't support this use and so your millage may vary.

iotwifi is only expected to run properly on stock Raspberry Pis and not tested on any other hardware configurations.

IOT Wifi (Raspberry Pi AP + Client)

Go Report Card GoDoc Docker Container Image Size Docker Container Layers Docker Container Pulls

Waffle.io - Columns and their card count

IOT Wifi is very small/8MB Docker Container built for the Raspberry Pi 3. IOT Wifi exposes a simple JSON based REST API for controlling the wireless network interface. This container allows the Raspberry Pi to accept wifi connections as an access point (aka AP) while at the same time connecting to an existing wifi network (station mode).

Go (Golang) was used to develop the main application code, to produce a minimal docker image with great performance. The container runs Alpine Linux with small, optimized versions of hostapd, wpa_supplicant and dnsmasq, controlled by the container's API endpoints.

If you have a Raspberry Pi 3 and you want to provide wifi based configuration abilities, all you need is Docker installed and a little over 8MB of free drive space.

Raspberry Pi AP + Client

Table of Contents

TL;DR? If you are not interested in reading all this, you can skip ahead to Getting Started.

IOT Wifi is a Raspberry Pi wifi management REST service written in Go and intended to run in a Docker container on a Raspberry Pi.

IOT Wifi sets up network interfaces, runs hostapd, wpa_supplicant and dnsmasq to run simultaneously, allowing a user (or another service) to connect to the Raspberry Pi via hostapd/dnsmasq and issue commands that configure and connect wpa_supplicant to another AP. IOT Wifi then exposes a small web server on the Pi and offers a JSON based REST API to configure Wifi. The IOT Wifi container allows you to build a custom Captive Portal web page or even programmatically connect from another device and use the exposed API to configure the target device.

Using wifi to configure a wifi connection is often a standard requirement for IOT. As Raspberry Pis are becoming a popular choice as an IOT platform, this helps solve the frequent need to manage AP and Station modes.

Background

Over a year ago I wrote a blog post called RASPBERRY PI 3 - WIFI STATION+AP with my notes on setting up a Raspberry Pi 3 to run as a Wifi Access Point (Hotspot) and a Wifi Client (aka Wifi Station) simultaneously. This old blog post gets a considerable amount of traffic, so it seems there is quite a bit of interest in this. I have come to realize that some of the steps in my old post have changed since newer versions of Raspian (n00bs build) are released.

Since writing the post, I have had a few personal and professional projects requiring a Raspberry Pi to allow wifi setup over wifi. I decided to open source this simple project to help others with similar requirements as well as gain some feedback on where and how I can improve it. I would welcome any contribution and credit any contributors.

Getting Started

You will need a Raspberry Pi 3, running Raspian Stretch. You can use the Noobs release to install the latest version of Raspian.

Disable wpa_supplicant on Raspberry Pi

You do not want the default wpa_supplicant (the software that communicates with the wifi driver and connects to Wifi networks,) running and competing with the IOT Wifi container.

# prevent wpa_supplicant from starting on boot
$ sudo systemctl mask wpa_supplicant.service

# rename wpa_supplicant on the host to ensure that it is not
# used.
sudo mv /sbin/wpa_supplicant /sbin/no_wpa_supplicant

# kill any running processes named wpa_supplicant
$ sudo pkill wpa_supplicant

Install Docker on Raspberry Pi

Ssh into the Pi or use the terminal application from the desktop on the Pi to get a Bash shell.

# Docker install script
$ curl -sSL https://get.docker.com | sh

Install Docker

# add pi user to Docker user group
$ sudo usermod -aG docker pi

Usermod Docker

Reboot the Pi and test Docker.

$ sudo reboot

After reboot, ensure Docker is installed correctly by running a Hello World Docker container.

# run the Docker Hello World container and remove the container
# when finished (the --rm flag)
$ docker run --rm hello-world

Docker Hello World on Raspberry Pi

Pull the IOT Wifi Docker Image

You can optionally clone and build the entire project, however, to get started quickly I'll show you how to use a pre-built Docker Image. At only 16MB this little image contains everything you need. The image is based on Alpine Linux and contains hostapd, wpa_supplicant and dnsmasq, along with a compiled wifi management utility written in go, the source is found in this repository: https://github.com/cjimti/iotwifi.

# Pull the IOT Wifi Docker Image
$ docker pull cjimti/iotwifi

Docker IOT Wifi Image

IOT Wifi Configuration

You will need a configuration JSON file. You can download a default as a template or just it unmodified for testing. You can mount the configuration file into the container or specify a location with an environment variable.

Use the default configuration file and location for testing:

# Download the default configuration file

$ wget https://raw.githubusercontent.com/cjimti/iotwifi/master/cfg/wificfg.json

Download Configuration

The default configuration looks like this:

{
    "dnsmasq_cfg": {
      "address": "/#/192.168.27.1",
      "dhcp_range": "192.168.27.100,192.168.27.150,1h",
      "vendor_class": "set:device,IoT"
    },
    "host_apd_cfg": {
       "ip": "192.168.27.1",
       "ssid": "iot-wifi-cfg-3",
       "wpa_passphrase":"iotwifipass",
       "channel": "6"
    },
      "wpa_supplicant_cfg": {
        "cfg_file": "/etc/wpa_supplicant/wpa_supplicant.conf"
    }
}

You may want to change the ssid (AP/Hotspot Name) and the wpa_passphrase to something more appropriate to your needs. However, the defaults are fine for testing.

Run The IOT Wifi Docker Container

The following docker run command will create a running Docker container from the cjimti/iotwifi Docker image we pulled in the steps above. The container needs to run in a privileged mode and have access to the host network (the Raspberry Pi device) to configure and manage the network interfaces on the Raspberry Pi. We will also need to mount the configuration file.

We will run it in the foreground to observe the startup process. If you want it to run the background, you need to remove the --rm and pass the -d flag. If you want to it restart on reboot or failure, you can pass the flag --restart=unless-stopped.

Read more on the docker run command.

$ docker run --rm --privileged --net host \
      -v $(pwd)/wificfg.json:/cfg/wificfg.json \
      cjimti/iotwifi

Optionally, you can also provide a wpa_supplicant.conf, like so:

$ docker run --rm --privileged --net host \
      -v $(pwd)/wificfg.json:/cfg/wificfg.json \
      -v <HOST_PATH>/wpa_supplicant.conf:<CONTAINER_PATH>/wpa_supplicant.conf \
      cjimti/iotwifi

Where <CONTAINER_PATH> is the path to wpa_supplicant.conf specified in wificfg.json.

The IOT Wifi container outputs logs in the JSON format. While this makes them a bit more challenging to read, we can feed them directly (or indirectly) into tools like Elastic Search or other databases for alerting or analytics.

You should see some initial JSON objects with messages like Starting IoT Wifi...:

{"hostname":"raspberrypi","level":30,"msg":"Starting IoT Wifi...","name":"iotwifi","pid":0,"time":"2018-03-15T20:19:50.374Z","v":0}

Keeping the current terminal open, you can log in to another terminal and take a look the network interfaces on the Raspberry Pi.

# use ifconfig to view the network interfaces
$ ifconfig

You should see a new interface called uap0:

uap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.27.1  netmask 255.255.255.0  broadcast 192.168.27.255
        inet6 fe80::6e13:d169:b00b:c946  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:fe:c8:ab  txqueuelen 1000  (Ethernet)
        RX packets 111  bytes 8932 (8.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 182  bytes 24416 (23.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The standard wifi interface wlan0 should be available, yet unconfigured since we have not yet connected to an external wifi network (access point).

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:fe:c8:ab  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Connect to the Pi over Wifi

On your laptop or phone, you should now see a Wifi Network named iot-wifi-cfg-3 assuming you did not change it from the default. The default password for this network is iotwifipass. Once connected to this network you should get an IP address assigned to the range specified in the config: 192.168.27.100,192.168.27.150,1h.

Coeect Phone

Once connected open a web browser and go to http://192.168.27.1:8080/status. You can access this API endpoint on the Raspberry Pi device itself from localhost*. On on Pi try the curl command curl http://localhost:8080/status.

You should receive a JSON message similar to the following:

{"status":"OK","message":"status","payload":{"address":"b8:27:eb:fe:c8:ab","uuid":"a736659a-ae85-5e03-9754-dd808ea0d7f2","wpa_state":"INACTIVE"}}

From now on I'll demonstrate API calls to the new container with the curl command on the device. If you were developing a Captive Portal or configuration web page, you could translate these calls into Javascript and control the device Wifi with AJAX.

You can use my simple static web server IOT Web container for hosting a Captive Portal or configuration web page. See https://github.com/cjimti/iotweb.

To get a list of Wifi Networks the device can see, issue a call to the scan endpoint:

curl http://localhost:8080/scan

Connect the Pi to a Wifi Network

The device can connect to any network it can see. After running a network scan curl http://localhost:8080/scan you can choose a network and post the login credentials to IOT Web.

# post wifi credentials
$ curl -w "\n" -d '{"ssid":"home-network", "psk":"mystrongpassword"}' \
     -H "Content-Type: application/json" \
     -X POST localhost:8080/connect

You should get a JSON response message after a few seconds. If everything went well you will see something like the following:

{"status":"OK","message":"Connection","payload":{"ssid":"straylight-g","state":"COMPLETED","ip":"","message":""}}

You can get the status at any time with the following call to the status endpoint. Here is an example:

# get the wifi status
$ curl -w "\n" http://localhost:8080/status

Sample return JSON:

{"status":"OK","message":"status","payload":{"address":"b7:26:ab:fa:c9:a4","bssid":"50:3b:cb:c8:d3:cd","freq":"2437","group_cipher":"CCMP","id":"0","ip_address":"192.168.86.116","key_mgmt":"WPA2-PSK","mode":"station","p2p_device_address":"fa:27:eb:fe:c9:ab","pairwise_cipher":"CCMP","ssid":"straylight-g","uuid":"a736659a-ae85-5e03-9754-dd808ea0d7f2","wpa_state":"COMPLETED"}}

Check the network interface status

The wlan0 is now a client on a wifi network. In this case, it received the IP address 192.168.86.116. We can check the status of wlan0 with ifconfig*

# check the status of wlan0 (wireless interface)
$ ifconfig wlan0

Example return.

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.86.116  netmask 255.255.255.0  broadcast 192.168.86.255
        inet6 fe80::9988:beab:290e:a6af  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:fe:c8:ab  txqueuelen 1000  (Ethernet)
        RX packets 547  bytes 68641 (67.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 36  bytes 6025 (5.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

We can also check the connection by issuing a ping command from the device and specify the network interface to use:

# ping out from the wlan0 interface
$ ping -I wlan0 8.8.8.8

Hit Control-C to stop the ping and get calculations.

PING 8.8.8.8 (8.8.8.8) from 192.168.86.116 wlan0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=20.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=23.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=16.0 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 16.075/20.138/23.422/3.049 ms

Conclusion

Wrapping the all complexity of wifi management into a small Docker container, accessible over a web-based REST API reduces the dependencies on the device to only require Docker.

There are many ways to handle security using middleware or IP tables. A separate container can also manage security.

Check out the project IOT Web to get started with tiny a static web container suitable for building user interfaces for wifi management or captive portals.

Submit a Github issue or pull request if there are features or bug fixes you would like added to the project.

iotwifi's People

Contributors

cjimti avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

iotwifi's Issues

Docker build failing

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Building docker image returns:

Sending build context to Docker daemon  2.399MB
Step 1/17 : FROM arm32v7/golang:1.9 AS builder
1.9: Pulling from arm32v7/golang
1296b637c2f2: Pull complete
0e2ab5e048ba: Pull complete
e1a6513627db: Pull complete
397cc0ade5ea: Pull complete
45538672a803: Pull complete
369f691657f3: Pull complete
453516bc4670: Pull complete
bbf59a23e201: Pull complete
Digest: sha256:5c91a39a7dcf0f9ba1f38c2cbe48b9964024e5fcb8408d1f010780f72a9fbba2
Status: Downloaded newer image for arm32v7/golang:1.9
 ---> 1ba8d01a7dcf
Step 2/17 : ENV GOPATH /go
 ---> Running in 770753108df1
Removing intermediate container 770753108df1
 ---> 25c2f05a12e8
Step 3/17 : WORKDIR /go/src
Removing intermediate container d974fec09baa
 ---> 2179870dcc15
Step 4/17 : RUN go get github.com/bhoriuchi/go-bunyan/bunyan
 ---> Running in 6b3427fdec17
The command '/bin/sh -c go get github.com/bhoriuchi/go-bunyan/bunyan' returned a non-zero code: 139
  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  1. Run docker build . -t iotwifi
  • What is the expected behavior?

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Device: Raspberry Pi B+
    • OS: Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
    I'm trying to provide custom HostAPD configuration for TLWN725n USB WIFI dongle.

Addditional info in README.md

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?
    request for README.md additions

  • What is the current behavior?
    Phones can connect to Rpi only if the container started manually (because of DHCPCD i think)

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  • What is the expected behavior?
    How can i start container automatically on system boot with wificfg.json inside (with some kind of container manual reload command)?

  • What is the motivation / use case for changing the behavior?
    I'm tired...)

  • Please tell us about your environment:

    • Device: Raspberry Pi 3
    • OS: Raspbian Stretch
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Force DHCP on station interface

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    After calling connect API call with successful result, wlan0 doesn't get an IP address and traffic can't flow to the gateway.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Start iotwifi
  2. Call connect API to one of existing networks
  3. wlan0 doesn't receive proper IP configuration
  • What is the expected behavior?
    wlan0 should have an IP address in order to communicate with gateway.

  • Please tell us about your environment:

    • Device: Raspberry Pi Zero W
    • OS: Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
    Logs: https://gist.github.com/cecchisandrone/ad6f7348d2a7eab8096e3492d6ab4733

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ba27:ebff:fee0:496f  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:e0:49:6f  txqueuelen 1000  (Ethernet)
        RX packets 72  bytes 4462 (4.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17  bytes 2720 (2.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Cannot save connected WIFI information into wpa_supplicant.conf

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?
    Report a Bug

  • What is the current behavior?
    Cannot save connected WIFI information into wpa_supplicant.conf

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. run docker container on boot
# Add below command to ~/.config/lxsession/LXDE-pi/autostart
docker run --rm --privileged --net host \
-v /path/to/wificfg.json:/cfg/wificfg.json \
-v /path/to/wpa_supplicant.conf:/etc/wpa_supplicant/wpa_supplicant.conf \
cjimti/iotwifi
  1. Try to connect WIFI network
$ curl -w "\n" -d '{"ssid":"MYSSID","psk":"mypassword"}' \
-H "Content-Type: application/json" \
-X POST localhost:8080/connect
  1. check wpa_supplicant.conf (or just reboot and check network status)
$ sudo docker exec CONTAINER_ID ls -al /etc/wpa_supplicant/
  • What is the expected behavior?
    Save WIFI information into wpa_supplicant.conf and can reconnect to the network after reboot.

  • What is the motivation / use case for changing the behavior?
    N/A

  • Please tell us about your environment:

    • Device: Raspberry Pi 3 Model B+
    • OS: Raspbian Stretch 9.4 (NO NOOBS)
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Here is my result of step 3.
test_result

localhost:8080/connect api issue from iOS Device

  • I'm submitting a ...
    • bug report

DESCRIPTION:
There is a bug in the localhost:8080/connect. I am calling the API http://192.168.27.1:8080/connect from my iOS app. The data is being sent exactly like how it's shown in the documentation. The raspberry pi connects to my home wifi however the api does not give any response. It times out.

ERROR: The API successfully connects the Raspberry pi to the wifi but I do not get any response from the api. Please help.

ENVIRONMENT:

  • Device: iPhone 5s
  • OS: iOS

Add disconnect endpoint.

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Killing the iotwifi container, keeps WIFI ssid visible, probably some processes stay alive.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Start with docker run --rm --privileged --net host \ -v $(pwd)/wificfg.json:/cfg/wificfg.json \ cjimti/iotwifi
  2. Hit CTRL+C
  3. Configured WIFI network is still visible by devices
  • What is the expected behavior?
    After killing the container I expect everything cleaned in terms of resources / processes.

  • Please tell us about your environment:

    • Device: Raspberry Pi Zero W
    • OS: Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

"post wifi credentials" ,this part can't work on openwrt with shadowsocks

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?

  • What is the current behavior?

I tried several times, it can't connect my router which has shadowsocks, or has a very unstable connection, I have to say it works in few chance, but when I reboot RPI, obviously no automatically connect, if I input:

curl -w "\n" -d '{"ssid":"home-network", "psk":"mystrongpassword"}'
-H "Content-Type: application/json"
-X POST localhost:8080/connect

three or four times to try to connect my router, even the AP don't work.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  • What is the expected behavior?

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Device: RPI 3B+
    • OS: stretch
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Bridge/repeater mode?

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?

I have a question.

  • What is the current behavior?

When I connect to the RPi running in AP+Station mode using my laptop, I cannot access the internet from the RPi, even though the RPi itself has access to the internet via station mode. I can ping 8.8.8.8 from the RPi and have no trouble reaching the internet when SSH'd into the RPi...

  • What is the expected behavior?

I would like to be able to access the internet from a client connected over Wi-Fi using AP mode, when the RPi is connected to an internet enabled router. Is this possible, and if so, how?

Raspberry Pi Zero W

  • I'm submitting a ...

    • [x? ] bug report
    • feature request
    • [x ] support request
  • Do you want to request a feature or report a bug?
    Not sure if a bug or not as i dont know if the pi zero w is supported.

  • What is the current behavior?
    I followed your guide up to this part

docker run --rm --privileged --net host
-v $(pwd)/wificfg.json:/cfg/wificfg.json
cjimti/iotwifi

When i run this the pi will just spit out loads of lines i ran it for a few minutes and at no point did an access point appear on my phone or laptop so i assume that the pi zero isn't supported i can't open another terminal while it's running as the pi zero has no ethernet so i cant interface with it while that command is running . I would like to ask for you to add pi zero w support

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  • What is the expected behavior?

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Device: Pi Zero W
    • OS: Raspbian Stretch Lite
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Could you add WEP support?

  • I'm submitting a ...

    • [๐Ÿ™…โ€โ™‚๏ธ] bug report
    • [โœ…] feature request
    • [๐Ÿ™…โ€โ™‚๏ธ] support request
  • Do you want to request a feature or report a bug?

It is a feature.

  • What is the current behavior?

WPA-2 Encryption

  • What is the expected behavior?

A configuration option to use WEP encryption instead.

  • What is the motivation / use case for changing the behavior?

I've just discovered this project and it's helping solve a problem I've run into in a project of my own.

I'm building an intentionally vulnerable raspberry pi image for use as an IoT pentesting range. I'd love for it to broadcast a WEP network to be used not only for connectivity, but as another surface area that one can choose to attack.

Unfortunately, I can't use apt to install dnsmasq or any other dns server applications I've come across, because the sources are outdated in the raspbian image I'm using. Updating the sources would defeat the point of being able to load old, intentionally vulnerable software, and I was at a roadblock until I came across this project.

Running within Docker solves my problem handily. Unfortunately, I'm not savvy enough to figure out where within these configs I can change it to use WEP instead of WPA-2.

If you could add a line in wificfg.json that toggled WEP on instead of WPA-2, it'd help immensely.

  • Please tell us about your environment:

    • Device: Raspberry Pi 3b
    • OS: 2016-09-23-raspbian-jessie

Container keeps crashing

  • I'm submitting a ...
    • bug report
    • feature request
    • support request

I have a Raspberry Pi 3 Model B and a Raspberry Pi 3 Model B+.
And I flashed 2018-04-18-raspbian-stretch-lite.img to the Micro SD cards of both of them (using Etcher).
Both Pis should host an AP and one Pi should connect the other Pis AP while the other Pi should connect to my home WiFi. The docker containers keep crashing almost immediately, though.

I documented everything I did:

I booted both of them up (for the first time with the newly flashed images) and used raspi-config to:

  • set the keyboard layout to German
  • set the timezone to Germany
  • set the WiFi country to BO
  • change the default password
  • change the host name
  • enable SSH

then I rebooted and ran:

sudo apt update
sudo apt upgrade
sudo apt install vim screen git nmap

then for the Pi 3b I changed /etc/wpa_supplicant/wpa_supplicant.conf to:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=BO

network={
    ssid="MyHomeNetwork"
    psk="PasswordOfMyHomeNetwork"
}

for the Pi 3b+ I used:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=BO

network={
    ssid="rpi3bwap"
    psk="iotwifipass"
}

Then I ran:

sudo systemctl mask wpa_supplicant.service
sudo pkill wpa_supplicant
curl -sSL https://get.docker.com | sh
sudo usermod -aG docker pi
sudo reboot

After the reboot I ran

docker run --rm hello-world

which worked as expected.
Then I ran:

docker pull cjimti/iotwifi

Then I created ./wificfg.json and for the Pi 3b I set it to:

{
    "dnsmasq_cfg": {
      "address": "/#/192.168.27.1",
      "dhcp_range": "192.168.27.100,192.168.27.150,1h",
      "vendor_class": "set:device,IoT"
    },
    "host_apd_cfg": {
       "ip": "192.168.27.1",
       "ssid": "rpi3bwap",
       "wpa_passphrase":"iotwifipass",
       "channel": "11"
    },
      "wpa_supplicant_cfg": {
        "cfg_file": "/etc/wpa_supplicant/wpa_supplicant.conf"
    }
}

For the Pi 3b+ I set it to:

{
    "dnsmasq_cfg": {
      "address": "/#/192.168.28.1",
      "dhcp_range": "192.168.28.100,192.168.28.150,1h",
      "vendor_class": "set:device,IoT"
    },
    "host_apd_cfg": {
       "ip": "192.168.28.1",
       "ssid": "rpi3bpwap",
       "wpa_passphrase":"iotwifipass",
       "channel": "11"
    },
      "wpa_supplicant_cfg": {
        "cfg_file": "/etc/wpa_supplicant/wpa_supplicant.conf"
    }
}

I used channel 11 just in case, because that is the same channel as my home WiFi. For the Pi 3b+ I used 192.168.28.x instead of 192.168.27.x, also just in case in matters.

Then I ran:

docker run -d --restart=unless-stopped --name=wifi --privileged --net host -v $(pwd)/wificfg.json:/cfg/wificfg.json -v /etc/wpa_supplicant/wpa_supplicant.conf:/etc/wpa_supplicant/wpa_supplicant.conf cjimti/iotwifi

(Note that I'm passing the wpa_supplicant.conf through.)

Since it didn't work at that point I rebooted and then I ran:

docker stop wifi
docker rm wifi
docker run -d --restart=unless-stopped --name=wifi --privileged --net host -v $(pwd)/wificfg.json:/cfg/wificfg.json -v /etc/wpa_supplicant/wpa_supplicant.conf:/etc/wpa_supplicant/wpa_supplicant.conf cjimti/iotwifi

But it was still not working correctly on either of the Pis.

On the Pi 3b+ the Docker container keeps crashing. The output of docker ps -a was:

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                      PORTS               NAMES                                  
b625404fad52        cjimti/iotwifi      "/wifi"             About a minute ago   Exited (2) 40 seconds ago                       wifi  

It crashes after around 30-60 seconds.

Here is the output of docker logs wifi on the Pi 3b+: rpi3bp.log (MAC addresses and SSIDs censored)

(log of the original post: docker.log (MAC addresses and SSIDs censored))

On the Pi 3b it was slightly different. The container keeps running, but it spits out massive amounts of log output and it doesn't actually work...
Here is the output of docker logs wifi on the Pi 3b: rpi3b.log (MAC addresses and SSIDs censored)

Raspberry Pi Zero W compatibility

  • I'm submitting a ...
    • bug report
    • feature request
    • support request

Hello,
I'm very much interested in seeing this working on a Raspberry Pi Zero W.
Will you add support for that?

Cool but why do I need Ethernet

This is great tutorial. May I have a suggestion?

This configuration requires additional hardware, an Ethernet cable. It is a bit not logical to deal with WiFi configuration while there is a need for cable.

I would recommend to download all packages first and then turn off the wpa_supplicant. I would also recommend to put all steps into simple shell script, so Raspberry could be configured over ssh and WiFi.

Thanks, Jan

Can uap0 and wlan0 be bridged ?

  • I'm submitting a feature request

  • What is the current behavior? : when connecting a device to the Raspberry Pi access point on uap0, there does not seem to be a bridge between uap0 and wlan0, so the connected device cannot route trafic through the Raspberry Pi access point's WLAN0 connection.

  • Steps to reproduce the problem

  1. Ensure the IOT Wifi has an Internet connection on Wlan0
  2. Connect a device on the IOT Wifi access point
  3. Try and ping an internet host on the device
  4. All traffic resolves to 192.168.27.1 (IOT Wifi device)
  • What is the expected behavior?

Ideally the IOT Wifi WLAN0 and UAP0 network adapters would be bridged

  • What is the motivation / use case for changing the behavior?

This would allow devices connected on the IOT access point to get internet connectivity. This may or may not be desirable, but if the IOT WIFI device is to act as a configurable gateway, this would be useful.

  • Please tell us about your environment:

    • Device: Android or Ubuntu laptop
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

For an example, see
https://github.com/peebles/rpi3-wifi-station-ap-stretch
"Bridge AP to client side" paragraph

Unable to assign custom SSID

  • I'm submitting a ...

    • [x ] bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?

Reporting a Bug

  • What is the current behavior?
    When SSID is changed from the default SSID , docker run command as per the documentation when executed does not start properly

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Replace the SSID to another name , and start with the docker run command
  • What is the expected behavior?

Able to change the default SSID to a SSID name of choice.

  • What is the motivation / use case for changing the behavior?

N/A

  • Please tell us about your environment:

    • Device: Raspberry PI 3 B+
    • OS: Rasbian Stretch from NOOB
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Hide the SSID

  • I'm submitting a ...
    • bug report
    • feature request
    • support request

Thanks for this Docker Container it's pretty much doing exactly what I need it to do.
However, I am looking to hide the SSID that I am broadcasting with this container but I am a little unsure if that configuration is set via the mounted wpa_supplicant.conf file or if it is set via hostapd.

If it is done via hostapd - are you reading the conf file from: /etc/hostapd/hostapd.conf inside the container?

Raspberry Pi 3 Model B+ (New Release March 2018) supported?

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Please tell us about your environment:

    • Device: Raspberry Pi 3 Model B+ (Release March 2018)
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Is this software working on the new Raspberry Pi 3 Model B+ which released last month?
I want to create a cluster with several raspberry pi and plan to buy the new version.

Thanks for your help and great software.

Raspberry Pi 3 B+

  • I'm submitting a ...

    • bug report
    • feature request
    • [ x] support request
  • Do you want to request a feature or report a bug?
    None

  • What is the current behavior?
    Client is not able to authenticate and connect to the iot-wifi-cfg-3. Seeing authentication problem

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Unsure if it is a bug or conifguration issue

  • What is the expected behavior?

Client should be able to connect to the iot-wifi-cfg-3 network

  • What is the motivation / use case for changing the behavior?

N/A

  • Please tell us about your environment:

    • Device:
      Brand new Raspberry PI E B+

    • OS:
      Fresh install of Raspbian stretch through noob

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
    Using the docker , seeing the SSID so that the clients can connect , but unable to authenticate .

dnsmasq resolves any query to IP of uap0

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?
    I'd like a new feature to allow specifying upstream DNS server/honouring existing configured DNS servers of wlan0.

  • What is the current behavior?
    dnsmasq resolves any query to IP of uap0, there is no option to specify an upstream server for dnsmasq. I've checked the source code and this seems to be hardcoded.

  • What is the expected behavior?
    I'd expect dnsmasq to either forward to DNS configured in /etc/resolv.conf or honour a "server" entry in the "dnsmasq_cfg" config.

  • What is the motivation / use case for changing the behavior?
    The raspberry PI is supposed to be a router/bridge for the wifi of my dash cam which can't connect to 802.1x networks, the REST API would allow me to easily connect the RPI to new wifi networks or even better, auto connect to open networks any try them. Either way, without a working DNS resolution on the uap0 network, this is not going to proceed anywhere.

  • Please tell us about your environment:

    • Device: Raspberry Pi Zero W
    • OS: Raspbian Stretch

Cannot connect as client to wifi network of router

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • What is the current behavior?

I cannot connect to my existing wifi at home (or smartphone hotspot) even if the api scan shows the network.
I am able to connect to the raspberrypi accesspoint point though.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

The command:
curl -w "\n" -d '{"ssid":"<nameofmywifi>", "psk":"<passwordofmywifi>"}' -H "Content-Type: application/json" -X POST localhost:8080/connect
returns:
{"status":"OK","message":"Connection","payload":{"ssid":"","state":"FAIL","ip":"","message":"Unable to connection to <nameofmywifi>"}}

  • What is the expected behavior?

Connect to my wifi as client

  • Please tell us about your environment:

    • Device: Raspberry Pi 3 Model B (without +)
    • OS: Raspbian Stretch 2018-03-13

Troubleshooting when uap0 isn't created

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?

Report a bug or get help

  • What is the current behavior?
$ docker run --rm --privileged --net host -v /home/keith/wificfg.json:/cfg/wificfg.json cjimti/iotwifi
{"hostname":"raspberrypi","level":30,"msg":"Starting IoT Wifi...","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.364Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HTTP Listening on 8080","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.368Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"Loading IoT Wifi...","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.366Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"Starting Hostapd.","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.374Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"Hostapd CFG: interface=uap0\nssid=mypiwifi\nhw_mode=g\nchannel=6\nmacaddr_acl=0\nauth_algs=1\nignore_broadcast_ssid=0\nwpa=2\nwpa_passphrase=secretpassword\nwpa_key_mgmt=WPA-PSK\nwpa_pairwise=TKIP\nrsn_pairwise=CCMP","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.427Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: random: Trying to read entropy from /dev/random","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.44Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: Configuration file: /dev/stdin","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.441Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: Could not read interface uap0 flags: No such device","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.465Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: nl80211: Driver does not support authentication/association or connect commands","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.466Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: nl80211: deinit ifname=uap0 disabled_11b_rates=0","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.468Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: nl80211: Remove monitor interface: refcount=0","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.469Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: netlink: Operstate: ifindex=0 linkmode=0 (kernel-control), operstate=6 (IF_OPER_UP)","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.47Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: Could not read interface uap0 flags: No such device","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.482Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: nl80211: Set mode ifindex 0 iftype 2 (STATION)","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.484Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: nl80211: Failed to set interface 0 to mode 2: -19 (No such device)","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.485Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: nl80211 driver initialization failed.","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.486Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: hostapd_interface_deinit_free(0x76f9c010)","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.488Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: hostapd_interface_deinit_free: num_bss=1 conf-\u003enum_bss=1","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.489Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: hostapd_interface_deinit(0x76f9c010)","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.49Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: uap0: interface state UNINITIALIZED-\u003eDISABLED","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.491Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: hostapd_bss_deinit: deinit bss uap0","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.492Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: uap0: AP-DISABLED ","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.493Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: hostapd_cleanup(hapd=0x76f9c500 (uap0))","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.494Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"Hostapd DISABLED","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.494Z","v":0}
{"hostname":"raspberrypi","level":30,"msg":"HOSTAPD GOT: hostapd_free_hapd_data: Interface uap0 wasn't started","name":"iotwifi","pid":0,"time":"2018-09-22T22:53:10.495Z","v":0}
...

Then running ifconfig doesn't show uap0.

$ ifconfig                                        
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500                
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255  
        ether 02:42:fd:ca:9a:45  txqueuelen 0  (Ethernet)   
        RX packets 0  bytes 0 (0.0 B)            
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)           
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enxb827eb4e0d5e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.42.0.92  netmask 255.255.255.0  broadcast 10.42.0.255
        inet6 fe80::dfb5:5699:ddf2:30b  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:4e:0d:5e  txqueuelen 1000  (Ethernet)
        RX packets 4105  bytes 258381 (252.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3878  bytes 1613147 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:1b:58:0b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlx00e04c1a7f2d: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:e0:4c:1a:7f:2d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I have two wireless interfaces, if that could be part of the problem.

$ sudo lshw -C network
  *-network:0               
       description: Ethernet interface
       physical id: 2
       logical name: docker0
       serial: 02:42:fd:ca:9a:45
       capabilities: ethernet physical
       configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=172.17.0.1 link=no multicast=yes
  *-network:1
       description: Ethernet interface
       physical id: 3
       logical name: enxb827eb4e0d5e
       serial: b8:27:eb:4e:0d:5e
       size: 100Mbit/s
       capacity: 100Mbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=smsc95xx driverversion=22-Aug-2005 duplex=full firmware=smsc95xx USB 2.0 Ethernet ip=10.42.0.92 link=yes multicast=yes port=MII speed=100Mbit/s
  *-network:2
       description: Wireless interface
       physical id: 4
       bus info: usb@1:1.3
       logical name: wlx00e04c1a7f2d
       serial: 00:e0:4c:1a:7f:2d
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=rtl8192eu multicast=yes wireless=unassociated
  *-network:3
       description: Wireless interface
       physical id: 5
       logical name: wlan0
       serial: b8:27:eb:1b:58:0b
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=brcmfmac driverversion=7.45.98.38 firmware=01-e58d219f multicast=yes wireless=IEEE 802.11
  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  1. See above
  • What is the expected behavior?

See above

  • What is the motivation / use case for changing the behavior?

Making it work?

  • Please tell us about your environment:

    • Device: Raspberry Pi 3
    • OS: raspbian stretch lite (Linux raspberrypi 4.14.70-v7+ #1144 SMP Tue Sep 18 17:34:46 BST 2018 armv7l GNU/Linux )
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

See above

Clients lose connection from AP

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • What is the current behavior?
    After some time, apparently randomly, the clients get disconnected and if they try to connect again to the AP, they receive bad password error. There are no logs regarding HOSTAPD.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Start iotwifi container
  2. Connect with a client
  3. After some time client gets disconnected and cannot join the network again
  • What is the expected behavior?
    Maintain connection

  • Please tell us about your environment:

    • Device: Raspberrypizero W
    • OS: Raspian
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

pkill wpa_supplicant

  • I'm submitting a ...
    • bug report
      Strange behaviour on Raspberry Pi 3 B, I need to call these commands after every reboot:

prevent wpa_supplicant from starting on boot

$ sudo systemctl mask wpa_supplicant.service

kill any running processes named wpa_supplicant

$ sudo pkill wpa_supplicant

Otherwise I couldnโ€™t connect to the Pi. Which is a little uncomfortable, because if I need to call this commands I could also set the WiFi Credentials.

  • feature request
  • support request
  • Do you want to request a feature or report a bug?

  • What is the current behavior?

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  • What is the expected behavior?

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Device:
    • OS:
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Raspberry Pi 3B+ support?

Has anyone tried using this on the RPi 3B+ and experienced issues with intermittent or limited connectivity? Currently debugging some issues with the WiFi support and having difficulty establishing a stable connection on these boards. Thanks!

Clients cannot access internet once connected

Note: for support questions, please use stackoverflow. This repository's issues are reserved for feature requests and bug reports.

  • I'm submitting a ...

    • [* ] bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • Do you want to request a feature or report a bug?
    bug

  • What is the current behavior?

rpi is running as host and client... all devices connected to pi are receiving ip addresses from the pi, however none of them are able to access internet.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  • What is the expected behavior?
    I would like connected devices to be able to access internet..

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • Device: rpi 3
    • OS: raspian stretch
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.