From: Johannes Berg <johannes@sipsolutions.net>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] IBSS network crashes after one device leaves network
Date: Mon, 20 Oct 2014 21:29:16 +0200 [thread overview]
Message-ID: <1413833356.32358.4.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <54455DDF.50305@rempel-privat.de> (sfid-20141020_211003_234775_62CEB57E)
On Mon, 2014-10-20 at 21:09 +0200, Oleksij Rempel wrote:
> Hi Johannes,
>
> since this function was added by you, may be you can help here (commit
> f09603a259). ath9k_htc support max 8 STAs in AP or ADHOC mode. If more
> then 8 stations connected, driver will return error, but
> sta_info_insert_drv_state() setting it to zero.
> What was initial purpose of this?
The reason for this is that it's pointless to do anything else - the
station will try to communicate with us since there's no protocol that
allows rejecting the link. We therefore don't fail here, and try to
communicate with the station anyway - that might end up with not having
proper rate scaling etc. but is still better.
johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Oleksij Rempel <linux@rempel-privat.de>
Cc: "Li, Hongchun" <lihongchun@cn.fujitsu.com>,
"(ath9k-devel@lists.ath9k.org)" <ath9k-devel@lists.ath9k.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [ath9k-devel] IBSS network crashes after one device leaves network
Date: Mon, 20 Oct 2014 21:29:16 +0200 [thread overview]
Message-ID: <1413833356.32358.4.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <54455DDF.50305@rempel-privat.de> (sfid-20141020_211003_234775_62CEB57E)
On Mon, 2014-10-20 at 21:09 +0200, Oleksij Rempel wrote:
> Hi Johannes,
>
> since this function was added by you, may be you can help here (commit
> f09603a259). ath9k_htc support max 8 STAs in AP or ADHOC mode. If more
> then 8 stations connected, driver will return error, but
> sta_info_insert_drv_state() setting it to zero.
> What was initial purpose of this?
The reason for this is that it's pointless to do anything else - the
station will try to communicate with us since there's no protocol that
allows rejecting the link. We therefore don't fail here, and try to
communicate with the station anyway - that might end up with not having
proper rate scaling etc. but is still better.
johannes
next prev parent reply other threads:[~2014-10-20 19:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-18 7:46 [ath9k-devel] IBSS network crashes after one device leaves network Li, Hongchun
2014-10-18 10:01 ` [ath9k-devel] ath9k-htc: " Oleksij Rempel
2014-10-20 2:00 ` Li, Hongchun
2014-10-20 19:09 ` [ath9k-devel] " Oleksij Rempel
2014-10-20 19:09 ` Oleksij Rempel
2014-10-20 19:29 ` Johannes Berg [this message]
2014-10-20 19:29 ` Johannes Berg
2014-10-21 13:56 ` Oleksij Rempel
2014-10-21 13:56 ` Oleksij Rempel
2014-12-24 2:45 ` Melroy van den Berg
2014-12-24 16:46 ` Oleksij Rempel
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=1413833356.32358.4.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ath9k-devel@lists.ath9k.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.