Questions Regarding ANQP Fetch

[Shyam]

Hi Jouni,
Is ANQP information consumption limited to wpa_supplicant? I thought that
any client could read the ANQP information through BSS command?
Is this understanding correct.?

On Monday, March 24, 2014, Shyam <shyamms2003 at gmail.com> wrote:

> Thanks Jouni for your reply.
> Okay, Its a bit clear now..However I am curious to know one thing from
> your reply:
> Is ANQP information consumption limited to wpa_supplicant? I thought that
> the client could read the ANQP information through BSS command?
>
> Thanks,
> Shyam
>
> > As I understand from the code the ANQP fetch is supported by 2 commands
> >  1. FETCH_ANQP- To Fetch ANQP information from all the BSSIDs.
> >  2. ANQP_GET- Fetch BSSID for a single BSSID.
> > Now what was interested to see is that the FETCH_ANQP banks upon the
> > in-memory cache maintained in the BSS structure. If the wifi is turned
> > on-off or when the BSS flush happens this cache is cleared and hence we
> > loose the data. Was there any reason why you didnt think about writing
> the
> > anqp information into a file/DB in which case the data would be available
> > upon state resets?
>
> I'm not sure whether any ANQP information should really be expected to
> remain constant and since there is no other way of confirming its
> current validity apart from fetching it again, I don't see much point in
> storing it to a file. The BSS table should not really be flushed during
> normal operation, so the information there remains valid as long as the
> AP is in range (and then for three minutes, by default, after that to
> avoid temporary out-of-range state dropping an entry).
>
> > Were you suggesting that clients read ANQP information from the BSS
> command
> > and they cache it?
>
> No.
> Okay, so the
> What type of ANQP information are you thinking of here and what is the
> justification in assuming it to remain static for longer periods of
> time?
>
> > in-memory cache maintained in the BSS structure. If the wifi is turned
> > on-off or when the BSS flush happens this cache is cleared and hence we
> > loose the data. Was there any reason why you didnt think about writing
> the
> > anqp information into a file/DB in which case the data would be available
> > upon state resets?
>
> I'm not sure whether any ANQP information should really be expected to
> remain constant and since there is no other way of confirming its
> current validity apart from fetching it again, I don't see much point in
> storing it to a file. The BSS table should not really be flushed during
> normal operation, so the information there remains valid as long as the
> AP is in range (and then for three minutes, by default, after that to
> avoid temporary out-of-range state dropping an entry).
>
> > Were you suggesting that clients read ANQP information from the BSS
> command
> > and they cache it?
>
> No.
>
> What type of ANQP information are you thinking of here and what is the
> justification in assuming it to remain static for longer periods of
> time?
>
>
>
> On Thu, Mar 20, 2014 at 11:09 PM, Shyam <shyamms2003 at gmail.com<javascript:_e(%7B%7D,'cvml','shyamms2003 at gmail.com');>
> > wrote:
>
>> Hi Jouni,
>>> As I understand from the code the ANQP fetch is supported by 2 commands
>>>
>>  1. FETCH_ANQP- To Fetch ANQP information from all the BSSIDs.
>>  2. ANQP_GET- Fetch BSSID for a single BSSID.
>> Now what was interested to see is that the FETCH_ANQP banks upon the
>> in-memory cache maintained in the BSS structure. If the wifi is turned
>> on-off or when the BSS flush happens this cache is cleared and hence we
>> loose the data. Was there any reason why you didnt think about writing the
>> anqp information into a file/DB in which case the data would be available
>> upon state resets?
>> Were you suggesting that clients read ANQP information from the BSS
>> command and they cache it?
>>
>> Pls share your thoughts?
>>
>> Thanks
>> Shyam
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20140326/dbfaa3d8/attachment.htm>