All the system header files are supposed to be included before any other
internal header file apart from utils/includes.h.
Signed-off-by: Jouni Malinen <j@w1.fi>
The multi-SSID design that used a single beaconing BSSID with multiple
SSIDs was never completed in this repository, so there is no need to
maintain the per-STA ssid/ssid_probe pointers that could only point to
&hapd->conf->ssid. Save some memory and reduce code complexity by
removing this unused partial capability.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes it easier to interpret debug logs for cases where hostapd
control multiple interfaces.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
hostapd receives NEWLINK messages multiple times and thus does
configuration of the the vlan interface multiple times.
This is not required and leads to the following during cleanup in
test pmksa_cache_preauth_vlan_used:
1. run-test.py does: brctl delif brvlan1 wlan3.1
2. hostapd processes NEWLINK and does: brctl addif brvlan1 wlan3.1
3. run-test.py does: brctl delbr brvlan1
-> fails as wlan3.1 is still in the bridge
This patch fixes this by ignoring repeated NEWLINK messages.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
When hitting
> Failed to create interface wlan3.1: -23 (Too many open files in system)
> Try to remove and re-create wlan3.1
hostapd deletes the AP_VLAN interface and then recreates it. Thus the
kernel assigns the same ifidx to the new interfaces and sends DELLINK
and NEWLINK mesages.
As the DELLINK messages are processed after the struct hostapd_vlan is
added, hostapd deletes the struct hostapd_vlan entry, deconfigures the
AP_VLAN interface and leaves vlan_newlink nothing to find afterwards.
So this patch makes DELLINK messages to be ignored when the interface
exists.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
This uses couple of additional helper macros and prints more debug
information to make the VLAN events easier to analyze.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This reverts commit 4345fe963e. That
introduced number of memory leaks and since the rest of the VLAN changes
did not yet go in, it is easier to revert this for now and bring back
the changes after fixes if there is sufficient interest for them in the
future.
Signed-off-by: Jouni Malinen <j@w1.fi>
These files have been distributed only under the BSD license option
since February 2012. Clarify the license statements in the files to
match that to avoid confusion.
Signed-hostap: Jouni Malinen <j@w1.fi>
This fixes some issues where dynamic interface enable/disable cycles
could end up trying to free resources twice and crash the process while
doing so.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Currently, struct hostapd_vlan is a per-BSS data structure which
also contains informations about whether to remove the bridge
or clear wlan / tagged-vlan interface from the bridge.
In a multi-interface multi-BSS setup, this can lead to the following
race condition:
1. wlan0 creates VLAN A, sets DVLAN_CLEAN_BR and DVLAN_CLEAN_VLAN_PORT
2. wlan1 creates VLAN A, does not set DVLAN_CLEAN_BR and
DVLAN_CLEAN_VLAN_PORT as already there
3. wlan0 removes VLAN A, removes tagged-interface from the bridge
but not the bridge.
Now wlan1 VLAN A is unusable due to the missing uplink.
4. wlan1 removes VLAN A, does not cleanup
Solution:
This requires an inter-BSS inter-interface data structure to track the
bridge / bridge port usage within hostapd. This data structure could
also be used to track any other device-has-been-created-by-hostapd
information or when regarding interface freeing.
Signed-hostap: Michael Braun <michael-dev@fami-braun.de>
Currently by default, all BSS share the bridge brvlan%d.
While this is sane when no tagged-interface is given, this
is insane when different tagged interfaces are given, as
it would result in bridging those tagged interfaces.
This patch therefore uses br%s%d with %s=tagged_interface
and %d=VLAN ID as bridge name when a tagged-interface is given.
Signed-hostap: Michael Braun <michael-dev@fami-braun.de>
Currently, when different BSS using different tagged vlan
interfaces, they are forced to share the bridge brvlan#,
which is not desirable.
This patch fixes this by making the bridge name configurable.
Signed-hostap: Michael Braun <michael-dev@fami-braun.de>
My APs generate their configuration on their own using a different
number of (vlan-enabled) bss. Currently, all my vlan_file files consist
of a single line: the wildcard line. Configuration file generation would
be easier, if the hostapd configuration file would not depend on those
simple vlan_file files.
This patch removes the need for those one-line files by using the
<device>.<vlan> naming scheme if no vlan_file is given (or that file is
empty). This should not break any existing setup, as using dynamic_vlan
with no vlan configured does not make sense anyway.
Signed-hostap: Michael Braun <michael-dev@fami-braun.de>
CONFIG_VLAN_NETLINK=y build option can now be used to replace the
ioctl()-based interface for creating and removing VLAN interfaces
with netlink-based interface.
Signed-hostap: M. Braun <michael-dev@fami-braun.de>
This is not needed anymore and just makes things more difficult
to understand, so move the remaining function pointers to direct
function calls and get rid of the struct hostapd_driver_ops.
send_eapol, set_key, read_sta_data, sta_clear_stats,
set_radius_acl_auth, set_radius_acl_expire, and set_beacon
to use inline functions instead of extra abstraction.
Both the wildcard VLAN entry and the statically configured VLAN
interfaces should behave in the same way. Initializing the
full dynamic VLAN code before adding the statically configured VLAN
interfaces allows the same processing to be applied to both statically
and dynamically added VLAN interface (i.e., also the statically
configured ones will be added to a bridge).
Doxygen and some build tools may get a bit confused about same file
name being used in different directories. Clean this up a bit by
renaming some of the duplicated file names in src/ap.
This code can be shared by both hostapd and wpa_supplicant and this
is an initial step in getting the generic code moved to be under the
src directories. Couple of generic files still remain under the
hostapd directory due to direct dependencies to files there. Once the
dependencies have been removed, they will also be moved to the src/ap
directory to allow wpa_supplicant to be built without requiring anything
from the hostapd directory.
