error in Torizon + NetworkManager
OK in Linux + hostapd
error message :
if we modify the NetworkManager “ipv4.method” to “shared” with this command :
nmcli con modify TEST_AP_NAME ipv4.method shared
the following error message occur:
(uap0): Activation: Stage 5 of 5 (IPv4 Commit) start sharing failed: could not start dnsmasq due to Could not find “dnsmasq” binary
As I noticed, the “dnsmasq” is not included in the Toradex image, however this plugin is required by the NetworkManager.
Since you noted this happened on both a 1.0 and 1.1 module this issue seems to be independent of hardware.
Could you please provide the full steps you did to reproduce. Just to make sure nothing is missing when we investigate this issue further.
So you setup a WiFi access point using the Network manager instructions. You modify the ipv4.method to shared with nmcli con modify TEST_AP_NAME ipv4.method shared. Then you connected two clients to this access point?
Please check the reproduce steps as below. As you can see the error message is “dnsmasq”, I think it is due to the “dnsmasq” is not included in the TorizonCore kernel image. Can Toradex consider to include the “dnsmasq” in the future TorizonCore image release? Currently the wifi AP mode “ipv4.method=shared” is not working in Torizon + Networkmanager without the dnsmasq.
Install TorizonCore 5.7.0-devel-202206+build.24 (2022-06-07) on verdin imx8m plus V1.0E
bring up the wifi access point with NetworkManager, error occur:
$ nmcli con add type wifi ifname uap0 mode ap con-name TEST_AP_NAME ssid TEST_SSID
Connection ‘TEST_AP_NAME’ (0879ebf6-508d-4291-9eb0-4fdcdd00acf9) successfully added.
$ nmcli con modify TEST_AP_NAME 802-11-wireless-security.key-mgmt wpa-psk
$ nmcli con modify TEST_AP_NAME 802-11-wireless-security.proto rsn
$ nmcli con modify TEST_AP_NAME 802-11-wireless-security.group ccmp
$ nmcli con modify TEST_AP_NAME 802-11-wireless-security.pairwise ccmp
$ nmcli con modify TEST_AP_NAME 802-11-wireless-security.psk aaaaaaaa
$ nmcli con modify TEST_AP_NAME ipv4.addresses 192.168.1.100
$ nmcli con modify TEST_AP_NAME ipv4.method shared
$ nmcli con up TEST_AP_NAME
Error: Connection activation failed: IP configuration could not be reserved (no available address, timeout, etc.)
Hint: use ‘journalctl -xe NM_CONNECTION=0879ebf6-508d-4291-9eb0-4fdcdd00acf9 + NM_DEVICE=uap0’ to get more details.
Check the NetworkManager error message :
$journalctl -xe NM_CONNECTION=0879ebf6-508d-4291-9eb0-4fdcdd00acf9 + NM_DEVICE=uap0
[1667334908.9399] device (uap0): ip:shared4: could not start dnsmasq: Could not find “dnsmasq” binary
[1667334940.9099] device (uap0): Activation: failed for connection ‘TEST_AP_NAME’
Ok I was able to reproduce this myself using your steps. It seems when using ipv4.method=shared, Network Manager internally uses a dnsmasq process to handle this. I don’t see an easy way to change this behavior.
Out of curiosity were you planning to use ipv4.method=shared, to share the wired internet connection on the device via the access point? Like a hotspot of sorts?
In any case I can put forth a request to our team to include dnsmasq into TorizonCore. However, TorizonCore 5.7.0 is a LTS release, meaning the only future releases will be patch releases (5.7.1, 5.7.2, etc). Which by our definition means we only include essential bug fixes. That is to say, I can’t guarantee the team will add dnsmasq to some TorizonCore 5.7.Y
Our new 6.X.Y TorizonCore releases are in active development so I imagine it will be easier to make the argument to add dnsmasq here.
All that said, are you planning to develop and release your product on TorizonCore 5.7.Y? Or are you okay with waiting for a future release of TorizonCore 6.X.Y that has dnsmasq?
Also I guess as you said using the hostapd method works for your use-case correct? Would this be a suitable workaround for the time being?
I am thinking to turn the Toradex into a hotspot. Currently the work around is to use TorizonCore 5.6.x, “unmanage” the “uap0” from the NetworkManager, then bring up a “hostapd” in the TorizonCore for the hotspot only.
For the image version: the “uap0” has some other issue in both 5.7.x and 6.0.x, please check the following thread. Logically it will be nice to fix both of them in the 6.0.x future release, so the wireless hotspot can really work.