On Sat, Apr 25, 2020 at 11:20:45AM -0500, KeithG wrote:
I looked at the IWD readme and cannot enable this on the RPi:
# ip link set dev nlmon allmulticast on
> Cannot find device "nlmon"
The RPi kernel has no support for nlmon enabled. If you want to debug this you
propably need to compile your own RPi kernel with nlmon enabled.
I did verify a couple things. I do have iwd set explicitly when I
start
connman
/usr/bin/connmand --wifi=iwd_agent -n --nodnsproxy
--wifi=iwd_agent is wrong. If you want iwd support you need to define this
at compile time only:
./configure --enable-iwd --disable-wifi
which adds the iwd plugin and disables the wpa_supplicant plugin. But I don't
think it matter. --iwfi-iwd_agent will be ignored and ConnMan will dynamically
discover iwd. Just make sure wpa_supplicant is not running. With the above
command line you would make sure wpa_supplicant is not accidentally used.
When I issue the command from connman, the mode changes in iwd:
> # connmanctl tether wifi on myssid password
> Wifi SSID set
> Wifi passphrase set
> Enabled tethering for wifi
> # ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
> link/ether a0:ce:c8:12:ed:05 brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.25/24 brd 192.168.2.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 fe80::a2ce:c8ff:fe12:ed05/64 scope link
> valid_lft forever preferred_lft forever
> 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> fq_codel master tether state DORMANT group default qlen 1000
> link/ether b8:27:eb:28:18:48 brd ff:ff:ff:ff:ff:ff
> 4: tether: <NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP> mtu 1500 qdisc
> noqueue state DOWN group default qlen 1000
> link/ether 9a:69:3a:48:c1:32 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.1/24 brd 192.168.0.255 scope global tether
> valid_lft forever preferred_lft forever
> inet6 fe80::d024:5eff:fe80:1a57/64 scope link
> valid_lft forever preferred_lft forever
> # iwctl device wlan0 show
> Device: wlan0
>
> --------------------------------------------------------------------------------
> Settable Property Value
>
> --------------------------------------------------------------------------------
> Name wlan0
> * Mode ap
> * Powered on
> Address b8:27:eb:28:18:48
> Adapter phy0
>
I get these responses in the journal when I try to connect but it never
connects:
> src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
> src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
> src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
>
Did you try to run iwd with debug enabled 'iwd -d'? Maybe there is more
info. And if there isn't any clue, the best way forward is to get
nlmon running and provide the information the iwd developers. From what I
see ConnMan is talking to iwd and setups the AP mode.
I currently use hostapd and dnsmasq to have this headless RPi audio
appliance work as an AP for initial setup, but want to remove hostapd and
dnsmasq if I can get connman/iwd to do the same thing. I tried to get iwd
to go into ap mode and connect, but cannot do it there, either. I do get
some messages at startup of iwd. I do not think these are the problem, but
they are missing kernel modules:
No Diffie-Hellman support found, WPS will not be available
> No asymmetric key support found.
> TLS based WPA-Enterprise authentication methods will not function.
> Kernel 4.20+ is required for this feature.
> The following options are missing in the kernel:
> CONFIG_ASYMMETRIC_KEY_TYPE
> CONFIG_KEY_DH_OPERATIONS
> CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> CONFIG_PKCS7_MESSAGE_PARSER
> CONFIG_X509_CERTIFICATE_PARSER
> CONFIG_PKCS8_PRIVATE_KEY_PARSER
> Wireless daemon version 1.6
I don't know but I would suggest to address this in the same go when you build
a new kernel with nlmon support.
Thanks,
Daniel