what is your 5GHz rank modifier?
by James Prestwood
Hi,
Several others in the past have asked about IWD's 5/2.4GHz ranking and
explained that on their particular network 2.4GHz is heavily preferred.
I have done some minimal testing and also noticed this. IWD heavily
weights signal strength, and in my case the 5GHz network is
significantly lower than 2.4, e.g. -71db vs -43db. Although the signal
is worse I have found that I actually get higher throughput on 5GHz in
many cases. IWD's own data rate calculation (theoretical) is coming up
higher on 5GHz since its 802.11AC/VHT vs 802.11N on 2.4GHz. The issue
boils down to IWD's significant weight on signal strength.
Signal strength is usually the best way for rank calculation especially
when you have two networks using the same technology. For this reason
its probably a bad idea to reduce the signal strength weights.
As we have suggested others, it seems most appropriate to modify IWD's
5GHz ranking specifically to handle this scenario. By default the 5Ghz
rank modifier is unused (set to 1.0). I would like to know if anyone
else has been playing with [Rank].BandModifier5Ghz, and found values
that work for them as we are considering changing the default to better
handle the average user.
Or maybe IWD handles your network just fine the way it is? Either way
it would be nice to get some feedback from the community.
Thanks,
James
5 months, 2 weeks
[PATCH 1/3] station: add Roam() diagnostics method
by James Prestwood
This is being added as a developer method and should not be used
in production. For testing purposes though, it is quite useful as
it forces IWD to roam to a provided BSS and bypasses IWD's roaming
and ranking logic for choosing a roam candidate.
To use this a BSSID is provided as the only parameter. If this
BSS is not in IWD's current scan results -EINVAL will be returned.
If IWD knows about the BSS it will attempt to roam to it whether
that is via FT, FT-over-DS, or Reassociation. These details are
still sorted out in IWDs station_transition_start() logic.
---
src/station.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/src/station.c b/src/station.c
index d2234e15..62eebfa2 100644
--- a/src/station.c
+++ b/src/station.c
@@ -3721,12 +3721,47 @@ static struct l_dbus_message *station_get_diagnostics(struct l_dbus *dbus,
return NULL;
}
+static struct l_dbus_message *station_force_roam(struct l_dbus *dbus,
+ struct l_dbus_message *message,
+ void *user_data)
+{
+ struct station *station = user_data;
+ struct scan_bss *target;
+ struct l_dbus_message_iter iter;
+ uint8_t *mac;
+ uint32_t mac_len;
+
+ if (!l_dbus_message_get_arguments(message, "ay", &iter))
+ goto invalid_args;
+
+ if (!l_dbus_message_iter_get_fixed_array(&iter, &mac, &mac_len))
+ goto invalid_args;
+
+ if (mac_len != 6)
+ return dbus_error_invalid_args(message);
+
+ l_debug("Attempting roam to BSS "MAC, MAC_STR(mac));
+
+ target = network_bss_find_by_addr(station->connected_network, mac);
+ if (!target || target == station->connected_bss)
+ return dbus_error_invalid_args(message);
+
+ station_transition_start(station, target);
+
+ return l_dbus_message_new_method_return(message);
+
+invalid_args:
+ return dbus_error_invalid_args(message);
+}
+
static void station_setup_diagnostic_interface(
struct l_dbus_interface *interface)
{
l_dbus_interface_method(interface, "GetDiagnostics", 0,
station_get_diagnostics, "a{sv}", "",
"diagnostics");
+ l_dbus_interface_method(interface, "Roam", 0, station_force_roam,
+ "", "ay", "mac");
}
static void station_destroy_diagnostic_interface(void *user_data)
--
2.26.2
5 months, 2 weeks
[PATCH] main: Add D-Bus Daemon.GetInfo method
by Andrew Zaborowski
Expose the state directory/storage directory path on D-Bus because it
can't be known to clients until IWD runs, and client might need to
occasionally fiddle with the network config files. While there also
expose the IWD version string, similar to how some other D-Bus services
do.
---
I'm not happy with the name of the interface and the name of the method
but couldn't find better names that would work well and satisfy
everybody. "net.connman.IWD" or "net.connman.iwd.Control" are other
names I considered, and as for GetInfo the alternative could be using
properties similar to how org.freedesktop.NetworkManager exposes
Version, org.freedesktop.ColorManager exposes DaemonVersion,
org.gnome.DisplayManager exposes Version{Major,Minor,Micro}, etc.
---
src/dbus.h | 1 +
src/main.c | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+)
diff --git a/src/dbus.h b/src/dbus.h
index 4936dc6c..b3896108 100644
--- a/src/dbus.h
+++ b/src/dbus.h
@@ -24,6 +24,7 @@
#define IWD_SERVICE "net.connman.iwd"
+#define IWD_DAEMON_INTERFACE "net.connman.iwd.Daemon"
#define IWD_AGENT_MANAGER_INTERFACE "net.connman.iwd.AgentManager"
#define IWD_WIPHY_INTERFACE "net.connman.iwd.Adapter"
#define IWD_DEVICE_INTERFACE "net.connman.iwd.Device"
diff --git a/src/main.c b/src/main.c
index 2ee6188c..f65fa7f4 100644
--- a/src/main.c
+++ b/src/main.c
@@ -185,6 +185,16 @@ static void request_name_callback(struct l_dbus *dbus, bool success,
if (!l_dbus_object_manager_enable(dbus, "/"))
l_warn("Unable to register the ObjectManager");
+ if (!l_dbus_object_add_interface(dbus, IWD_BASE_PATH,
+ IWD_DAEMON_INTERFACE,
+ NULL) ||
+ !l_dbus_object_add_interface(dbus, IWD_BASE_PATH,
+ L_DBUS_INTERFACE_PROPERTIES,
+ NULL))
+ l_info("Unable to add %s and/or %s at %s",
+ IWD_DAEMON_INTERFACE, L_DBUS_INTERFACE_PROPERTIES,
+ IWD_BASE_PATH);
+
/* TODO: Always request nl80211 for now, ignoring auto-loading */
l_genl_request_family(genl, NL80211_GENL_NAME, nl80211_appeared,
NULL, NULL);
@@ -194,12 +204,44 @@ fail_exit:
l_main_quit();
}
+static struct l_dbus_message *iwd_dbus_get_info(struct l_dbus *dbus,
+ struct l_dbus_message *message,
+ void *user_data)
+{
+ struct l_dbus_message *reply;
+ struct l_dbus_message_builder *builder;
+ L_AUTO_FREE_VAR(char *, storage_dir) = storage_get_path(NULL);
+
+ reply = l_dbus_message_new_method_return(message);
+ builder = l_dbus_message_builder_new(reply);
+ l_dbus_message_builder_enter_array(builder, "{sv}");
+
+ dbus_append_dict_basic(builder, "StateDirectory", 's', storage_dir);
+ dbus_append_dict_basic(builder, "Version", 's', VERSION);
+
+ l_dbus_message_builder_leave_array(builder);
+ l_dbus_message_builder_finalize(builder);
+ l_dbus_message_builder_destroy(builder);
+
+ return reply;
+}
+
+static void iwd_setup_deamon_interface(struct l_dbus_interface *interface)
+{
+ l_dbus_interface_method(interface, "GetInfo", 0, iwd_dbus_get_info,
+ "a{sv}", "", "info");
+}
+
static void dbus_ready(void *user_data)
{
struct l_dbus *dbus = user_data;
l_dbus_name_acquire(dbus, "net.connman.iwd", false, false, false,
request_name_callback, NULL);
+
+ l_dbus_register_interface(dbus, IWD_DAEMON_INTERFACE,
+ iwd_setup_deamon_interface,
+ NULL, false);
}
static void dbus_disconnected(void *user_data)
--
2.27.0
5 months, 2 weeks
[PATCH] station: print reason why autoconnect failed
by James Prestwood
---
src/station.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/station.c b/src/station.c
index 442f8ee2..d2234e15 100644
--- a/src/station.c
+++ b/src/station.c
@@ -180,10 +180,11 @@ static void station_autoconnect_next(struct station *station)
int r;
while ((entry = l_queue_pop_head(station->autoconnect_list))) {
+ const char *ssid = network_get_ssid(entry->network);
+
l_debug("Considering autoconnecting to BSS '%s' with SSID: %s,"
" freq: %u, rank: %u, strength: %i",
- util_address_to_string(entry->bss->addr),
- network_get_ssid(entry->network),
+ util_address_to_string(entry->bss->addr), ssid,
entry->bss->frequency, entry->rank,
entry->bss->signal_strength);
@@ -206,7 +207,8 @@ static void station_autoconnect_next(struct station *station)
}
return;
- }
+ } else
+ l_debug("Failed to autoconnect to %s (%d)", ssid, r);
}
}
--
2.26.2
5 months, 2 weeks
[PATCH] test-runner: increase RAM for valgrind
by James Prestwood
Certain tests like testAP spawn two IWD process in separate
namespaces. When --valrind is used this eats up quite a bit
of RAM and causes the VM to run out of memory and start
killing off processes.
---
tools/test-runner | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/test-runner b/tools/test-runner
index b890b3e7..dd4cbf82 100755
--- a/tools/test-runner
+++ b/tools/test-runner
@@ -1570,7 +1570,15 @@ class Main:
else:
smp = int(nproc / 2)
- print("Using %d cores for VM" % smp)
+ #
+ # Increase RAM if valgrind is being used
+ #
+ if self.args.valgrind:
+ ram = 512
+ else:
+ ram = 256
+
+ print("Using %d cores, %d RAM for VM" % (smp, ram))
#
# This passes through most of the command line options to
@@ -1593,7 +1601,7 @@ class Main:
qemu_binary,
'-machine', 'type=q35,accel=kvm:tcg',
'-nodefaults', '-no-user-config', '-monitor', 'none',
- '-display', 'none', '-m', '256M', '-nographic', '-vga',
+ '-display', 'none', '-m', '%dM' % ram, '-nographic', '-vga',
'none', '-no-acpi', '-no-hpet',
'-no-reboot', '-fsdev',
'local,id=fsdev-root,path=/,readonly,security_model=none,multidevs=remap',
--
2.26.2
5 months, 2 weeks
[PATCH] build: fix ell/shared build failure
by Alvin Šipraga
Fix the following build error:
$ /path/to/iwd/configure --disable-dependency-tracking
$ make
GEN ell/shared
/bin/sh: line 5: ell/shared: No such file or directory
make: *** [Makefile:3656: ell/shared] Error 1
The error can also arise if building with --enable-external-ell.
Fixes: ed05585063f2 ("build: Always link in the ell/useful.h header file")
---
Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.am b/Makefile.am
index 644f3556..68035e46 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -625,6 +625,7 @@ unit/tls-settings.8021x: unit/cert-ca.pem unit/cert-client.pem unit/cert-client-
BUILT_SOURCES = $(ell_built_sources) src/builtin.h
ell/shared: Makefile
+ $(AM_V_at)$(MKDIR_P) ell
$(AM_V_GEN)for f in $(ell_shared) ; do \
if [ ! -f $$f ] ; then \
$(LN_S) -t ell -f $(abs_srcdir)/../ell/$$f ; \
--
2.30.2
5 months, 3 weeks
Use of kernel crypto lib
by Alexander Monakov
Hi,
I raised the topic of inappropriate use of kernel crypto lib for
certchain validation in IWD and was told it was discussed previously. I
do not see such threads in the archives (but at the moment archives
before September 2019 are not available).
To me this design looks poorly justified. IWD seems to basically use the
kernel crypto API as a normal crypto library, just running with kernel
privileges. The kernel code is evidently imperfect, and IWD is basically
short-cutting any defense-in-depth measures that could have been in
place by feeding certificates presented by random APs to the kernel.
I don't want to get a kernel oops (or worse) by simply walking past by
an "evil" access point.
If history tells us that ASN.1 parsing code usually has mistakes, then
applying also the principle of least privilege I expect certificate
validation to run in a seccomp'ed child subprocess of IWD, not the
kernel.
I don't buy the comparison against signed modules offered on IRC. A random
webpage I visit cannot trivially elevate itself to root to attempt to
load a module with crafted signature. IWD's use strikes me as reckless
to put it mildly.
(there's also the "patch-the-kernel-to-use-IWD" angle, which is less
important, but still: whenever kernel crypto lib doesn't cut it, the
user has to upgrade the kernel or ditch IWD; in my adjacent thread it
happened due to leaf cert not following RFC, but it could plausibly
happen with completely valid certificates as well)
Alexander
5 months, 3 weeks
[PATCH] client: Show WEP networks as unsupported
by Sean Anderson
WEP networks are not supported by iwd. However, the only indication is the
message "Operation not supported" while trying to connect. It is not clear
enough that this is due to intentional lack of support (as opposed to some
kind of misconfiguration). This patch explicitly lists WEP networks shown
with get-networks as unsupported. Hopefully this will make it clearer for
those of us not as familiar with iwd.
CC: James Prestwood <prestwoj(a)gmail.com>
CC: Marcel Holtmann <marcel(a)holtmann.org>
CC: Denis Kenzior <denkenz(a)gmail.com>
---
client/station.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/client/station.c b/client/station.c
index de25d12b..425b10a1 100644
--- a/client/station.c
+++ b/client/station.c
@@ -352,7 +352,7 @@ static void ordered_networks_display(struct l_queue *ordered_networks)
display_table_header("Available networks", "%s%-*s%-*s%-*s%*s",
MARGIN, 2, "", 32, "Network name",
- 10, "Security", 6, "Signal");
+ 18, "Security", 6, "Signal");
if (!l_queue_length(ordered_networks)) {
display("No networks available\n");
@@ -369,13 +369,16 @@ static void ordered_networks_display(struct l_queue *ordered_networks)
const char *network_name = network_get_name(network_i);
const char *network_type = network_get_type(network_i);
+ if (!strcmp(network_type, "wep"))
+ network_type = "wep (unsupported)";
+
if (display_signal_as_dbms)
dbms = l_strdup_printf("%d", network->signal_strength);
display("%s%-*s%-*s%-*s%-*s\n", MARGIN, 2,
network_is_connected(network_i) ?
COLOR_BOLDGRAY "> " COLOR_OFF : "",
- 32, network_name, 10, network_type,
+ 32, network_name, 18, network_type,
6, display_signal_as_dbms ? dbms :
dbms_tostars(network->signal_strength));
--
2.25.1
5 months, 3 weeks
