On Fri, 2016-06-10 at 23:16 -0700, David Miller wrote:
> > Can I ask you to pull net into net-next, preferably before merging
> > this?
> Looks good, pulled, thanks!
Thanks! I see you also had pulled net in for other reasons, so I'll
include the hwsim namespace patch in the next pull request :)
I was about to apply this (with a typo fix for "responsile"), but
noticed these messages:
> printk(KERN_DEBUG "mac80211_hwsim: received a REGISTER, "
> "switching to wmediumd mode with pid %d\n", info-
> >snd_portid);
> + if (notify->portid ==
On Wed, 2016-06-15 at 14:37 +0200, Martin Willi wrote:
> >
> >
> > > printk(KERN_INFO "mac80211_hwsim: wmediumd released netlink"
> > > " socket, switching to perfect channel medium\n");
>
> > I wonder if we can do something better about them? Or perhaps if we
> > should remove them,
On Fri, 2016-05-13 at 12:41 +0200, Martin Willi wrote:
> A wmediumd that does not send this attribute causes a NULL pointer
> dereference, as the attribute is accessed even if it does not exist.
>
> The attribute was required but never checked ever since userspace
> frame
> forwarding has been
Hi Dave,
For now, I have just three fixes for the current cycle.
One of them, the hwsim one, becomes interesting with some pending
work to make hwsim work for unprivileged users in namespaces, and
I don't want to allow them to crash the system ... I'll thus wait
with that patch until you pull
> The requirement is to be __aligned(2). I've added 4 instances of
> ether_addr_copy with 8 addresses as arguments. Of these, the 4
> src arguments are really the same type (i.e. nla_data acting on a
> const nlattr*), so I'll try to reason about the 5 total cases below -
> 1. cfg->dst_mac should
On Mon, 2016-05-30 at 10:30 +1000, Julian Calaby wrote:
> Hi All,
>
> On Sun, May 29, 2016 at 1:30 PM, Kirtika Ruchandani
> wrote:
> >
> > This patch fixes the following checkpatch.pl warnings about
> > comments in nl80211.c :
> > - networking block comments don't
> - if (sta->mesh->fail_avg >= 100)
> - return MAX_METRIC;
> + /* try to get rate based on HW RC algorithm */
> + rate = drv_get_expected_throughput(local, >sta);
This doesn't look correct, since you should use the rate control op if
available, to get data from rate
On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote:
>
> (Actually, "::wifi" is super confusing, I'd expect that to be a led
> that blinks when wifi is active.)
Agree with that, yeah, that'd be confusing.
> Well... "airplane" is quite confusing. I'd we use "rfkill" for
> disabling radios, and
On Thu, 2016-06-23 at 14:12 +0300, Yaniv Machani wrote:
> Changed the configuration to support 64bit instead of 32bit
> this in order to offload the driver from handling a wraparound.
[...]
Since you Cc'ed me, and presumably want me to review it, I'll say that
this looks like a terrible idea:
>
> > Additionally, this looks like it changes the firmware API, so that
> > older firmware images will no longer work?
>
> It is backwards compatible,
> although it changes a API structure, older firmware are using only
> u16 for the field so there is no impact on that.
>
Oh, ok. I had also
On Thu, 2016-05-12 at 17:34 +0800, Wei-Ning Huang wrote:
>
> Johannes, I feel like being able to set calibration data at runtime
> is something common to all wireless drivers, so instead of using
> vendor commands what do you think if I pass the calibration data name
> instead of using those
On Wed, 2016-06-15 at 22:29 +0200, Arnd Bergmann wrote:
> When building a kernel with W=1, the nl80211.c file causes a number
> of
> warnings, all about the same problem:
>
> net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config':
> net/wireless/nl80211.c:5287:103: error: comparison is
On Sat, 2016-06-25 at 21:32 +0300, Jouni Malinen wrote:
>
> All you need to do is to prepare a hostap.git contribution that
> requests a new subcommand/attribute to be assigned and once that gets
> applied to the hostap.git master branch, the values have been
> assigned and can be used for
Hi Dave,
Another (pretty old) bug showed up, and I have a single fix for it
from Jouni; would be nice to still get it in, but it's in mesh which
seems to mostly have users who integrate everything themselves.
Let me know if there's any problem.
Thanks,
johannes
The following changes since
On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
>
> net/mac80211/mesh.c | 33 -
> net/mac80211/util.c | 3 ---
> net/wireless/mesh.c | 2 +-
That's not a good patch - one change is mac80211 and the other
cfg80211.
> - .ht_opmode =
On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> Some drivers (e.g. wl18xx) expect that the last stage in the
> de-initialization process will be stopping the beacons, similar to
> ap. Update ieee80211_stop_mesh() flow accordingly.
>
How well have
On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> In the reconfigure process for mesh interface, moved the
> reconfiguration
> of the mesh peers to be done only after restarting the beacons,
> the same as it is done for AP.
>
> Signed-off-by: Maital
Also - your subject lines should explain the *fix*, not the *bug*
johannes
On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote:
> From: Meirav Kama
>
> MP received data frames from another MP. Frames are forwarded
> from Rx to Tx to be transmitted to a third MP.
> Upon cloning the skb, the tx_info was zeroed, and the
> hw_queue wasn't set correctly,
On 2016-02-10 17:53, Dan Williams wrote:
Yeah, I get that now. It's just that to me, something called
"AIRPLANE_MODE_CHANGE" seems like it should actually change airplane
mode on/off, which implies killing radios. I wouldn't have had the
problem if it was named AIRPLANE_MODE_INDICATOR_CHANGE,
On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote:
> I'd like to clarify a bit, so tell me if I'm correct or not. Using
> RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> state. It's just an indicator with no relationship to any of the
> registered rfkill switches, right?
From: Johannes Berg <johannes.b...@intel.com>
In certain 802.11 wireless deployments, there will be NA proxies
that use knowledge of the network to correctly answer requests.
To prevent unsolicitd advertisements on the shared medium from
being a problem, on such deployments wireless needs t
From: Johannes Berg <johannes.b...@intel.com>
In order to solve a problem with 802.11, the so-called hole-196 attack,
add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
enabled, causes the stack to drop IPv6 unicast packets encapsulated in
link-layer multi- or
From: Johannes Berg <johannes.b...@intel.com>
In order to solve a problem with 802.11, the so-called hole-196 attack,
add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
enabled, causes the stack to drop IPv4 unicast packets encapsulated in
link-layer multi- or
From: Johannes Berg <johannes.b...@intel.com>
In certain 802.11 wireless deployments, there will be ARP proxies
that use knowledge of the network to correctly answer requests.
To prevent gratuitous ARP frames on the shared medium from being
a problem, on such deployments wireless needs t
On 2016-02-08 17:20, Marcel Holtmann wrote:
as explained in an earlier response, the concept Airplane Mode seems
to be imposing policy into the kernel. Do we really want have this as
a kernel exposed API.
This patch is the one that *solves* that problem ... please read it more
carefully?
On Thu, 2016-01-28 at 19:54 -0600, Larry Finger wrote:
>
> I have been running an RTL8821AE since kernel 3.18 without hitting
> this problem
> using a TRENDnet AC1750 dual-band AP. The UniFi may be doing
> something that the
> driver is not expecting.
Are you quite sure you're actually using
On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote:
>
> Upon further inspection, my log has the line "rtl8821ae :02:00.0
> wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that
> first.
>
Likely TKIP; enable only WPA2 (CCMP) on the AP.
johannes
On Thu, 2016-01-28 at 23:02 +0100, Arnd Bergmann wrote:
> On Thursday 28 January 2016 14:25:32 Troy Kisky wrote:
> > Signed-off-by: Troy Kisky
> > ---
> > drivers/net/ethernet/freescale/fec_main.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
On Thu, 2016-01-28 at 14:04 -0800, Linus Torvalds wrote:
>
> Well, it "makes a difference" in the sense that the warning goes
> away.
> But it doesn't make things work. In fact, it might be making things
> worse.
Heh, ok.
> Because with that patch, the wireless still authenticates and
>
On Thu, 2016-01-28 at 11:01 -0800, Linus Torvalds wrote:
>
> I used to have the basic original UniFi UAP. I've replaced them with
> the newer "AC Lite" version:
>
> https://www.ubnt.com/unifi/unifi-ap-ac-lite/
>
> so it's a fairly big jump from a 2.4GHz-only network to a dual-band
> one.
>
mac80211: clear local->sched_scan_req properly on reconfig
mac80211: handle sched_scan_stopped vs. hw restart race
Emmanuel Grumbach (1):
mac80211: fix PS-Poll handling
Helmut Schaa (1):
mac80211: Don't buffer non-bufferable MMPDUs
Johannes Berg (4):
mac80211: recal
On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote:
> .. except now I upgraded the nearest access point, and now wireless
> on that machine no longer works.
Can you describe the upgrade a bit more, just for background?
> Or rather, it actually *does* work in the sense that it
>
Hi,
Is there anything I should do about these patches?
I see you marked them as "deferred" in patchwork, but I don't really
know how you're using that state.
johannes
On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote:
>
> seems to work fine. I wish we could instantiate this from device-tree
> so we can finially get rid of this file.
That'd be nice - anyone want to propose rfkill DT bindings? :)
johannes
ather take the entire
series through your tree to get it into one place for Marc?
In which case, you have my
Acked-by: Johannes Berg <johan...@sipsolutions.net>
for the other 3 patches.
Let me know which you prefer.
johannes
On Wed, 2016-02-03 at 10:26 -0500, Josh Boyer wrote:
> On Wed, Feb 3, 2016 at 10:24 AM, Josh Boyer g> wrote:
> > Hi All,
> >
> > We've had a user report the backtrace below when loading batman-adv
> > on
> > his machine. It looks like the cfg80211 layer is
On Fri, 2016-01-29 at 11:35 +0300, Konstantin Khlebnikov wrote:
> Patch fixes this splat
>
> BUG: KASAN: slab-out-of-bounds in
> minstrel_ht_update_stats.isra.7+0x6e1/0x9e0
> [mac80211] at addr 8800cee640f4 Read of size 4 by task
> swapper/3/0
>
> Signed-off-by: Konstantin Khlebnikov
On Wed, 2016-02-24 at 13:14 +0100, Pavel Machek wrote:
>
> Why would it need to? It could look at default triggers for the led
> if it really wanted to.
And then it needs to change them; if anything goes wrong error recovery
is practically impossible since the trigger information is lost
On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote:
> If you want different trigger, implement different trigger. If you
> want to indicate all but wifi, implement all but wifi, and then
> userspace can select it by writing trigger name.
This is still mostly a strawman, since userspace
On Tue, 2016-02-23 at 15:45 +0100, Johannes Berg wrote:
> Hi Dave,
>
> Here's a (first, even? I didn't have much until before the
> conference...) pull request for net-next.
>
Hm, need to withdraw this, sorry about that. There appears to be some
compilation issue that I'm not
On Tue, 2016-02-23 at 22:45 +0100, Pavel Machek wrote:
> Well "the airplane mode" is well defined. It means no intentional
> transmitting at radio frequencies.
>
> The fact that you are allowed to use WIFI on certain flights does not
> change anything.
Nope, not that simple. Pick up any
critical protocol session upon disconnect event
Chris Bainbridge (1):
mac80211: fix use of uninitialised values in RX aggregation
Felix Fietkau (1):
mac80211: minstrel_ht: set default tx aggregation timeout to 0
Johannes Berg (2):
wext: fix message delay/ordering
cfg80211
On Fri, 2016-02-19 at 19:03 +0100, Thierry Reding wrote:
> On Thu, Feb 18, 2016 at 09:04:49PM +0100, Johannes Berg wrote:
> > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote:
> > > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
> > > >
> > >
On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote:
> So... you add LED trigger to display the state of the airplane
> mode. Ok, why not.
Yes. However, consider that "the airplane mode" isn't a well-defined
concept; some systems may want to light up that LED even when wifi is
still enabled,
On Tue, 2016-02-23 at 16:06 +0100, Arnd Bergmann wrote:
>
> Does rfkill always have a separate device in the Linux driver model?
Yes, the rfkill core code registers and adds one in the rfkill class.
> johannes
l function
Ilan Peer (1):
mac80211: Recalc min chandef when station is associated
Johannes Berg (8):
cfg80211: remove CFG80211_REG_DEBUG
mac80211: document status.freq restrictions
mac80211: refactor HT/VHT to chandef code
mac80211_hwsim: remove shadowing variable
def when station is associated
Johannes Berg (8):
cfg80211: remove CFG80211_REG_DEBUG
mac80211: document status.freq restrictions
mac80211: refactor HT/VHT to chandef code
mac80211_hwsim: remove shadowing variable
rfkill: disentangle polling pause and suspend
mac80
-by: Johannes Berg <johan...@sipsolutions.net>
---
drivers/net/ethernet/freescale/Makefile | 2 +
drivers/net/ethernet/freescale/fec.h | 39 ++---
drivers/net/ethernet/freescale/fec_main.c | 130 --
3 files changed, 99 insertions(+), 72 deletions(-)
diff
On Sat, 2016-01-23 at 23:09 +0100, Johannes Berg wrote:
>
> +/* buffer endianness appears to be a mess ... ARM is usually LE but
> can be BE */
> +#if defined(CONFIG_ARM) && defined(CONFIG_CPU_BIG_ENDIAN)
Just realized that this is, of course, completely wrong. If the ARM
On Mon, 2016-01-25 at 10:52 +1000, Greg Ungerer wrote:
>
> I tested this on a ColdFire (5208) target that uses this driver.
> Simple testing showed it working with no problems. The ColdFire
> SoC processors use a version of the FEC hardware module, and they
> always run big-endian.
>
Great,
not clear that the ifdef there really is correct and shouldn't
just be #ifdef CONFIG_ARM, but I also can't test on anything but the
i.MX6 HummingBoard where this gets it working with a BE kernel.
Signed-off-by: Johannes Berg <johan...@sipsolutions.net>
---
drivers/net/ethernet/freescale/Ma
CONFIG_ARM is safe for them.
Signed-off-by: Johannes Berg <johan...@sipsolutions.net>
---
drivers/net/ethernet/freescale/fec.h | 8 +++-
drivers/net/ethernet/freescale/fec_main.c | 3 +--
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h
b/d
From: Johannes Berg <johannes.b...@intel.com>
As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28
is wrong if some other ARM platform uses this device - the operation
of the driver would depend on an unrelated ARM platform that might
or might not be set for multi-platform k
On Tue, 2016-01-26 at 10:55 +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers WARNING message in rfkill_fop_read:
>
> [ cut here ]
> WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663
> __might_sleep+0x138/0x1a0()
> do not call blocking ops when
On Thu, 2016-01-21 at 11:06 +0530, Sunil Shahu wrote:
> Remove unnecessory "if" statement and club it with previos "if"
> block.
>
Applied.
johannes
Hi,
On Tue, 2016-01-19 at 10:42 -0500, João Paulo Rechi Vita wrote:
> This series contains a few general improvements to the RFKill code,
> found while
> I was writing the rfkill-all / airplane mode LED trigger. All were
> points where
> I had to read twice or do some other kind of extra effort
From: Johannes Berg <johannes.b...@intel.com>
Since cfg80211 frequently takes actions from its netdev notifier
call, wireless extensions messages could still be ordered badly
since the wext netdev notifier, since wext is built into the
kernel, runs before the cfg80211 netdev notifier. For e
From: Johannes Berg <johannes.b...@intel.com>
Beniamino reported that he was getting an RTM_NEWLINK message for a
given interface, after the RTM_DELLINK for it. It turns out that the
message is a wireless extensions message, which was sent because the
interface had been con
On Sun, 2016-01-24 at 17:49 +0100, Arnd Bergmann wrote:
> I'd argue that the "(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)"
> is definitely wrong, because if we ever get another ARM platform
> that uses this driver, it may or may not work depending on whether
> the ARCH_MXC is also set, and
On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote:
> On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
> >
> > Johannes, I assume that you'll want to take this through your tree
> > because of the dependency? In that case:
> >
> > Acked-by: Thierry R
On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
> This creates a new LED trigger to be used by platform drivers as a
> default trigger for airplane-mode indicator LEDs.
>
> By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
> for all types (RFKILL_TYPE_ALL),
Hi,
Sorry for the delay reviewing this.
On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
> Provide an interface for the airplane-mode indicator be controlled
> from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open
On Tue, 2016-03-01 at 17:11 -0500, David Miller wrote:
>
> There was a minor merge conflict with net/mac80211/debugfs.c, take
> a look and send me any fixups necessary.
>
Ah yes, I'd wondered when that change was coming in, but missed that
you had it in net-next now.
Looks good, thanks!
Hi,
> +struct macsec_rx_sa_stats {
> + __u32 InPktsOK;
> + __u32 InPktsInvalid;
> + __u32 InPktsNotValid;
> + __u32 InPktsNotUsingSA;
> + __u32 InPktsUnusedSA;
> +};
> +
> +struct macsec_tx_sa_stats {
> + __u32 OutPktsProtected;
> + __u32 OutPktsEncrypted;
> +};
Just
On Wed, 2016-03-09 at 11:51 +0100, Sabrina Dubroca wrote:
> > > +#define DEFAULT_CIPHER_NAME "GCM-AES-128"
> > > +#define DEFAULT_CIPHER_ID 0x008002000101ULL
> > > +#define DEFAULT_CIPHER_ALT 0x0080C2000101ULL
> >
> > > +enum macsec_attrs {
> > [...]
> > > + MACSEC_ATTR_CIPHER_SUITE,
Hi,
Thanks for the comments.
> > > +struct gcm_iv {
> > > + union {
> > > + u8 secure_channel_id[8];
> > > + sci_t sci;
> > > + };
> > > + __be32 pn;
> > > +};
> >
> > Should this be __packed?
>
> I think that's not necessary here.
Yeah, there's probably no way a compiler
On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote:
> If someone can fix rhashtable, then great.
> I read some earlier comments [1] back when someone else reported
> similar problems, and the comments seemed to indicate that rhashtable
> was broken in this manner on purpose to protect against
On Wed, 2016-04-06 at 11:20 +0300, Dmitrijs Ivanovs wrote:
> Hi Johannes!
>
> I will prepare patch which does not send NETLINK_URELEASE for unbound
> sockets as you suggest. But I think protocol check in nl80211 is
> still needed because port_id is unique per-protocol.
>
Yes, good point. Can
e them to stop reporting events, as if
NFULNL_CFG_CMD_UNBIND/NFQNL_CFG_CMD_UNBIND had been called.
Fix this problem by checking that the socket is bound before generating
the NETLINK_URELEASE notification.
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Ivanov <d...@ubnt.com>
Signed-off-by: J
> The patch was build-tested / debugged by removing the
> "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
Stands to reason that we should just remove the (more or less) dead
code, since I don't think anyone really ever touches this driver any
more or will ever again ...
johannes
Hi,
> + [ETHTOOL_ATTR_FLAGS]= { .type = NLA_U32 },
I suppose this comes from the current API, but perhaps it'd be
worthwhile to make provision for more flags? Perhaps even using
NLA_BINARY and have "infinitely extensible" flags.
> + [ETHTOOL_ATTR_SSET_COUNT] =
On Wed, 2016-04-06 at 15:25 +0200, Johannes Berg wrote:
> Hi Dave,
>
> For the 4.6 cycle, there's of course much more. The few things that
>
Err, -next, so that's 4.7.
johannes
tx support
mac80211: minstrel_ht: set A-MSDU tx limits based on selected
max_prob_rate
Johannes Berg (17):
wext: unregister_pernet_subsys() on notifier registration failure
mac80211: allow drivers to report CLOCK_BOOTTIME for scan results
mac80211: remove sta_info debugfs
multicast frames with queue control and txq
Ilan Peer (1):
mac80211: Fix BW upgrade for TDLS peers
Jeff Mahoney (1):
mac80211: fix "warning: ‘target_metric’ may be used uninitialized"
Johannes Berg (1):
mac80211: properly deal with station hashtable insert errors
Lu
On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote:
> Fix order of mac80211_rx_flags description to match the enum.
>
> Signed-off-by: Luis de Bethencourt
> ---
> Hi,
>
> I want ahead and fixed the order of the descriptions. checkpatch.pl
> was giving
> a
On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote:
> Use alloc_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is
> scheduled for removal.
Scheduled where?
> static void iwl_setup_deferred_work(struct iwl_priv *priv)
On Sun, 2016-03-20 at 14:55 -0400, Tejun Heo wrote:
> If everything else is working, I'd be happy to throw in
> WQ_MEM_RECLAIM but I really don't want to add it if it doesn't
> actually achieve the goal. Can a wireless person chime in here?
>
I think for many wireless devices the workqueue,
On Fri, 2016-03-04 at 15:35 -0800, Stephen Hemminger wrote:
>
> > There have been reports about 'ip addr' printing "Message
> > truncated" on
[...]
> I thought this was addressed in kernel by making the VF info
> optional.
> The netlink protocol is showing some strain, this is one of them.
I
On Wed, 2016-03-02 at 14:43 -0500, David Miller wrote:
> From: Bob Copeland
> Date: Wed, 2 Mar 2016 10:09:20 -0500
>
> > In the time since the mesh path table was implemented as an
> > RCU-traversable, dynamically growing hash table, a generic RCU
> > hashtable
On Wed, 2016-03-02 at 10:09 -0500, Bob Copeland wrote:
> In certain cases, the 802.11 mesh pathtable code wants to
> iterate over all of the entries in the forwarding table from
> the receive path, which is inside an RCU read-side critical
> section. Enable walks inside atomic sections by
On Sun, 2016-02-28 at 20:06 -0500, Bob Copeland wrote:
> In certain cases, the 802.11 mesh pathtable code wants to
> iterate over all of the entries in the forwarding table from
> the receive path, which is inside an RCU read-side critical
> section. Enable walks inside atomic sections by
On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>
> +typedef u64 codel_time_t;
Do we really need this? And if yes, does it have to be in the public
header file? Why a typedef anyway?
> - * @txq_ac_max_pending: maximum number of frames per AC pending in
> all txq
> - * entries for a
On Tue, 2016-03-01 at 00:39 +0200, Jouni Malinen wrote:
> > I agree there is a difference in the logic here,
Gah. I thought I'd reviewed the logic and made sure there's no
difference ... :)
> > thanks for taking the
> > time to point it out so clearly, and sorry for missing this. But AFAIU
> >
for it
Felix Fietkau (1):
mac80211: minstrel_ht: fix a logic error in RTS/CTS handling
Johannes Berg (2):
mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs
mac80211_hwsim: treat as part of mac80211 for MAINTAINERS
On Mon, 2016-03-07 at 18:12 +0100, Sabrina Dubroca wrote:
> +++ b/include/uapi/linux/if_macsec.h
Some bits of documentation in this file, regarding all the various
operations and attributes, might be nice. At least the netlink types?
E.g., given this:
> +#define DEFAULT_CIPHER_NAME
On Mon, 2016-03-07 at 18:12 +0100, Sabrina Dubroca wrote:
>
> +struct gcm_iv {
> + union {
> + u8 secure_channel_id[8];
> + sci_t sci;
> + };
> + __be32 pn;
> +};
Should this be __packed?
But the struct is confusing; sci_t is a host type (that depends on
On Fri, 2016-04-01 at 10:51 -0700, santosh shilimkar wrote:
> Hi Dave,
>
> I noticed something odd while checking the recent
> commits of mine in kernel.org tree made it via netdev.
>
> Don't know if its patchwork tool doing this.
> Usual author line in my git objects :
> Author: Santosh
On Fri, 2016-04-01 at 08:46 +0800, Herbert Xu wrote:
> On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote:
> >
> >
> > Does removing this completely disable the "-EEXIST" error? I can't
> > say
> > I fully understand the elasticity stuf
On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
>
> Having a common check makes sense. The tricky thing is that the type can
> only be checked after taking the reference, and I wanted to keep the
> scope of the prog brief in the case of errors. I would have to move the
> bpf_prog_get
On Sun, 2016-04-03 at 11:28 +0900, Lorenzo Colitti wrote:
> That said, getting BPF to the driver is part of the picture. On the
> chipsets we're targeting for APF, we're only seeing 2k-4k of memory
> (that's 256-512 BPF instructions) available for filtering code, which
> means that BPF might be
On Fri, 2016-03-18 at 16:09 +, Luis de Bethencourt wrote:
> Add documentation for the flag for duplication check.
>
> Fixes the following warning when running make htmldocs:
> warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum
> 'mac80211_rx_flags'
>
Applied, thanks.
johannes
Hi Dmitrijs,
Thanks for reporting this problem.
> The patch below corrects this problem in kernel space.
I don't think that this is correct, there are four more users of
NETLINK_URELEASE (nfnetlink, NFC), and afaict all of them have the same
bug as nl80211.
Rather than fix all of them, I
On Fri, 2016-03-18 at 19:23 +, Luis de Bethencourt wrote:
> Commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd")
> removed the member from the sta_info struct but the description
> stayed
> lingering. Remove it.
>
Also applied.
johannes
On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote:
> Looks like rhashtable has too much policy in it to properly deal with
> cases where there are too many hash collisions, so I am going to work
> on reverting it's use in mac80211.
I'm not really all that happy with that approach - can't we fix
On Wed, 2016-03-30 at 21:55 +0800, Herbert Xu wrote:
> Well to start with you should assess whether you really want to
> hash multiple objects with the same key. In particular, can an
> adversary generate a large number of such objects?
No, the only reason this happens is local - if you take
On Thu, 2016-03-31 at 08:13 -0700, Ben Greear wrote:
>
> I see insertion failure, and then later, if of course fails to delete
> as well since it was never inserted to begin with. There is no good
> way to deal with insertion error, so just need to fix the hashtable.
Oh, that's an oversight in
On Thu, 2016-03-31 at 15:50 +0800, Herbert Xu wrote:
> On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote:
> >
> >
> > In this case, I think perhaps you can just patch your local system
> > with
> > the many interfaces connecting to the same AP
On Fri, 2016-04-01 at 18:21 -0700, Brenden Blanco wrote:
> +static int mlx4_bpf_set(struct net_device *dev, int fd)
> +{
[...]
> + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) {
> + bpf_prog_put(prog);
> + return -EINVAL;
> + }
> +
801 - 900 of 1516 matches
Mail list logo