Coder Social home page Coder Social logo

txn2 / txwifi Goto Github PK

View Code? Open in Web Editor NEW

This project forked from cjimti/iotwifi

144.0 16.0 60.0 1.24 MB

Raspberry Pi (arm) wifi configuration container. Configure and control wifi connectivity with a JSON based REST api.

Home Page: https://imti.co/iot-wifi/

License: MIT License

Makefile 2.63% Go 92.69% Dockerfile 4.68%

txwifi's Introduction

Update - 20180601: Any future development will happen on this new fork. Hoping add stability as well as new SOCs. If you are interesrted in joining the txn2 team please email [email protected].

Update: Tested and functioning on well on the Raspberry Pi 3 B+ and Raspberry Pi 3 B. Looking to support additional SOCs in upcoming versions. (Disclosure: the Pi links to Amazon are affiliate links, why not?)

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.

txwifi 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/txn2/txwifi.

# 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/txn2/txwifi/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 map a directory containing wpa_supplicant.conf, like so:

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

Where <WPA_SUPPLICANT_CONTAINER_PATH> is the path containing 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.

txwifi's People

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

txwifi's Issues

no address range available for DHCP request via eth0

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    When starting the container, everything seems to work as expected on the RPi side. However, when connecting from my phone to the WiFi AP, I get this message:

nl80211: Ignored event (cmd=20) for foreign interface (ifindex 8 wdev0x0)
dnsmasq-dhcp[22]: no address range available for DHCP request via eth0
  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  1. Follow installation instructions
  • What is the expected behavior?
    To be able to connect

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

  • Please tell us about your environment:

    • Device: PI 3B v1.2
    • OS: Linux pi2 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux

Feature - Set SSID from environment rather than .json

Feature - Would be nice to set SSID from environmental variable so that if one is creating many devices they could have unique SSIDs - currently doing so requires template replace/bash to modify JSON. AND/OR - Pull the permit the device HOST name to be a go template so 'YourDevicePrefix{HOST}' could be used.

This is a great project!

NOISSUE: embedding txwifi

Since i don't need/want docker and want to embed it into another app, i've made some changes.
I don't request a pull because i don't know if you agree, you can take a look here
beres@b68393b or check out the master branch to take a look.

  • what have modified
    Added these two config options
    • DontFallBackToApMode
    • AllowStartStop, permit to enable two method that start or stop the wifi. One the user access the device via ap, it could decide to disable wifi and configure cabled network. The configuration is not part of this project, simply add a third case AP/CL/OFF
  • if WpaPassphrase is empty in configuration file, the ap start without auth support
  • other changes
    • replaced go-bunyan/bunyan with sirupsen/logrus
    • added two example server_gin and server_gorilla

If you are interested we could discuss how and what to merge

Best Regards
ale

cjimti/iotwif:arm32v6-1.0.4 docker image not accessible

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    Attempting to pull the build for armv6 based on the github issue #13, but doesn't seem to have work.

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

  1. Install docker
  2. run docker pull cjimti/iotwif:arm32v6-1.0.4
  • What is the expected behavior?
    Should pull build based on what was said in closed issue linked above

  • What is the motivation / use case for changing the behavior?
    I'm trying to run this on a Raspberry Pi Zero W. I was successful with installing when using the cjimti/iotwif build, however when trying to connect to the broadcasted ssid, it wont connect. I figured this issue may be due to the fact the Raspberry Pi Zero W is ARMv6. This is otherwise not an issue when I run this on any ARMv64 or ARMv7 Raspberry Pi.

  • Please tell us about your environment:

    • Device:
      Raspberry Pi Zero W

    • OS:
      Distributor ID: Raspbian
      Description: Raspbian GNU/Linux 9.8 (stretch)
      Release: 9.8
      Codename: stretch

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
    Screen Shot 2019-08-11 at 8 57 26 PM

Support Open Network?

Is it possible to make the AP opened?

What should be the correct config json in this case? Just leave the wpa_passphrase field blank?

Thanks!

Connecting to multiple Wifi networks

  • I'm submitting a ...

    • bug report
    • feature request
    • support request
  • Do you want to request a feature or report a bug?
    I believe it is a feature

  • What is the current behavior?
    Currently, we are able to connect to only one Wifi access point. I would like to be able to connect to multiple Wifi networks from my Raspberry Pi.

  • What is the motivation / use case for changing the behavior?
    Connecting two or more networks is highly desirable in certain situations.

  • Please tell us about your environment:

    • Device: Raspberry Pi 3 B+
    • OS: Raspbian NOOBS

Cannot connect to AP after some time

  • I'm submitting a ...

    • [ x ] bug report
  • What is the current behavior?
    After ~1h I am not able to connect to the access point (uap0) anymore.

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

  1. Start the docker container as described in the README.
  2. Do stuff for about an hour.
  3. Disconnect mobile phone from access point.
  4. Try to reconnect...
  • What is the expected behavior?
    It should be possible to connect to the access point at any time.
    There should be at least the possibility to detect the error condition and restart the access point.
    Otherwise clients won't be able to connect and have to manually restart the whole device.

  • What is the motivation / use case for changing the behavior?
    I am exploring the stability of this project in order to deploy it on a fleet of IoT devices.

  • Please tell us about your environment:

    • Device: Huawei Honor 9 Smatphone (client) + Raspberry Pi rev. 4 (server)
    • OS: Android + Raspbian Lite (Buster)
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Do you have any idea how I could start to debug this issue and gather additional information? Much appreciated! =)

Possibly related to cjimti#18

BUG - Can't change networks a second time

Bug: Unable to set network a second time.

Steps:

  1. Set a network - works
  2. Try to change/set another - it fails to change, retains initial setting
  3. Can set a second network if docker container is deleted - suspect that something is being persisted there.

Expect to be able to set connection several times:

Creating a docker container from source git

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    When I create a new container from Dockerfile within git repo (master branch), I am getting the following error, please read lines 28-31 below:

1 pi@raspberrypi:~/docker-txwifi $ docker build -t txwifi .
2 Sending build context to Docker daemon   2.56kB
3 Step 1/14 : FROM arm32v6/golang:1.10.1-alpine3.7 AS builder
4 1.10.1-alpine3.7: Pulling from arm32v6/golang
5 95d54dd4bdad: Pull complete 
6 72bf7d76c392: Pull complete 
7 78bbf490f4d6: Pull complete 
8 c07c7b2c41ac: Pull complete 
9 d9815fe4c941: Pull complete 
10 Digest: 11 sha256:d98cc903f00f47488b65984ec9e0fc1c8c8ce2bc123a7e3b661d2c64152d80df
12 Status: Downloaded newer image for arm32v6/golang:1.10.1-alpine3.7
13  ---> 68c10e8072f5
14 Step 2/14 : ENV GOPATH /go
15  ---> Running in ec6df367d210
16 Removing intermediate container ec6df367d210
17  ---> 1420d862500a
18 Step 3/14 : WORKDIR /go/src
19  ---> Running in 6427adb2ab76
20 Removing intermediate container 6427adb2ab76
21  ---> e5109b34512a
22 Step 4/14 : RUN mkdir -p /go/src/github.com/txn2/txwifi
23  ---> Running in 2af4df821a6e
24 Removing intermediate container 2af4df821a6e
25  ---> d9cb4788223d
26 Step 5/14 : COPY . /go/src/github.com/txn2/txwifi
27  ---> 40e58c5cc646
28 Step 6/14 : RUN CGO_ENABLED=0 go build -a -installsuffix cgo -o /go/bin/wifi /go/src/github.com/txn2/txwifi/main.go
29  ---> Running in 5c060d01de77
30 stat /go/src/github.com/txn2/txwifi/main.go: no such file or directory
31 The command '/bin/sh -c CGO_ENABLED=0 go build -a -installsuffix cgo -o /go/bin/wifi /go/src/github.com/txn2/txwifi/main.go' returned a non-zero code: 1
32 pi@raspberrypi:~/docker-txwifi $
  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
pi@raspberrypi:~ $ git clone https://github.com/txn2/txwifi.git /home/pi/docker-txwifi
pi@raspberrypi:~ $ cd docker-txwifi
pi@raspberrypi:~/docker-txwifi $ docker build -t txwifi .
  • What is the expected behavior?
    docker image created

  • What is the motivation / use case for changing the behavior?
    docker image should contain latest commits from the git repo

  • Please tell us about your environment:

    • Device: Raspberry Pi 3 B+
    • OS:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.19.58-v7+ #1245 SMP Fri Jul 12 17:25:51 BST 2019 armv7l GNU/Linux
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
  • Docker
pi@raspberrypi:~ $ docker version
Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:32:16 2019
 OS/Arch:           linux/arm
 Experimental:      false
  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
    scrot

Adding support for networking across Pi Zero usb0 interface

Discovered this project this weekend and am currently running an cjimti/iotwifi image on hypriot v1.11.0b3 on a Raspberry Pi Zero W (Tried to pull txn2/txwifi however it gives not found: manifest unknown).

The Pi Zero W can configure it's usb port to act as an USB-OTG RNDIS ethernet device (usb0), which my Zero W can use to communicate to the internet.

I'm wondering if modifying this image to route uap0 -> usb0 when wlan0 is not connected to a client would be possible (or just uap0 -> usb0 all the time would be ok too)...

Anyway, if there are any config files you can point me to that'd be helpful otherwise I'll just grep around in /etc tomorrow.

Must say your docker image is pretty sweet. :)

Doesn't seem to re-connect to configured wifi access point on restart (of container) or reboot of pi

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    Everything is up and running ok, and am able to get the wifi access point set. A wpa_supplicant.conf is created in /etc/wpa_supplicant/wpa_supplicant.conf. If I stop the container, the wifi connection to the configured AP is terminated, which makes sense. However, should it use the previous configuration upon starting the container again?

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

  1. Follow instructions in the README.MD
  2. curl the api and set a wifi access point.
  3. ping external server to confirm working (ie google.com)
  4. stop the container
  5. restart the container
  6. ping external server, or ifconfig wlan0 and observe no ping is possible and no ip lease exists
  • What is the expected behavior?
    Previously configured wifi access point is used upon starting the container.

  • What is the motivation / use case for changing the behavior?
    Use to provide configuration of wifi access point to IOT device and have that configuration persist across restarts.

  • Please tell us about your environment:

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

Unable to connect to AP after client configured

This is a great utility. But I've noticed that after I connect to the AP the first time and set up the client connection, subsequent attempts to connect to the AP give me a bad password error unless I reboot.

I'm running the container on a Pi Zero Wireless with Raspberry Pi OS Lite.

I've gotten the password error from both an iPhone connecting or a Linux PC connecting, both after having connected previously.

Maybe I'm just doing something wrong?

Network still available after container removal

  • I'm submitting a ...

    • bug report
  • What is the current behavior?
    When container is stopped by the command docker stop <NAME> the AP network (configured within wificfg.json) remains available untill Raspberry reboot.

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

  1. Docker installation
  2. txn2/txwifi downloading by docker pull cjimti/iotwifi command
  3. txn2/txwifi container run by respective command -> uap0 interface for AP is created with iot-wifi-cfg-3 network available for connection.
  4. txn2/txwifi container stop/remove by respective commands
  • What is the expected behavior?
    After the container stop/removal, the network interface should be stopped.

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

  • Please tell us about your environment:

    • Device: Rasp 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)

No wifi when container is down

  • I'm submitting a ...

    • [ *] bug report
  • What is the current behavior?

When container exits wifi configuration is no more

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

1.follow the configuration steps
2.set up wifi
3.stop container

  • What is the expected behavior?

I was expecting that container is not needed after initial configuration

  • Please tell us about your environment:

    • Device: raspi 3 b+
    • OS: raspbian

Adding wifi forwarding to eth0

Hi @cjimti - thanks for open sourcing this project. It worked straight out of the box on an RPi4. For my use case I also need to forward the wlan0 connection to a peripheral device connected on an ethernet port. I seem to be able to achieve that by following these simple steps: https://www.raspberrypi.org/forums/viewtopic.php?t=223295

But unfortunately I can't get the port forwarding to work while I'm also running the docker container with the wpa_supplicant file masked. I'm curious how I might be able to forward the wifi connection to the ethernet port if there is a wifi connection status?

Thanks!

How can I disconnect the Wifi?

After I see the code, I see there is only support for scan, status, connect, and kill. So how can i disconnect the wifi or I need to modify the code myself?

Rewrite Conversation.

I am planning something a re-write of txwifi and would like to make sure that I maintain a reasonably amount of backwards compatibility.

I plan to keep/maintain

  • /status
  • /scan
  • /connect

I plan to drop (thought I am open to making it available via environment variable flag.)

  • /kill

I plan to add

  • a static file handler to server index.html and such.

also considering

  • /add -- add config but don't connect to network
  • /delete -- delete network config
  • /list -- list configured networks

Specific to behaviour I plan to attempt to bring wlan0 up. If wlan0 can connect uap0 will be left offline. When wlan0 cannot connect or losses it connection (for a period of time) uap0 will be brought online. If wlan0 is taken/goes back offline uap0 will come back online.

Via the static file handler I plan to implement a web/ui that will allow the user to select from a list of available wifi networks and supply a PSK...

If you have any thoughts, or insights comments are welcome.

Question: Facing issue in running txwifi when cloned from git repo

  • I'm submitting a ...

    • Question
  • What is the current behavior?
    When running the tx wifi container I get following error =>

{"hostname":"51910a099cf4","level":30,"msg":"Starting IoT Wifi...","name":"txwifi","pid":0,"time":"2019-07-25T07:37:46.214Z","v":0}
panic: open cfg/wificfg.json: no such file or directory

goroutine 1 [running]:
github.com/txn2/txwifi/iotwifi.loadCfg(0x2a5481, 0x10, 0x0, 0x0, 0x0)
	/go/src/github.com/txn2/txwifi/iotwifi/iotwifi.go:76 +0x264
github.com/txn2/txwifi/iotwifi.NewWpaCfg(0x2a27ef, 0x6, 0x2a2442, 0x5, 0x2dd3a0, 0x10a0c0f8, 0x0, 0x0, 0x0, 0x0, ...)
	/go/src/github.com/txn2/txwifi/iotwifi/wpacfg.go:46 +0x24
main.main()
	/go/src/github.com/txn2/txwifi/main.go:55 +0x2d4
  • Steps to Reproduce the problem
  1. git clone -b develop https://github.com/txn2/txwifi.git
  2. cd txwifi
  3. wget https://raw.githubusercontent.com/txn2/txwifi/master/cfg/wificfg.json
  4. nano wificfg.json # Edited the wificfg.json
  5. mv wificfg.json cfg/
  6. docker build -t wifi-connect .
  7. docker run wifi-connect --rm --privileged --net host -v $(pwd)/cfg/wificfg.json:/go/src/github.com/txn2/txwifi/cfg/wificfg.json
  • What is the expected behavior?

When I pulled the txwifi image from the docker hub then it was working properly. But when I ran this manually using the above steps I am getting the error panic: open cfg/wificfg.json: no such file or directory.

  • Please tell us about your environment:

    • Device: Raspberry pi 3 b+
    • OS: Raspbian Stretch

uap0 IP address not assigned correct

  • I'm submitting a ...
    • support request

Hi
I am trying to make raspberry pi 3 Access point and I have done all the steps given .
But I am unable to connect to access point.
it always says failed to obtain IP address on mobile or laptop.
In terminal it assigns correct IP to uap0 but on desktop wifi connect section it does not assign IP and no device can connect to Access point.
Please help me .. its urgent

wlan0 persisting network

This worked out of the box for me for RPI4, I'm hoping to get guidance on 2 problems I'm facing;

  1. Once connected to a network I can't seem to undo it, is it possible to "forget network" with the API (I was hoping that this would solve problem num.2)?
  2. When I attempt to connect to a different network, it doesn't seem to want to let go of the old one. Sometimes I even see the wlan0 ipv4 address jumping back and forth between the 2 networks although it seems to persist with the network that it was already connected to.

Thanks in advance!

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.