Re: [PATCH v2] mac80211: add assoc beacon timeout logic

On Mon, 2013-11-11 at 10:56 -0600, Felipe Contreras wrote:

On Mon, Nov 11, 2013 at 10:53 AM, Felipe Contreras
[off-list ref] wrote:

quoted

On Mon, Nov 11, 2013 at 10:41 AM, Johannes Berg
[off-list ref] wrote:

quoted

On Mon, 2013-11-11 at 10:23 -0600, Felipe Contreras wrote:

quoted

quoted

quoted

quoted

This isn't really true like I said above - the kernel can only drop the
association, if userspace *insists* then it will try again and again.

But it's not doing this:

  ieee80211_destroy_assoc_data(sdata, false);
  cfg80211_assoc_timeout(sdata->dev, bss);

Which is what causes the association to stop for me.

So where exactly in the code is the association being "dropped"?

This does get called in my setup.

Yes, because your setup is receiving beacons.

Check the code:

if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
   ieee80211_do_assoc(sdata)) {
struct cfg80211_bss *bss = ifmgd->assoc_data->bss;

ieee80211_destroy_assoc_data(sdata, false);
cfg80211_assoc_timeout(sdata->dev, bss);
}

If there's no beacon, cfg80211_assoc_timeout() is not called.

I'm sure if you don't call ieee80211_rx_mgmt_beacon() at all you will
see the same behavior I see.

My bad, actually the code that is not being called is:

  cfg80211_unlink_bss(local->hw.wiphy, assoc_data->bss);

In ieee80211_do_assoc().

That's not really interesting though, it just deletes the scan entry. If
it was deleted, then the supplicant would just scan again and probably
retry the connection.

johannes