TDLS Discovery support in wpa_supplicant
j at w1.fi
Fri Apr 3 04:12:49 EDT 2015
On Mon, Mar 30, 2015 at 09:14:35AM -0700, Paul Stewart wrote:
> 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.
I'm not actually sure why Discovery Request processing adds a peer
entry.. Before checking the source code, I would have assumed it didn't.
> 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.
Unless there is a clearly identified use for this entry within
wpa_supplicant, I wouldn't add an entry here (and might even consider
removing it from Discovery Request processing).
> 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.
It's certainly fine to add event messages to report the response to
> 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.
I'd agree with that approach.
Jouni Malinen PGP id EFC895FA
More information about the HostAP