[RTEMS Project] #3223: libbsd: wpa_supplicant has to be started dynamically

RTEMS trac trac at rtems.org
Fri Feb 25 18:13:18 UTC 2022


#3223: libbsd: wpa_supplicant has to be started dynamically
--------------------------------------------+------------------------------
 Reporter:  Christian Mauderer              |       Owner:  Christian
                                            |  Mauderer
     Type:  enhancement                     |      Status:  accepted
 Priority:  normal                          |   Milestone:  Indefinite
Component:  network/libbsd                  |     Version:  5
 Severity:  normal                          |  Resolution:
 Keywords:  SoC, libbsd, WiFi, WLAN, large  |  Blocked By:
 Blocking:                                  |
--------------------------------------------+------------------------------
Description changed by Gedare Bloom:

Old description:

> To connect to a WPA encrypted network using libbsd it is currently
> necessary to restart the wpa_supplicant for each new connection. A better
> solution for that should be found.
>
> In FreeBSD, the wpa_supplicant will somehow automatically be started if
> the `ifconfig_<interface>` line or rc.conf contains a WPA (see
> [https://www.freebsd.org/cgi/man.cgi?query=rc.conf&manpath=FreeBSD+12-current
> rc.conf(5)] section ''network_interfaces'').
>
> The rtems-libbsd should have a similar mechanism. One possibility would
> be to try to make the dhcpcd script hooks usable on RTEMS and start
> wpa_supplicant from a hook.

New description:

 To connect to a WPA encrypted network using libbsd it is currently
 necessary to restart the wpa_supplicant for each new connection. A better
 solution for that should be found.

 In FreeBSD, the wpa_supplicant will somehow automatically be started if
 the `ifconfig_<interface>` line or rc.conf contains a WPA (see
 [https://www.freebsd.org/cgi/man.cgi?query=rc.conf&manpath=FreeBSD+12-current
 rc.conf(5)] section ''network_interfaces'').

 The rtems-libbsd should have a similar mechanism. One possibility would be
 to try to make the dhcpcd script hooks usable on RTEMS and start
 wpa_supplicant from a hook.

 **Possible Approaches**
 The DHCP client used in the libbsd (dhcpcd) has a script hook support.
 That support has been removed in the RTEMS port because there is no script
 interpreter. One possibility would be to try to make the dhcpcd script
 hooks usable on RTEMS so that they can call C functions instead of the
 scripts. Such a hook could then start a wpa_supplicant from a hook.
 Another solution would be to take a detailed look at the FreeBSD
 implementation and create something similar.

 **Additional Problems**
 Most likely it will be necessary to start more then one instance of
 wpa_supplicant (for example if two interfaces are connected). Currently
 that is not possible. The wpa_supplicant should be reviewed whether it can
 be started multiple times in parallel.

 **Necessary Hardware**
 I would recommend some real hardware (like a Beagle Bone Black with a
 RTL8188 based USB WiFi? dongle) and a hardware debugger (Segger J-Link,
 Flyswatter 2, something supported by OpenOCD, ...). Real hardware with
 WiFi? is the most likely later use case.
 Theoretically WPA should be usable on wired interfaces. So it might be
 possible to develop this in a simulator too. The advantage of this is that
 there are no hardware costs and a simple debug integration. If you think
 about that solution, please discuss it with your (planned) mentor before
 starting.

 **Related projects**
 #3222 will need some WiFi? related rc.conf integration too. Maybe the hot-
 plug detection of that project could be of some use too.

 **Skills**
 C programming and understanding of system configuration/administration.

 This is a 350-hour project of hard difficulty.

--

--
Ticket URL: <http://devel.rtems.org/ticket/3223#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list