Enable support for stronger SHA256-based algorithms in hostapd and
wpa_supplicant when using WPA-EAP or WPA-PSK with 802.11w enabled.
We cannot unconditionally enable it, as it requires hostapd to be
compiled with 802.11w support, which is disabled in the -mini variants.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Tested-by: Sebastian Kemper <sebastian_ml@gmx.net>
Now that wpa_key_mgmt handling for hostapd and wpa_supplicant are
consistent, we can move parts of it to a dedicated function.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Tested-by: Sebastian Kemper <sebastian_ml@gmx.net>
Rework wpa_key_mgmt handling for wpa_supplicant to be consistent with
how it is done for hostapd.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Tested-by: Sebastian Kemper <sebastian_ml@gmx.net>
RADIUS accounting can be used even when RADIUS authentication is not
used. Move the accounting configuration outside of the EAP-exclusive
sections.
Signed-off-by: Petko Bordjukov <bordjukov@gmail.com>
The wpa_supplicant supports an "anonymous_identity" field, which some
EAP networks require. From the documentation:
anonymous_identity: Anonymous identity string for EAP (to be used as the
unencrypted identity with EAP types that support different tunnelled
identity, e.g., EAP-TTLS).
This change modifies the hostapd.sh script to propagate this field
from the UCI config to the wpa_supplicant.conf file.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Reviewed-by: Manuel Munz <freifunk@somakoma.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 49181
Introduce config options client_cert2, priv_key2 and priv_key2_pwd
used for EAP-TLS phase2 authentication in WPA-EAP client mode.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 48345
WPA-EAP supports several phase2 (=inner) authentication methods when
using EAP-TTLS, EAP-PEAP or EAP-FAST (the latter is added as a first
step towards the UCI model supporting EAP-FAST by this commit)
The value of the auth config variable was previously expected to be
directly parseable as the content of the 'phase2' option of
wpa_supplicant.
This exposed wpa_supplicant's internals, leaving it to view-level to
set the value properly. Unfortunately, this is currently not the case,
as LuCI currently allows values like 'PAP', 'CHAP', 'MSCHAPV2'.
Users thus probably diverged and set auth to values like
'auth=MSCHAPV2' as a work-around.
This behaviour isn't explicitely documented anywhere and is not quite
intuitive...
The phase2-string is now generated according to $eap_type and $auth,
following the scheme also found in hostap's test-cases:
http://w1.fi/cgit/hostap/tree/tests/hwsim/test_ap_eap.py
The old behaviour is also still supported for the sake of not breaking
existing, working configurations.
Examples:
eap_type auth
'ttls' 'EAP-MSCHAPV2' -> phase2="autheap=MSCHAPV2"
'ttls' 'MSCHAPV2' -> phase2="auth=MSCHAPV2"
'peap' 'EAP-GTC' -> phase2="auth=GTC"
Deprecated syntax supported for compatibility:
'ttls' 'autheap=MSCHAPV2' -> phase2="autheap=MSCHAPV2"
I will suggest a patch to LuCI adding EAP-MSCHAPV2, EAP-GTC, ... to
the list of Authentication methods available.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 48309
In sta-only configuration, wpa_supplicant needs correct regulatory
domain because otherwise it may skip channel of its AP during scan.
Another alternative is to fix "iw reg set" in mac80211 netifd script.
Currently it fails if some phy has private regulatory domain which
matches configured one.
Signed-off-by: Dmitry Ivanov <dima@ubnt.com>
SVN-Revision: 48099
The scripts for authsae and iw use the option mesh_id to get set the
"meshid" during a mesh join. But the script for wpad-mesh ignores the
option mesh_id and instead uses the option ssid. Unify the mesh
configuration and let the wpa_supplicant script also use the mesh_id from
the configuration.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 47615
r46861 introduced a new option eapol_version to hostapd, but did not
provide a default value. When the option value is evaluated,
the non-existing value causes errors to the systen log:
"netifd: radio0: sh: out of range"
Add a no-op default value 0 for eapol_version. Only values 1 or 2 are
actually passed on, so 0 will not change the default action in hostapd.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 47361
Add eapol_version to the openwrt wireless config ssid section.
Only eapol_version=1 and 2 will get passed to hostapd, the default
in hostapd is 2.
This is only useful for really old client devices that don't
accept eapol_version=2.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
SVN-Revision: 46861
Other VLAN related options are already being processed in netifd.sh
but the vlan_file option is missing. This option allows the mapping
of vlan IDs to network interfaces and will be used in dynamic VLAN
feature for binding stations to interfaces based on VLAN
assignments. The change is done similarly to the wpa_psk_file
option.
Signed-off-by: Gong Cheng <chengg11@yahoo.com>
SVN-Revision: 46652
Add 802.11r client support to wpa_supplicant. It's only enabled in
wpa_supplicant-full. hostapd gained 802.11r support in commit r45051.
Tested on a TP-Link TL-WR710N sta psk client with two 802.11r enabled
openwrt accesspoints (TP-Link TL-WDR3600).
Signed-off-by: Stefan Hellermann <stefan@the2masters.de>
SVN-Revision: 46377
Hostapd's control file location was changed in 2013, and that has apparently
broken the wps button hotplug script in cases where there are multiple radios
and wps is possibly configured also for the second radio. The current wps
button hotplug script always handles only the first radio.
https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wps-hotplug.sh
The reason is that the button hotplug script seeks directories like
/var/run/hostapd*, as the hostapd-phy0.conf files were earlier in
per-interface subdirectories.
Currently the *.conf files are directly in /var/run and the control sockets
are in /var/run/hostapd, but there is no subdirectory for each radio.
root@OpenWrt:/# ls /var/run/hostapd*
/var/run/hostapd-phy0.conf /var/run/hostapd-phy1.conf
/var/run/hostapd:
wlan0 wlan1
The hotplug script was attempted to be fixed after the hostapd change by
r38986 in Dec2013, but that change only unbroke the script for the first
radio, but left it broken for multiple radios.
https://dev.openwrt.org/changeset/38986/
The script fails to find subdirectories with [ -d "$dir" ], and passes just
the only found directory /var/run/hostapd, leading into activating only the
first radio, as hostapd_cli defaults to first socket found inthe passed
directory:
root@OpenWrt:/# hostapd_cli -?
...
usage: hostapd_cli [-p<path>] [-i<ifname>] [-hvB] [-a<path>] \
[-G<ping interval>] [command..]
...
-p<path> path to find control sockets (default: /var/run/hostapd)
...
-i<ifname> Interface to listen on (default: first interface found in the
socket path)
Below is a run with the default script and with my proposed solution.
Default script (with logging added):
==================================
root@OpenWrt:/# cat /etc/rc.button/wps
#!/bin/sh
if [ "$ACTION" = "pressed" -a "$BUTTON" = "wps" ]; then
for dir in /var/run/hostapd*; do
[ -d "$dir" ] || continue
logger "WPS activated for: $dir"
hostapd_cli -p "$dir" wps_pbc
done
fi
>>>> WPS BUTTON PRESSED <<<<<
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan0 wps_get_status
PBC Status: Active
Last WPS result: None
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan1 wps_get_status
PBC Status: Timed-out
Last WPS result: None
root@OpenWrt:/# logread | grep WPS
Tue Apr 14 18:38:50 2015 user.notice root: WPS activated for: /var/run/hostapd
wlan0 got WPS activated, while wlan1 remained inactive.
I have modified the script to search for sockets instead of directories and
to use the "-i" option with hostapd_cli, and now the script properly
activates wps for both radios. As "-i" needs the interface name instead of
the full path, the script first changes dir to /var/run/hostapd to get simply
the interface names.
Modified script (with logging):
===============================
root@OpenWrt:/# cat /etc/rc.button/wps
#!/bin/sh
if [ "$ACTION" = "pressed" -a "$BUTTON" = "wps" ]; then
cd /var/run/hostapd
for dir in *; do
[ -S "$socket" ] || continue
logger "WPS activated for: $socket"
hostapd_cli -i "$socket" wps_pbc
done
fi
>>>> WPS BUTTON PRESSED <<<<<
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan0 wps_get_status
PBC Status: Active
Last WPS result: None
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan1 wps_get_status
PBC Status: Active
Last WPS result: None
root@OpenWrt:/# logread | grep WPS
Tue Apr 14 18:53:06 2015 user.notice root: WPS activated for: wlan0
Tue Apr 14 18:53:06 2015 user.notice root: WPS activated for: wlan1
Both radios got their WPS activated properly.
I am not sure if my solution is optimal, but it seems to work. WPS button is
maybe not that often used functionality, but it might be fixed in any case.
Routers with multiple radios are common now, so the bug is maybe more
prominent than earlier.
The modified script has been in a slightly different format in my community
build since r42420 in September 2014.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45492
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r45051 (ieee80211r in
hostapd) and r45326 (start_disabled in mac80211). My patches fix two
instances of "bad number", but there may be a third one, as the original
report in bug 19345 pre-dates r45326 and already has two "bad number" errors
for radio0.
https://dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45380
To enable 802.11r, wpa_key_mgmt should contain FT-EAP or FT-PSK. Allow
multiple key management algorithms to make this possible.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
SVN-Revision: 45050
The 802.11r implementation in hostapd uses nas_identifier as PMK-R0 Key
Holder identifier. As 802.11r can also be used with WPA Personal, nasid
should be appended to the hostapd config for all WPA types.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
SVN-Revision: 45049
These new variants include support for mesh mode and SAE crypto.
They always depend on openssl as EC operations are not provided by
the internal crypto implementation.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 45047
madwifi was dropped upstream, can't find it anywhere in OpenWrt
either, thus finally burrying madwifi.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45045
This change adds the configuration options "bssid_whitelist" and
"bssid_blacklist" used to limit the AP selection of a network to a
specified (finite) set or discard certain APs.
This can be useful for environments where multiple networks operate
using the same SSID and roaming between those is not desired. It is also
useful to ignore a faulty or otherwise unwanted AP.
In many applications it is useful not just to enumerate a group of well
known access points, but to use a address/mask notation to match an
entire set of addresses (ca:ff:ee:00:00:00/ff:ff:ff:00:00:00).
This is especially useful if an OpenWrt device with two radios is used to
retransmit the same network (one in AP mode for other clients, one as STA for
the uplink); the following configuration prevents the device from associating
with itself, given that the own AP to be avoided is using the bssid
'C0:FF:EE:D0:0D:42':
config wifi-iface
option device 'radio2'
option network 'uplink'
option mode 'sta'
option ssid 'MyNetwork'
option encryption 'none'
list bssid_blacklist 'C0:FF:EE:D0:0D:42/00:FF:FF:FF:FF:FF'
This change consists of the following cherry-picked upstream commits:
b3d6a0a8259002448a29f14855d58fe0a624ab76
b83e455451a875ba233b3b8ac29aff8b62f064f2
79cd993a623e101952b81fa6a29c674cd858504f
(squashed to implement bssid_{white,black}lists)
0047306bc9ab7d46e8cc22ff9a3e876c47626473
(Add os_snprintf_error() helper)
Signed-off-by: Stefan Tomanek <stefan.tomanek+openwrt@wertarbyte.de>
SVN-Revision: 44438
The uapsd option sets the uapsd_advertisement_enabled flag in hostapd.
The check for phy support is already implemented here in hostapd since 2011:
http://w1.fi/cgit/hostap/commit/?id=70619a5d8a3d32faa43d66bcb1b670cacf0c243e
So this can be safely set to 1 as default.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
SVN-Revision: 43846
In r41872 and r42787 Dynamic VLAN support was reintroduced, but the vlan_bridge
parameter is not read while setting up the config, so the default is used which
is undesirable for some uses.
Signed-off-by: Ben Franske <ben.mm@franske.com>
SVN-Revision: 43473
The wpa_psk_file option offers the possibility to use a different WPA-PSK key for each client. The directive points to a file with the following syntax:
mac_address wpa_passphrase_or_hex_key
Example:
00:11:22:33:44:55 passphrase_for_client_1
00:11:22:33:44:67 passphrase_for_client_2
00:11:22:33:44:89 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
So it is possible to specify both ASCII passphrases and raw 64-chars hex keys.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
SVN-Revision: 43001
[base-files] shell-scripting: fix wrong usage of '==' operator
normally the '==' is used for invoking a regex parser and is a bashism.
all of the fixes just want to compare a string. the used busybox-ash
will silently "ignore" this mistake, but make it portable/clean at least.
this patch does not change the behavior/logic of the scripts.
Signed-off-by: Bastian Bittorf <bittorf@bluebottle.com>
SVN-Revision: 42911
In r41872 Dynamic VLAN support was reintroduced, but the vlan_naming
parameter is not read while setting up the config, so it always
defaults to 1.
Signed-off-by: Reiner Herrmann <reiner@reiner-h.de>
SVN-Revision: 42787
This patch brings full dynamic vlan support to netifd that existed in hostapd.sh in Attitude Adjustment.
Signed-off-by: Joseph CG Walker <Joe@ChubbyPenguin.net>
[jow@openwrt.org: changed commit message, rebased on top of current hostapd.sh]
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 41872
rsn_preauth is used outside of "case $auth_type", so if it is set
for an EAP-enabled SSID, it would also be set for the following
non-EAP-enabled SSIDs, because it would not be read again.
Signed-off-by: Reiner Herrmann <reiner@reiner-h.de>
SVN-Revision: 41012
`own_ip_addr` is used by hostapd as NAS-IP-Address.
This is used to identify the AP that is requesting the authentication of the
user and could be used to define which AP's can authenticate users.
Some vendors implement only NAS-Identifier or NAS-IP-Address and not both.
This patch adds ownip as an optional parameter in /etc/config/wireless.
Signed-off-by: Thomas Wouters <thomaswouters@gmail.com>
SVN-Revision: 40934
This patch implements support for 802.11s protected mesh wireless networks (using authsae) in the netifd framework.
Until meshd-nl80211 implements a proper -P option for the PID file, this uses shell backgrounding in order to be able to get the PID for the process.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
SVN-Revision: 40497
r39995 introduced a new parameter wps_pbc_in_m1 to wifi wps config, but
apparently did not provide a default value 0.
When that option's non-existing value is later evaluated in
/lib/netifd/hostapd.sh, it causes the "bad number" error to be logged in
syslog if user has not set the wps_pbc_in_m1 option. The error materialises
only if user has enabled wps.
Sat Apr 12 13:25:01 2014 daemon.notice netifd: radio1 (1254): sh: bad number
Sat Apr 12 13:25:01 2014 daemon.notice netifd: radio0 (1253): sh: bad number
Discussion in bug 15508: https://dev.openwrt.org/ticket/15508#comment:3
Error is caused by line 282:
https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/netifd.sh#L282
My patch sets the parameter's default value to 0, which does nothing. The
default might also be set a bit later in the function, but this felt like the
most clear place to do that.
Signed-off-by hnyman <hannu.nyman@iki.fi>
SVN-Revision: 40469
Option pbc_in_m1 is being used as a WPS capability discovery
workaround for PBC with Windows 7.
Add possibility to enable this workaround from UCI.
To enable it, turn on wps and set wps_pbc_in_m1 parameter to 1.
Signed-off-by: Pawel Kulakowski <pawel.kulakowski@tieto.com>
SVN-Revision: 39995
This patch introduces 802.11ac support to mac80211 and hostapd. The split of
VHT160 in two 80 MHz bands is not yet supported, since it requires an
additional user supplied parameter for the channel of the second band.
Signed-off-by: Matti Laakso <malaakso@elisanet.fi>
Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
[sven@open-mesh.com: Rebased patch, merged htmode and vhtmode,
removed special hwmode, replaced uci vht_capab list with overwritable
autoconfig, fixed hostapd integration, fixed commit description, add HT40+/-
for VHT modes, add VHT40 center_freq autoconfig, refactored major parts]
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 39456
Introduced by ("netifd: add wireless configuration support and port mac80211 to
the new framework")
Reported-by: René van Weert <r.vanweert@sowifi.com>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
SVN-Revision: 39288
Introduced by ("netifd: add wireless configuration support and port mac80211 to
the new framework")
Reported-by: René van Weert <rene@sowifi.com>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
SVN-Revision: 39231
Currently, in order to configure the authentication daemon in
8021x mode, we need to set wireless.@wifi-iface[0].encryption="wpa"
Though it works it confuses folks as 8021x is using WEP
encryption and not WPA. Therefore the terminology itself is
confusing. This change adds 8021x as a recognized string for 8021x
authentication.
Signed-off-by: Mathieu Olivari <mathieu@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
SVN-Revision: 38339
Setting wireless.@wifi-iface[N].ext_registrar=1 will enable UPNP
advertising and add an external registrar to the interface this vif
belongs to (br-lan if the vif is included in the LAN bridge). By
enabling this we append upnp_iface=xxx to the hostapd config file.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Mathieu Olivari <mathieu@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
SVN-Revision: 38338
Enable CONFIG_WPS2 for hostapd. This is required to support
options like Virtual Push Button in WPS.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
SVN-Revision: 38337
In 2009 OpenWrt's hostapd config added an "auth_cache" boolean
to be used to address a reported issue #12129 [0] on a forum [1].
The reported issue on the ticket is different that the one
described on the forum. The commit was r33359. This change broke
proper RSN preauthentication [2] [3] [4] expectations on hostapd's
configuration for WPA2 and this in turn disabled PMKSA caching and
Opportunistic Key Caching. This change:
* Leaves the "auth_cache" to be used only for WPA networks for those
looking to use this as a workaround to a reported issue but annotates
a warning over its usage.
* Separate "auth_cache" from WPA2 RSN preauthentication, leaving
WPA2 RSN preauthentication to enabled only with "rsn_preauth" with
the expected and recommended settings.
* Adds a new WPA2 RSN preauthentication "rsn_preauth_testing" to
be used when evaluating funcionality for WPA2 RSN preauthentication
with the expected and recommended settings with the only difference
so far with what should be enabled by default to disable Opportunistic
Key Caching.
Disabling the PMKSA cache should mean the STA could not roam off and back
onto the AP that had PMKSA caching disabled and would require a full
authentication cycle. This fixes this for WPA2 networks with
RSN preauthentication enabled.
This change should be applied to AA as well as trunk.
TL DR;
The issue described on the forum has to do with failure of a STA
being able to try to authenticate again with the AP if it failed
its first try. This may have been an issue with hostapd in 2009
but as per some tests I cannot reproduce this today on a WPA2
network.
The issue described on the ticket alludes to a security issue with the
design of using a Radius server to authenticate to an AP. The issue
vaguely alludes to the circumstances of zapping a user, deleting their
authentication credentials to log in to the network, and that if
RSN preauthentication is enabled with PMKSA caching that the user
that was zapped would still be able to authenticate.
Lets treat these as separate issues.
I cannot reproduce the first issue reported on the forums of not
being able to authenticate anymore on a WPA2 network.
The issue reported on the ticket modified WPA2 RSN preauthentication
by adding two fields to the hostapd configuration if auth_cache
was enabled:
* disable_pmksa_caching=1
* okc=0
The first one disables PMKSA authentication cache.
The second one disables Opportunistic Key Caching.
The issue reported on the ticket was fixed by implementing a workaround
in hostapd's configuration. Disabling PMKSA caching breaks proper use
of WPA2 RSN pre authentication. The usage of disable_pmksa_caching=1
prevents hostapd from adding PMKSA entries into its cache when a successful
802.1x authentication occurs. In practice RSN preauthentication would
trigger a STA to perform authentication with other APs on the same SSID,
it would then have its own supplicant PMKSA cache held. If a STA roams
between one AP to another no new authenitcation would need to be performed
as the new AP would already have authenticated the STA. The purpose of the
PMKSA cache on the AP side would be for the AP to use the same PMKID for
a STA when the STA roams off onto another BSSID and later comes back to it.
Disabling Opportunistic Key Caching could help the reported issue
as well but its not the correct place to address this. Opportunistic
Key Caching enables an AP with different interfaces to share the
PMKSA cache. Its a technical enhancement and disabling it would
be useful to let a testing suite properly test for RSN preauthentication
given that otherwise Opportunistic Key Caching would enable an
interface being tested to derive its own derive the PMKSA entry.
In production though okc=1 should be enabled to help with RSN
preauthentication.
The real fix for this particular issue outside of the scope of hostapd's
configuration and it should not be dealt with as a workaround to
its configuration and breaking expected RSN preauthentication and
technical optimizations. Revert this change and enable users to pick
and choose to enable or disable disable_pmksa_caching and okc expecting them
to instead have read clearly more what these do.
As for the core issure ported, the correct place to fix this is to
enable a sort of messaging between the RADIUS server and its peers
so that if caching for authentication is enabled that cache can be
cleared upon user credential updates. Updating a user password
(not just zapping a user) is another possible issue that would need
to be resolved here. Another part of the solution might be to reduce
the cache timing to account for any systematic limitations (RADIUS
server not able to ask peers to clear cache might be
one).
[0] https://dev.openwrt.org/changeset/33359
[1] https://forum.openwrt.org/viewtopic.php?id=19596
[2] http://wireless.kernel.org/en/users/Documentation/hostapd#IEEE_802.11i.2FRSN.2FWPA2_pre-authentication
[3] http://wireless.kernel.org/en/users/Documentation/wpa_supplicant#RSN_preauthentication
[4] http://wiki.openwrt.org/doc/recipes/rsn_preauthentication
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
SVN-Revision: 38336
This adds the eap_reauth_period to be used for modifying
the RADIUS server reauthentication authentication period,
a parameter that gets passed directly to the hostapd
configuration file.
Signed-off-by: Mathieu Olivari <mathieu@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
SVN-Revision: 38334
hostapd supports "Dynamic Authorization Extensions", making it possible
to forcibly disconnect a user by sending it a RADIUS "Disconnect-Request"
packet.
I've added three new variables to enable setting of the
"radius_das_client" and "radius_das_port" variables in the hostapd
configuration, which enable these extensions.
* dae_client - IP of the client that can send disconnect requests
* dae_secret - shared secret for DAE packets
These are combined into the "radius_das_client" option in hostapd.conf
To enable the server, both dae_client and dae_secret must be set.
* dae_port - optional, default value is 3799 as specified in RFC 5176
Signed-off-by: Martijn van de Streek <martijn@vandestreek.net>
SVN-Revision: 37734
Make hostapd.sh correctly handle the macfile uci option.
Such option specifies the macfile name to pass into the
hostapd configuration file. Moreover, if a maclist option
has been specified, copy the macfile before appending new
entries.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
SVN-Revision: 36944
Using variables from the outer scope unnecessarily complicates the code and
leads to issues.
This patch fixes the bug when having an "adhoc" wifi-iface section before a
"sta" section prevents wpa_supplicant from using the key specified in the
corresponding section as it tries to use the "adhoc" key instead (1 by
default).
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
SVN-Revision: 34716
Previously only the first macfilter configuration would have been used
on all interfaces. However, the configuration was always done per vif
already. Hence, move the macfilter setup into hostapd.sh where and
create one mac list file per vif.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
SVN-Revision: 34470
