All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: iwd@lists.01.org
Subject: Re: [PATCH 1/2] anqp: refactor to use frame-xchg
Date: Thu, 28 May 2020 17:40:24 +0000	[thread overview]
Message-ID: <8995436a-a96b-ef56-b99a-0e2ac6f8d00a@gmail.com> (raw)
In-Reply-To: <9aa953f7148035150dbac69774703a763833603d.camel@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Hi James,

<snip>

>>>    
>>> -uint32_t anqp_request(uint32_t ifindex, const uint8_t *addr,
>>> +bool anqp_request(uint64_t wdev_id, const uint8_t *addr,
>>
>> See above for the likely reason why we had this return a uint32_t
>> originally.
> 
> I am kinda thinking this should be implemented in frame-xchg since
> cancellation doesn't even exist at this point. Then we can just give
> that ID directly to station and ANQP doesnt need to track it.
> 

I'm fine either way.  You could in theory do this in anqp.c for now and 
just use frame_xchg_stop for the ongoing operation.  But adding this 
directly too frame-xchg would be fine as well.

>> Do we currently send a single ANQP request per network?  If so, maybe
>> we
>> can drop this structure completely, by:
>>
>> 1. Adding network_get_station() getter if necessary
>> 2. Using the network object itself as the user_data for
>> station_anqp_response_cb
>> 3. Maybe storing pending inside network itself?
>>
>> The above would also make it easier to solve the issue of the user
>> triggering Connect just when ANQP hasn't been done yet...
> 
> The tricky part is that ANQP is directly tied to the scan results, so

Hm, how so?

> putting anything in network is difficult. We could have
> network_set_anqp_pending (or a better name), then if that was set and
> Connect() came in we would know to wait. But that would get ugly as
> station would need to detect that a Connect() came in (so another flag
> in network + getter) while waiting for ANQP and to re-issue the
> Connect() once ANQP completed.

Well, can't we just check if anqp is pending for the network inside 
network_connect() or so, and if it is, defer taking any action until 
anqp succeeds / fails?

If that is too complicated, then I guess we have to document that 
.Connect shouldn't be called until KnownNetwork property has been 
signaled and make our auto tests do this as well.

Regards,
-Denis

  reply	other threads:[~2020-05-28 17:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 20:45 [PATCH 1/2] anqp: refactor to use frame-xchg James Prestwood
2020-05-27 20:45 ` [PATCH 2/2] auto-t: work around race between ANQP and dbus Connect() James Prestwood
2020-05-28 15:53   ` Denis Kenzior
2020-05-28 15:42 ` [PATCH 1/2] anqp: refactor to use frame-xchg Denis Kenzior
2020-05-28 17:01   ` James Prestwood
2020-05-28 17:40     ` Denis Kenzior [this message]
2020-05-29 16:19       ` James Prestwood
2020-05-29 16:13         ` Denis Kenzior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8995436a-a96b-ef56-b99a-0e2ac6f8d00a@gmail.com \
    --to=denkenz@gmail.com \
    --cc=iwd@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.