can i extend this number? how about using radio0?
No, it cannot be extended, only if you use another radio, like 2,4 and 5GHz.
3 Likes
So its going to be 16 SSIDs at total?
1 Like
Usually radio0 and radio1 are different physical radios, radio0 being on 5ghz and radio1 being on 2.4 ghz.
So if all your guests have devices that are capable of both bands, you could probably serve up to 16 tables with one AP.
But if anyone has been dining in this restaurant, he/she could afterwards place orders just for fun. So your qr-code alone is really not safe in any way.
Maybe a human waiter is the easier and safer way... or on the ordering web page the credit card info has to be entered with the order. In that model the table number could be added on addition via a 2nd qr code.
2 Likes
You should check the iw list for the other radio too.
1 Like
Wiphy phy1
wiphy index: 1
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short long limit: 2
Coverage class: 0 (up to 0m)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 1:
Capabilities: 0x2fe
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 2-streams
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 2 usec (0x04)
HT TX/RX MCS rate indexes supported: 0-15, 32
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) (no IR)
* 2472 MHz [13] (20.0 dBm) (no IR)
* 2484 MHz [14] (20.0 dBm) (no IR)
valid interface combinations:
* #{ managed, AP, mesh point } <= 8,
total <= 8, #channels <= 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ RRM ]: RRM
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 4
max scan IEs length: 2243 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0x1 RX 0x1
Configured Antennas: TX 0x1 RX 0x1
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x17e
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-7
Frequencies:
* 2412 MHz [1] (0.0 dBm)
* 2417 MHz [2] (0.0 dBm)
* 2422 MHz [3] (0.0 dBm)
* 2427 MHz [4] (0.0 dBm)
* 2432 MHz [5] (0.0 dBm)
* 2437 MHz [6] (0.0 dBm)
* 2442 MHz [7] (0.0 dBm)
* 2447 MHz [8] (0.0 dBm)
* 2452 MHz [9] (0.0 dBm)
* 2457 MHz [10] (0.0 dBm)
* 2462 MHz [11] (0.0 dBm)
* 2467 MHz [12] (0.0 dBm) (no IR)
* 2472 MHz [13] (0.0 dBm) (no IR)
* 2484 MHz [14] (0.0 dBm) (no IR)
Band 2:
Capabilities: 0x17e
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-7
VHT Capabilities (0x31800120):
Max MPDU length: 3895
Supported Channel Width: neither 160 nor 80+80
short GI (80 MHz)
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: not supported
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: not supported
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Frequencies:
* 5180 MHz [36] (15.0 dBm)
* 5200 MHz [40] (15.0 dBm)
* 5220 MHz [44] (14.0 dBm)
* 5240 MHz [48] (14.0 dBm)
* 5260 MHz [52] (14.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (14.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (14.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (12.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (10.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (10.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (10.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (10.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (10.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (10.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (10.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (10.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (10.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (10.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (10.0 dBm) (no IR, radar detection)
* 5720 MHz [144] (10.0 dBm) (no IR, radar detection)
* 5745 MHz [149] (10.0 dBm) (no IR)
* 5765 MHz [153] (10.0 dBm) (no IR)
* 5785 MHz [157] (10.0 dBm) (no IR)
* 5805 MHz [161] (11.0 dBm) (no IR)
* 5825 MHz [165] (12.0 dBm) (no IR)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 8,
total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Your "personal project", "only for fun", could wind up compromising your customers personal data, and opening you up to lawsuits which could eventually shut down your restaurant.
Buy a commercial product that is tested and proven.
2 Likes
Dude it wont happen in my country 
. (there is no payment at all, only ordering ...)
Thanks for your concerns 
DISCLAIMER: I have not tested what I'm about to describe. I just read the commits.
Let me start be agreeing with other comments in that this not sound like a secure approach.
If you have a recent OpenWrt version (it's part of 21.02 if I'm reading it correctly), you can define multiple passwords for the same SSID and then associate it users with different VLANs.
Having different passwords would generate different QR codes.
If I remember this correctly, there is no LuCI support for this.
The commit you are looking is 5aa2ddd0 (hostapd: add support for wifi-station and wifi-vlan sections)
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5aa2ddd0d6b9759c62bbb7bb11b72a7f4269c16b
From the commit message:
With this patch applied it is possible to use multiple PSKs on a single BSS.
1 Like
Then how can i find out which is which? from password/PSK?
BTW:
root@OpenWrt:~# cat /etc/banner
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 21.02.1, r16325-88151b8303
-----------------------------------------------------
Now i'v got it. i can find them with their vlan (IP range)
From your current configuration, my understanding is that you already have VLANs created for each customer / table.
So, instead of creating one SSID for each customer, you only create one with several passwords.
On this new configuration, each password is associated with one VLAN, giving you the separation you want.
EDIT: Replying to your edited comment
Now i'v got it. i can find them with their vlan (IP range)
Exactly
1 Like
I also believe that this is a badly thought out system and is likely to cause lots of issues for both the OP and the customers.
But another way that this will fall apart fast: @masoumi.saeed -- how often will you rotate the passwords (and QR codes) for each of the SSIDs? I hope at least daily, maybe even multiple times per day. Why? Because the second and subsequent times that a customer visits your restaurant (and sits at a different table), their device will automatically login to the SSID that was used previously because most people have their devices set to "remember this network" and auto connect when available. Therefore, they would have to know that they need to login to a different SSID each time and they would have to do it reliably. And if the newer SSID is lower down on the priority connect list, the phone might possibly reconnect to the previous SSID.
Oh, and if you're not offering internet service via wifi, your customers and their phones may not be tolerant of that. Some OS's disconnect when they cannot get internet. Others prompt the user if they want to keep using wifi or to disconnect. Some will connect and still have an internet connection via the cellular network, others will require that the user dis-associates from wifi in order to have internet access again. So yeah, you're going to make it rather inconvenient for your customers.
4 Likes
You can't do this with normal Wifi. It is not possible to have multiple passwords for a single SSID. You can use WPA2 Enterprise and a RADIUS server to achieve stuff like this, or a captive portal with multi-user/multi-password functionality, but regular WPA2/WPA3 wifi can only have a single password per SSID.
Yes! you are absolutely right.
That "remember this network" is a deal breaker.
I will come with a solution for that later. but now this problem must be solved because its eating me alive!
How about
?
I'd recommend coming up with a solution to that first. Otherwise all the effort you put into the rest of this project will be wasted. It's like planning your own wedding without having even met your future spouse.
1 Like
I was under the same impression, but the commit is saying otherwise...
I think it's a hostapd feature, which eventually got supported on OpenWrt.
1 Like
I'd be very skeptical of that working properly. But you could try it.
EDIT: worth mentioning that I haven't seen this type of thing implemented on any other platforms.
1 Like
So i will give it a chance and report back.
Thank you all for your great generosity.
As I read the code in that commit, I think this is not what you are claiming it to be...
I believe that this is an easier way to create multiple SSIDs that map directly to VLANs, each SSID with it's own password.
The key, if I am understanding this correctly, is here:
With this patch applied it is possible to use multiple PSKs on a single BSS.
BSS refers to the MAC address of the radio hardware. It does not claim to make it possible to use multiple PSKs on an ESSID or SSID (which refers to the actual wifi network name). Therefore, unless I have misunderstood this and someone can tell me otherwise, I maintain that you cannot set multiple passwords for a single SSID.
1 Like