[PATCH] nl80211: increase the max number of rules in regdomain

[PATCH] nl80211: increase the max number of rules in regdomain

[Arik Nemtsov]

Some network cards (Intel) produce per-channel regdomains and rely on
cfg80211 to merge rules as needed. This hits the max rules limit and
fails.

Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
---
 include/uapi/linux/nl80211.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index c0383e9..18cb0aa 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2112,7 +2112,7 @@ enum nl80211_attrs {
 
 #define NL80211_MAX_SUPP_RATES			32
 #define NL80211_MAX_SUPP_HT_RATES		77
-#define NL80211_MAX_SUPP_REG_RULES		32
+#define NL80211_MAX_SUPP_REG_RULES		64
 #define NL80211_TKIP_DATA_OFFSET_ENCR_KEY	0
 #define NL80211_TKIP_DATA_OFFSET_TX_MIC_KEY	16
 #define NL80211_TKIP_DATA_OFFSET_RX_MIC_KEY	24
-- 
1.9.1

Re: [PATCH] nl80211: increase the max number of rules in regdomain

[Johannes Berg]

On Wed, 2014-12-17 at 18:00 +0200, Arik Nemtsov wrote:
> Some network cards (Intel) produce per-channel regdomains and rely on
> cfg80211 to merge rules as needed. This hits the max rules limit and
> fails.

Maybe we should consider just getting rid of this or bumping it to
something ridiculously large like 1000? Looking at how this is (not)
used, there's no real sense in limiting it. The only possible problem is
the O(n^2) complexity when doing an intersection, but processing a
million combinations is probably not a big deal? In fact, even if that
becomes a problem, we can easily optimise that complexity away by
sorting the rules or so. Then it becomes O(n log n)...

johannes

Re: [PATCH] nl80211: increase the max number of rules in regdomain

[Johannes Berg]

On Thu, 2014-12-18 at 14:56 +0100, Johannes Berg wrote:
> On Wed, 2014-12-17 at 18:00 +0200, Arik Nemtsov wrote:
> > Some network cards (Intel) produce per-channel regdomains and rely on
> > cfg80211 to merge rules as needed. This hits the max rules limit and
> > fails.
> 
> Maybe we should consider just getting rid of this or bumping it to
> something ridiculously large like 1000? Looking at how this is (not)
> used, there's no real sense in limiting it. The only possible problem is
> the O(n^2) complexity when doing an intersection, but processing a
> million combinations is probably not a big deal? In fact, even if that
> becomes a problem, we can easily optimise that complexity away by
> sorting the rules or so. Then it becomes O(n log n)...

For now I'll apply this anyway though.

johannes

Re: [PATCH] nl80211: increase the max number of rules in regdomain

[Arik Nemtsov]

On Thu, Dec 18, 2014 at 3:56 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2014-12-17 at 18:00 +0200, Arik Nemtsov wrote:
>> Some network cards (Intel) produce per-channel regdomains and rely on
>> cfg80211 to merge rules as needed. This hits the max rules limit and
>> fails.
>
> Maybe we should consider just getting rid of this or bumping it to
> something ridiculously large like 1000? Looking at how this is (not)
> used, there's no real sense in limiting it. The only possible problem is
> the O(n^2) complexity when doing an intersection, but processing a
> million combinations is probably not a big deal? In fact, even if that
> becomes a problem, we can easily optimise that complexity away by
> sorting the rules or so. Then it becomes O(n log n)...

Well when someone does NL80211_CMD_GET_REG from usermode, we send the
entire regdom in a single message, so 1000 rules may become
problematic..

Arik

Re: [PATCH] nl80211: increase the max number of rules in regdomain

[Johannes Berg]

On Thu, 2014-12-18 at 15:59 +0200, Arik Nemtsov wrote:
> On Thu, Dec 18, 2014 at 3:56 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2014-12-17 at 18:00 +0200, Arik Nemtsov wrote:
> >> Some network cards (Intel) produce per-channel regdomains and rely on
> >> cfg80211 to merge rules as needed. This hits the max rules limit and
> >> fails.
> >
> > Maybe we should consider just getting rid of this or bumping it to
> > something ridiculously large like 1000? Looking at how this is (not)
> > used, there's no real sense in limiting it. The only possible problem is
> > the O(n^2) complexity when doing an intersection, but processing a
> > million combinations is probably not a big deal? In fact, even if that
> > becomes a problem, we can easily optimise that complexity away by
> > sorting the rules or so. Then it becomes O(n log n)...
> 
> Well when someone does NL80211_CMD_GET_REG from usermode, we send the
> entire regdom in a single message, so 1000 rules may become
> problematic..

Good point. But arguably that's a different problem :)

johannes