RPI3 AP with multiple ssid - has anyone made this?

[petter.oj.norman]

I'm in the middle of a hobby project. Making a standalone EyeFi server on my new RPI3 with latest Raspbian Jessie.
I have succeded to get 4G internet wia a Huawei dongle, and made an Accesspoint of the RPI inbuilt wifi radio. The AP is bridged to the 4G for internet access. And i got the eyefiserver working. Happy so far.

Now I want to set up an extra ssid for a second wlan-interface which I will leave unbridged. Just to give acces for guests browsing images on the Pi but not eating from my mobile broadband quota.

I have read tons of tutorials on how to set up multiple ssid on one radio on the RPI, but none exclusive for the RPI3. I can't get it working. One AP ssid works perfect. But when trying to add another one even the first stops working.
Although the 4G dongle includes a dhcp server itself I also have setup dhcp and dnsmaq in the Pi to make it work truly standalone without activating the bridge.

My setup (from memory)
Defining the interfaces in
/etc/network/interfaces

Defining the AP's and theirs ssid in
hostapd.conf

Defining fixed ip-addresses in
dhcpd.conf

Defining ip-ranges in
dnsmasq.conf

Has anyone out there managed to get multiple ssid on an Accessponit on the RPI3 built in radio?

Best

Petter...

[epoch1970]

There might be some driver issues there. I don't grok much about wireless, but "iw list" says on a Pi 3:

Code: Select all

	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

I'm sure I don't fully understand what this means, but my interpretation is (2nd line): "1 AP + 1 client is OK as long as they use the same channel."
I tried to do this, and performance and reliability were plain horrible. In addition, I'd have to setup the STA interface first and then the AP as a virtual interface like this: "pre-up iw dev wlan0 interface add wap0 type __ap" (note the magic type used)
It works, meaning it doesn't crash on startup, but it borders on unusable so I ditched the idea of having wifi as an unbridged client + an AP on another network.

I haven't tried putting 2 radios on a Pi, I expected hostapd would work fine with 2 physically different interfaces.
I suppose you still have the possiblity to run 2 instances of hostapd, one for each interface...
On my Pis, apt-get remove --purge dhcpdc is the 1st order of the day; I wouldn't know if it has an influence on what you're seeing.

HTH

[petter.oj.norman]

Interesting that you get another answer on "iw list" than I do.

Code: Select all

        valid interface combinations:
                 * #{ IBSS, managed, AP } <= 2, #{ P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
                   total <= 3, #channels <= 2
 

Are we running the same machine?

Reading my Machines iw list would (based on some tutorials) mean that is is capable of running two AP:s, as I have got it.
And when reding the iw list now I also see that it shuld support two simultaneous channels?

Petter ...

[epoch1970]

My machine is a Pi 3 and the wifi card is the embedded one. I run (hopefully) the latest stable kernel.
I really don't know if my interpretation of the iw list report is correct. You'd better double-check on that, but this bit of the always helpful (IMHO) Archlinux documentation does not go against it.

Some boring identification traces and the full iw list command output, for your enjoyment

Code: Select all

root@berck:~# uname -a
Linux berck 4.4.9-v7+ #884 SMP Fri May 6 17:28:59 BST 2016 armv7l GNU/Linux

root@berck:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 8.0 (jessie)
Release:	8.0
Codename:	jessie

root@berck:~# cat /proc/cpuinfo |grep Revision
Revision	: a02082

root@berck:~# lshw -c network -sanitize | head -7
  *-network:0             
       description: Wireless interface
       physical id: 2
       logical name: wap0
       serial: [REMOVED]
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=brcmfmac driverversion=7.45.41.23 firmware=01-cc4eda9c multicast=yes wireless=IEEE 802.11bgn
root@berck:~# modinfo  brcmfmac |head -3
filename:       /lib/modules/4.4.9-v7+/kernel/drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko
license:        Dual BSD/GPL
description:    Broadcom 802.11 wireless LAN fullmac driver.

root@berck:~# iw list
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 roaming.
	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.

EDIT: Ha! I had an output of iw list saved as comment in my hostapd.conf file, which dates back the early days of Pi 3 availability. And I can read this:

Code: Select all

#       valid interface combinations:
#                * #{ IBSS, managed, AP } <= 2, #{ P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
#                  total <= 3, #channels <= 2
#       Device supports scan flush.

and also this:

Code: Select all

#               Frequencies:
#                       * 2412 MHz [1] (20.0 dBm)
...
#                       * 2462 MHz [11] (20.0 dBm)
#       Supported commands:
...

There you see 2 diffs with the current iw list output. I would suggest you apt-get update and reboot, the wifi driver has improved since launch.

[petter.oj.norman]

Still interesting!
I apt-get update and apt-get upgrade rather often, and did it once more right now. But the answer on iw list stays the same. Have you made a separate download of the driver?

Petter ...

[epoch1970]

Nope, I rarely use rpi-update but I think the last apt-get update did pull rpi-update.

[petter.oj.norman]

I ran apt-get dist-upgrade now and after that I get the same reply on iw list as you. So now its time to explore the topic again. Trying all tutos once more.

Petter...

[epoch1970]

If along your way you find a recipe for STA+bridged AP that works well on the stock PI3 card, then I'll be interested in a few hints

[petter.oj.norman]

For that purpose I would try
viewtopic.php?f=36&t=138730.
The post by anthony19114 made march 26 (far down on the page).
I will try it myself this evening.

Petter .

[epoch1970]

Ah yes, I think I was there when I tried doing this.
What definitely put me off was: "use the same password on STA and AP". For me that was a definite "no".

I'll be glad to hear your impressions, thanks

[petter.oj.norman]

I haven't seen anywhere in Anthonys posts that the passwords should be the same. Where's that?
I'm on my way home from work now. Will play with this later tonight.

And, by the way, I've given up the idéa of two AP:s. It just came to me that that would hinder my guests from reaching the internet. And that would make no one happy. I have to find another solution for sharing my pictures. And thats where a more normal wifi repeater comes in place.

Petter...

[petter.oj.norman]

I made some tries tonight - and it was positive!
Had both a wifi-connection to my home wifi-router and published an accesspoint from the RPI3, using the same onboard wifi-chip.
Not the same ssid nor the same password on either of these.
Basically following Anthonys tuto, but with minor changes to fit my previous setup.

Had some troubles with conflicting networks when connected to Ethernet as well.
And haven't wrapped it up yet so I have to start the AP with commands.

When trying to automate the startup I made some misconfiguration and after that the RPI won't start. (Or at least it is wating for some network to load - for ages)

Ending the day by wiping the sd-card and will try this again in a few days. And i'm very hopefull to get it working.

Petter ...

Petter ...

[epoch1970]

Oops. Poor Pi
Encouraging news, I'll look into it myself when I have time. Thanks again!

[petter.oj.norman]

I got it working! (concurrent AP and station mode with the onboard chip). The only flaw is that the AP has to use the same channel as the home router (or whatever) the station is connected to. The onboard chip supports only one channel for this combination.
This makes it a bit troublesom at home where I run multiple accesspoints with same ssid but different channels to cover the whole area.

I used most of Anthonys tuto, but couldn't get the "autostart" working so I put most of his startscript as pre-up and post-up statements in /etc/network/interfaces instead.

Petter...

[epoch1970]

Mhh. I'm not happy with it. I think it's better than last time I tried, but still...
- The "same channel" requirement is awkward. In effect you're generating interference against the main AP. Biting the hand that feeds you...
- For some reason hostapd_cli doesn't work any longer, and I use that to survey the AP activity.
- You cannot create a virtual interface if the base STA interface was renamed in udev (=if you're not using "wlan0"). Maybe it's possible with some serious udev-fu or by changing the MAC address of the AP, I didn't search further.
- Super heavy logging from the kernel (I thought it was oops'ing)

If it helps, here is the script I wrote that looks up the channel on the STA and updates the hostapd.conf file to match, then reload the service. It's in shell... I had it running as a post-up stanza on an interface declaration in /etc/networking/interfaces. It tries not to update the hostapd.conf with anything stupid, but I can't say it's been heavily tested.

Code: Select all

#!/bin/bash
# Prep AP config for STA+AP mode. For Pi 3 integrated wifi interface.
# Call it with 2 args, e.g. checksta.sh wlan0 uap0
DEBUG=1
ME="chksta"
LOGGER="/usr/bin/logger"
LOGGEROPTS="-t $ME -i --"

# The wireless interface in STA mode we examine, the AP interface we create
STA_IFACE="$1"
[ "$STA_IFACE" == "" ] && $LOGGER $LOGGEROPTS "This script takes a wifi STA interface name as argument. Exit" && exit
WAP_IFACE="$2"
[ "$WAP_IFACE" == "" ] && $LOGGER $LOGGEROPTS "This script takes wifi AP interface name as argument. Exit" && exit
# The hostapd config we may need to refresh
HOSTAPD_CONF='/etc/hostapd/hostapd.conf'
[ ! -f "${HOSTAPD_CONF}" ] && $LOGGER $LOGGEROPTS "Can't find hostapd config [${HOSTAPD_CONF}]. Exit" && exit

function get_channel {
    # 2.4GHz band only.
    # http://stackoverflow.com/questions/5485759/android-how-to-determine-a-wifi-channel-number-used-by-wifi-ap-network
    F="$1"
    case "$F" in
	 "2484")
             echo "14"
	     ;;
	 *)
             echo "$(( ( $F - 2407 ) / 5 ))"
	     ;;
	 esac
}

(( $DEBUG )) && $LOGGER $LOGGEROPTS "Start adding AP interface [$WAP_IFACE] to STA interface [$STA_IFACE]"
LINK=$(/sbin/iw "${STA_IFACE}" link)
(( $? )) && $LOGGER $LOGGEROPTS "Error looking up STA interface [$STA_IFACE] config. Exit" && exit
mapfile -t SSID < <(/bin/echo "${LINK}" | /bin/grep -o -P '(?<=SSID: ).*')
mapfile -t FREQ < <(/bin/echo "${LINK}" | /bin/grep -o -P '(?<=freq: ).*')
(( $FREQ )) && CHAN=$(get_channel "$FREQ")
((! $CHAN )) && $LOGGER $LOGGEROPTS "Can't determine channel or frequency for STA interface [$STA_IFACE]: got (chan|freq MHz)[$CHAN|$FREQ]. Exit" && exit
(( $DEBUG )) && $LOGGER $LOGGEROPTS "STA interface [$STA_IFACE] connected to SSID [$SSID]: (chan|freq MHz)[$CHAN|$FREQ]"

/sbin/iw dev "${STA_IFACE}" interface add "${WAP_IFACE}" type __ap
(( $? )) && $LOGGER $LOGGEROPTS "Error adding AP interface [$WAP_IFACE] to STA interface [$STA_IFACE]. Exit" && exit
(( $DEBUG )) && $LOGGER $LOGGEROPTS "Added interface [$WAP_IFACE]"

# Change hostapd config to reflect our channel and AP interface name
(( $DEBUG )) && $LOGGER $LOGGEROPTS "Updating file [$HOSTAPD_CONF]"
/bin/sed -i -e "s/interface=.*/interface=${WAP_IFACE}/" ${HOSTAPD_CONF}
/bin/sed -i -e "s/channel=.*/channel=${CHAN}/" ${HOSTAPD_CONF}
# Finally, reload hostapd config
(( $DEBUG )) && $LOGGER $LOGGEROPTS "All done. Reloading hostapd, exit."
/usr/sbin/service hostapd reload

exit 0

Third time the charm?