TDLS Discovery support in wpa_supplicant
Mon Mar 30 09:14:35 PDT 2015
Currently wpa_supplicant supports launching TDLS discovery via the
control interface and D-Bus. However, in handling the discovery
response, currently there's only a log message generated. I'd like to
get feedback on the two possible ways the result of a TDLS discovery
could further be dealt with in wpa_supplicant:
- Adding the responder as a TDLS peer
- Creating a CTRL-EVENT / D-Bus broadcast message
The first of these proposals would add a TDLS peer, in the same
manner that an incoming TDLS discovery request creates a peer.
There are considerations here about how to maintain the lifetime
of the TDLS peer object, and how to make sure that these peer
objects don't form a nuisance (picture lots of gratuitous TDLS
discovery responses). For example, we'd probably want
only to create such a peer object if it came as the result of a TDLS
discovery request -- perhaps provisionally creating the peer at
the time the discovery request was sent.
The second proposal could move the entire concept of tracking
discovered TDLS peers over to the entity requesting them.
Since wpa_supplicant currently has not vested interest in outgoing
TDLS discovery (a TDLS setup does not require it), the right thing
to do might simply be to announce the TDLS discovery response
in a way that the D-Bus / control interface caller can see it and
track these potential peers separately.
Does anyone have a preference for one behavior over another
before we send an RFC patch up? We're currently leaning
towards the second of these behaviors, since this gets us past
the object lifetime issue.
More information about the Hostap