| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Jay, I would assume, perhaps wrongly, that the probe requests in Joe’s wording are directed probe requests since he talks about probe requests and association requests to a known AP. Undirected probe requests would operate as normal with random MAC addresses. I don’t see why the non-AP STA would be inhibited from issuing undirected probe requests and discovering that no APs are responding. Kind regards, -Peter From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> Hi All, I agree Dan’s comment, such proposal will cause the UI frozen issue, which is already know for more than 10 years. You can image a scenario like this: an end user may move from an open place to a shield room. The original WIFI connection will suddenly disconnect, and the STA will try to send probe to find new APs. The probe inhibition proposal makes the end user thought other APs are still available due to no flash on the UI, the end user may try to connect other APs shown in the UI but not exist indeed. Thanks Best Regards Jay Yang From: Harkins, Dan <daniel.harkins@xxxxxxx> Another thing*… how is this going to be explained to the user? It's gonna have to be on a per-profile basis because there's some SSIDs you might want to roam to regardless of what the location is, think of "xfinity" or "boingo" if you had such a service, or "ieee" or "marriot_guest" if you attend 802.11 meetings. "Check this box if you want to restrict access to geographically specific APs". "Huh?", said Joe Random. Then imagine the debugging issues when Joe Random calls the Boingo IT helpline because he's paying all this money and it doesn't work. regards, Dan. * yea, I don't work for a STA vendor but I keep hearing people who do complain about this or that feature because their UI is getting cluttered and confusing. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 8/18/22, 1:43 PM, "Luther Smith" <l.smith@xxxxxxxxxxxxx> wrote: Joseph and All, It seems to be confusing in the later part: “This mechanism should allow the non-AP STA to limit its transmission of Probes Requests and Association Requests to a known AP to a location where the known AP is actually present (i.e., not to a spoofed AP). “ Based on the text it appears that the non-AP STA will be able to limit Probes Requests and Association Request to a known AP and it is linked to the location of the AP. Could this be read that if the known AP is at a different location the non-AP STA does not have the mechanism limit the messages? As well we may not want to link the AP location (use case would be a mobile AP). Maybe the following: This mechanism should allow the non-AP STA to limit its transmission of Probes Requests and Association Requests to an AP which appears to be known to the non-AP STA; however, is not the actual known AP. (i.e., not to a spoofed AP). Cheers, Luther From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> Love it. My excuse is that I obviously have not understood the BPE/CPE concept. Thanks Joe, Graham From: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx> Hi Graham and All, A couple questions/comments: 1) Graham what was your motivation to restrict this mechanism to a BPE AP? I don’t think it is a necessary restriction. 2) I think the proposed requirement could be more clearly stated so the privacy advantage is clearer, how about: Regards, Joseph From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> Thank you for the comments and feedback on 22/1253r0 on the subject of protection against a Spoof AP. I am considering proposing the following text for insertion into 21/1848 Requirements document: • 11bi shall define a mechanism for a BPE AP to be identified such that a BPE Client can confirm that the AP is not a spoof AP. Hence, the BPE Client will not send an Association Request and reveal its presence. I welcome any suggestions or comments Thanks Graham To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 |