On Tue, 2018-10-09 at 17:40 +0300, Lior David wrote: > Thanks for the explanation. The send to same socket does sound more efficient. > (In our internal implementation with vendor commands we were forced > to send the results as broadcast...) I suppose we can fix that, in the sense that we can add API to allow vendor commands to know the socket to send back to etc. > Yes as far as I remember rtt<->distance is a trivial calculation. What I meant > here, you return the average of few measurements done in a burst, and for > debugging we could return all the measurements done in the burst. For example if > there were 4 measurements per burst return the 4 distance measurements done. Ah, OK. I guess you'd have to report separate measurements or something. Though if it's for debugging I'd think it may not make sense in this API but rather something out-of-band. > I meant we could have an AoA value (angle in degrees or other units) which > drivers can fill up if they want. For example if the driver has 2 antennas on > both sides it can report either 90 or 270 degrees. It will be usually very low > accuracy but at least can provide some information like from which side of the > AP you are. This can certainly be added later if at all (hopefully we will have > AoA measurement with higher accuracy in the future) Yeah, ok, I get it now - I guess we can add it if somebody plays with it and finds how to obtain and use the value. > > > For connected station, usually you will want to do the measurement on the > > > connected channel (possibly some chips will not be able to do otherwise) > > > Maybe add option to use default channel? > > > > Perhaps. It's somewhat complicated to look up in general, userspace > > generally has a decent idea, and making it optional means you end up > > with an invalid chandef? > > > > I'll take a look, perhaps just leaving all the fields 0/NULL can work > > reasonably well, but drivers would have to support it. > > > > As I remember the driver/FW can easily find the connected channel for connected > station. For unconnected station we should probably force this parameter. Should be able to, yes, but I suppose even userspace can. It just seems like extra complexity to impose on the driver, since cfg80211 doesn't necessarily have all the right information. Actually, hmm, that would imply "use maximum bandwidth" or something? And then what if that bandwidth isn't possible with FTM for some reason? It's a bit tricky then. > > If so, that sounds like something that generally needs improvement? > > > > Good point. I see we currently use 20_NOHT for DMG, guess we can continue using it. Well, I think it'd make more sense to just enforce the DMG bandwidth everywhere, but I won't force the issue over this. > Ok I thought 15 meant to actually request 65535 bursts :-) > I still prefer the default to be 1 burst. Supporting the "no preference" means > it will be difficult to pre-allocate memory for burst results. Also all drivers > should know to do one burst. Fair, I'll change it. johannes
