From: Denis Kenzior <denkenz@gmail.com>
To: Fabian Herb <fabian.herb@xtonomy.ai>
Cc: "iwd@lists.linux.dev" <iwd@lists.linux.dev>
Subject: Re: How to Autoconnect Two WiFi Cards?
Date: Wed, 24 Jan 2024 10:18:41 -0600 [thread overview]
Message-ID: <0bae4724-6d12-4e5e-9f6a-37f5e93ba40a@gmail.com> (raw)
In-Reply-To: <A3545185-22E7-4491-AD80-FFF9FEDCB8F1@xtonomy.ai>
Hi Fabian,
On 1/24/24 10:07, Fabian Herb wrote:
> Hi Denis,
>
>> - When considering a network, first check whether a network with the same SSID/security type is being connected to by other stations managed by iwd
>> - This should be easy to do by looping of the station_list and checking connected_network / connected_bss members of struct station.
>> - If the networks match, just skip it and continue on to the next autoconnect target.
>> - This should result in each station object connecting to a different SSID. Once latched onto the SSID, station will try to roam only within that network.
>
> Thanks for the hint! But wouldn’t that mean that it’s basically random which interface connects to which SSID? Right now I’m configuring IPs and routing via systemd-networkd for each
Yes, but if your cards are identical, does it matter? If your cards have
asymmetric capabilities, things are a bit trickier, but that would be the realm
of defining a policy iwd can follow.
interface, and that would stop working if the two interfaces are connected the
wrong way
Make your policy smarter. For example, have it consider the SSID instead of the
interface name?
around. The approach also screams for race conditions :D.
Not really. There would be corner cases of course, for example if there's only
a single SSID to connect to the second card will never connect.
>
> I was thinking about something like this:
> - Add a configuration option to the network file format which holds an interface name
interface names are made up by iwd itself, and are not static across things like
hardware hotplug/unplug. Yes you can beat iwd into honoring the name coming in
from the kernel, or with some care, from udev renaming, but even those are not
guaranteed to be static. What you really want to take into account is the
underlying hardware capabilities.
> - When iterating the list of networks to autoconnect to, skip the entries for which the interface name is set AND it does not match the current interface.
Yeah, NM does something similar. But see above.
Regards,
-Denis
prev parent reply other threads:[~2024-01-24 16:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 16:48 How to Autoconnect Two WiFi Cards? Fabian Herb
2024-01-16 17:15 ` James Prestwood
2024-01-18 11:51 ` Fabian Herb
2024-01-18 12:18 ` James Prestwood
2024-01-23 13:36 ` Fabian Herb
2024-01-23 14:15 ` James Prestwood
2024-01-23 16:15 ` Denis Kenzior
2024-01-24 12:34 ` Fabian Herb
2024-01-24 15:21 ` Denis Kenzior
2024-01-24 16:07 ` Fabian Herb
2024-01-24 16:18 ` Denis Kenzior [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bae4724-6d12-4e5e-9f6a-37f5e93ba40a@gmail.com \
--to=denkenz@gmail.com \
--cc=fabian.herb@xtonomy.ai \
--cc=iwd@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).