Failed to start on Raspberry Pi 3

[rosenk]

I'm trying to use this to start access point into rpi3 but it fails with:

| \ ___ | |___ _ _ /\ | _ \
| |) / _ / | / / -) '| / _ | /
|/**/**|__|| // __|

[INFO] Architecture: armv7l
[INFO] Number of physical wireless interfaces connected: 1
[INFO] Docker image fgg89/armhf-docker-ap found
[INFO] Unblocking wifi and setting wlan0 up
[INFO] Found WLAN config file
[+] Generating hostapd.conf
[+] Generating dnsmasq.conf
[+] Starting the docker container with name ap-container
command failed: Operation not supported (-95)
[+] Configuring wlan0 with IP address 192.168.7.1
Device "wlan0" does not exist.
Cannot find device "wlan0"
Cannot find device "wlan0"
[+] Adding natting rule to iptables (container)
[+] Enabling IP forwarding (container)
[+] Starting hostapd and dnsmasq in the docker container ap-container

I have tried to debug it within my limited knowledge on this subject and apparently:
iw phy "$PHY" set netns "$pid"
fails with
command failed: Operation not supported (-95)

I have no idea what exactly this means. Is it not supported by the hardware?
$iw list output:

Wiphy phy0
    max # scan SSIDs: 10
    max scan IEs length: 2048 bytes
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports T-DLS.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP (00-0f-ac:4)
        * CMAC (00-0f-ac:6)
    Available Antennas: TX 0 RX 0
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * P2P-client
         * P2P-GO
         * P2P-device
    Band 1:
        Capabilities: 0x1020
            HT20
            Static SM Power Save
            RX HT20 SGI
            No RX STBC
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT TX/RX MCS rate indexes supported: 0-7
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps (short preamble supported)
            * 5.5 Mbps (short preamble supported)
            * 11.0 Mbps (short preamble supported)
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (20.0 dBm)
            * 2417 MHz [2] (20.0 dBm)
            * 2422 MHz [3] (20.0 dBm)
            * 2427 MHz [4] (20.0 dBm)
            * 2432 MHz [5] (20.0 dBm)
            * 2437 MHz [6] (20.0 dBm)
            * 2442 MHz [7] (20.0 dBm)
            * 2447 MHz [8] (20.0 dBm)
            * 2452 MHz [9] (20.0 dBm)
            * 2457 MHz [10] (20.0 dBm)
            * 2462 MHz [11] (20.0 dBm)
            * 2467 MHz [12] (20.0 dBm)
            * 2472 MHz [13] (20.0 dBm)
            * 2484 MHz [14] (disabled)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * join_ibss
         * set_pmksa
         * del_pmksa
         * flush_pmksa
         * remain_on_channel
         * frame
         * set_channel
         * tdls_oper
         * start_sched_scan
         * start_p2p_device
         * crit_protocol_start
         * crit_protocol_stop
         * connect
         * disconnect
    Supported TX frame types:
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * managed: 0x40 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
    valid interface combinations:
         * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
           total <= 3, #channels <= 2
         * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
           total <= 4, #channels <= 1
    Device supports scan flush.

Please help.

[fgg89]

Hi @rosenk, unfortunately I don't have a Raspberry Pi 3 for testing. Was the docker container started successfully? otherwise the iw command will fail.

[rosenk]

Yes the container even remains started after the fail. There is indeed a dir where

pi@raspberrypi:/var/run/netns $ ll
total 0
lrwxrwxrwx 1 root root 17 окт 12 15:23 9624 -> /proc/9624/ns/net

so everything prior iw is correct, but then when I manually try:

pi@raspberrypi:/var/run/netns $ sudo iw phy phy0 set netns 9624
command failed: Operation not supported (-95)

The same error occurs. Please help, It would be great to switch my raspberry to AP and back with docker

[fgg89]

It seems that there is a problem when exporting the wifi interface of the Raspberry Pi 3 to a container, as pointed in the following link:

https://www.raspberrypi.org/forums/viewtopic.php?f=56&t=153212&p=1003680

I'm afraid I cannot help further here. I would give it a try with a USB wifi card to make sure the hardware (or possibly "iw"?) is the problem here.

[N2ITN]

@fgg89 Any thoughts on this?
https://stackoverflow.com/questions/30019734/docker-get-access-to-wifi-interface

[rosenk]

My current take on this is to use create_ap. Probably it will work in docker --privileged too

[N2ITN]

I'm running now after replacing -net=bridge with -net=host in line 178 of docker_ap as per the SO link I posted, will let you know how it goes.

If it doesn't work I'll try create AP!

[rosenk]

Thanks, and good luck

[N2ITN]

It worked.

[N2ITN]

I will upload to Dockerhub and specify it's for RPi3.

Quick question - do you know of a way to bridge to local wifi network instead of just ethernet?

[fgg89]

Hi,

Thank you for the feedback! Running a container with -net=host will open up a security breach since the container networking will not be containerized.

Regarding the question of bridging a local wifi network, can you provide more details about this setup? remember that a wireless interface in managed mode cannot be bridged.

[N2ITN]

Good to know about security. Is password protection on the hotspot able to mitigate this?

About bridging, I made a locally hosted page with for users to enter wifi credentials to transfer the Pi to the user's network. Right now the docker-ap hotspot and the local web page + data entry work, as well as the script to connect to a new network (using the python wifi module). However, the two don't work together, even if I first stop the docker container before interfacing with wln0 with the wifi module.

[fgg89]

Exposing the host networking to the docker container is unrelated to wireless encryption. You will find more info in the Docker documentation but basically the thing is that by using net=host you are able to access all the host network interfaces from the container and that goes against the idea of container isolation.

If I understand correctly, you want to be able to be connected to a wireless network and at the same time run docker_ap to create a hotspot using the same wireless interface? If that's the setup, it cannot work as the interface will only work as a client or as an access point, in that case you would either need an Ethernet connection or a second wireless interface.

[rosenk]

As far as I know the rpi3 can't be simultaneously wifi access point and wifi client. That is a hardware limitation that can't be circumvented with docker tricks

[N2ITN]

I should have been clearer, I'm trying to set up an access point to get wireless credentials, store them, turn off the AP, then log on to wlan0 with provided credentials.

EDIT - This works:
Add bash script that starts AP + local web server to /etc/rc.local so it runs on boot --> enter credentials fro web interface, store to txt --> restart wlan with:

os.system('sudo ifconfig wlan0 down')
os.system('sudo ifconfig wlan0 up')

--> call wifi_login.py --> change startup script to call wifi_login.py instead of AP/web server

Not the most graceful solution but it works!

Will post to my account if anyone is interested.

[fgg89]

I am not aware of any wireless interface that works in client and AP mode simultaneously, this is simply not possible. If you want to see your wireless interface capabilities and possible mode combinations you can run iw list.

Thank you for your feedback @N2ITN, I'm glad you found the project useful.