TDLS Discovery support in wpa_supplicant

[Jouni Malinen]

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
upper layers.

> 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