Hi.
When doing iw dev wlan0 set noack_map 0x0009, frames are sent with
Ack Policy set to No Ack (at QoS header), receiver don't ack those
frames and I guess that minstrel_ht falls to lowest bitrate possible
or it is disabled when iw command is executed. At this point, manually
setting a
If it is the case that the 4-way handshake fails, then I have seen this
issue before. The problem is that messages 1 to 4 are sent with the
previous key. However, right after sending message 4/4, does
wpa_supplicant set the new key. In some cases, such as in a high
throughput environment, this
On Mon, Feb 23, 2015 at 11:55:30AM +0100, wim torfs wrote:
If it is the case that the 4-way handshake fails, then I have seen
this issue before. The problem is that messages 1 to 4 are sent with
the previous key. However, right after sending message 4/4, does
wpa_supplicant set the new key. In
On Fri, Feb 20, 2015 at 6:47 PM, ap420073 . ap420...@gmail.com wrote:
hostapd 2.3 has no problem but i found problem that hostapd is not
starting in hostapd 1.0.
would you like to try testing hostapd 2.3?
Unfortunately v2.3 has the some problem. After a few cycles of
/etc/init.d/hostapd stop
On Mon, 2015-02-23 at 21:57 +0800, Rohan Joyce wrote:
This patch adds a command NL80211_CMD_GET_TSF that retrieves the 64 bit time
synchronisation value for an interface. It returns the value in a uint64
attribute of type NL80211_ATTR_TSF.
This should explain why and how this could possibly be
The # flag in %X means print a 0X prefix. Remove the extra 0x prefix.
Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
---
The file uses a mix of explicit 0x prefixes and # flags, as well as a
mix of %x and %X, so it's not clear what the most consistent choice
would be.
This patch adds a command NL80211_CMD_GET_TSF that retrieves the 64 bit time
synchronisation value for an interface. It returns the value in a uint64
attribute of type NL80211_ATTR_TSF.
Signed-off-by: Rohan Joyce rojoyce.git...@gmail.com
---
include/net/cfg80211.h | 6 ++
On Tue, 2015-02-17 at 15:59 -0800, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
The goal is to allow the user-space application to properly
filter packets before sending them down to the kernel. This
should more closely mimic what a real piece of hardware would
Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
was only able to use the second mac address (those starting with
0x42). This is confusing and needlessly limiting, so allow any
configured address.
While at it, use ether_addr_equal since data-addresses and the
address from the netlink
Hi,
The motivation for this patch is to assist using a WiiU Gamepad with Linux.
The WiiU Gamepad is an input device that also contains an LCD touchscreen,
speakers and a variety of sensors. The Gamepad connects to an access
point (usually the WiiU console itself, but it can be coerced to connect
In addition to what Arend said,
@@ -4263,7 +4263,8 @@ struct sk_buff *__cfg80211_alloc_event_skb(struct wiphy
*wiphy,
enum nl80211_commands cmd,
enum nl80211_attrs attr,
Hello there,
[linux-4.0-rc1/drivers/net/wireless/ath/wil6210/debugfs.c:634]: (error) Width 8
given in format string (no. 1) is larger than destination buffer 'cmd[8]', use
%7s to prevent overflowing it.
This looks like an off-by-one error to me.
Suggest either make the buffer bigger, to
On Mon, 2015-01-26 at 11:58 +0200, Jouni Malinen wrote:
If you need to distinguish, you should be able to advertise P2P-Device
supports, and then get P2P scans on the P2P-Device virtual interface.
Could be a pure driver thing of course.
It would be unfortunate to force people to use
On Fri, 2015-02-13 at 14:13 -0800, Ben Greear wrote:
Oooh, maybe finally time to mix local addr with peer addr to
make lots of vifs connected to same AP hash well too? :)
As we discussed before, mixing it in isn't actually possible. Your patch
will get easier to maintain (if you also convert
On 02/23/2015 08:08 AM, Johannes Berg wrote:
On Tue, 2015-02-10 at 10:25 -0800, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
Otherwise, skb is not cleaned up until there is some timeout
and the tx-queue quickly becomes overly full.
+++
On Thu, 2015-02-19 at 15:42 -0600, James Minor wrote:
+#define CHECK_BUF_FULL(p, c, e) \
+ do { \
+ if (unlikely(p == c)) \
+ e = -E2BIG;\
+ } while (0)
I think this would be
On Tue, 2015-02-10 at 10:25 -0800, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
Otherwise, skb is not cleaned up until there is some timeout
and the tx-queue quickly becomes overly full.
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -928,10 +928,14 @@ static
On Sat, 2015-02-14 at 05:14 +0300, Sergey Ryazanov wrote:
A nice change! Couple of years ago I did some tests with real sets of
MACs and jhash gives a better distribution than usage of a last octet.
BTW, why do you use full address and generic jhash? Hashing of two
least significant words
On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote:
Nope, everything else I have seems to be intel wireless. I think one
of the kids machines is a Mac Mini with an ath5k thing, but I'm hoping
the wpa_supplicant.log is sufficient to give somebody an idea.
It looks like there are two
On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote:
Ok. Attached is what seems to be the relevant part of the
wpa_supplicant.log file.
The datestamp has been changed so that it can be matched up with the
dmesg, and I added empty lines for pauses when I was trying to figure
out
2015-02-23 19:33 GMT+03:00 Johannes Berg johan...@sipsolutions.net:
On Sat, 2015-02-14 at 05:14 +0300, Sergey Ryazanov wrote:
A nice change! Couple of years ago I did some tests with real sets of
MACs and jhash gives a better distribution than usage of a last octet.
BTW, why do you use full
On Mon, Feb 23, 2015 at 12:06:09PM -0800, Linus Torvalds wrote:
On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi wrote:
mac80211: Do not encrypt EAPOL frames before peer has used the key
Hmm. This patch does not seem to make a difference. I thought it did
at first, but then removed
On Fri, Feb 20, 2015 at 2:58 AM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
Hi Johannes,
The BW tracking feature in mac80211 is causing connection problems and
operating mode/bw problems when switching
Daniele Alessandrelli daniele.alessandre...@gmail.com writes:
Fix all checkpatch braces {} are not necessary warnings for
rtl8723au/hal/rtl8723a_hal_init.c
Signed-off-by: Daniele Alessandrelli daniele.alessandre...@gmail.com
---
drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 40
On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi wrote:
mac80211: Do not encrypt EAPOL frames before peer has used the key
Hmm. This patch does not seem to make a difference. I thought it did
at first, but then removed the wpa_supplicant debugging, and got the
same failures.
On Sun,
On Mon, Feb 23, 2015 at 12:06 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
This machine has a fairly minimal kernel config. Does that type
monitor interface perhaps need some debug infrastructure that I
haven't added?
Nope. Same behavior with a F21 kernel (which means that the
+/**
+ * cfg80211_vendor_event_alloc_ext - allocate vendor-specific event
+skb
+ * @wiphy: the wiphy
+ * @event_idx: index of the vendor event in the wiphy's vendor_events
+ * @approxlen: an upper bound of the length of the data that will
+ * be put into the skb
+ * @gfp: allocation
On Tue, 2015-02-24 at 00:26 +0300, Sergey Ryazanov wrote:
Well - not sure what you're trying to say? First you're saying jhash()
was clearly better and then you're saying I shouldn't use it? ;-)
In first case, I mean the jhash _algorithm_, which has a better
distribution, in second case I
On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote:
How far is the station from the AP? Would it be possible to see whether
the behavior changes if you were within, say, five meters or so?
Well, it was pretty much within five meters already, but there was a
thin wall in between
On Mon, 2015-02-23 at 22:52 +0100, Johannes Berg wrote:
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
return jhash_3words(a[0], a[1], a[2], seed);
}
Or better do
On Mon, 2015-02-23 at 23:01 +0100, Johannes Berg wrote:
On Mon, 2015-02-23 at 22:52 +0100, Johannes Berg wrote:
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
From: Johannes Berg johannes.b...@intel.com
We currently have a hand-rolled table with 256 entries and are
using the last byte of the MAC address as the hash. This hash
is obviously very fast, but collisions are easily created and
we waste a lot of space in the common case of just connecting
as a
2015-02-24 1:07 GMT+03:00 Johannes Berg johan...@sipsolutions.net:
On Mon, 2015-02-23 at 23:01 +0100, Johannes Berg wrote:
On Mon, 2015-02-23 at 22:52 +0100, Johannes Berg wrote:
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void
On 23 February 2015 at 13:53, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote:
How far is the station from the AP? Would it be possible to see whether
the behavior changes if you were within, say, five meters or so?
Well, it
Err, well, I need to rebase this patch on the changed rhashtable APIs in
net-next :) WIP.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 23, 2015 at 02:22:32PM -0800, Adrian Chadd wrote:
On 23 February 2015 at 13:53, Linus Torvalds
torva...@linux-foundation.org wrote:
So the theory that the driver starts at too high a transmit rate, and
then does not handle failures well, might be true. Of course, not
handle
On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi wrote:
This did not get exactly supportive response when this was proposed last
time (Sep 2013). Anyway, for a quick test, this can be done with the
following one-liner:
fwiw, that one-liner seems to work fine for me.
Which I guess is
Jouni Malinen wrote:
Even I think that this goes a bit too far especially on 2.4 GHz band,
but I would actually consider limiting EAPOL frames to using non-HT/VHT
(e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some
interoperability issues. I would say that the current minstrel_ht
(sorry to send HTML the first time... oops)
Over the weekend I found a bug in minstrel-ht that might well be
implicated here.
The last retransmit rate is meant to be a 'get the packet there
reliably' rate; minstrel-ht doesn't do that right, and can pick a
fairly flaky rate instead.
Can't
From: Johannes Berg johannes.b...@intel.com
When changing AP SMPS, we need to look up all the stations for this
interface, so there's no reason to iterate over hash chains rather than doing
the simpler iteration over the station list.
Yup - thank you for that.
I remember I tried to find a
On Mon, Feb 23, 2015 at 03:00:39PM -0800, Linus Torvalds wrote:
On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi wrote:
This did not get exactly supportive response when this was proposed last
time (Sep 2013). Anyway, for a quick test, this can be done with the
following
From: Johannes Berg johannes.b...@intel.com
We currently have a hand-rolled table with 256 entries and are
using the last byte of the MAC address as the hash. This hash
is obviously very fast, but collisions are easily created and
we waste a lot of space in the common case of just connecting
as a
From: Johannes Berg johannes.b...@intel.com
There's no need for the second conditional as the same will be
done immediately afterwards if there's no station assigned.
Remove the useless conditional, move fallback assignment into
the else branch and don't try to look up a multicast address
which
From: Johannes Berg johannes.b...@intel.com
When changing AP SMPS, we need to look up all the stations
for this interface, so there's no reason to iterate over
hash chains rather than doing the simpler iteration over
the station list.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
44 matches
Mail list logo
