Opened on 11/09/17 at 09:44:16
Last modified on 02/25/22 at 18:13:18
#3223 accepted enhancement
libbsd: wpa_supplicant has to be started dynamically
Reported by: | Christian Mauderer | Owned by: | Christian Mauderer |
---|---|---|---|
Priority: | normal | Milestone: | Indefinite |
Component: | network/libbsd | Version: | 5 |
Severity: | normal | Keywords: | SoC, libbsd, WiFi, WLAN, large |
Cc: | Blocked By: | ||
Blocking: |
Description (last modified by Gedare Bloom)
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 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.
Change History (6)
comment:1 Changed on 01/03/18 at 20:28:21 by Christian Mauderer
Keywords: | SoC added |
---|
comment:2 Changed on 01/03/18 at 20:31:18 by Christian Mauderer
comment:3 Changed on 01/18/18 at 19:54:41 by Christian Mauderer
Owner: | set to Christian Mauderer |
---|---|
Status: | new → accepted |
comment:4 Changed on 01/18/18 at 20:06:51 by Christian Mauderer
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.
comment:5 Changed on 02/03/22 at 20:16:00 by Gedare Bloom
Keywords: | large added |
---|
comment:6 Changed on 02/25/22 at 18:13:18 by Gedare Bloom
Description: | modified (diff) |
---|
If wpa_supplicant is started dynamically, it would be necessary to make sure that more than one instance can be started at the same time.