On Sat, Aug 13, 2016 at 2:18 PM, Arran Cudbard-Bell <a.cudbardb@xxxxxxxxxxxxxx> wrote: >> On 11 Aug 2016, at 08:35, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: >> >> >>> +##### Client Taxonomy ######################################################### >>> +# >>> +# Has the AP retain the Probe Request and Association Request MLME frames from >>> +# a client, from which a signature can be produced which can identify the model >>> +# of client device like "Nexus 6P" or "iPhone 5s" >>> +# client_taxonomy=1 >>> >> This being a fairly niche feature, perhaps it should get a build time >> option so the code can be excluded? Even things almost everybody wants >> like 11N have build time options, and this one seems to be much more >> likely to not be desired in all builds. Thoughts? > > I think the techniques Avery described in his presentation (https://www.youtube.com/watch?v=yZcHbD84j5Y) are equally useful in Education, Enterprise and Carrier deployments and are not at all niche. > > If signature definitions were bundled, and the determination/confidence info were inserted into an attribute like Connect-Info (or a hostapd VSA - I’m sure Alan DeKok will comment on appropriate attribute usage), you’d see very widespread adoption and use. It’d represent an ultra low barrier to the sort of analysis Google are doing on their ISP network. > > If there’s interest, and the Client Taxonomy patches go in, we (FreeRADIUS) would definitely be up for submitting patches to add RADIUS support. > > -Arran > > Arran Cudbard-Bell <a.cudbardb@xxxxxxxxxxxxxx> > FreeRADIUS Development Team > > FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 The signature database we've assembled is available: https://gfiber.googlesource.com/vendor/google/platform/+/master/taxonomy/wifi.py We intend to extract it out of the git repository it is currently in (shared with a number of other tools we use) and into a github repo of its own. That would let signature submissions be handled as pull requests. We also need to revamp how it gets its inputs. Previously we had hostapd writing directly to files, the current signature lookup code expects to use those files. However using it from hostapd at the time of sending the RADIUS report would be challenging. A number of the signatures supplement the information from the MLME frames with information from DHCP, and the DHCP exchange happens later. We talk about this in the paper https://arxiv.org/pdf/1608.01725v1.pdf in sections labelled "Supplemental Information" about OUIs and DHCP. There are a number of signatures where we could switch from DHCP to rely on OUIs, but some of the important ones would be difficult. For example we use the DHCP signature of iOS for the various Apple devices. Apple's production volume is such that they consume OUIs every couple weeks, faster than we can keep up. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
