Age | Commit message (Collapse) | Author |
|
Some drivers (e.g. wl18xx) expect that the last stage in the
de-initialization process will be stopping the beacons, similar to AP flow.
Update ieee80211_stop_mesh() flow accordingly.
As peers can be removed dynamically, this would not impact other drivers.
Tested also on Ralink RT3572 chipset.
Signed-off-by: Maital Hahn <maitalm@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We've accumulated a couple of different fixes now to mesh_sta_cleanup()
due to the different paths that user_mpm and !user_mpm cases take -- one
fix to flush nexthop paths and one to fix the counting.
The only caller of mesh_plink_deactivate() is mesh_sta_cleanup(), so we
can push the user_mpm checks down into there in order to share more
code.
In doing so, we can remove an extra call to mesh_path_flush_by_nexthop()
and the (unnecessary) call to mesh_accept_plinks_update(). This will
also ensure the powersaving state code gets called in the user_mpm case.
The only cleanup tasks we need to avoid when MPM is in user-space
are sending the peering frames and stopping the plink timer, so wrap
those in the appropriate check.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
If a user space program (e.g., wpa_supplicant) deletes a STA entry that
is currently in NL80211_PLINK_ESTAB state, the number of established
plinks counter was not decremented and this could result in rejecting
new plink establishment before really hitting the real maximum plink
limit. For !user_mpm case, this decrementation is handled by
mesh_plink_deactive().
Fix this by decrementing estab_plinks on STA deletion
(mesh_sta_cleanup() gets called from there) so that the counter has a
correct value and the Beacon frame advertisement in Mesh Configuration
element shows the proper value for capability to accept additional
peers.
Cc: stable@vger.kernel.org
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
Currently, the mesh paths associated with a nexthop station are cleaned
up in the following code path:
__sta_info_destroy_part1
synchronize_net()
__sta_info_destroy_part2
-> cleanup_single_sta
-> mesh_sta_cleanup
-> mesh_plink_deactivate
-> mesh_path_flush_by_nexthop
However, there are a couple of problems here:
1) the paths aren't flushed at all if the MPM is running in userspace
(e.g. when using wpa_supplicant or authsae)
2) there is no synchronize_rcu between removing the path and readers
accessing the nexthop, which means the following race is possible:
CPU0 CPU1
~~~~ ~~~~
sta_info_destroy_part1()
synchronize_net()
rcu_read_lock()
mesh_nexthop_resolve()
mpath = mesh_path_lookup()
[...] -> mesh_path_flush_by_nexthop()
sta = rcu_dereference(
mpath->next_hop)
kfree(sta)
access sta <-- CRASH
Fix both of these by unconditionally flushing paths before destroying
the sta, and by adding a synchronize_net() after path flush to ensure
no active readers can still dereference the sta.
Fixes this crash:
[ 348.529295] BUG: unable to handle kernel paging request at 00020040
[ 348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
[ 348.530014] *pde = 00000000
[ 348.530014] Oops: 0000 [#1] PREEMPT
[ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
[ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1
[ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014
[ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
[ 348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0
[ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
[ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
[ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
[ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
[ 348.530014] Stack:
[ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
[ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
[ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
[ 348.530014] Call Trace:
[ 348.530014] [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
[ 348.530014] [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
[ 348.530014] [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211]
[ 348.530014] [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
[ 348.530014] [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3
[ 348.530014] [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b
[ 348.530014] [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
[ 348.530014] [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
[ 348.530014] [<c04c6f45>] ? netif_skb_features+0x14d/0x30a
[ 348.530014] [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
[ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
[ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253
[ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
[ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
[ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc
[ 348.530014] [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv]
[ 348.530014] [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
[ 348.530014] [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv]
[ 348.530014] [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
[ 348.530014] [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
[ 348.530014] [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv]
[ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
[ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253
[ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
[ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
[ 348.530014] [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb]
[ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc
[ 348.530014] [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
[ 348.530014] [<f843a35f>] br_forward_finish+0x29/0x74 [bridge]
[ 348.530014] [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge]
[ 348.530014] [<f843a714>] __br_forward+0x89/0xe7 [bridge]
[ 348.530014] [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
[ 348.530014] [<f843a234>] deliver_clone+0x34/0x3b [bridge]
[ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
[ 348.530014] [<f843a66d>] br_flood+0x77/0x95 [bridge]
[ 348.530014] [<f843a809>] br_flood_forward+0x13/0x1a [bridge]
[ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
[ 348.530014] [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge]
[ 348.530014] [<c04e9b2b>] ? nf_iterate+0x2b/0x6b
[ 348.530014] [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge]
[ 348.530014] [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge]
[ 348.530014] [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b
[ 348.530014] [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge]
[ 348.530014] [<c023cea4>] ? resched_curr+0x19/0x37
[ 348.530014] [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe
[ 348.530014] [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc
[ 348.530014] [<c04c4fc1>] __netif_receive_skb+0x47/0x55
[ 348.530014] [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a
[ 348.530014] [<c04c61ef>] napi_gro_receive+0x3a/0x94
[ 348.530014] [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb]
[ 348.530014] [<c0242bd8>] ? swake_up_locked+0x14/0x26
[ 348.530014] [<c04c5d29>] net_rx_action+0xde/0x250
[ 348.530014] [<c022a743>] __do_softirq+0x8a/0x163
[ 348.530014] [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19
[ 348.530014] [<c021100f>] do_softirq_own_stack+0x26/0x2c
[ 348.530014] <IRQ>
[ 348.530014] [<c022a957>] irq_exit+0x31/0x6f
[ 348.530014] [<c0210eb2>] do_IRQ+0x8d/0xa0
[ 348.530014] [<c058152c>] common_interrupt+0x2c/0x40
[ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
[ 348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
[ 348.530014] CR2: 0000000000020040
[ 348.530014] ---[ end trace 48556ac26779732e ]---
[ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt
[ 348.530014] Kernel Offset: disabled
Cc: stable@vger.kernel.org
Reported-by: Fred Veldini <fred.veldini@gmail.com>
Tested-by: Fred Veldini <fred.veldini@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The mesh path table needs to be around for the entire time the
interface is in mesh mode, as users can perform an mpath dump
at any time. The existing path table lifetime is instead tied
to the mesh BSS which can cause crashes when different MBSSes
are joined in the context of a single interface, or when the
path table is dumped when no MBSS is joined.
Introduce a new function to perform the final teardown of the
interface and perform path table cleanup there. We already
free the individual path elements when the leaving the mesh
so no additional cleanup is needed there. This fixes the
following crash:
[ 47.753026] BUG: unable to handle kernel paging request at fffffff0
[ 47.753026] IP: [<c0239765>] kthread_data+0xa/0xe
[ 47.753026] *pde = 00741067 *pte = 00000000
[ 47.753026] Oops: 0000 [#4] PREEMPT
[ 47.753026] Modules linked in: ppp_generic slhc 8021q garp mrp sch_fq_codel iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ath9k_htc ath5k 8139too ath10k_pci ath10k_core arc4 ath9k ath9k_common ath9k_hw mac80211 ath cfg80211 cpufreq_powersave br_netfilter bridge stp llc ipw usb_wwan sierra_net usbnet af_alg natsemi via_rhine mii iTCO_wdt iTCO_vendor_support gpio_ich sierra coretemp pcspkr i2c_i801 lpc_ich ata_generic ata_piix libata ide_pci_generic piix e1000e igb i2c_algo_bit ptp pps_core [last unloaded: 8139too]
[ 47.753026] CPU: 0 PID: 12 Comm: kworker/u2:1 Tainted: G D W 4.5.0-wt-V3 #6
[ 47.753026] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014
[ 47.753026] task: f645a0c0 ti: f6462000 task.ti: f6462000
[ 47.753026] EIP: 0060:[<c0239765>] EFLAGS: 00010002 CPU: 0
[ 47.753026] EIP is at kthread_data+0xa/0xe
[ 47.753026] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
[ 47.753026] ESI: f645a0c0 EDI: f645a2fc EBP: f6463a80 ESP: f6463a78
[ 47.753026] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 47.753026] CR0: 8005003b CR2: 00000014 CR3: 353e5000 CR4: 00000690
[ 47.753026] Stack:
[ 47.753026] c0236866 00000000 f6463aac c05768b4 00000009 f6463ba8 f6463ab0 c0247010
[ 47.753026] 00000000 f645a0c0 f6464000 00000009 f6463ba8 f6463ab8 c0576eb2 f645a0c0
[ 47.753026] f6463aec c0228be4 c06335a4 f6463adc f6463ad0 c06c06d4 f6463ae4 c02471b0
[ 47.753026] Call Trace:
[ 47.753026] [<c0236866>] ? wq_worker_sleeping+0xb/0x78
[ 47.753026] [<c05768b4>] __schedule+0xda/0x587
[ 47.753026] [<c0247010>] ? vprintk_default+0x12/0x14
[ 47.753026] [<c0576eb2>] schedule+0x72/0x89
[ 47.753026] [<c0228be4>] do_exit+0xb8/0x71d
[ 47.753026] [<c02471b0>] ? kmsg_dump+0xa9/0xae
[ 47.753026] [<c0203576>] oops_end+0x69/0x70
[ 47.753026] [<c021dcdb>] no_context+0x1bb/0x1c5
[ 47.753026] [<c021de1b>] __bad_area_nosemaphore+0x136/0x140
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c021de32>] bad_area_nosemaphore+0xd/0x10
[ 47.753026] [<c021e0a1>] __do_page_fault+0x26c/0x320
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c021e2fa>] do_page_fault+0xb/0xd
[ 47.753026] [<c05798f8>] error_code+0x58/0x60
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c0239765>] ? kthread_data+0xa/0xe
[ 47.753026] [<c0236866>] ? wq_worker_sleeping+0xb/0x78
[ 47.753026] [<c05768b4>] __schedule+0xda/0x587
[ 47.753026] [<c0247010>] ? vprintk_default+0x12/0x14
[ 47.753026] [<c0576eb2>] schedule+0x72/0x89
[ 47.753026] [<c0228be4>] do_exit+0xb8/0x71d
[ 47.753026] [<c02471b0>] ? kmsg_dump+0xa9/0xae
[ 47.753026] [<c0203576>] oops_end+0x69/0x70
[ 47.753026] [<c021dcdb>] no_context+0x1bb/0x1c5
[ 47.753026] [<c021de1b>] __bad_area_nosemaphore+0x136/0x140
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c021de32>] bad_area_nosemaphore+0xd/0x10
[ 47.753026] [<c021e0a1>] __do_page_fault+0x26c/0x320
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c021e2fa>] do_page_fault+0xb/0xd
[ 47.753026] [<c05798f8>] error_code+0x58/0x60
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c0239765>] ? kthread_data+0xa/0xe
[ 47.753026] [<c0236866>] ? wq_worker_sleeping+0xb/0x78
[ 47.753026] [<c05768b4>] __schedule+0xda/0x587
[ 47.753026] [<c0391e32>] ? put_io_context_active+0x6d/0x95
[ 47.753026] [<c0576eb2>] schedule+0x72/0x89
[ 47.753026] [<c02291f8>] do_exit+0x6cc/0x71d
[ 47.753026] [<c0203576>] oops_end+0x69/0x70
[ 47.753026] [<c021dcdb>] no_context+0x1bb/0x1c5
[ 47.753026] [<c021de1b>] __bad_area_nosemaphore+0x136/0x140
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c021de32>] bad_area_nosemaphore+0xd/0x10
[ 47.753026] [<c021e0a1>] __do_page_fault+0x26c/0x320
[ 47.753026] [<c03b9160>] ? debug_smp_processor_id+0x12/0x16
[ 47.753026] [<c02015e2>] ? __switch_to+0x24/0x40e
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c021e2fa>] do_page_fault+0xb/0xd
[ 47.753026] [<c05798f8>] error_code+0x58/0x60
[ 47.753026] [<c021e2ef>] ? vmalloc_sync_all+0x19a/0x19a
[ 47.753026] [<c03b59d2>] ? rhashtable_walk_init+0x5c/0x93
[ 47.753026] [<f9843221>] mesh_path_tbl_expire.isra.24+0x19/0x82 [mac80211]
[ 47.753026] [<f984408b>] mesh_path_expire+0x11/0x1f [mac80211]
[ 47.753026] [<f9842bb7>] ieee80211_mesh_work+0x73/0x1a9 [mac80211]
[ 47.753026] [<f98207d1>] ieee80211_iface_work+0x2ff/0x311 [mac80211]
[ 47.753026] [<c0235fa3>] process_one_work+0x14b/0x24e
[ 47.753026] [<c0236313>] worker_thread+0x249/0x343
[ 47.753026] [<c02360ca>] ? process_scheduled_works+0x24/0x24
[ 47.753026] [<c0239359>] kthread+0x9e/0xa3
[ 47.753026] [<c0578e50>] ret_from_kernel_thread+0x20/0x40
[ 47.753026] [<c02392bb>] ? kthread_parkme+0x18/0x18
[ 47.753026] Code: 6b c0 85 c0 75 05 e8 fb 74 fc ff 89 f8 84 c0 75 08 8d 45 e8 e8 34 dd 33 00 83 c4 28 5b 5e 5f 5d c3 55 8b 80 10 02 00 00 89 e5 5d <8b> 40 f0 c3 55 b9 04 00 00 00 89 e5 52 8b 90 10 02 00 00 8d 45
[ 47.753026] EIP: [<c0239765>] kthread_data+0xa/0xe SS:ESP 0068:f6463a78
[ 47.753026] CR2: 00000000fffffff0
[ 47.753026] ---[ end trace 867ca0bdd0767790 ]---
Fixes: 3b302ada7f0a ("mac80211: mesh: move path tables into if_mesh")
Reported-by: Fred Veldini <fred.veldini@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The RMC cache has 256 list heads plus a u32, which puts it at the
unfortunate size of 4104 bytes with padding. kmalloc() will then
round this up to the next power-of-two, so we wind up actually
using two pages here where most of the second is wasted.
Switch to hlist heads here to reduce the structure size down to
fit within a page.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In the unlikely case that mesh_rmc_init() fails with -ENOMEM,
the rmc pointer will be left as NULL but the interface is still
operational because ieee80211_mesh_init_sdata() is not allowed
to fail.
If this happens, we would blindly dereference rmc when checking
whether a multicast frame is in the cache. Instead just drop the
frames in the forwarding path.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In the time since the mesh path table was implemented as an
RCU-traversable, dynamically growing hash table, a generic RCU
hashtable implementation was added to the kernel.
Switch the mesh path table over to rhashtable to remove some code
and also gain some features like automatic shrinking.
Cc: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The mesh path and mesh gate hashtables are global, containing
all of the mpaths for every mesh interface, but the paths are
all tied logically to a single interface. The common case is
just a single mesh interface, so optimize for that by moving
the global hashtable into the per-interface struct.
Doing so allows us to drop sdata pointer comparisons inside
the lookups and also saves a few bytes of BSS and data.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
Here's another round of updates for -next:
* big A-MSDU RX performance improvement (avoid linearize of paged RX)
* rfkill changes: cleanups, documentation, platform properties
* basic PBSS support in cfg80211
* MU-MIMO action frame processing support
* BlockAck reordering & duplicate detection offload support
* various cleanups & little fixes
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The station MLME and IBSS/mesh ones use entirely different
code for interpreting HT and VHT operation elements. Change
the code that interprets them a bit - it now modifies an
existing chandef - and use it also in the MLME code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
During a sw scan ieee80211_iface_work ignores work items for all vifs.
However after the scan complete work is requeued only for STA, ADHOC
and MESH iftypes.
This occasionally results in event processing getting delayed/not
processed for iftype AP when it coexists with a STA. This can result
in data halt and eventually disconnection on the AP interface.
Cc: stable@vger.kernel.org
Signed-off-by: Sachin Kulkarni <Sachin.Kulkarni@imgtec.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When 11n peers performs a TDLS connection on a legacy BSS, the HT
operation IE must be specified according to IEEE802.11-2012 section
9.23.3.2. Otherwise HT-protection is compromised and the medium becomes
noisy for both the TDLS and the BSS links.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The function returns always non-negative values.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the basics required for supporting very high throughput
with mesh: include VHT information elements in beacons, probe
responses, and peering action frames, and check for compatible VHT
configurations when peering.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There are now a fairly large number of mesh fields that really
aren't needed in any other modes; move those into their own
structure and allocate them separately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The csa counter has moved from sdata to beacon/presp but
it is not updated accordingly for mesh and ibss. Fix this.
Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp")
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
Lots of updates for net-next; along with the usual flurry
of small fixes, cleanups and internal features we have:
* VHT support for TDLS and IBSS (conditional on drivers though)
* first TX performance improvements (the biggest will come later)
* many suspend/resume (race) fixes
* name_assign_type support from Tom Gundersen
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use the built-in function instead of memset.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Both wpa_supplicant and mac80211 have and inactivity timer. By default
wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30
minutes. If wpa_supplicant uses a longer timer than mac80211, it will
get unexpected disconnection by mac80211.
Using 0xffffffff instead as the configured value could solve this w/o
changing the code, but due to integer overflow in the expression used
this doesn't work. The expression is:
(current jiffies) > (frame Rx jiffies + NL80211_MESHCONF_PLINK_TIMEOUT * 250)
On 32bit system, the right side would overflow and be a very small
value if NL80211_MESHCONF_PLINK_TIMEOUT is sufficiently large,
causing unexpectedly early disconnections.
Instead allow disabling the inactivity timer to avoid this situation,
by passing the (previously invalid and useless) value 0.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
[reword/rewrap commit log]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If we are switching from an HT40+ to an HT40- channel (or vice-versa),
we need the secondary channel offset IE to specify what is the
post-CSA offset to be used. This applies both to beacons and to probe
responses.
In ieee80211_parse_ch_switch_ie() we were ignoring this IE from
beacons and using the *current* HT information IE instead. This was
causing us to use the same offset as before the switch.
Fix that by using the secondary channel offset IE also for beacons and
don't ever use the pre-switch offset. Additionally, remove the
"beacon" argument from ieee80211_parse_ch_switch_ie(), since it's not
needed anymore.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Having csa counters part of beacon and probe_resp
structures makes it easier to get rid of possible
races between setting a beacon and updating
counters on SMP systems by guaranteeing counters
are always consistent against given beacon struct.
While at it relax WARN_ON into WARN_ON_ONCE to
prevent spamming logs and racing.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[remove pointless array check]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Cc: Luis Carlos Cobo <luisca@cozybit.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Support up to IEEE80211_MAX_CSA_COUNTERS_NUM csa counters.
This is defined to be 2 now, to support both CSA and eCSA
counters.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Previously, the code to copy the RSN IE from the mesh config
would increment its pointer by one in the loop instead of by
the element length, so there was the potential for mistaking
another IE's data fields as the RSN IE.
cfg80211_find_ie() exists, so just use that.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Some interface types don't require DFS (such as STATION, P2P_CLIENT
etc). In order to centralize these decisions, make
cfg80211_chandef_dfs_required() take the iftype into consideration.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
rcu_assign_pointer() ensures that the initialization of a structure is
carried out before storing a pointer to that structure. However, in the
case that NULL is assigned there's no structure to initialize so using
RCU_INIT_POINTER instead is safe and more efficient.
Signed-off-by: Monam Agarwal <monamagarwal123@gmail.com>
[squash eight tiny patches, rewrite commit log]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The patch adds a missing sdata lock and adds a few
lockdeps for easier maintenance.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of having
ieee80211_bss_info_change_notify() scattered all
over the place just call it once when finalizing
CSA.
As a side effect this patch adds missing error
checking for IBSS CSA beacon update.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
[fix err vs. changed variable usage in ieee80211_csa_finalize()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Since we copy the mesh_id_len into our own data structures,
use it consistently and don't sometimes use cfg80211's copy.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
A beacon should never have a Channel Switch Announcement information
element with a count of 0, because a count of 1 means switch just
before the next beacon. So, if a count of 0 was valid in a beacon, it
would have been transmitted in the next channel already, which is
useless. A CSA count equal to zero is only meaningful in action
frames or probe_responses.
Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
functions accordingly.
With a CSA count of 0, we won't transmit any CSA beacons, because the
switch will happen before the next TBTT. To avoid extra work and
potential confusion in the drivers, complete the CSA immediately,
instead of waiting for the driver to call ieee80211_csa_finish().
To keep things simpler, we also switch immediately when the CSA count
is 1, while in theory we should delay the switch until just before the
next TBTT.
Additionally, move the ieee80211_csa_finish() function to cfg.c,
where it makes more sense.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The return value of ieee80211_mesh_csa_beacon is not aligned with the
return value of ieee80211_assign_beacon() and
ieee80211_ibss_csa_beacon(). For consistency and to be able to use
both functions with similar code, change ieee80211_mesh_csa_beacon()
not to send the bss changed notification itself, but return what has
changed so the caller can send the notification instead.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Refactor ieee80211_mesh_process_chanswitch() to use
ieee80211_channel_switch() and avoid code duplication.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
On starting a mesh or AP BSS, the interface dtim_count
countdown should match that of the driver TSF.
Signed-off-by: Thomas Pedersen <twpedersen@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This regression was introduced in "mac80211: cache mesh
beacon".
mesh_sync_offset_adjust_tbtt() was assuming that the
beacon would be rebuilt in every single pre-tbtt
interrupt, but now the beacon update happens on the
workqueue, and it must be ready for immediate delivery to
the driver.
Save a pointer to the meshconf IE in the beacon_data (this
works because both the IE pointer and beacon buffer are
protected by the same rcu_{dereference,assign_pointer}())
for quick updates during pre-tbtt. This is faster and a
little prettier than iterating over the elements to find
the meshconf IE every time.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
Conflicts:
drivers/net/wireless/brcm80211/Kconfig
net/mac80211/util.c
|
|
There is no reason why we should have only one channel switch
announcement at a time for a single phy. When support for channel
switch with multiple contexts and multiple vifs per context is
implemented, we will need the chandef data for each vif. Move the
csa_chandef structure to sdata to prepare for this.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
[Fixed compilation with mesh]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
use put_unaligned_le16 for precedence value in mesh
channel switch support
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Mesh STA receiving the mesh CSA action frame is not able to trigger
the mesh channel switch due to the incorrect handling and comparison
of mesh channel switch parameters element (MCSP)'s TTL. Make sure
the MCSP's TTL is updated accordingly before calling the
ieee80211_mesh_process_chnswitch. Also, we update the beacon before
forwarding the CSA action frame, so MCSP's precedence value and
initiator flag need to be updated prior to this.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Trigger the mesh channel switching procedure if the mesh STA
happens to miss the CSA action frame but able to receive the
beacon containing the CSA and MCSP elements from its peer
mesh STAs.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
[fix locking in ieee80211_mesh_process_chnswitch()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the required procedures for mesh channel switching as defined
in the IEEE Std 802.11-2012 section 10.9.8.4.3 and also handle the CSA
and MCSP elements as followed:
* Add the function for updating the beacon and probe response frames
with CSA and MCSP elements during the period of switching to the new
channel. Both CSA and MCSP elements must be included in beacon and
probe response frames until the intended channel switch time.
* The ifmsh->csa_settings is set to NULL and the CSA and MCSP elements
will then be removed from the beacon or probe response frames once the
new channel is switched to.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Process the CSA frame according to the procedures define in IEEE Std
802.11-2012 section 10.9.8.4.3 as follow:
* The mesh channel switch parameters element (MCSP) must be availabe.
* If the MCSP's TTL is 1, drop the frame but still process the CSA.
* If the MCSP's precedence value is less than or equal to the current
precedence value, drop the frame and do not process the CSA.
* The CSA frame is forwarded after TTL is decremented by 1 and the
initiator field is set to 0. Transmit restrict field and others
are maintained as is.
* No beacon or probe response frame are handled here.
Also, introduce the debug message used for mesh CSA purpose.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Previously, the mesh STA responds to probe request from legacy STA
but now it will only respond to legacy STA if the legacy STA does include
the specific mesh ID or wildcard mesh ID in the probe request.
The iw patch "iw: scan using meshid" can be used either by legacy STA
or by mesh STA to do active scanning by inserting the mesh ID in the
probe request frame.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Acked-by: Thomas Pedersen <thomas@cozybit.com>
Acked-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Set the Forwarding bit in Mesh Capability Info according
to dot11MeshForwarding as defined in IEEE 802.11-2012
section 8.4.2.100.8.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The various components accessing the bitrates table must use consider
the used channel bandwidth to select only available rates or calculate
the bitrate correctly.
There are some rates in reduced bandwidth modes which can't be
represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The
standard suggests to round up to the next multiple of 500kbps, just do
that in mac80211 as well.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
[make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
This is a collection of minor fixes:
* don't allow HT IEs in IBSS for 5/10 MHz
* don't allow HT IEs in Mesh for 5/10 MHz
* don't downgrade from/to 5 and 10 MHz channels
* don't try HT rates for 5 and 10 MHz channels when selecting rates
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of updating the mesh beacon immediately when
requested (which would require the sdata_lock()), defer it
to the mac80211 workqueue.
Fixes yet another deadlock on calling sta_info_flush()
with the sdata_lock() held from ieee80211_stop_mesh(). We
could just drop the sdata_lock() around the
mesh_sta_cleanup() call, but this path is also taken from
several non-locked error paths.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
[fix comment position]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently mesh uses mandatory rates as the default basic rates. Allow basic
rates to be configured during mesh join. Basic rates are applied only if
channel is also provided with mesh join command.
Signed-off-by: Ashok Nagarajan <ashok@cozybit.com>
[some whitespace fixes, refuse basic rates w/o channel]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The time it takes to see the peer link expire may differ
by a minute since sta_expire() is run once a minute as a
mesh housekeeping task.
Signed-off-by: Colleen Twitty <colleen@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|