* Re: bdm 4353 802.11n monitor mode you can?
From: Larry Finger @ 2010-08-05 13:54 UTC (permalink / raw)
To: Arthur Moreira; +Cc: wireless
In-Reply-To: <AANLkTi=Q7FXWnH9dyH3mPX7G+JDBNVb0NWuYjqd_VN2F@mail.gmail.com>
On 08/05/2010 06:57 AM, Arthur Moreira wrote:
> Someone can put the broadcom card 802.11n bcmw 4353 in monitor mode?
The Broadcom wl hybrid driver does not support monitor mode, and that is the
only driver for 802.11n Broadcom chips. Until we finish getting b43 running on
such devices, you will not have that option.
Complain to Broadcom.
Larry
^ permalink raw reply
* Re: [ath9k]: Beaconing process in ad-hoc mode
From: John W. Linville @ 2010-08-05 13:45 UTC (permalink / raw)
To: Jónatan Muñoz; +Cc: linux-wireless
In-Reply-To: <002c01cb3495$0ff49610$2fddc230$@es>
On Thu, Aug 05, 2010 at 01:55:05PM +0200, Jónatan Muñoz wrote:
> Dear All,
>
> I am working in a project where I need to modified the currently beaconing
> system for adhoc mode in ath9k, what I want to achieve is that each station
> in an adhoc network send periodically a beacon. As I know, when a station in
> the network receives a beacon before sending its own beacon, cancels the
> transmission, updates its hw tsf based on the received beacon and waits for
> a chance to send the beacon during next TBTT.
>
> For my goal, I think that I should comment the part where the transmission
> of the beacon is cancelled. In this way, each station will send a beacon
> each 100TU (~100 ms). I know that this mean a increased traffic load on the
> network, but it is so much important for the project to obtain a beacon for
> each station each 100ms.
>
> Right now, I am looking at the source code of ath9k, I am trying to modify
> the file beacon.c, but I don’t find the way to get my purpose. Could anyone
> help me to find the right place at the code that I have to modify? I am a
> bit lost and any help would be greatly appreciated.
>
> Thanks in advance.
>
> PD: Please excuse my poor English
>
> John
I think you should be looking in net/mac80211/ibss.c.
Hth!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Capturing packets with bad FCS in monitor mode
From: Daniel Haid @ 2010-08-05 14:14 UTC (permalink / raw)
To: linux-wireless
Hello,
is it possible to receive packets with bad FCS in monitor mode (ath9k driver)?
There is a comment in ath9k/common.c which says that a bad checksum is
ignored in monitor mode, but I have so far never been able to receive a
packet with bad FCS (I do not know how to generate such packets,
so I might just be too lucky that all packets are received unimpaired).
Does ath9k hardware drop packets with bad FCS directly? If so, can
it be disabled?
Best regards.
^ permalink raw reply
* Re: [PATCH 11/15] net: mac80211: Fix a typo.
From: Gábor Stefanik @ 2010-08-05 14:44 UTC (permalink / raw)
To: Andrea Gelmini
Cc: gelma, Stefano Brivio, Mattias Nissler, John W. Linville,
Johannes Berg, David S. Miller, Stephen Hemminger,
Alexey Dobriyan, Tejun Heo, linux-wireless, netdev
In-Reply-To: <1281016299-23958-11-git-send-email-andrea.gelmini@gelma.net>
On Thu, Aug 5, 2010 at 3:51 PM, Andrea Gelmini <andrea.gelmini@gelma.net> wrote:
> "userpace" -> "userspace"
>
> Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
> ---
> net/mac80211/rc80211_pid_debugfs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/rc80211_pid_debugfs.c b/net/mac80211/rc80211_pid_debugfs.c
> index 47438b4..135f36f 100644
> --- a/net/mac80211/rc80211_pid_debugfs.c
> +++ b/net/mac80211/rc80211_pid_debugfs.c
> @@ -162,7 +162,7 @@ static ssize_t rate_control_pid_events_read(struct file *file, char __user *buf,
> file_info->next_entry = (file_info->next_entry + 1) %
> RC_PID_EVENT_RING_SIZE;
>
> - /* Print information about the event. Note that userpace needs to
> + /* Print information about the event. Note that userspace needs to
> * provide large enough buffers. */
> length = length < RC_PID_PRINT_BUF_SIZE ?
> length : RC_PID_PRINT_BUF_SIZE;
length = min(length, RC_PID_PRINT_BUF_SIZE) maybe? (Though this is not
part of the patch.)
> --
> 1.7.2.1.85.g2d089
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Arnd Hannemann @ 2010-08-05 14:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless, sfr
In-Reply-To: <20100805.014637.13722703.davem@davemloft.net>
Am 05.08.2010 10:46, schrieb David Miller:
> From: Arnd Hannemann <arnd@arndnet.de> Date: Thu, 05 Aug 2010
> 09:57:50 +0200
>
>> if I try to fetch from net-next-2.6, I get: fatal: The remote end
>> hung up unexpectedly
>>
>> if I try to clone net-2.6: (e.g. git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>>
>> I get lots of errors reading the tags "does not point to a valid
>> object!" and then: remote: error: Could not read
>> 3cfc2c42c1cbc8e238bb9c0612c0df4565e3a8b4 remote: fatal: Failed to
>> traverse parents of commit
>> 7aaaaa1e44b2a4047dfe05f304a5090eb995cf44 remote: aborting due to
>> possible repository corruption on the remote side. fatal: early
>> EOF fatal: index-pack failed
>
> I fixed the alternates file but it will take some time for the fix to
> propagate from master.kernel.org
>
> Let me know if it doesn't work even after an hour or so.
It works now, for both net-next-2.6 and net-2.6.
Thanks,
Arnd
^ permalink raw reply
* RE: Capturing packets with bad FCS in monitor mode
From: ABM Musa @ 2010-08-05 14:43 UTC (permalink / raw)
To: 'Daniel Haid', linux-wireless
In-Reply-To: <201008051614.11546.d.haid@gogi.tv>
Packets with crc error can be captured using corresponding flag of iw.
iw phy phy0 interface add wlan0 type monitor flags fcsfail
However, there is also option for plcpfail flag but I never obtained any
packet with plcpfail using this flag. Any info about that will be helpful.
Musa
-----Original Message-----
From: linux-wireless-owner@vger.kernel.org
[mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Daniel Haid
Sent: Thursday, August 05, 2010 9:14 AM
To: linux-wireless@vger.kernel.org
Subject: Capturing packets with bad FCS in monitor mode
Hello,
is it possible to receive packets with bad FCS in monitor mode (ath9k
driver)?
There is a comment in ath9k/common.c which says that a bad checksum is
ignored in monitor mode, but I have so far never been able to receive a
packet with bad FCS (I do not know how to generate such packets, so I might
just be too lucky that all packets are received unimpaired).
Does ath9k hardware drop packets with bad FCS directly? If so, can it be
disabled?
Best regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Capturing packets with bad FCS in monitor mode
From: Johannes Berg @ 2010-08-05 14:56 UTC (permalink / raw)
To: ABM Musa; +Cc: 'Daniel Haid', linux-wireless
In-Reply-To: <475A8455ABBB4AD79E2B0AD03B1F69B9@personal>
On Thu, 2010-08-05 at 09:43 -0500, ABM Musa wrote:
> Packets with crc error can be captured using corresponding flag of iw.
>
> iw phy phy0 interface add wlan0 type monitor flags fcsfail
>
> However, there is also option for plcpfail flag but I never obtained any
> packet with plcpfail using this flag. Any info about that will be helpful.
It only works with very few drivers (b43) and also had issues -- you'll
probably need this patch:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-no-rate-check.patch
johannes
^ permalink raw reply
* [PATCH] mac80211: per interface idle notification
From: Johannes Berg @ 2010-08-05 15:02 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Sometimes we don't just need to know whether or
not the device is idle, but also per interface.
This adds that reporting capability to mac80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 6 +++++
net/mac80211/ibss.c | 8 +++++-
net/mac80211/ieee80211_i.h | 3 ++
net/mac80211/iface.c | 53 ++++++++++++++++++++++++++++++++++++++-------
net/mac80211/mlme.c | 17 ++++++++++++--
net/mac80211/scan.c | 2 +
net/mac80211/work.c | 8 +++---
7 files changed, 81 insertions(+), 16 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2010-08-05 16:11:44.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-08-05 16:12:39.000000000 +0200
@@ -149,6 +149,7 @@ struct ieee80211_low_level_stats {
* @BSS_CHANGED_ARP_FILTER: Hardware ARP filter address list or state changed.
* @BSS_CHANGED_QOS: QoS for this association was enabled/disabled. Note
* that it is only ever disabled for station mode.
+ * @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -165,6 +166,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_IBSS = 1<<11,
BSS_CHANGED_ARP_FILTER = 1<<12,
BSS_CHANGED_QOS = 1<<13,
+ BSS_CHANGED_IDLE = 1<<14,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -223,6 +225,9 @@ enum ieee80211_bss_change {
* hardware must not perform any ARP filtering. Note, that the filter will
* be enabled also in promiscuous mode.
* @qos: This is a QoS-enabled BSS.
+ * @idle: This interface is idle. There's also a global idle flag in the
+ * hardware config which may be more appropriate depending on what
+ * your driver/device needs to do.
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -247,6 +252,7 @@ struct ieee80211_bss_conf {
u8 arp_addr_cnt;
bool arp_filter_enabled;
bool qos;
+ bool idle;
};
/**
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2010-08-05 16:12:31.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2010-08-05 16:12:39.000000000 +0200
@@ -497,6 +497,9 @@ struct ieee80211_sub_if_data {
*/
bool ht_opmode_valid;
+ /* to detect idle changes */
+ bool old_idle;
+
/* Fragment table for host-based reassembly */
struct ieee80211_fragment_entry fragments[IEEE80211_FRAGMENT_MAX];
unsigned int fragment_next;
--- wireless-testing.orig/net/mac80211/iface.c 2010-08-05 16:07:38.000000000 +0200
+++ wireless-testing/net/mac80211/iface.c 2010-08-05 16:12:39.000000000 +0200
@@ -307,7 +307,9 @@ static int ieee80211_open(struct net_dev
if (sdata->flags & IEEE80211_SDATA_PROMISC)
atomic_inc(&local->iff_promiscs);
+ mutex_lock(&local->mtx);
hw_reconf_flags |= __ieee80211_recalc_idle(local);
+ mutex_unlock(&local->mtx);
local->open_count++;
if (hw_reconf_flags) {
@@ -514,7 +516,9 @@ static int ieee80211_stop(struct net_dev
sdata->bss = NULL;
+ mutex_lock(&local->mtx);
hw_reconf_flags |= __ieee80211_recalc_idle(local);
+ mutex_unlock(&local->mtx);
ieee80211_recalc_ps(local, -1);
@@ -1195,28 +1199,61 @@ u32 __ieee80211_recalc_idle(struct ieee8
{
struct ieee80211_sub_if_data *sdata;
int count = 0;
+ bool working = false, scanning = false;
+ struct ieee80211_work *wk;
- if (!list_empty(&local->work_list))
- return ieee80211_idle_off(local, "working");
-
- if (local->scanning)
- return ieee80211_idle_off(local, "scanning");
+#ifdef CONFIG_PROVE_LOCKING
+ WARN_ON(debug_locks && !lockdep_rtnl_is_held() &&
+ !lockdep_is_held(&local->iflist_mtx));
+#endif
+ lockdep_assert_held(&local->mtx);
list_for_each_entry(sdata, &local->interfaces, list) {
- if (!ieee80211_sdata_running(sdata))
+ if (!ieee80211_sdata_running(sdata)) {
+ sdata->vif.bss_conf.idle = true;
continue;
+ }
+
+ sdata->old_idle = sdata->vif.bss_conf.idle;
+
/* do not count disabled managed interfaces */
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
- !sdata->u.mgd.associated)
+ !sdata->u.mgd.associated) {
+ sdata->vif.bss_conf.idle = true;
continue;
+ }
/* do not count unused IBSS interfaces */
if (sdata->vif.type == NL80211_IFTYPE_ADHOC &&
- !sdata->u.ibss.ssid_len)
+ !sdata->u.ibss.ssid_len) {
+ sdata->vif.bss_conf.idle = true;
continue;
+ }
/* count everything else */
count++;
}
+ list_for_each_entry(wk, &local->work_list, list) {
+ working = true;
+ wk->sdata->vif.bss_conf.idle = false;
+ }
+
+ if (local->scan_sdata) {
+ scanning = true;
+ local->scan_sdata->vif.bss_conf.idle = false;
+ }
+
+ list_for_each_entry(sdata, &local->interfaces, list) {
+ if (sdata->old_idle == sdata->vif.bss_conf.idle)
+ continue;
+ if (!ieee80211_sdata_running(sdata))
+ continue;
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_IDLE);
+ }
+
+ if (working)
+ return ieee80211_idle_off(local, "working");
+ if (scanning)
+ return ieee80211_idle_off(local, "scanning");
if (!count)
return ieee80211_idle_on(local);
else
--- wireless-testing.orig/net/mac80211/scan.c 2010-08-05 16:12:31.000000000 +0200
+++ wireless-testing/net/mac80211/scan.c 2010-08-05 16:12:39.000000000 +0200
@@ -305,7 +305,9 @@ void ieee80211_scan_completed(struct iee
ieee80211_offchannel_return(local, true);
done:
+ mutex_lock(&local->mtx);
ieee80211_recalc_idle(local);
+ mutex_unlock(&local->mtx);
ieee80211_mlme_notify_scan_completed(local);
ieee80211_ibss_notify_scan_completed(local);
ieee80211_mesh_notify_scan_completed(local);
--- wireless-testing.orig/net/mac80211/work.c 2010-08-05 16:12:31.000000000 +0200
+++ wireless-testing/net/mac80211/work.c 2010-08-05 16:12:39.000000000 +0200
@@ -888,10 +888,10 @@ static void ieee80211_work_work(struct w
while ((skb = skb_dequeue(&local->work_skb_queue)))
ieee80211_work_rx_queued_mgmt(local, skb);
- ieee80211_recalc_idle(local);
-
mutex_lock(&local->mtx);
+ ieee80211_recalc_idle(local);
+
list_for_each_entry_safe(wk, tmp, &local->work_list, list) {
bool started = wk->started;
@@ -1001,10 +1001,10 @@ static void ieee80211_work_work(struct w
&local->scan_work,
round_jiffies_relative(0));
- mutex_unlock(&local->mtx);
-
ieee80211_recalc_idle(local);
+ mutex_unlock(&local->mtx);
+
list_for_each_entry_safe(wk, tmp, &free_work, list) {
wk->done(wk, NULL);
list_del(&wk->list);
--- wireless-testing.orig/net/mac80211/mlme.c 2010-08-05 16:12:31.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2010-08-05 16:22:42.000000000 +0200
@@ -1103,8 +1103,11 @@ static void __ieee80211_connection_loss(
printk(KERN_DEBUG "Connection to AP %pM lost.\n", bssid);
ieee80211_set_disassoc(sdata, true);
- ieee80211_recalc_idle(local);
mutex_unlock(&ifmgd->mtx);
+
+ mutex_lock(&local->mtx);
+ ieee80211_recalc_idle(local);
+ mutex_unlock(&local->mtx);
/*
* must be outside lock due to cfg80211,
* but that's not a problem.
@@ -1173,7 +1176,9 @@ ieee80211_rx_mgmt_deauth(struct ieee8021
sdata->name, bssid, reason_code);
ieee80211_set_disassoc(sdata, true);
+ mutex_lock(&sdata->local->mtx);
ieee80211_recalc_idle(sdata->local);
+ mutex_unlock(&sdata->local->mtx);
return RX_MGMT_CFG80211_DEAUTH;
}
@@ -1203,7 +1208,9 @@ ieee80211_rx_mgmt_disassoc(struct ieee80
sdata->name, mgmt->sa, reason_code);
ieee80211_set_disassoc(sdata, true);
+ mutex_lock(&sdata->local->mtx);
ieee80211_recalc_idle(sdata->local);
+ mutex_unlock(&sdata->local->mtx);
return RX_MGMT_CFG80211_DISASSOC;
}
@@ -1840,8 +1847,10 @@ void ieee80211_sta_work(struct ieee80211
" after %dms, disconnecting.\n",
bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
ieee80211_set_disassoc(sdata, true);
- ieee80211_recalc_idle(local);
mutex_unlock(&ifmgd->mtx);
+ mutex_lock(&local->mtx);
+ ieee80211_recalc_idle(local);
+ mutex_unlock(&local->mtx);
/*
* must be outside lock due to cfg80211,
* but that's not a problem.
@@ -2319,7 +2328,9 @@ int ieee80211_mgd_deauth(struct ieee8021
if (assoc_bss)
sta_info_destroy_addr(sdata, bssid);
+ mutex_lock(&sdata->local->mtx);
ieee80211_recalc_idle(sdata->local);
+ mutex_unlock(&sdata->local->mtx);
return 0;
}
@@ -2357,7 +2368,9 @@ int ieee80211_mgd_disassoc(struct ieee80
cookie, !req->local_state_change);
sta_info_destroy_addr(sdata, bssid);
+ mutex_lock(&sdata->local->mtx);
ieee80211_recalc_idle(sdata->local);
+ mutex_unlock(&sdata->local->mtx);
return 0;
}
--- wireless-testing.orig/net/mac80211/ibss.c 2010-08-05 16:11:12.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2010-08-05 16:22:05.000000000 +0200
@@ -920,12 +920,14 @@ int ieee80211_ibss_join(struct ieee80211
memcpy(sdata->u.ibss.ssid, params->ssid, IEEE80211_MAX_SSID_LEN);
sdata->u.ibss.ssid_len = params->ssid_len;
+ mutex_unlock(&sdata->u.ibss.mtx);
+
+ mutex_lock(&sdata->local->mtx);
ieee80211_recalc_idle(sdata->local);
+ mutex_unlock(&sdata->local->mtx);
ieee80211_queue_work(&sdata->local->hw, &sdata->work);
- mutex_unlock(&sdata->u.ibss.mtx);
-
return 0;
}
@@ -980,7 +982,9 @@ int ieee80211_ibss_leave(struct ieee8021
mutex_unlock(&sdata->u.ibss.mtx);
+ mutex_lock(&local->mtx);
ieee80211_recalc_idle(sdata->local);
+ mutex_unlock(&local->mtx);
return 0;
}
^ permalink raw reply
* [PATCH] mac80211: allow drivers to request SM PS mode change
From: Johannes Berg @ 2010-08-05 15:05 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Sometimes drivers have more information than the
stack about how their antennas/chains are used,
and may require that the SM PS mode be changed.
This could happen, for example, when detecting
that the user disconnected an antenna. Thus this
patch introduces API to allow drivers to request
SM PS mode changes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 12 ++++++++++++
net/mac80211/ht.c | 28 ++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 6 +++++-
net/mac80211/mlme.c | 3 +++
4 files changed, 48 insertions(+), 1 deletion(-)
--- wireless-testing.orig/include/net/mac80211.h 2010-08-05 16:12:39.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-08-05 17:03:03.000000000 +0200
@@ -2524,6 +2524,18 @@ void ieee80211_cqm_rssi_notify(struct ie
*/
void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool success);
+/**
+ * ieee80211_request_smps - request SM PS transition
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ * @mode: new SM PS mode
+ *
+ * This allows the driver to request an SM PS transition in managed
+ * mode. This is useful when the driver has more information than
+ * the stack about possible interference, for example by bluetooth.
+ */
+void ieee80211_request_smps(struct ieee80211_vif *vif,
+ enum ieee80211_smps_mode smps_mode);
+
/* Rate control API */
/**
--- wireless-testing.orig/net/mac80211/ht.c 2010-07-30 16:08:28.000000000 +0200
+++ wireless-testing/net/mac80211/ht.c 2010-08-05 17:03:03.000000000 +0200
@@ -265,3 +265,31 @@ int ieee80211_send_smps_action(struct ie
return 0;
}
+
+void ieee80211_request_smps_work(struct work_struct *work)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
+ u.mgd.request_smps_work);
+
+ mutex_lock(&sdata->u.mgd.mtx);
+ __ieee80211_request_smps(sdata, sdata->u.mgd.driver_smps_mode);
+ mutex_unlock(&sdata->u.mgd.mtx);
+}
+
+void ieee80211_request_smps(struct ieee80211_vif *vif,
+ enum ieee80211_smps_mode smps_mode)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+
+ if (WARN_ON(vif->type != NL80211_IFTYPE_STATION))
+ return;
+
+ if (WARN_ON(smps_mode == IEEE80211_SMPS_OFF))
+ smps_mode = IEEE80211_SMPS_AUTOMATIC;
+
+ ieee80211_queue_work(&sdata->local->hw,
+ &sdata->u.mgd.request_smps_work);
+}
+/* this might change ... don't want non-open drivers using it */
+EXPORT_SYMBOL_GPL(ieee80211_request_smps);
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2010-08-05 16:12:39.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2010-08-05 17:03:03.000000000 +0200
@@ -343,7 +343,10 @@ struct ieee80211_if_managed {
unsigned long timers_running; /* used for quiesce/restart */
bool powersave; /* powersave requested for this iface */
enum ieee80211_smps_mode req_smps, /* requested smps mode */
- ap_smps; /* smps mode AP thinks we're in */
+ ap_smps, /* smps mode AP thinks we're in */
+ driver_smps_mode; /* smps mode request */
+
+ struct work_struct request_smps_work;
unsigned int flags;
@@ -1108,6 +1111,7 @@ void ieee80211_send_delba(struct ieee802
int ieee80211_send_smps_action(struct ieee80211_sub_if_data *sdata,
enum ieee80211_smps_mode smps, const u8 *da,
const u8 *bssid);
+void ieee80211_request_smps_work(struct work_struct *work);
void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
u16 initiator, u16 reason);
--- wireless-testing.orig/net/mac80211/mlme.c 2010-08-05 16:22:42.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2010-08-05 17:03:03.000000000 +0200
@@ -1926,6 +1926,8 @@ void ieee80211_sta_quiesce(struct ieee80
* time -- the code here is properly synchronised.
*/
+ cancel_work_sync(&ifmgd->request_smps_work);
+
cancel_work_sync(&ifmgd->beacon_connection_loss_work);
if (del_timer_sync(&ifmgd->timer))
set_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running);
@@ -1961,6 +1963,7 @@ void ieee80211_sta_setup_sdata(struct ie
INIT_WORK(&ifmgd->chswitch_work, ieee80211_chswitch_work);
INIT_WORK(&ifmgd->beacon_connection_loss_work,
ieee80211_beacon_connection_loss_work);
+ INIT_WORK(&ifmgd->request_smps_work, ieee80211_request_smps_work);
setup_timer(&ifmgd->timer, ieee80211_sta_timer,
(unsigned long) sdata);
setup_timer(&ifmgd->bcn_mon_timer, ieee80211_sta_bcn_mon_timer,
^ permalink raw reply
* Re: bdm 4353 802.11n monitor mode you can?
From: Larry Finger @ 2010-08-05 15:35 UTC (permalink / raw)
To: Arthur Moreira; +Cc: wireless
In-Reply-To: <AANLkTinrj6ApbFz5_3T95Z96RBbuz5hTh3x=Q98qpgpP@mail.gmail.com>
On 08/05/2010 09:38 AM, Arthur Moreira wrote:
> Tks Larry
> I willl wait, the broadcom support team call for look the dell. And
> the dell only windows driver.
>
> Larry i need much to can make a scan in networks, i work with network
> secutiry and buyed a dell laptop, without knowing that it would take
> this job.
>
> what you can do to help me or guide me I appreciate.
>
> you who work with creating the modules and drivers can not create a
> module to put the card 802.11n broadcom 4353 chipset in monitor mode?
> and packet injection?
You can certainly use ndiswrapper and the Windows driver. My only question would
be the stability of that configuration.
Your other option would be to purchase a USB device that does support monitor
mode. My favorite is the Netgear WG111V2, which uses the rtl8187 driver. These
are available for ~$10 on Ebay. Any device that uses mac80211 should be capable
of monitor mode. If you want both 2.4 and 5 GHz bands, then you can use a Dell
Wireless 1450 USB adapter (Model D1450U). There is one on Ebay for $21.
Reverse-engineering a complicated device like the Broadcom 802.11n chips is not
trivial. We get no specifications or any help from Broadcom. Yes, we will be
able to provide a driver with full capabilities; however, I have no idea when
that will happen.
Please do a "Reply-to-all" so that the mailing list archives have the full
record of our mails.
Larry
^ permalink raw reply
* [PATCH] cfg80211: support sysfs namespaces
From: Johannes Berg @ 2010-08-05 15:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, netdev, Eric W. Biederman
From: Johannes Berg <johannes.berg@intel.com>
Enable using network namespaces with
wireless devices even when sysfs is
enabled using the same infrastructure
that was built for netdevs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
NB: This generates a harmless gcc warning, I submitted
a patch to fix it here:
http://thread.gmane.org/gmane.linux.kernel/1019330
include/linux/netdevice.h | 2 ++
net/core/net-sysfs.c | 3 ++-
net/wireless/core.c | 7 ++++++-
net/wireless/sysfs.c | 9 +++++++++
4 files changed, 19 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/core/net-sysfs.c 2010-08-05 17:33:47.000000000 +0200
+++ wireless-testing/net/core/net-sysfs.c 2010-08-05 17:38:27.000000000 +0200
@@ -789,12 +789,13 @@ static const void *net_netlink_ns(struct
return sock_net(sk);
}
-static struct kobj_ns_type_operations net_ns_type_operations = {
+struct kobj_ns_type_operations net_ns_type_operations = {
.type = KOBJ_NS_TYPE_NET,
.current_ns = net_current_ns,
.netlink_ns = net_netlink_ns,
.initial_ns = net_initial_ns,
};
+EXPORT_SYMBOL_GPL(net_ns_type_operations);
static void net_kobj_ns_exit(struct net *net)
{
--- wireless-testing.orig/net/wireless/sysfs.c 2010-08-05 17:33:47.000000000 +0200
+++ wireless-testing/net/wireless/sysfs.c 2010-08-05 17:39:11.000000000 +0200
@@ -110,6 +110,13 @@ static int wiphy_resume(struct device *d
return ret;
}
+static const void *wiphy_namespace(struct device *d)
+{
+ struct wiphy *wiphy = container_of(d, struct wiphy, dev);
+
+ return wiphy_net(wiphy);
+}
+
struct class ieee80211_class = {
.name = "ieee80211",
.owner = THIS_MODULE,
@@ -120,6 +127,8 @@ struct class ieee80211_class = {
#endif
.suspend = wiphy_suspend,
.resume = wiphy_resume,
+ .ns_type = &net_ns_type_operations,
+ .namespace = wiphy_namespace,
};
int wiphy_sysfs_init(void)
--- wireless-testing.orig/net/wireless/core.c 2010-08-05 17:33:47.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2010-08-05 17:38:27.000000000 +0200
@@ -253,11 +253,16 @@ int cfg80211_switch_netns(struct cfg8021
WARN_ON(err);
wdev->netdev->features |= NETIF_F_NETNS_LOCAL;
}
+
+ return err;
}
wiphy_net_set(&rdev->wiphy, net);
- return err;
+ err = device_rename(&rdev->wiphy.dev, dev_name(&rdev->wiphy.dev));
+ WARN_ON(err);
+
+ return 0;
}
static void cfg80211_rfkill_poll(struct rfkill *rfkill, void *data)
--- wireless-testing.orig/include/linux/netdevice.h 2010-08-05 17:13:50.000000000 +0200
+++ wireless-testing/include/linux/netdevice.h 2010-08-05 17:39:02.000000000 +0200
@@ -2171,6 +2171,8 @@ extern void dev_seq_stop(struct seq_file
extern int netdev_class_create_file(struct class_attribute *class_attr);
extern void netdev_class_remove_file(struct class_attribute *class_attr);
+extern struct kobj_ns_type_operations net_ns_type_operations;
+
extern char *netdev_drivername(const struct net_device *dev, char *buffer, int len);
extern void linkwatch_run_queue(void);
^ permalink raw reply
* Re: Capturing packets with bad FCS in monitor mode
From: Daniel Haid @ 2010-08-05 16:19 UTC (permalink / raw)
To: ABM Musa; +Cc: linux-wireless
In-Reply-To: <475A8455ABBB4AD79E2B0AD03B1F69B9@personal>
> Packets with crc error can be captured using corresponding flag of iw.
>
> iw phy phy0 interface add wlan0 type monitor flags fcsfail
Is this supported on ath9k? I do not see any difference so far
with the packet capturing.
I also do not find the FIF_FCSFAIL flag be used anywhere in
the ath9k code.
Will I get lots of corrupted packets if this is enabled properly or only
casually?
^ permalink raw reply
* Re: Capturing packets with bad FCS in monitor mode
From: ABM Musa @ 2010-08-05 16:30 UTC (permalink / raw)
To: Daniel Haid; +Cc: linux-wireless
In-Reply-To: <201008051819.55252.d.haid@gogi.tv>
On 08/05/2010 11:19 AM, Daniel Haid wrote:
>> Packets with crc error can be captured using corresponding flag of iw.
>>
>> iw phy phy0 interface add wlan0 type monitor flags fcsfail
>>
> Is this supported on ath9k? I do not see any difference so far
> with the packet capturing.
> I also do not find the FIF_FCSFAIL flag be used anywhere in
> the ath9k code.
>
> Will I get lots of corrupted packets if this is enabled properly or only
> casually?
>
>
I can get packets with crc error using this method and I get lot of
corrupted packets. I am using ath9k with openwrt for router station
pro+ubiquity sr-71A card and tplink 1043nd.
Musa
^ permalink raw reply
* Re: Capturing packets with bad FCS in monitor mode
From: Daniel Haid @ 2010-08-05 16:40 UTC (permalink / raw)
To: ABM Musa; +Cc: linux-wireless
In-Reply-To: <4C5AE723.5070708@uic.edu>
> I can get packets with crc error using this method and I get lot of
> corrupted packets. I am using ath9k with openwrt for router station
> pro+ubiquity sr-71A card and tplink 1043nd.
I am using an ubiquity sr-71X card, and still not one corrupted packet.
I think I need to artificially create and transmit a corrupted packet. How
can I do that?
^ permalink raw reply
* Re: Capturing packets with bad FCS in monitor mode
From: ABM Musa @ 2010-08-05 16:50 UTC (permalink / raw)
To: Daniel Haid; +Cc: linux-wireless
In-Reply-To: <201008051840.18914.d.haid@gogi.tv>
On 08/05/2010 11:40 AM, Daniel Haid wrote:
>> I can get packets with crc error using this method and I get lot of
>> corrupted packets. I am using ath9k with openwrt for router station
>> pro+ubiquity sr-71A card and tplink 1043nd.
>>
> I am using an ubiquity sr-71X card, and still not one corrupted packet.
>
> I think I need to artificially create and transmit a corrupted packet. How
> can I do that?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
I am not sure about how to create corrupted packets. Normally you should
get lot of corrupted packets from surrounding transmission. In my case,
monitor mode hangs sometime and I don't get any packets. Then if I
delete the interface and create a new interface using the iw command I
gave earlier, I get packets with crc error. You can also modify already
created interface using
iw wlan0 set monitor flag fcsfail
Musa
^ permalink raw reply
* Re: [wt PATCH 0/5] libertas: make association work again
From: Dan Williams @ 2010-08-05 17:27 UTC (permalink / raw)
To: John W. Linville; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20100804193442.GR17666@tuxdriver.com>
On Wed, 2010-08-04 at 15:34 -0400, John W. Linville wrote:
> On Wed, Aug 04, 2010 at 02:15:46PM -0500, Dan Williams wrote:
> > On Wed, 2010-08-04 at 09:46 +0200, Johannes Berg wrote:
> > > On Wed, 2010-08-04 at 00:41 -0500, Dan Williams wrote:
> > > > On Fri, 2010-07-30 at 08:35 +0200, Johannes Berg wrote:
> > > > > On Thu, 2010-07-29 at 23:07 -0700, Dan Williams wrote:
> > > > > > This series makes libertas actually associate with APs after the
> > > > > > cfg80211 conversion. There was a pretty big TODO where if cfg80211
> > > > > > didn't pass in the BSSID of the AP to associate with, then libertas
> > > > > > would fail because the firmware really, really, really wants a BSSID.
> > > > > > So lets do a scan to find that BSSID. The other notable change is
> > > > > > a fix to make sure all supported rates are included in the firmware's
> > > > > > association request, lack of which caused some APs to deny the attempt.
> > > > >
> > > > > I'm a bit tempted to say we could use the connect logic in cfg80211 to
> > > > > provide this? cfg80211 _already_ provides this if the hardware wants
> > > > > auth()/assoc() rather than connect() calls, so it seems fairly simple to
> > > > > also (optionally) do it here?
> > > >
> > > > Yeah, I thought about that too. Do you want me to work on that now
> > > > instead of letting this patch through? I can revert the relevant bits
> > > > of this later if that's acceptable too.
> > >
> > > Either way works for me since I don't care about any cruft in
> > > libertas ;)
> >
> > John, if you don't mind applying this patch I'll work on generic
> > scan-before-connect support in cfg80211 in a further patch series.
>
> OK...which of these need to be in 2.6.36?
They should stick with the libertas cfg80211 bits, wherever they are.
If you've pushed whatever was in wireless-testing into 2.6.36, then this
latest series of 5 should go there too.
Dan
^ permalink raw reply
* [PATCH] rtl8180: avoid potential NULL deref in rtl8180_beacon_work
From: John W. Linville @ 2010-08-05 17:46 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
ieee80211_beacon_get can return NULL...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 1d81785..b50c39a 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -695,6 +695,8 @@ static void rtl8180_beacon_work(struct work_struct *work)
/* grab a fresh beacon */
skb = ieee80211_beacon_get(dev, vif);
+ if (!skb)
+ goto resched;
/*
* update beacon timestamp w/ TSF value
--
1.7.2
^ permalink raw reply related
* Re: WARNING at net/wireless/reg.c when wireless network is disconnected
From: Luis R. Rodriguez @ 2010-08-05 18:22 UTC (permalink / raw)
To: John W. Linville
Cc: Thomas Bächler, linux-wireless, linux-kernel, Johannes Berg
In-Reply-To: <20100804145258.GC17666@tuxdriver.com>
On Wed, Aug 4, 2010 at 7:52 AM, John W. Linville <linville@tuxdriver.com> wrote:
> On Wed, Aug 04, 2010 at 04:28:28PM +0200, Thomas Bächler wrote:
>> Am 04.08.2010 15:49, schrieb John W. Linville:
>> > On Wed, Aug 04, 2010 at 01:36:23PM +0200, Thomas Bächler wrote:
>> >> Hello,
>> >>
>> >> this warning has been around ever since I switched to 2.6.34, has
>> >> accompanied me through the 2.6.35-rc* phase and is still there with
>> >> 2.6.35. I didn't bother to report it so far, as there seems to be no harm.
>> >>
>> >> Whenever I disconnect/get disconnected from the wireless, I receive the
>> >> below warning:
>> >>
>> >> ------------[ cut here ]------------
>> >> WARNING: at net/wireless/reg.c:272
>> >> regulatory_hint_disconnect+0x1b3/0x230 [cfg80211]()
>> >> Hardware name: TECRA A11
>> >> Unexpected user alpha2: de
>> >
>> > Perhaps you need to set the regdomain as "DE" rather than "de"?
>> >
>> > John
>>
>> You are actually right. I did set it to "DE" with iw, but wpa_supplicant
>> had a setting country="de". I just fixed that and will soon see if the
>> problem disappears.
>>
>> Still, the warning shouldn't look like a bad kernel bug, but rather an
>> advisory to the user to set something sane. What confuses me even more
>> is that this has been set to DE afterwards:
>
> Perhaps we should just upcase the alpha2 value? I'm not sure why we don't.
It just needs to be implemented.
Luis
^ permalink raw reply
* Re: [PATCH] build fixes for compat-wireless due to PCMCIA changes
From: Luis R. Rodriguez @ 2010-08-05 18:27 UTC (permalink / raw)
To: Kshitij Kulshreshtha; +Cc: Hauke Mehrtens, linux-wireless
In-Reply-To: <1280931516-29665-1-git-send-email-kkhere.geo@gmail.com>
On Wed, Aug 4, 2010 at 7:18 AM, Kshitij Kulshreshtha
<kkhere.geo@gmail.com> wrote:
> Hello,
> here are two patches for compat and compat-wireless that fix build with
> linux-next.git tag next-20100804 and kernel v2.6.34
>
> The patch for compat-wireless is only
> leftovers from Luis R. Rodriguez' commit dedb6981 in
> drivers/net/wireless/orinoco/{orinoco,spectrum}_cs.c
>
> The patch for compat backports the newly added pcmcia_{read,write}_config_byte()
> functions in <pcmcia/ds.h>
>
> Thanks and regards.
Thank you, patches applied and pushed out!
Luis
^ permalink raw reply
* [PATCH] wireless: upcase alpha2 values in queue_regulatory_request
From: John W. Linville @ 2010-08-05 18:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
This provides a little more flexibility for human users, and it allows
us to use isalpha rather than the custom is_alpha_upper.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/reg.c | 16 +++++++---------
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index f180db0..b0d9a08 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -36,6 +36,7 @@
#include <linux/slab.h>
#include <linux/list.h>
#include <linux/random.h>
+#include <linux/ctype.h>
#include <linux/nl80211.h>
#include <linux/platform_device.h>
#include <net/cfg80211.h>
@@ -181,14 +182,6 @@ static bool is_alpha2_set(const char *alpha2)
return false;
}
-static bool is_alpha_upper(char letter)
-{
- /* ASCII A - Z */
- if (letter >= 65 && letter <= 90)
- return true;
- return false;
-}
-
static bool is_unknown_alpha2(const char *alpha2)
{
if (!alpha2)
@@ -220,7 +213,7 @@ static bool is_an_alpha2(const char *alpha2)
{
if (!alpha2)
return false;
- if (is_alpha_upper(alpha2[0]) && is_alpha_upper(alpha2[1]))
+ if (isalpha(alpha2[0]) && isalpha(alpha2[1]))
return true;
return false;
}
@@ -1399,6 +1392,11 @@ static DECLARE_WORK(reg_work, reg_todo);
static void queue_regulatory_request(struct regulatory_request *request)
{
+ if (isalpha(request->alpha2[0]))
+ request->alpha2[0] = toupper(request->alpha2[0]);
+ if (isalpha(request->alpha2[1]))
+ request->alpha2[1] = toupper(request->alpha2[1]);
+
spin_lock(®_requests_lock);
list_add_tail(&request->list, ®_requests_list);
spin_unlock(®_requests_lock);
--
1.7.2
^ permalink raw reply related
* [PATCH] iwlwifi: disable aspm by default
From: John W. Linville @ 2010-08-05 18:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Wey-Yi Guy, John W. Linville
Some iwlwifi devices inexplicably disconnect themselves from the PCI-E
bus causing the predictable failures. This seems to disappear if ASPM
is disabled.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 4 ++++
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 35337b1..49a7a98 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -33,6 +33,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/pci.h>
+#include <linux/pci-aspm.h>
#include <linux/slab.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
@@ -3968,6 +3969,9 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/**************************
* 2. Initializing PCI bus
**************************/
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+ PCIE_LINK_STATE_CLKPM);
+
if (pci_enable_device(pdev)) {
err = -ENODEV;
goto out_ieee80211_free_hw;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index d24eb47..bc08242 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -33,6 +33,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/pci.h>
+#include <linux/pci-aspm.h>
#include <linux/slab.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
@@ -3963,6 +3964,9 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
/***************************
* 2. Initializing PCI bus
* *************************/
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+ PCIE_LINK_STATE_CLKPM);
+
if (pci_enable_device(pdev)) {
err = -ENODEV;
goto out_ieee80211_free_hw;
--
1.7.2
^ permalink raw reply related
* Re: bdm 4353 802.11n monitor mode you can?
From: Arthur Moreira @ 2010-08-05 19:01 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4C5ADA52.40106@lwfinger.net>
Tk Larry
I will wait
I am from brazil and to buy in ebay is complicated
but, i will look in mercadolivre com br the symilar in brazil
but i dont want to buy a extra card for mobility, but i will see
i will wait the guys try to correct the wl driver.
tks all
off corse, sorry for my bad english.
Arthur Moreira
2010/8/5 Larry Finger <Larry.Finger@lwfinger.net>:
> On 08/05/2010 09:38 AM, Arthur Moreira wrote:
>> Tks Larry
>> I willl wait, the broadcom support team call for look the dell. And
>> the dell only windows driver.
>>
>> Larry i need much to can make a scan in networks, i work with network
>> secutiry and buyed a dell laptop, without knowing that it would take
>> this job.
>>
>> what you can do to help me or guide me I appreciate.
>>
>> you who work with creating the modules and drivers can not create a
>> module to put the card 802.11n broadcom 4353 chipset in monitor mode?
>> and packet injection?
>
> You can certainly use ndiswrapper and the Windows driver. My only question would
> be the stability of that configuration.
>
> Your other option would be to purchase a USB device that does support monitor
> mode. My favorite is the Netgear WG111V2, which uses the rtl8187 driver. These
> are available for ~$10 on Ebay. Any device that uses mac80211 should be capable
> of monitor mode. If you want both 2.4 and 5 GHz bands, then you can use a Dell
> Wireless 1450 USB adapter (Model D1450U). There is one on Ebay for $21.
>
> Reverse-engineering a complicated device like the Broadcom 802.11n chips is not
> trivial. We get no specifications or any help from Broadcom. Yes, we will be
> able to provide a driver with full capabilities; however, I have no idea when
> that will happen.
>
> Please do a "Reply-to-all" so that the mailing list archives have the full
> record of our mails.
>
> Larry
>
>
>
^ permalink raw reply
* Compat-wireless release for 2010-08-05 is baked
From: Compat-wireless cronjob account @ 2010-08-05 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
b2124fd..1bf4bba linux-2.6.35.y -> origin/linux-2.6.35.y
4b6128d..3672499 master -> origin/master
* [new tag] compat-wireless-v2.6.35-0 -> compat-wireless-v2.6.35-0
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
1b21e25..226b1c2 master -> origin/master
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
d9285f7..8a39b1f history -> origin/history
+ 262e79e...b07c08d master -> origin/master (forced update)
3a09b1b..3cfc2c4 stable -> origin/stable
* [new tag] next-20100805 -> next-20100805
compat-wireless code metrics
494547 - Total upstream lines of code being pulled
1532 - backport code changes
1296 - backport code additions
236 - backport code deletions
5805 - backport from compat module
7337 - total backport code
1.4836 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2463 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100805
compat-wireless release: compat-wireless-2010-08-03-1-g3672499
^ permalink raw reply
* Re: bdm 4353 802.11n monitor mode you can?
From: Larry Finger @ 2010-08-05 19:08 UTC (permalink / raw)
To: Arthur Moreira; +Cc: wireless
In-Reply-To: <AANLkTi=2qk6GExYE+daK4XHT5B22LpQxNZOdsrMrsmUx@mail.gmail.com>
On 08/05/2010 02:01 PM, Arthur Moreira wrote:
> Tk Larry
> I will wait
> I am from brazil and to buy in ebay is complicated
> but, i will look in mercadolivre com br the symilar in brazil
> but i dont want to buy a extra card for mobility, but i will see
>
> i will wait the guys try to correct the wl driver.
> tks all
>
> off corse, sorry for my bad english.
No problem. Your English is much better than my Portuguese.
Larry
^ permalink raw reply
* Re: ath5k : Channel 149 thru 161 not working with compat-wireless-2.6.34.1
From: Gopal Raman @ 2010-08-05 19:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTikcWNzO7tbheeJp=NYMsY=Kh983DrR2P=OKCJ5p@mail.gmail.com>
Jonathan Guerin <jonathan@...> writes:
>
> I found issues when switching to ath5k where the wrong antenna was selected.
>
> Try forcing the antenna (especially if you don't have 1 of them
> plugged in) and see how you go:
> http://www.mail-archive.com/ath5k-devel-xDcbHBWguxEUs3QNXV6qNA <at>
public.gmane.org/msg02979.html
>
Hi
I could not find the sysfs node where antenna control is being set in the
compat-wireless-2.6.34.1 driver. Maybe that was taken out ? To rule out
problems with my NIC card can anyone confirm that with this driver we can
receive frames on channels 149 thru 161 ?
Thanks much
-gopal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox