* Re: [PATCH 3.11] cfg80211: fix P2P GO interface teardown
From: Johannes Berg @ 2013-07-31 19:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1375297347-1380-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 21:02 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When a P2P GO interface goes down, cfg80211 doesn't properly
> tear it down, leading to warnings later. Add the GO interface
> type to the enumeration to tear it down like AP interfaces.
> Otherwise, we leave it pending and mac80211's state can get
> very confused, leading to warnings later.
Applied
(it's obvious and we've tested it for a while)
johannes
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: continue using disabled channels while connected
From: Johannes Berg @ 2013-07-31 19:17 UTC (permalink / raw)
To: linux-wireless; +Cc: chrisw
In-Reply-To: <1375297799-2023-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 21:09 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In case the AP has different regulatory information than we do,
> it can happen that we connect to an AP based on e.g. the world
> roaming regulatory data, and then update our database with the
> AP's country information disables the channel the AP is using.
> If this happens on an HT AP, the bandwidth tracking code will
> hit the WARN_ON() and disconnect. Since that's not very useful,
> ignore the channel-disable flag in bandwidth tracking.
Applied.
(ok, so this was a short time, but it's kinda an important fix ...)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix infinite loop in ieee80211_determine_chantype
From: Johannes Berg @ 2013-07-31 19:15 UTC (permalink / raw)
To: Chris Wright; +Cc: linux-wireless, Derek Atkins
In-Reply-To: <20130731191224.GB28308@sequoia2.sous-sol.org>
On Wed, 2013-07-31 at 12:12 -0700, Chris Wright wrote:
> Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
> infinite loop by moving the out target above the chandef_downgrade
> while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
> back up to re-run the while loop...indefinitely. Replace goto with
> break and carry on. This may not be sufficient to connect to the AP,
> but will at least keep the cpu from livelocking. Thanks to Derek Atkins
> as an extra pair of debugging eyes.
Applied, thanks.
johannes
^ permalink raw reply
* Re: pull request: bluetooth 2013-07-30
From: John W. Linville @ 2013-07-31 19:08 UTC (permalink / raw)
To: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20130730123848.GE5975@joana>
On Tue, Jul 30, 2013 at 01:38:48PM +0100, Gustavo Padovan wrote:
> Hi John,
>
> A few fixes and devices ID additions for 3.11:
>
> * There are 4 new ath3k device ids
> * Fixed stack memory usage in ath3k.
> * Fixed the init process of BlueFRITZ! devices, they were failing to init
> due to an unsupported command we sent.
> * Fixed wrong use of PTR_ERR in btusb code that was preventing intel devices
> to work properly.
> * Fixed race condition between hci_register_dev() and hci_dev_open() that
> could cause a NULL pointer dereference.
> * Fixed race condition that could call hci_req_cmd_complete() and make some
> devices to fail as showed in the log added to the commit message.
>
> Please pull or let me know of any issues. Thanks.
>
> Gustavo
>
> --
> The following changes since commit 075163bbb0f51174359947e1bce84f5edb23f21e:
>
> ath9k_htc: Handle IDLE state transition properly (2013-06-24 13:52:52 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
>
> for you to fetch changes up to 53e21fbc288218a423959f878c86471a0e323a9a:
>
> Bluetooth: Fix calling request callback more than once (2013-07-29 12:28:04 +0100)
Pulling now...
--
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
* [PATCH] mac80211: fix infinite loop in ieee80211_determine_chantype
From: Chris Wright @ 2013-07-31 19:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: Chris Wright, linux-wireless, Derek Atkins
In-Reply-To: <20130731132625.GA23521@sequoia2.sous-sol.org>
Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
infinite loop by moving the out target above the chandef_downgrade
while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
back up to re-run the while loop...indefinitely. Replace goto with
break and carry on. This may not be sufficient to connect to the AP,
but will at least keep the cpu from livelocking. Thanks to Derek Atkins
as an extra pair of debugging eyes.
Cc: stable@kernel.org
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0e5aab1..b68ca05 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -336,7 +336,7 @@ out:
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
- goto out;
+ break;
}
ret |= chandef_downgrade(chandef);
^ permalink raw reply related
* Re: [PATCH 3.11] mac80211: continue using disabled channels while connected
From: Johannes Berg @ 2013-07-31 19:10 UTC (permalink / raw)
To: linux-wireless; +Cc: chrisw
In-Reply-To: <1375297799-2023-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-31 at 21:09 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In case the AP has different regulatory information than we do,
> it can happen that we connect to an AP based on e.g. the world
> roaming regulatory data, and then update our database with the
> AP's country information disables the channel the AP is using.
> If this happens on an HT AP, the bandwidth tracking code will
> hit the WARN_ON() and disconnect. Since that's not very useful,
> ignore the channel-disable flag in bandwidth tracking.
>
> Reported-by: Chris Wright <chrisw@sous-sol.org>
> Tested-by: Chris Wright <chrisw@sous-sol.org>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Forgot Cc stable, will add.
johannes
^ permalink raw reply
* [PATCH 3.11] mac80211: continue using disabled channels while connected
From: Johannes Berg @ 2013-07-31 19:09 UTC (permalink / raw)
To: linux-wireless; +Cc: chrisw, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
In case the AP has different regulatory information than we do,
it can happen that we connect to an AP based on e.g. the world
roaming regulatory data, and then update our database with the
AP's country information disables the channel the AP is using.
If this happens on an HT AP, the bandwidth tracking code will
hit the WARN_ON() and disconnect. Since that's not very useful,
ignore the channel-disable flag in bandwidth tracking.
Reported-by: Chris Wright <chrisw@sous-sol.org>
Tested-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 77e7796..3df4fb3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -335,8 +335,17 @@ out:
if (ret & IEEE80211_STA_DISABLE_VHT)
vht_chandef = *chandef;
+ /*
+ * Ignore the DISABLED flag when we're already connected and only
+ * tracking the APs beacon for bandwidth changes - otherwise we
+ * might get disconnected here if we connect to an AP, update our
+ * regulatory information based on the AP's country IE and the
+ * information we have is wrong/outdated and disables the channel
+ * that we're actually using for the connection to the AP.
+ */
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
- IEEE80211_CHAN_DISABLED)) {
+ tracking ? 0 :
+ IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
--
1.8.0
^ permalink raw reply related
* [PATCH 3.11] cfg80211: fix P2P GO interface teardown
From: Johannes Berg @ 2013-07-31 19:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When a P2P GO interface goes down, cfg80211 doesn't properly
tear it down, leading to warnings later. Add the GO interface
type to the enumeration to tear it down like AP interfaces.
Otherwise, we leave it pending and mac80211's state can get
very confused, leading to warnings later.
Cc: stable@vger.kernel.org
Reported-by: Ilan Peer <ilan.peer@intel.com>
Tested-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4f9f216..a8c29fa4 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -765,6 +765,7 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,
cfg80211_leave_mesh(rdev, dev);
break;
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_P2P_GO:
cfg80211_stop_ap(rdev, dev);
break;
default:
--
1.8.0
^ permalink raw reply related
* CLI scan tool needed
From: Michael McElroy @ 2013-07-31 18:27 UTC (permalink / raw)
To: linux-wireless
I've done a lot of searching before posting but can't seem to find the answer.
Using the backports project, I have one of the latest ralink driver
going on an arm processor running 2.6.29 along with all nl80211 parts.
Works great, thank you! The last piece I need is to get the to SSID
list, their security protocols, and signal strength. I'm looking for
output similar to 'wilist scanning'. 'iw scan' gives a lot of info but
not quite what I need without a lot of massaging.
GUI based utilities won't work for my environment.Can anyone give me
some suggestions where to look?
Thanks,
Mike
^ permalink raw reply
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Ben Greear @ 2013-07-31 18:13 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Paul Stewart, Felix Fietkau, Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On 07/30/2013 05:53 PM, Luis R. Rodriguez wrote:
> Folks,
>
> Back in 2009 Intel had put out a wifi-test tree [0] but that seems
> deprecated now. The git tree at least is gone. Can someone confirm if
> that's dead? We later had Google present at the 2010 San Francisco
> wireless summit [1] their test infrastructure using autotest. Last I
> checked that stuff was not merged back upstream to autotest. Can
> someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
> internal testing infrastructures that obviously are not open.
>
> If we are to embark on a new journey towards an open testing
> infrastructure what should be used? Ben, you have some stuff, and I
> know you also report some interesting bugs with insane amount of
> stations. Is any of it open?
Our user-space app is not open. I'm happy to offer free licenses
for good causes, but I understand that is probably not so interesting to most
folks.
Our stuff only really works with ath9k (and possibly ath5k). Might
work in the future with ath10k if we can get the firmware and other
limitations resolved. And, maybe some other vendors will start
supporting lots of virtual stations..but I don't know of any others
at this time.
At the least, we'll keep running our internal testing & dev efforts
and will continue to report strange bugs :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Intel WiFi Link 4965AGN - Failed, HW not ready
From: Sedat Dilek @ 2013-07-31 18:06 UTC (permalink / raw)
To: Abdur Rehman; +Cc: linux-wireless, ilw
In-Reply-To: <51F94EEA.8040503@gespk.com>
On Wed, Jul 31, 2013 at 7:52 PM, Abdur Rehman <arqureshi@gespk.com> wrote:
> Hi we are unable to load the driver for Intel 4965agn module on a linux
> system.
> We are seeing "HW not ready" error. Please see the log below
>
Hi,
can't say who is "we"... but /me sees no Linux-kernel version!
Attach a full dmesg - it does not hurt together with your kernel-config file?
Do you have installed a firmware? What firmware-version do you use?
... (have a look into docs on <wireless.kernel.org>?)...
Make "we" "us" "you" "me" $(hello-)world happy :-)!
- Sedat -
> modprobe iwlagn
> [ 54.690000] cfg80211: Using static regulatory domain info
> [ 54.700000] cfg80211: Regulatory domain: US
> [ 54.710000] (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> [ 54.720000] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> [ 54.730000] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.740000] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.750000] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.760000] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 54.770000] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> [ 54.780000] cfg80211: Calling CRDA for country: US
> [ 55.080000] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
> 1.3.27k
> [ 55.090000] iwlagn: Copyright(c) 2003-2009 Intel Corporation
> [ 55.100000] PCI: enabling device 0000:04:00.0 (0000 -> 0002)
> [ 55.110000] iwlagn 0000:04:00.0: Detected Intel Wireless WiFi Link 4965AGN
> REV=0x0
> [ 55.120000] iwlagn 0000:04:00.0: Failed, HW not ready
> --
> 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
* Intel WiFi Link 4965AGN - Failed, HW not ready
From: Abdur Rehman @ 2013-07-31 17:52 UTC (permalink / raw)
To: linux-wireless, ilw
Hi we are unable to load the driver for Intel 4965agn module on a linux
system.
We are seeing "HW not ready" error. Please see the log below
modprobe iwlagn
[ 54.690000] cfg80211: Using static regulatory domain info
[ 54.700000] cfg80211: Regulatory domain: US
[ 54.710000] (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
[ 54.720000] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 54.730000] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.740000] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.750000] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.760000] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 54.770000] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 54.780000] cfg80211: Calling CRDA for country: US
[ 55.080000] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
1.3.27k
[ 55.090000] iwlagn: Copyright(c) 2003-2009 Intel Corporation
[ 55.100000] PCI: enabling device 0000:04:00.0 (0000 -> 0002)
[ 55.110000] iwlagn 0000:04:00.0: Detected Intel Wireless WiFi Link
4965AGN REV=0x0
[ 55.120000] iwlagn 0000:04:00.0: Failed, HW not ready
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Chris Wright @ 2013-07-31 17:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Chris Wright, linux-wireless, Derek Atkins
In-Reply-To: <20130731132625.GA23521@sequoia2.sous-sol.org>
* Chris Wright (chrisw@sous-sol.org) wrote:
> while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
> IEEE80211_CHAN_DISABLED)) {
> if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
> ret = IEEE80211_STA_DISABLE_HT |
> IEEE80211_STA_DISABLE_VHT;
> goto out;
> }
Actually, it just looks like this above loop is broken. Code flow is:
chandef->width = NL80211_CHAN_WIDTH_20;
...
if (!vht_oper || !sband->vht_cap.vht_supported) {
ret = IEEE80211_STA_DISABLE_VHT;
goto out;
}
...
out:
/* don't print the message below for VHT mismatch if VHT is disabled */
if (ret & IEEE80211_STA_DISABLE_VHT)
vht_chandef = *chandef;
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
goto out;
}
ret |= chandef_downgrade(chandef);
}
We enter the while loop w/ width NL80211_CHAN_WIDTH_20
(i.e. ht_cap.ht_supported is true), do one downgrade to
NL80211_CHAN_WIDTH_20_NOHT, and then we are stuck in a permanent loop.
I did not see any way that cfg80211_chandef_usable() will update chandef->width
so once width is NL80211_CHAN_WIDTH_20_NOHT and ht_cap.ht_supported is
true there is no end to the goto loop.
So here is a hack that at least gets wireless working (only because
there's another AP that's not got 11n enabled I believe).
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0e5aab1..b68ca05 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -336,7 +336,7 @@ out:
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
- goto out;
+ break;
}
ret |= chandef_downgrade(chandef);
^ permalink raw reply related
* Re: [PATCH 2/2] rtlwifi: sparse warnings: cast to restricted type
From: Larry Finger @ 2013-07-31 17:21 UTC (permalink / raw)
To: Mark Schulte; +Cc: linville, linux-wireless
In-Reply-To: <1375254507-26154-2-git-send-email-schultetwin@gmail.com>
On 07/31/2013 02:08 AM, Mark Schulte wrote:
> Adding type casts to suppress sparse warnings:
> * warning: cast to restricted __le32/__le16
>
> Signed-off-by: Mark Schulte <schultetwin@gmail.com>
> ---
> drivers/net/wireless/rtlwifi/ps.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
I think this patch is OK, but until I get a chance to test it on a big-endian
machine (PowerBook G4 Titanium), please do not apply it.
When I tried the patch, I discovered some kind of regression that causes a
kernel oops with an RTL8192CU device installed. This patch is not the problem,
but I will need to bisect the oops before I can test. The machine takes a long
time to build each kernel, thus it will probably be a while.
Larry
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 15:11 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F9276F.1040908@broadcom.com>
This is my hook: it gets called after I set dev to wlan0. I used a
guide for this and it seems to work for my notebook where I'm able to
find the 802.3 header but still no 802.11.
static int ptype_function(struct sk_buff *skb, struct net_device *dev,
struct packet_type *ptype, struct net_device *dev2);
static void throw_hook(struct net_device *dev){
ptype.type = htons(ETH_P_ALL);
ptype.func = &ptype_function;
ptype.dev = dev;
dev_add_pack(&ptype);
printk(KERN_CRIT "Done setting up packet type");
}
All code can be found here:
android: https://github.com/mathieudevos/kernelmodules/blob/master/ethernet_test.c
notebook: https://github.com/mathieudevos/wifi_kernelmodules/blob/master/ethernet_test.c
Kind regards,
Mathieu Devos
On Wed, Jul 31, 2013 at 5:04 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/31/2013 03:45 PM, Mathieu Devos wrote:
>>
>> Alright,
>>
>> Seems like I have fixed some issues while added some others. Since I
>> assume that when my hook gets activated the data pointer should be at
>> the start of the 802.3 header I casted an ethhdr (8023) on top of that
>> and it seems that on my notebook this is handled correctly (I can
>> actually check on my own mac addr and see that these frames are
>> for/from me).
>
>
> How does your hook work? Are you intercepting packets?
>
> Regards,
> Arend
>
>
>> On Wed, Jul 31, 2013 at 2:55 PM, Arend van Spriel <arend@broadcom.com>
>> wrote:
>>>
>>> On 07/31/2013 02:39 PM, Mathieu Devos wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> The wireless chip is a Broadcast BCM4330 chip. After looking around a
>>>> bit I found that this is a fullMAC and links to the driver on
>>>> wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
>>>> and also links directly to android itself:
>>>> https://android.googlesource.com/platform/hardware/broadcom/wlan
>>>
>>>
>>>
>>> I suspected. The bcm4330 is indeed a fullmac device, which means the
>>> 802.11
>>> stack is running on the device. The driver on Android is located under:
>>>
>>>
>>> https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-ics-mr1/drivers/net/wireless/bcmdhd/
>>>
>>> Not sure which android version you have.
>>>
>>> The brcm80211 on wireless.kernel.org is the upstream linux driver.
>>>
>>> Gr. AvS
>>>
>>>
>>>> Still trying to learn a lot in this tightly packed world of protocol
>>>> stacks, wireless and all the other poisons. Seems like I still have a
>>>> long way to go. Thank you already for helping me out with these issues
>>>> and taking the time to explain these things to me.
>>>>
>>>> Kind regards,
>>>> Mathieu Devos
>>>>
>>>> On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>>>>>> have a normal ethernet 802.3 input even. I check before selecting the
>>>>>> device that it's wireless (through ieee80211_ptr) and this properly
>>>>>> returns the wlan0 device which should be on the 80211 standard.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *sigh* Welcome in the world of protocol stacks, wireless, networking
>>>>> (choose
>>>>> your poison). Let me draw the picture.
>>>>>
>>>>> o user-space
>>>>> |
>>>>> ----------------------
>>>>> | kernel
>>>>> +-----------+
>>>>> | NET | networking subsystem, ie. TCP/IP stack
>>>>> +-----------+
>>>>> | 802.3
>>>>> +----------------+
>>>>> | | driver |
>>>>> | +------------+ |
>>>>> | |802.11 stack| |
>>>>> | +------------+ |
>>>>> | | 802.11 |
>>>>> +----------------+
>>>>> |
>>>>> o RF
>>>>>
>>>>> The device hooks up to the networking subsystem as an ethernet device
>>>>> and
>>>>> as
>>>>> such it receives 802.3 packets. These are converted to 802.11 packets
>>>>> by
>>>>> the
>>>>> 802.11 stack. Now depending on your device that happens in the device
>>>>> driver
>>>>> or on the device itself. Another option is that this is done by
>>>>> mac80211
>>>>> (kernel provided 802.11 stack), but that is probably not the case, but
>>>>> to
>>>>> be
>>>>> sure I ask again: what wireless device do you have in your galaxy S2?
>>>>>
>>>>> Gr. AvS
>>>>>
>>>>>
>>>>>> My goal is to get the ieee80211_header properly on the skb with this
>>>>>> device, but some of the pointers and original data in the skb seem
>>>>>> totally off. This leaves me clueless as to where to put this
>>>>>> ieee80211_header.
>>>>>> I've tried putting it right on skb->head (wrong I know, but I was
>>>>>> getting desperate), on skb->mac_header (also wrong, no idea why
>>>>>> though), I went back from skb->tail with len and even added ETH_HLEN
>>>>>> to that as well because you can see that before my hook gets
>>>>>> activated: skb_pull_inline(skb, ETH_HLEN);
>>>>>> In the end I'm left with a header that is forced onto data but with a
>>>>>> wrong origin pointer thus basically leaving me with all wrong data in
>>>>>> the header.
>>>>>>
>>>>>> Kind regards,
>>>>>> Mathieu Devos
>>>>>>
>>>>>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel
>>>>>> <arend@broadcom.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I hope this is the right place to ask for a little bit of help as
>>>>>>>> I'm
>>>>>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>>>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>>>>>> to print information about the mac addresses (addr1->addr4) and
>>>>>>>> later
>>>>>>>> down the road try to send my own data.
>>>>>>>>
>>>>>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>>>>>> ieee80211 based on input from skb would be huge for me.
>>>>>>>>
>>>>>>>> So my issue: when placing the ieee80211 on my mac_header after I
>>>>>>>> hook
>>>>>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Not sure what you goal is, but what wireless device is that? You may
>>>>>>> just
>>>>>>> get 802.3 packets from the device.
>>>>>>>
>>>>>>> Gr. AvS
>>>>>>>
>>>>>>>
>>>>>>>> I get a huge
>>>>>>>> amount of zero's and random(?) numbers when trying to print the
>>>>>>>> addresses. This leads me to the first conclusion that mac_header is
>>>>>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>>>>>> using the skb->data pointer. Now this gives even weirder issues for
>>>>>>>> me
>>>>>>>> and actually totally crashes my kernel.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Andy Isaacson @ 2013-07-31 15:09 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Arkadiusz Miskiewicz, Stanislaw Gruszka,
Johannes Berg
In-Reply-To: <1375264234-31077-1-git-send-email-johannes@sipsolutions.net>
On Wed, Jul 31, 2013 at 11:50:34AM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> While we're connected, the AP shouldn't change the primary channel
> in the HT information. We checked this, and dropped the connection
> if it did change it.
>
> Unfortunately, this is causing problems on some APs, e.g. on the
> Netgear WRT610NL: the beacons seem to always contain a bad channel
> and if we made a connection using a probe response (correct data)
> we drop the connection immediately and can basically not connect
> properly at all.
>
> Work around this by ignoring the HT primary channel information in
> beacons if we're already connected.
>
> Also print out more verbose messages in the other situations to
> help diagnose similar bugs quicker in the future.
>
> Cc: stable@vger.kernel.org [3.10]
Acked-by: Andy Isaacson <adi@hexapodia.org>
LGTM. Wasn't able to test though. Recommend this for -stable,
regressing wifi connectivity makes it hard to report bugs.
-andy
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Arend van Spriel @ 2013-07-31 15:04 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless
In-Reply-To: <CAE_+Soy4Hy+uMAsn30PX9QpqY=Jah2f5qUCa=MkCskJczQB05w@mail.gmail.com>
On 07/31/2013 03:45 PM, Mathieu Devos wrote:
> Alright,
>
> Seems like I have fixed some issues while added some others. Since I
> assume that when my hook gets activated the data pointer should be at
> the start of the 802.3 header I casted an ethhdr (8023) on top of that
> and it seems that on my notebook this is handled correctly (I can
> actually check on my own mac addr and see that these frames are
> for/from me).
How does your hook work? Are you intercepting packets?
Regards,
Arend
> On Wed, Jul 31, 2013 at 2:55 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 07/31/2013 02:39 PM, Mathieu Devos wrote:
>>>
>>> Hi,
>>>
>>> The wireless chip is a Broadcast BCM4330 chip. After looking around a
>>> bit I found that this is a fullMAC and links to the driver on
>>> wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
>>> and also links directly to android itself:
>>> https://android.googlesource.com/platform/hardware/broadcom/wlan
>>
>>
>> I suspected. The bcm4330 is indeed a fullmac device, which means the 802.11
>> stack is running on the device. The driver on Android is located under:
>>
>> https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-ics-mr1/drivers/net/wireless/bcmdhd/
>>
>> Not sure which android version you have.
>>
>> The brcm80211 on wireless.kernel.org is the upstream linux driver.
>>
>> Gr. AvS
>>
>>
>>> Still trying to learn a lot in this tightly packed world of protocol
>>> stacks, wireless and all the other poisons. Seems like I still have a
>>> long way to go. Thank you already for helping me out with these issues
>>> and taking the time to explain these things to me.
>>>
>>> Kind regards,
>>> Mathieu Devos
>>>
>>> On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com>
>>> wrote:
>>>>
>>>> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>>>>> have a normal ethernet 802.3 input even. I check before selecting the
>>>>> device that it's wireless (through ieee80211_ptr) and this properly
>>>>> returns the wlan0 device which should be on the 80211 standard.
>>>>
>>>>
>>>>
>>>> *sigh* Welcome in the world of protocol stacks, wireless, networking
>>>> (choose
>>>> your poison). Let me draw the picture.
>>>>
>>>> o user-space
>>>> |
>>>> ----------------------
>>>> | kernel
>>>> +-----------+
>>>> | NET | networking subsystem, ie. TCP/IP stack
>>>> +-----------+
>>>> | 802.3
>>>> +----------------+
>>>> | | driver |
>>>> | +------------+ |
>>>> | |802.11 stack| |
>>>> | +------------+ |
>>>> | | 802.11 |
>>>> +----------------+
>>>> |
>>>> o RF
>>>>
>>>> The device hooks up to the networking subsystem as an ethernet device and
>>>> as
>>>> such it receives 802.3 packets. These are converted to 802.11 packets by
>>>> the
>>>> 802.11 stack. Now depending on your device that happens in the device
>>>> driver
>>>> or on the device itself. Another option is that this is done by mac80211
>>>> (kernel provided 802.11 stack), but that is probably not the case, but to
>>>> be
>>>> sure I ask again: what wireless device do you have in your galaxy S2?
>>>>
>>>> Gr. AvS
>>>>
>>>>
>>>>> My goal is to get the ieee80211_header properly on the skb with this
>>>>> device, but some of the pointers and original data in the skb seem
>>>>> totally off. This leaves me clueless as to where to put this
>>>>> ieee80211_header.
>>>>> I've tried putting it right on skb->head (wrong I know, but I was
>>>>> getting desperate), on skb->mac_header (also wrong, no idea why
>>>>> though), I went back from skb->tail with len and even added ETH_HLEN
>>>>> to that as well because you can see that before my hook gets
>>>>> activated: skb_pull_inline(skb, ETH_HLEN);
>>>>> In the end I'm left with a header that is forced onto data but with a
>>>>> wrong origin pointer thus basically leaving me with all wrong data in
>>>>> the header.
>>>>>
>>>>> Kind regards,
>>>>> Mathieu Devos
>>>>>
>>>>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I hope this is the right place to ask for a little bit of help as I'm
>>>>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>>>>> to print information about the mac addresses (addr1->addr4) and later
>>>>>>> down the road try to send my own data.
>>>>>>>
>>>>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>>>>> ieee80211 based on input from skb would be huge for me.
>>>>>>>
>>>>>>> So my issue: when placing the ieee80211 on my mac_header after I hook
>>>>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not sure what you goal is, but what wireless device is that? You may
>>>>>> just
>>>>>> get 802.3 packets from the device.
>>>>>>
>>>>>> Gr. AvS
>>>>>>
>>>>>>
>>>>>>> I get a huge
>>>>>>> amount of zero's and random(?) numbers when trying to print the
>>>>>>> addresses. This leads me to the first conclusion that mac_header is
>>>>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>>>>> using the skb->data pointer. Now this gives even weirder issues for me
>>>>>>> and actually totally crashes my kernel.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] rtlwifi: rtl8192cu: fix function declaration header
From: Larry Finger @ 2013-07-31 15:02 UTC (permalink / raw)
To: Mark Schulte; +Cc: linville, linux-wireless
In-Reply-To: <1375254507-26154-1-git-send-email-schultetwin@gmail.com>
On 07/31/2013 02:08 AM, Mark Schulte wrote:
> Move rtl92cu_update_hal_rate_tbl declartion to hw.h to correspond with function
-------^
> definition in hw.c
>
> Signed-off-by: Mark Schulte <schultetwin@gmail.com>
> ---
Please fix the typo above. In addition, please modify the commit message to note
that this change fixes a sparse warning in hw.c. Other than those two comments,
the patch is OK.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
> drivers/net/wireless/rtlwifi/rtl8192cu/hw.h | 3 +++
> drivers/net/wireless/rtlwifi/rtl8192cu/sw.h | 3 ---
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
> index 8e3ec1e..0f7812e 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
> @@ -109,5 +109,8 @@ void rtl92c_set_fw_joinbss_report_cmd(struct ieee80211_hw *hw, u8 mstatus);
> void rtl92c_fill_h2c_cmd(struct ieee80211_hw *hw,
> u8 element_id, u32 cmd_len, u8 *p_cmdbuffer);
> bool rtl92cu_phy_mac_config(struct ieee80211_hw *hw);
> +void rtl92cu_update_hal_rate_tbl(struct ieee80211_hw *hw,
> + struct ieee80211_sta *sta,
> + u8 rssi_level);
>
> #endif
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
> index 262e1e4..a1310ab 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
> @@ -49,8 +49,5 @@ bool rtl92cu_phy_set_rf_power_state(struct ieee80211_hw *hw,
> u32 rtl92cu_phy_query_rf_reg(struct ieee80211_hw *hw,
> enum radio_path rfpath, u32 regaddr, u32 bitmask);
> void rtl92cu_phy_set_bw_mode_callback(struct ieee80211_hw *hw);
> -void rtl92cu_update_hal_rate_tbl(struct ieee80211_hw *hw,
> - struct ieee80211_sta *sta,
> - u8 rssi_level);
>
> #endif
>
^ permalink raw reply
* Re: 3.10, iwlwifi 6200AGN: AP changed bandwidth in a way we can't support - disconnect
From: Johannes Berg @ 2013-07-31 14:59 UTC (permalink / raw)
To: Andy Isaacson
Cc: Stanislaw Gruszka, linux-wireless, netdev, Arkadiusz Miskiewicz
In-Reply-To: <20130731145737.GC31017@hexapodia.org>
On Wed, 2013-07-31 at 07:57 -0700, Andy Isaacson wrote:
> On Wed, Jul 31, 2013 at 10:59:56AM +0200, Stanislaw Gruszka wrote:
> > We have few reports about this. Johannes, proposed this patch
> > http://p.sipsolutions.net/9d1dd0734d2c3a7a.txt
> >
> > Could you check if it fixes the problem for you?
>
> I unfortunately didn't get a chance to confirm before leaving Berlin,
> but the patch Johannes posted in the other thread seems to agree with my
> analysis of the problem, and Johannes confirmed from my pcap that it
> is the same problem.
I think we have two problems - the one you have should be fixed by the
patch I posted (not the one above) but the problem Chris is running into
has a WARN_ON() and isn't fixed.
johannes
^ permalink raw reply
* Re: 3.10, iwlwifi 6200AGN: AP changed bandwidth in a way we can't support - disconnect
From: Andy Isaacson @ 2013-07-31 14:57 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Johannes Berg, linux-wireless, netdev, Arkadiusz Miskiewicz
In-Reply-To: <20130731085956.GC1681@redhat.com>
On Wed, Jul 31, 2013 at 10:59:56AM +0200, Stanislaw Gruszka wrote:
> We have few reports about this. Johannes, proposed this patch
> http://p.sipsolutions.net/9d1dd0734d2c3a7a.txt
>
> Could you check if it fixes the problem for you?
I unfortunately didn't get a chance to confirm before leaving Berlin,
but the patch Johannes posted in the other thread seems to agree with my
analysis of the problem, and Johannes confirmed from my pcap that it
is the same problem.
-andy
^ permalink raw reply
* Re: [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Chris Wright @ 2013-07-31 13:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1375264234-31077-1-git-send-email-johannes@sipsolutions.net>
* Johannes Berg (johannes@sipsolutions.net) wrote:
> While we're connected, the AP shouldn't change the primary channel
> in the HT information. We checked this, and dropped the connection
> if it did change it.
>
> Unfortunately, this is causing problems on some APs, e.g. on the
> Netgear WRT610NL: the beacons seem to always contain a bad channel
> and if we made a connection using a probe response (correct data)
> we drop the connection immediately and can basically not connect
> properly at all.
>
> Work around this by ignoring the HT primary channel information in
> beacons if we're already connected.
>
> Also print out more verbose messages in the other situations to
> help diagnose similar bugs quicker in the future.
I just gave this a try, and my laptop is still hanging w/ same WARN_ON
being triggered:
...
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
goto out;
}
...
Jul 31 05:45:10 x220 kernel: [ 40.047670] wlp3s0: authenticate with 2c:36:f8:fa:46:21
Jul 31 05:45:10 x220 kernel: [ 40.053635] wlp3s0: send auth to 2c:36:f8:fa:46:21 (try 1/3)
Jul 31 05:45:10 x220 kernel: [ 40.146302] wlp3s0: authenticated
Jul 31 05:45:10 x220 kernel: [ 40.146675] wlp3s0: waiting for beacon from 2c:36:f8:fa:46:21
Jul 31 05:45:11 x220 kernel: [ 40.250878] wlp3s0: associate with 2c:36:f8:fa:46:21 (try 1/3)
Jul 31 05:45:11 x220 kernel: [ 40.254241] wlp3s0: RX AssocResp from 2c:36:f8:fa:46:21 (capab=0x101 status=0 aid=3)
Jul 31 05:45:11 x220 kernel: [ 40.275168] wlp3s0: associated
Jul 31 05:45:11 x220 kernel: [ 40.275252] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
Jul 31 05:45:11 x220 kernel: [ 40.275385] cfg80211: Calling CRDA for country: DE
Jul 31 05:45:11 x220 kernel: [ 40.296753] cfg80211: Regulatory domain changed to country: DE
Jul 31 05:45:11 x220 kernel: [ 40.296763] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 31 05:45:11 x220 kernel: [ 40.296769] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 31 05:45:11 x220 kernel: [ 40.296774] cfg80211: (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 31 05:45:11 x220 kernel: [ 40.296778] cfg80211: (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 31 05:45:11 x220 kernel: [ 40.296782] cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
Jul 31 05:45:11 x220 kernel: [ 40.296787] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
Jul 31 05:45:11 x220 NetworkManager[574]: <info> (wlp3s0): supplicant interface state: scanning -> authenticating
Jul 31 05:45:11 x220 NetworkManager[574]: <info> (wlp3s0): supplicant interface state: authenticating -> associating
Jul 31 05:45:11 x220 NetworkManager[574]: <info> (wlp3s0): supplicant interface state: associating -> completed
Jul 31 05:45:11 x220 NetworkManager[574]: <info> Activation (wlp3s0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'ietf'.
Jul 31 05:45:11 x220 NetworkManager[574]: <info> Activation (wlp3s0) Stage 3 of 5 (IP Configure Start) scheduled.
Jul 31 05:45:11 x220 NetworkManager[574]: <info> Activation (wlp3s0) Stage 3 of 5 (IP Configure Start) started...
Jul 31 05:45:11 x220 NetworkManager[574]: <info> (wlp3s0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jul 31 05:45:11 x220 NetworkManager[574]: <info> Activation (wlp3s0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Jul 31 05:45:11 x220 NetworkManager[574]: <info> dhclient started with pid 1786
Jul 31 05:45:11 x220 NetworkManager[574]: <info> Activation (wlp3s0) Beginning IP6 addrconf.
Jul 31 05:45:11 x220 NetworkManager[574]: <info> Activation (wlp3s0) Stage 3 of 5 (IP Configure Start) complete.
Jul 31 05:45:11 x220 kernel: [ 40.354582] ------------[ cut here ]------------
Jul 31 05:45:11 x220 kernel: [ 40.354628] WARNING: CPU: 2 PID: 85 at net/mac80211/mlme.c:338 ieee80211_determine_chantype+0x26f/0x380 [mac80211]()
Jul 31 05:45:11 x220 kernel: [ 40.354631] Modules linked in: ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle tun bridge openvswitch stp llc bnep bluetooth arc4 iwldvm ip6t_REJECT nf_conntrack_ipv6 nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables xt_conntrack nf_conntrack mac80211 iwlwifi snd_hda_codec_hdmi uvcvideo snd_hda_codec_conexant cfg80211 snd_hda_intel videobuf2_vmalloc snd_hda_codec videobuf2_memops videobuf2_core snd_hwdep iTCO_wdt videodev iTCO_vendor_support snd_seq media snd_seq_device sdhci_pci sdhci snd_pcm e1000e i2c_i801 joydev mmc_core lpc_ich mfd_core thinkpad_acpi tpm_tis wmi tpm rfkill snd_page_alloc tpm_bios snd_timer snd ptp soundcore pps_core mperf uinput binfmt_misc dm_crypt i915 i2c_algo_bit drm_kms_helper drm i2c_core video
Jul 31 05:45:11 x220 kernel: [ 40.354715] CPU: 2 PID: 85 Comm: kworker/u16:4 Not tainted 3.11.0-rc3+ #7
Jul 31 05:45:11 x220 kernel: [ 40.354720] Hardware name: LENOVO 4291CL9/4291CL9, BIOS 8DET56WW (1.26 ) 12/01/2011
Jul 31 05:45:11 x220 kernel: [ 40.354744] Workqueue: phy0 ieee80211_iface_work [mac80211]
Jul 31 05:45:11 x220 kernel: [ 40.354748] 0000000000000009 ffff880403cff9d8 ffffffff8160bd12 0000000000000000
Jul 31 05:45:11 x220 kernel: [ 40.354754] ffff880403cffa10 ffffffff8105393d ffff880403cffae0 0000000000000810
Jul 31 05:45:11 x220 kernel: [ 40.354759] ffff8803f6638800 0000000000000001 ffff8803f3e37070 ffff880403cffa20
Jul 31 05:45:11 x220 kernel: [ 40.354765] Call Trace:
Jul 31 05:45:11 x220 kernel: [ 40.354776] [<ffffffff8160bd12>] dump_stack+0x45/0x56
Jul 31 05:45:11 x220 kernel: [ 40.354784] [<ffffffff8105393d>] warn_slowpath_common+0x7d/0xa0
Jul 31 05:45:11 x220 kernel: [ 40.354791] [<ffffffff81053a1a>] warn_slowpath_null+0x1a/0x20
Jul 31 05:45:11 x220 kernel: [ 40.354819] [<ffffffffa040be2f>] ieee80211_determine_chantype+0x26f/0x380 [mac80211]
Jul 31 05:45:11 x220 kernel: [ 40.354852] [<ffffffffa040f209>] ieee80211_rx_mgmt_beacon+0x589/0x10f0 [mac80211]
Jul 31 05:45:11 x220 kernel: [ 40.354885] [<ffffffffa04111d3>] ieee80211_sta_rx_queued_mgmt+0x2b3/0x530 [mac80211]
Jul 31 05:45:11 x220 kernel: [ 40.354931] [<ffffffff81092d74>] ? load_balance+0x144/0x790
Jul 31 05:45:11 x220 kernel: [ 40.354962] [<ffffffffa03e31cc>] ieee80211_iface_work+0x25c/0x360 [mac80211]
Jul 31 05:45:11 x220 kernel: [ 40.354971] [<ffffffff8107131f>] process_one_work+0x16f/0x420
Jul 31 05:45:11 x220 kernel: [ 40.354979] [<ffffffff81071f3b>] worker_thread+0x11b/0x390
Jul 31 05:45:11 x220 kernel: [ 40.354987] [<ffffffff81071e20>] ? manage_workers.isra.25+0x2a0/0x2a0
Jul 31 05:45:11 x220 kernel: [ 40.354994] [<ffffffff810784a0>] kthread+0xc0/0xd0
Jul 31 05:45:11 x220 kernel: [ 40.355002] [<ffffffff810783e0>] ? insert_kthread_work+0x40/0x40
Jul 31 05:45:11 x220 kernel: [ 40.355010] [<ffffffff8161af1c>] ret_from_fork+0x7c/0xb0
Jul 31 05:45:11 x220 kernel: [ 40.355017] [<ffffffff810783e0>] ? insert_kthread_work+0x40/0x40
Jul 31 05:45:11 x220 kernel: [ 40.355022] ---[ end trace a4924d352b62426c ]---
And this continues until I hit power switch. Any specific debugging that would
be helpful?
thanks,
-chris
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 13:45 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F90937.9080009@broadcom.com>
Alright,
Seems like I have fixed some issues while added some others. Since I
assume that when my hook gets activated the data pointer should be at
the start of the 802.3 header I casted an ethhdr (8023) on top of that
and it seems that on my notebook this is handled correctly (I can
actually check on my own mac addr and see that these frames are
for/from me).
The issue with android: the data pointer (see previous mails) is
totally off and causes a full blown kernel crash. Trying to set it
manually leaves me with nothing really. Could more information about
skb->data manipulation be in those drivers and is there a reason why
not everything is ended with the same data structure (thus
standardizing the part where the hook comes in). My next issue is with
mac_header that seems off just as much in both my notebook LKM and in
my android device (when casting 8023 or 80211 headers on them they
deliver totally wrong headers).
Somebody in the office told me that the 8023 header is added after the
80211 and thus to my logic when casting skb->data -
sizeof(*wirelessheader) I should end at the start of the 80211 header.
This however is wrong, are there more padding bytes present and if so,
how much would I have to move the pointer or is do I have to use a
whole other function for this.
A quick remark as to why I'm doing all this stuff: this is preparation
for my master thesis where I'll be researching the possibility of RINA
(instead of TCP/IP) in the wireless stack (android specifically).
Since this is preparation work I'd love to end this with just having
an sk_buff with correctly placed 802.3 header (works on my notebook,
not on android device) and with a properly set up 802.11 header (so I
can later on map functions from/to rina to 802.3/802.11).
Thanks again for the quick answers and the already provided help.
Kind regards,
Mathieu Devos
On Wed, Jul 31, 2013 at 2:55 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/31/2013 02:39 PM, Mathieu Devos wrote:
>>
>> Hi,
>>
>> The wireless chip is a Broadcast BCM4330 chip. After looking around a
>> bit I found that this is a fullMAC and links to the driver on
>> wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
>> and also links directly to android itself:
>> https://android.googlesource.com/platform/hardware/broadcom/wlan
>
>
> I suspected. The bcm4330 is indeed a fullmac device, which means the 802.11
> stack is running on the device. The driver on Android is located under:
>
> https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-ics-mr1/drivers/net/wireless/bcmdhd/
>
> Not sure which android version you have.
>
> The brcm80211 on wireless.kernel.org is the upstream linux driver.
>
> Gr. AvS
>
>
>> Still trying to learn a lot in this tightly packed world of protocol
>> stacks, wireless and all the other poisons. Seems like I still have a
>> long way to go. Thank you already for helping me out with these issues
>> and taking the time to explain these things to me.
>>
>> Kind regards,
>> Mathieu Devos
>>
>> On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com>
>> wrote:
>>>
>>> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>>>> have a normal ethernet 802.3 input even. I check before selecting the
>>>> device that it's wireless (through ieee80211_ptr) and this properly
>>>> returns the wlan0 device which should be on the 80211 standard.
>>>
>>>
>>>
>>> *sigh* Welcome in the world of protocol stacks, wireless, networking
>>> (choose
>>> your poison). Let me draw the picture.
>>>
>>> o user-space
>>> |
>>> ----------------------
>>> | kernel
>>> +-----------+
>>> | NET | networking subsystem, ie. TCP/IP stack
>>> +-----------+
>>> | 802.3
>>> +----------------+
>>> | | driver |
>>> | +------------+ |
>>> | |802.11 stack| |
>>> | +------------+ |
>>> | | 802.11 |
>>> +----------------+
>>> |
>>> o RF
>>>
>>> The device hooks up to the networking subsystem as an ethernet device and
>>> as
>>> such it receives 802.3 packets. These are converted to 802.11 packets by
>>> the
>>> 802.11 stack. Now depending on your device that happens in the device
>>> driver
>>> or on the device itself. Another option is that this is done by mac80211
>>> (kernel provided 802.11 stack), but that is probably not the case, but to
>>> be
>>> sure I ask again: what wireless device do you have in your galaxy S2?
>>>
>>> Gr. AvS
>>>
>>>
>>>> My goal is to get the ieee80211_header properly on the skb with this
>>>> device, but some of the pointers and original data in the skb seem
>>>> totally off. This leaves me clueless as to where to put this
>>>> ieee80211_header.
>>>> I've tried putting it right on skb->head (wrong I know, but I was
>>>> getting desperate), on skb->mac_header (also wrong, no idea why
>>>> though), I went back from skb->tail with len and even added ETH_HLEN
>>>> to that as well because you can see that before my hook gets
>>>> activated: skb_pull_inline(skb, ETH_HLEN);
>>>> In the end I'm left with a header that is forced onto data but with a
>>>> wrong origin pointer thus basically leaving me with all wrong data in
>>>> the header.
>>>>
>>>> Kind regards,
>>>> Mathieu Devos
>>>>
>>>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I hope this is the right place to ask for a little bit of help as I'm
>>>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>>>> to print information about the mac addresses (addr1->addr4) and later
>>>>>> down the road try to send my own data.
>>>>>>
>>>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>>>> ieee80211 based on input from skb would be huge for me.
>>>>>>
>>>>>> So my issue: when placing the ieee80211 on my mac_header after I hook
>>>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not sure what you goal is, but what wireless device is that? You may
>>>>> just
>>>>> get 802.3 packets from the device.
>>>>>
>>>>> Gr. AvS
>>>>>
>>>>>
>>>>>> I get a huge
>>>>>> amount of zero's and random(?) numbers when trying to print the
>>>>>> addresses. This leads me to the first conclusion that mac_header is
>>>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>>>> using the skb->data pointer. Now this gives even weirder issues for me
>>>>>> and actually totally crashes my kernel.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
From: Balaji T K @ 2013-07-31 13:08 UTC (permalink / raw)
To: Luciano Coelho
Cc: tony, linux-omap, devicetree, linux-arm-kernel, linux-wireless,
luca, balbi, laurent.pinchart
In-Reply-To: <1375218923-29876-2-git-send-email-coelho@ti.com>
On Wednesday 31 July 2013 02:45 AM, Luciano Coelho wrote:
> Add regulator, pin muxing and MMC5 configuration to be used by the
> on-board WiLink6 module.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index faa95b5..b3f6e1f 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -107,6 +107,16 @@
> */
> clock-frequency = <19200000>;
> };
> +
> + wilink_wl_en: fixedregulator@1 {
> + compatible = "regulator-fixed";
> + regulator-name = "wilink_wl_en";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&gpio2 11 0>; /* gpio line 43 */
> + startup-delay-us = <70000>;
> + enable-active-high;
> + };
> };
>
> &omap4_pmx_wkup {
> @@ -132,6 +142,7 @@
> &dss_hdmi_pins
> &tpd12s015_pins
> &hsusbb1_pins
> + &wilink_pins
> >;
>
> twl6030_pins: pinmux_twl6030_pins {
> @@ -235,6 +246,19 @@
> 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
> >;
> };
> +
> + wilink_pins: pinmux_wilink_pins {
> + pinctrl-single,pins = <
> + 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
> + 0x66 0x3 /* gpio_43 OUTPUT | MODE3 */
> + 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
> + 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
> + 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
> + 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
> + 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
> + 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
Hi,
Since the base for omap4_pmx_core is 0x4a100040, you need to offset 0x40 from
pad address :-)
and can you please use INPUT_EN / PIN_INPUT_PULLUP / MUX_MODEx macros
(from dt-bindings/pinctrl/omap.h)
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Arend van Spriel @ 2013-07-31 12:55 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless
In-Reply-To: <CAE_+SozB3cE36SKaHsyO9B1Eypm7KZFExV_uWBSsoiQ-Rn66Dw@mail.gmail.com>
On 07/31/2013 02:39 PM, Mathieu Devos wrote:
> Hi,
>
> The wireless chip is a Broadcast BCM4330 chip. After looking around a
> bit I found that this is a fullMAC and links to the driver on
> wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
> and also links directly to android itself:
> https://android.googlesource.com/platform/hardware/broadcom/wlan
I suspected. The bcm4330 is indeed a fullmac device, which means the
802.11 stack is running on the device. The driver on Android is located
under:
https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-ics-mr1/drivers/net/wireless/bcmdhd/
Not sure which android version you have.
The brcm80211 on wireless.kernel.org is the upstream linux driver.
Gr. AvS
> Still trying to learn a lot in this tightly packed world of protocol
> stacks, wireless and all the other poisons. Seems like I still have a
> long way to go. Thank you already for helping me out with these issues
> and taking the time to explain these things to me.
>
> Kind regards,
> Mathieu Devos
>
> On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>>
>>> Hi,
>>>
>>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>>> have a normal ethernet 802.3 input even. I check before selecting the
>>> device that it's wireless (through ieee80211_ptr) and this properly
>>> returns the wlan0 device which should be on the 80211 standard.
>>
>>
>> *sigh* Welcome in the world of protocol stacks, wireless, networking (choose
>> your poison). Let me draw the picture.
>>
>> o user-space
>> |
>> ----------------------
>> | kernel
>> +-----------+
>> | NET | networking subsystem, ie. TCP/IP stack
>> +-----------+
>> | 802.3
>> +----------------+
>> | | driver |
>> | +------------+ |
>> | |802.11 stack| |
>> | +------------+ |
>> | | 802.11 |
>> +----------------+
>> |
>> o RF
>>
>> The device hooks up to the networking subsystem as an ethernet device and as
>> such it receives 802.3 packets. These are converted to 802.11 packets by the
>> 802.11 stack. Now depending on your device that happens in the device driver
>> or on the device itself. Another option is that this is done by mac80211
>> (kernel provided 802.11 stack), but that is probably not the case, but to be
>> sure I ask again: what wireless device do you have in your galaxy S2?
>>
>> Gr. AvS
>>
>>
>>> My goal is to get the ieee80211_header properly on the skb with this
>>> device, but some of the pointers and original data in the skb seem
>>> totally off. This leaves me clueless as to where to put this
>>> ieee80211_header.
>>> I've tried putting it right on skb->head (wrong I know, but I was
>>> getting desperate), on skb->mac_header (also wrong, no idea why
>>> though), I went back from skb->tail with len and even added ETH_HLEN
>>> to that as well because you can see that before my hook gets
>>> activated: skb_pull_inline(skb, ETH_HLEN);
>>> In the end I'm left with a header that is forced onto data but with a
>>> wrong origin pointer thus basically leaving me with all wrong data in
>>> the header.
>>>
>>> Kind regards,
>>> Mathieu Devos
>>>
>>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com>
>>> wrote:
>>>>
>>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I hope this is the right place to ask for a little bit of help as I'm
>>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>>> to print information about the mac addresses (addr1->addr4) and later
>>>>> down the road try to send my own data.
>>>>>
>>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>>> ieee80211 based on input from skb would be huge for me.
>>>>>
>>>>> So my issue: when placing the ieee80211 on my mac_header after I hook
>>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>>
>>>>
>>>>
>>>> Not sure what you goal is, but what wireless device is that? You may just
>>>> get 802.3 packets from the device.
>>>>
>>>> Gr. AvS
>>>>
>>>>
>>>>> I get a huge
>>>>> amount of zero's and random(?) numbers when trying to print the
>>>>> addresses. This leads me to the first conclusion that mac_header is
>>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>>> using the skb->data pointer. Now this gives even weirder issues for me
>>>>> and actually totally crashes my kernel.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 12:39 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F8EF8F.90109@broadcom.com>
Hi,
The wireless chip is a Broadcast BCM4330 chip. After looking around a
bit I found that this is a fullMAC and links to the driver on
wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
and also links directly to android itself:
https://android.googlesource.com/platform/hardware/broadcom/wlan
Still trying to learn a lot in this tightly packed world of protocol
stacks, wireless and all the other poisons. Seems like I still have a
long way to go. Thank you already for helping me out with these issues
and taking the time to explain these things to me.
Kind regards,
Mathieu Devos
On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>
>> Hi,
>>
>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>> have a normal ethernet 802.3 input even. I check before selecting the
>> device that it's wireless (through ieee80211_ptr) and this properly
>> returns the wlan0 device which should be on the 80211 standard.
>
>
> *sigh* Welcome in the world of protocol stacks, wireless, networking (choose
> your poison). Let me draw the picture.
>
> o user-space
> |
> ----------------------
> | kernel
> +-----------+
> | NET | networking subsystem, ie. TCP/IP stack
> +-----------+
> | 802.3
> +----------------+
> | | driver |
> | +------------+ |
> | |802.11 stack| |
> | +------------+ |
> | | 802.11 |
> +----------------+
> |
> o RF
>
> The device hooks up to the networking subsystem as an ethernet device and as
> such it receives 802.3 packets. These are converted to 802.11 packets by the
> 802.11 stack. Now depending on your device that happens in the device driver
> or on the device itself. Another option is that this is done by mac80211
> (kernel provided 802.11 stack), but that is probably not the case, but to be
> sure I ask again: what wireless device do you have in your galaxy S2?
>
> Gr. AvS
>
>
>> My goal is to get the ieee80211_header properly on the skb with this
>> device, but some of the pointers and original data in the skb seem
>> totally off. This leaves me clueless as to where to put this
>> ieee80211_header.
>> I've tried putting it right on skb->head (wrong I know, but I was
>> getting desperate), on skb->mac_header (also wrong, no idea why
>> though), I went back from skb->tail with len and even added ETH_HLEN
>> to that as well because you can see that before my hook gets
>> activated: skb_pull_inline(skb, ETH_HLEN);
>> In the end I'm left with a header that is forced onto data but with a
>> wrong origin pointer thus basically leaving me with all wrong data in
>> the header.
>>
>> Kind regards,
>> Mathieu Devos
>>
>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com>
>> wrote:
>>>
>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I hope this is the right place to ask for a little bit of help as I'm
>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>> to print information about the mac addresses (addr1->addr4) and later
>>>> down the road try to send my own data.
>>>>
>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>> ieee80211 based on input from skb would be huge for me.
>>>>
>>>> So my issue: when placing the ieee80211 on my mac_header after I hook
>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>
>>>
>>>
>>> Not sure what you goal is, but what wireless device is that? You may just
>>> get 802.3 packets from the device.
>>>
>>> Gr. AvS
>>>
>>>
>>>> I get a huge
>>>> amount of zero's and random(?) numbers when trying to print the
>>>> addresses. This leads me to the first conclusion that mac_header is
>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>> using the skb->data pointer. Now this gives even weirder issues for me
>>>> and actually totally crashes my kernel.
>>>
>>>
>>>
>>>
>>>
>>
>
>
^ 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