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.
