Hi, try to take a look at the OpenWRT's patches of hostapd. They are
using UBUS - own tiny alternative to DBUS. There are good example for
how to integrate such system into hostapd code. May be shipping from
DBUS to UBUS will become another alternative for you.
On 02.05.2019 11:17, Joakim Lotsengård wrote:
Good morning,
I just join the hostap mailing list so please forgive me if I am touching a
subject which is already addressed.
I work for for a company that makes (home-) alarms and has a central unit
which talks WiFi. Both uplink (wpa_supplicant) and acts as an AP (hostapd)
for sub-nodes (stations). The system is closed, eg. the user/customer
can't use the AP for anything else. We have a database of all nodes that
can be connected to the central unit and generates a hostapd.conf and a
wpa_psk.conf. A generated PSK for each node. (Each node will be provided
with its PSK via a second channel, a 868 Mhz radio.)
The problem we have is that we want to know when a node is authenticated
(and deauthenticated) by hostapd. We use the control interface (that
hostapd_cli uses) today for this. The bad part of this is that it is a
datagram named unix socket. Not really well suitable for a server system
to talk to hostapd with. It is more adopted for a client (hostapd_cli). We
get state problems if hostapd dies. Since it is an datagram socket we don't
get notices that the other end closed down. If/when hostapd restarts we
can't be sure that we connected to the new cli socket fast enough that we
didn't miss any authed stations. We have to re-list all authed clients every
now and then in order to make sure we are in sync. We have to ping over the
socket so make sure we still connected. To add more, hostapd removes the
socket from file system and create it. Adding to a slight "file not
found"-problem for us. We had a number of state related problems. We also
have to reload the entire hostapd when new nodes (stations) are added or
removed in the configured PSK file. The daemon providing hostapd isn't
running as root for security reasons. We would like to express this a bit
more exact than just file system permissions.
We do not want to use radius for this as this complicates things and doesn't
fit with our environment at all.
Since we already use DBUS for about everything else in our system, we would
like to use it with hostapd as well. DBUS also has the possibility to
configure policy for permissions. We would need the following methods and
signals:
1. method: Add new station with its own PSK
2. method: Remove station
3. signal: Station was authed
4. signal Station was deauthed
5. Possibly: Method: List all added stations
6. Possibly: Method: List all authed stations
First question is if there is such a patch in any branch anywhere? If not,
we are willing to do the work for this and offer it to hostapd. We see two
solutions:
1. Integrate DBUS-support in the event loop. I see that wpa_supplicant has
DBUS-support, so something like how wpa_supplicant works.
2. If this community doesn't like this idea we are thinking of adding a
dbus-support in a parallel thread inside hostapd. That thread will map DBUS
to the internal control interface socket to get it to the event loop. Idea
here is to have a patch that will always apply even when hostapd updates.
To keep the function away from the hostapd core and isolate the code. The
patch will be offered to anyone who wants it.
Of course our goal is to give back to the community. We do have a specific
need, and a specific problem to solve. We will probably not implement
a DBUS method/signal for everything possible in hostapd to make the DBUS
interface "complete". But I guess a start is better than nothing.
I'd be happy to hear any feedback on the idea. Any limitations, any do or
don't, or other general comments before we start. We do not have any
limitations that conflicts with GPL or any other open community policy. We
are happy to share the solution.
--
Best regards,
Joakim Lotsengård
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
