* 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
* Re: Power saving features for iwl4965
From: Stanislaw Gruszka @ 2013-07-31 12:08 UTC (permalink / raw)
To: Pedro Francisco; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <CAJZjf_y9fnkHLp4YPdYY2sVo4r4+hKJcZAebJmjVKCBh-0EUtA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On Wed, Jul 17, 2013 at 12:48:30PM +0100, Pedro Francisco wrote:
> On Tue, Jul 16, 2013 at 11:27 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >> I seem only to be able to trigger it with disable_hw_scan=0, I need
> >> further testing with disable_hw_scan=1 (I use disable_hw_scan=0
> >> because it prevents me from getting disconnected from eduroam Cisco
> >> APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
> >> scanning patch, however).
> >>
> >> Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
> >> disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
> >> know if it matters).
> >
> > As this is not causing troubles with default disable_hw_scan option,
> > I'll post that patch.
>
> My mistake, I can trigger error conditions _independently_ of
> disable_hw_scan option being enabled or disabled, as long as powersave
> is enabled.
>
> I'll send you a private email with the logs.
I think I found bug which couse this firmware crash. We have only 5
queues so updating write_ptr for txq[5] can cause random value write
to HBUS_TARG_WRPTR register. I also added spin_lock to do not abuse
writes we do in tx skb.
Please test attached patch (with powersave on :-)
Stanislaw
[-- Attachment #2: iwlegacy_fix_wakeup_interrupt.patch --]
[-- Type: text/plain, Size: 818 bytes --]
diff --git a/drivers/net/wireless/iwlegacy/3945-mac.c b/drivers/net/wireless/iwlegacy/3945-mac.c
index b37a582..afa5c6e 100644
--- a/drivers/net/wireless/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/iwlegacy/3945-mac.c
@@ -1495,12 +1495,14 @@ il3945_irq_tasklet(struct il_priv *il)
if (inta & CSR_INT_BIT_WAKEUP) {
D_ISR("Wakeup interrupt\n");
il_rx_queue_update_write_ptr(il, &il->rxq);
+
+ spin_lock_irqsave(&il->lock, flags);
il_txq_update_write_ptr(il, &il->txq[0]);
il_txq_update_write_ptr(il, &il->txq[1]);
il_txq_update_write_ptr(il, &il->txq[2]);
il_txq_update_write_ptr(il, &il->txq[3]);
il_txq_update_write_ptr(il, &il->txq[4]);
- il_txq_update_write_ptr(il, &il->txq[5]);
+ spin_unlock_irqrestore(&il->lock, flags);
il->isr_stats.wakeup++;
handled |= CSR_INT_BIT_WAKEUP;
^ permalink raw reply related
* Re: Skb and ieee80211 headers
From: Arend van Spriel @ 2013-07-31 11:05 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless
In-Reply-To: <CAE_+Soyxz-RfyVeg-Z4Fv5tmUtH=9wutxgM0CGjHEne9zJq+Kg@mail.gmail.com>
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] ath10k: move irq setup
From: Michal Kazior @ 2013-07-31 10:50 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQn-VF-Ehio4Az6GenGb5cBTm2t2a9bQFAuALFhx+MQ+cw@mail.gmail.com>
On 31 July 2013 07:50, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 30 July 2013 20:35, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> There was a slight race during PCI shutdown. Since
>>> interrupts weren't really stopped (only Copy
>>> Engine interrupts were disabled through device hw
>>> registers) it was possible for a firmware
>>> indication (crash) interrupt to come in after
>>> tasklets were synced/killed. This would cause
>>> memory corruption and a panic in most cases. It
>>> was also possible for interrupt to come before CE
>>> was initialized during device probing.
>>>
>>> Interrupts are required for BMI phase so they are enabled as soon as
>>> power_up() is called but are freed upon both power_down() and stop()
>>> so there's asymmetry here. As by design stop() cannot be followed by
>>> start() it is okay. Both power_down() and stop() should be merged
>>> later on to avoid confusion.
>>
>> Why are the interrupts freed both in power_down() and stop()? I don't
>> get that.
>>
>> What if we call disable_irq() in power_down() instead?
>
> power_down() must call free_irq(), because power_up() calls
> request_irq() (if you want the symmetry). If anything, the stop()
> should call disable_irq(), but wouldn't that mean start() should call
> enable_irq()? But than, irqs are needed before start()..
>
> I did think about disable_irq() but AFAIR you need to enable_irq()
> later on (so either way you need to keep track of the irq state or
> you'll get a ton of WARN_ONs from the system). I'll double check that
> and report back later
enable/disable_irq must be balanced as well.
There are two cases of power cycle:
* power_up, power_down
* power_up, start, stop, power_down
If irq setup is moved from pci_probe/remove to power_up/power_down,
then stop() still needs irqs to be halted - either disable_irq, or
free_irq. In the latter case power_down must be prepared and not issue
free_irq again.
If irq setup remains in pci_probe/remove then both stop() and
power_down() need irqs to be halted too. Same issue applies.
If stop/power_down is merged than the whole problem is solved. This
seems like the sane solution to the whole problem but requires some
refactoring to be done first.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [PATCH v3] Documentation: dt: bindings: TI WiLink modules
From: Laurent Pinchart @ 2013-07-31 10:36 UTC (permalink / raw)
To: Luciano Coelho
Cc: devicetree, linux-doc, mturquette, mark.rutland, balbi,
grant.likely, rob.herring, linux-kernel, linux-omap,
linux-wireless, linux-arm-kernel, tony, nm
In-Reply-To: <1375215668-29171-1-git-send-email-coelho@ti.com>
Hi Luciano,
On Tuesday 30 July 2013 23:21:08 Luciano Coelho wrote:
> Add device tree bindings documentation for the TI WiLink modules.
> Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
> modules is supported.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>
> In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
>
> .../devicetree/bindings/net/wireless/ti-wilink.txt | 68
> ++++++++++++++++++++++ 1 file changed, 68 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file
> mode 100644
> index 0000000..aafebb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> @@ -0,0 +1,68 @@
> +TI WiLink Wireless Modules Device Tree Bindings
> +===============================================
> +
> +The WiLink modules provide wireless connectivity, such as WLAN,
> +Bluetooth, FM and NFC.
> +
> +There are several different modules available, which can be grouped by
> +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
> +currently supported with device tree.
> +
> +Currently, only the WLAN portion of the modules is supported with
> +device tree.
> +
> +Required properties:
> +--------------------
> +
> +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
> +- interrupt-parent: the interrupt controller
> +- interrupts: out-of-band WLAN interrupt
> + See the interrupt controller's bindings documentation for
> + detailed definition.
> +
> +Optional properties:
> +--------------------
> +
> +- clocks: list of clocks needed by the chip as follows:
> +
> + refclock: the internal WLAN reference clock frequency (required for
> + WiLink6 and WiLink7; not used for WiLink8).
> +
> + tcxoclock: the internal WLAN TCXO clock frequency (required for
> + WiLink7 not used for WiLink6 and WiLink8).
> +
> + The clocks must be defined and named accordingly. For example:
> +
> + clocks = <&refclock>
> + clock-names = "refclock";
> +
> + refclock: refclock {
> + compatible = "ti,wilink-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +
> + Some modules that contain the WiLink chip provide clocks in the
> + module itself. In this case, we define a "ti,wilink-clock" as shown
> + above. But any other clock could in theory be used, so the proper
> + clock definition should be used.
> +
> +
> +Example:
> +--------
> +
> +Example definition that can be used in OMAP4 Panda:
> +
> +wlan {
> + compatible = "ti,wilink6";
> + interrupt-parent = <&gpio2>;
> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
> + clocks = <&refclock>;
> + clock-names = "refclock";
> +
> + refclock: refclock {
> + compatible = "ti,wilink-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 10:28 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F8E228.9080600@broadcom.com>
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.
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: Arend van Spriel @ 2013-07-31 10:08 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless
In-Reply-To: <CAE_+Soy5=MfUUahaP3Ka2onp+jP9aupbhGu_QHco=CP7Y9sqhQ@mail.gmail.com>
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
* [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Johannes Berg @ 2013-07-31 9:50 UTC (permalink / raw)
To: linux-wireless
Cc: Arkadiusz Miskiewicz, Andy Isaacson, Stanislaw Gruszka,
Johannes Berg
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]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 383a961..77e7796 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -211,8 +211,9 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel *channel,
const struct ieee80211_ht_operation *ht_oper,
const struct ieee80211_vht_operation *vht_oper,
- struct cfg80211_chan_def *chandef, bool verbose)
+ struct cfg80211_chan_def *chandef, bool tracking)
{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct cfg80211_chan_def vht_chandef;
u32 ht_cfreq, ret;
@@ -231,7 +232,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan,
channel->band);
/* check that channel matches the right operating channel */
- if (channel->center_freq != ht_cfreq) {
+ if (!tracking && channel->center_freq != ht_cfreq) {
/*
* It's possible that some APs are confused here;
* Netgear WNDR3700 sometimes reports 4 higher than
@@ -239,11 +240,10 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
* since we look at probe response/beacon data here
* it should be OK.
*/
- if (verbose)
- sdata_info(sdata,
- "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
- channel->center_freq, ht_cfreq,
- ht_oper->primary_chan, channel->band);
+ sdata_info(sdata,
+ "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
+ channel->center_freq, ht_cfreq,
+ ht_oper->primary_chan, channel->band);
ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
goto out;
}
@@ -297,7 +297,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
channel->band);
break;
default:
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT operation IE has invalid channel width (%d), disable VHT\n",
vht_oper->chan_width);
@@ -306,7 +306,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_valid(&vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information is invalid, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -319,7 +319,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information doesn't match HT, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -346,7 +346,7 @@ out:
ret |= chandef_downgrade(chandef);
}
- if (chandef->width != vht_chandef.width && verbose)
+ if (chandef->width != vht_chandef.width && !tracking)
sdata_info(sdata,
"capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n");
@@ -386,7 +386,7 @@ static int ieee80211_config_bw(struct ieee80211_sub_if_data *sdata,
/* calculate new channel (type) based on HT/VHT operation IEs */
flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper,
- vht_oper, &chandef, false);
+ vht_oper, &chandef, true);
/*
* Downgrade the new channel if we associated with restricted
@@ -3838,7 +3838,7 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
cbss->channel,
ht_oper, vht_oper,
- &chandef, true);
+ &chandef, false);
sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss),
local->rx_chains);
--
1.8.0
^ permalink raw reply related
* Re: Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Sedat Dilek @ 2013-07-31 9:46 UTC (permalink / raw)
To: Felix Fietkau
Cc: Arend van Spriel, linux-wireless, John W. Linville, John Greene
In-Reply-To: <51F8D438.7020304@openwrt.org>
On Wed, Jul 31, 2013 at 11:09 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2013-07-31 10:39 AM, Arend van Spriel wrote:
>> Hi Felix,
>>
>> How are things in OpenWRT. I wanted to ask you something regarding a
>> defect I am looking at. Since kernel 3.9 several reports have been made
>> about a kernel panic in brcmsmac, ie. a divide-by-zero error.
> 3.9 was the first kernel to support CCK rates in minstrel_ht as
> fallback (in case the link gets very bad). Not sure if that triggers
> anything weird in brcmsmac.
>
>> Debugging the issue shows we end up with a rate with MCS index 110,
>> which is, well, impossible.
> Did you verify that it comes directly from minstrel_ht, or does it show
> up somewhere further down the chain in brcmsmac?
>
>> As brcmsmac gets the rate info from
>> minstrel_ht I was wondering if we have an intergration issue here. I saw
>> around April patches about new API which may have been in the 3.9 time
>> frame and something subtly changed things for brcmsmac.
> The new rate API was added in 3.10, not 3.9. It did add bug that caused
> bogus MCS rates. I've sent a patch for this a while back (shortly
> before 3.10 was released), but it was too late to make it into the
> release. I guess we have to wait for it to be applied through stable -
> no idea why that hasn't happened yet.
>
> Here is the fix:
>
> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Fri Jun 28 21:04:35 2013 +0200
>
> mac80211/minstrel_ht: fix cck rate sampling
>
That patch is not in Linus tree yet, so it won't get into stable.
- Sedat -
> The CCK group needs special treatment to set the right flags and rate
> index. Add this missing check to prevent setting broken rates for tx
> packets.
>
> Cc: stable@vger.kernel.org # 3.10
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> index 5b2d301..f5aed96 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
>
> sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
> info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
> + rate->count = 1;
> +
> + if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
> + int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
> + rate->idx = mp->cck_rates[idx];
> + rate->flags = 0;
> + return;
> + }
> +
> rate->idx = sample_idx % MCS_GROUP_RATES +
> (sample_group->streams - 1) * MCS_GROUP_RATES;
> rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
> - rate->count = 1;
> }
>
> static void
>
> --
> 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: Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Arend van Spriel @ 2013-07-31 9:45 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W. Linville, John Greene
In-Reply-To: <51F8D438.7020304@openwrt.org>
On 07/31/2013 11:09 AM, Felix Fietkau wrote:
> On 2013-07-31 10:39 AM, Arend van Spriel wrote:
>> Hi Felix,
>>
>> How are things in OpenWRT. I wanted to ask you something regarding a
>> defect I am looking at. Since kernel 3.9 several reports have been made
>> about a kernel panic in brcmsmac, ie. a divide-by-zero error.
> 3.9 was the first kernel to support CCK rates in minstrel_ht as
> fallback (in case the link gets very bad). Not sure if that triggers
> anything weird in brcmsmac.
It just might reading this in brcmsmac:
/*
* Currently only support same setting for primary and
* fallback rates. Unify flags for each rate into a
* single value for the frame
*/
use_rts |= txrate[k]->flags & IEEE80211_TX_RC_USE_RTS_CTS
? true : false;
use_cts |= txrate[k]->flags & IEEE80211_TX_RC_USE_CTS_PROTECT
? true : false;
Although this is not directly
>> Debugging the issue shows we end up with a rate with MCS index 110,
>> which is, well, impossible.
> Did you verify that it comes directly from minstrel_ht, or does it show
> up somewhere further down the chain in brcmsmac?
I am pretty sure it is not minstrel_ht. brcmsmac converts the
information from minstrel_ht into a so-called ratespec format. The
strange MCS is what I see in the ratespec leading up to the
divide-by-zero. Next thing to look at is the conversion step. As said
above the CCK fallback might be the culprit. I mean how brcmsmac deals
with it is.
>> As brcmsmac gets the rate info from
>> minstrel_ht I was wondering if we have an intergration issue here. I saw
>> around April patches about new API which may have been in the 3.9 time
>> frame and something subtly changed things for brcmsmac.
> The new rate API was added in 3.10, not 3.9. It did add bug that caused
> bogus MCS rates. I've sent a patch for this a while back (shortly
> before 3.10 was released), but it was too late to make it into the
> release. I guess we have to wait for it to be applied through stable -
> no idea why that hasn't happened yet.
Ping Greg? I will give it a try.
Thanks,
Arend
> Here is the fix:
>
> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Fri Jun 28 21:04:35 2013 +0200
>
> mac80211/minstrel_ht: fix cck rate sampling
>
> The CCK group needs special treatment to set the right flags and rate
> index. Add this missing check to prevent setting broken rates for tx
> packets.
>
> Cc: stable@vger.kernel.org # 3.10
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> index 5b2d301..f5aed96 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
>
> sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
> info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
> + rate->count = 1;
> +
> + if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
> + int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
> + rate->idx = mp->cck_rates[idx];
> + rate->flags = 0;
> + return;
> + }
> +
> rate->idx = sample_idx % MCS_GROUP_RATES +
> (sample_group->streams - 1) * MCS_GROUP_RATES;
> rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
> - rate->count = 1;
> }
>
> static void
>
>
^ permalink raw reply
* Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 9:39 UTC (permalink / raw)
To: linux-wireless
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) 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.
So I went back to starting with printing as much info as possible.
This is a sample output after I hook my packet type:
Skb->dev->name: wlan0
Skb->head: 0xe1d37040
Skb->mac_header: 0xe1d372a9
Skb->data: 0x510 (!!!)
Skb->tail: 0xe1d37460
Skb->len: 617
Skb->hdr_len: 0
When trying to just capture this and only print a certain message when
one of the addresses maches my dev->dev_addr I never get any data
while the phone is connected and actively browsing the internet.
I'm aware that before I throw my hook some data is being changed
around already in net/core/dev.c and in net/mac80211/rx.c The weird
part is that these seem to be putting on ethernet headers
(skb->protocol = eth_type_trans(skb, dev); AND kb_pull_inline(skb,
ETH_HLEN);
eth = eth_hdr(skb); ) on items that should be ieee80211 headers.
Any insights as to why my data header is in such a weird spot (nowhere
between my head and my tail) or where I should call the
ieee80211_header on? I have tried working my way back from tail with
len and adding another ETH_HLEN but while I get data, it never really
matches my own mac addr so I'm assuming the data is still pretty
wrong.
Added links:
https://github.com/mathieudevos/kernelmodules/blob/master/ethernet_test.c
(my own program)
https://github.com/mathieudevos/linux_kernel_3.2.48 (used to get all
the .c files from to acquire information)
If possible I'd like to write a small guide after these issues have
been fixes for people who like me would like to get started with a
basic LKM in the ieee80211 part of linux.
If this is not the place to ask these questions, please disregard me
(hopefully it is) but all help would be welcome.
Kind regards,
Mathieu Devos
^ permalink raw reply
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Arend van Spriel @ 2013-07-31 9:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau,
Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On 07/31/2013 02:53 AM, 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?
>
> AFAICT mac80211_hwism should and likely already is used for a slew of
> core API changes / tests. Addressing testing using that shoud
> hopefully address tons of testings and find a lot of issues. We'd then
> just need vendors to replicate behaviour on top of their drivers. The
> core test stuff though still needs to be available.
>
> What do we have, anyone have any lofty plans?
We have a large testing infrastructure consisting of shielded boxes,
attenuators, etc. It is all exercised using tcl scripts and none of it
is open today. Who knows what tomorrow will bring. The brcm80211
open-source drivers are tested limited but nightly using it.
I am considering coming up with a new test framework for the brcm80211
drivers using python scripting, which is why I started py80211
experiment (available on github), but your mentioning of autotest makes
me want to revisit that.
Regards,
Arend
> [0] http://wireless.kernel.org/en/developers/Testing/wifi-test
> [1] http://wireless.kernel.org/en/developers/Summits/SanFranciscoBayArea-2010
> [2] http://wireless.kernel.org/en/users/Drivers/mac80211_hwsim
>
> Luis
> --
> 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: AP changed bandwidth, new config is ... changed bandwidth in a way we can't support - disconnect - why? (intel advanced-n 6250)
From: Arkadiusz Miskiewicz @ 2013-07-31 9:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andy Isaacson, linux-wireless, ilw
In-Reply-To: <1375260632.8289.10.camel@jlt4.sipsolutions.net>
On Wednesday 31 of July 2013, Johannes Berg wrote:
> On Wed, 2013-07-31 at 08:55 +0200, Arkadiusz Miskiewicz wrote:
> > It basically reports:
> > [79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config
> > is 2422 MHz, width 1 (2422/0 MHz) [79477.496072] eth1: AP
> > 68:7f:74:06:b3:1b changed bandwidth in a way we can't support -
> > disconnect
> >
> > (note I have two wrt160nl here and problem happens with both)
> >
> > Any hints on why "we can't support" configuration issued by this (common)
> > AP?
>
> As far as I can tell, it seems to be an AP bug, but I had no idea this
> was so common.
>
> Testing with hostapd, I can switch bandwidth between 20 and 40 MHz just
> fine, and it only prints "new config is ..." and then carries on.
>
> Since you seem to be able to reproduce this easily, can you run tcpdump
> with the beacon info?
Will do. Unfortunately the problem doesn't always happen. Sometimes things
work fine with this AP, sometimes they don't (and right now can't reproduce,
so waiting for thing to happen again).
btw. full dmesg
http://pastebin.com/zTfR5rTK
> johannes
--
Arkadiusz Miśkiewicz, arekm / maven.pl
^ permalink raw reply
* Re: Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Felix Fietkau @ 2013-07-31 9:09 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, John W. Linville, John Greene
In-Reply-To: <51F8CD45.6060108@broadcom.com>
On 2013-07-31 10:39 AM, Arend van Spriel wrote:
> Hi Felix,
>
> How are things in OpenWRT. I wanted to ask you something regarding a
> defect I am looking at. Since kernel 3.9 several reports have been made
> about a kernel panic in brcmsmac, ie. a divide-by-zero error.
3.9 was the first kernel to support CCK rates in minstrel_ht as
fallback (in case the link gets very bad). Not sure if that triggers
anything weird in brcmsmac.
> Debugging the issue shows we end up with a rate with MCS index 110,
> which is, well, impossible.
Did you verify that it comes directly from minstrel_ht, or does it show
up somewhere further down the chain in brcmsmac?
> As brcmsmac gets the rate info from
> minstrel_ht I was wondering if we have an intergration issue here. I saw
> around April patches about new API which may have been in the 3.9 time
> frame and something subtly changed things for brcmsmac.
The new rate API was added in 3.10, not 3.9. It did add bug that caused
bogus MCS rates. I've sent a patch for this a while back (shortly
before 3.10 was released), but it was too late to make it into the
release. I guess we have to wait for it to be applied through stable -
no idea why that hasn't happened yet.
Here is the fix:
commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5
Author: Felix Fietkau <nbd@openwrt.org>
Date: Fri Jun 28 21:04:35 2013 +0200
mac80211/minstrel_ht: fix cck rate sampling
The CCK group needs special treatment to set the right flags and rate
index. Add this missing check to prevent setting broken rates for tx
packets.
Cc: stable@vger.kernel.org # 3.10
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 5b2d301..f5aed96 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
+ rate->count = 1;
+
+ if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
+ int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
+ rate->idx = mp->cck_rates[idx];
+ rate->flags = 0;
+ return;
+ }
+
rate->idx = sample_idx % MCS_GROUP_RATES +
(sample_group->streams - 1) * MCS_GROUP_RATES;
rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
- rate->count = 1;
}
static void
^ permalink raw reply related
* Re: 3.10, iwlwifi 6200AGN: AP changed bandwidth in a way we can't support - disconnect
From: Stanislaw Gruszka @ 2013-07-31 8:59 UTC (permalink / raw)
To: Andy Isaacson; +Cc: Johannes Berg, linux-wireless, netdev, Arkadiusz Miskiewicz
In-Reply-To: <20130729163452.GA454@hexapodia.org>
On Mon, Jul 29, 2013 at 09:34:52AM -0700, Andy Isaacson wrote:
> After upgrading to 3.10.4 and traveling to Europe I'm often suffering
> from failures to associate with the following in dmesg:
>
> [ 37.351621] wlan0: authenticate with 64:70:02:e6:a6:ba
> [ 37.364701] wlan0: send auth to 64:70:02:e6:a6:ba (try 1/3)
> [ 37.366358] wlan0: authenticated
> [ 37.368543] wlan0: associate with 64:70:02:e6:a6:ba (try 1/3)
> [ 37.372765] wlan0: RX AssocResp from 64:70:02:e6:a6:ba (capab=0x431 status=0 aid=8)
> [ 37.380190] wlan0: associated
> [ 37.438935] wlan0: AP 64:70:02:e6:a6:ba changed bandwidth, new config is 2447 MHz, width 1 (2447/0 MHz)
> [ 37.438941] wlan0: AP 64:70:02:e6:a6:ba changed bandwidth in a way we can't support - disconnect
>
> I hacked the driver to do
>
> - "AP %pM changed bandwidth, new config is %d MHz, width %d (%d/%d MHz)\n",
> + "AP %pM changed bandwidth, new config is %d MHz, width %d (%d/%d MHz) flags %x/%x\n",
> ifmgd->bssid, chandef.chan->center_freq, chandef.width,
> - chandef.center_freq1, chandef.center_freq2);
> + chandef.center_freq1, chandef.center_freq2, flags, ifmgd->flags);
>
> and
>
> - if (flags != (ifmgd->flags & (IEEE80211_STA_DISABLE_HT |
> + if ((flags != 0x810 && ifmgd->flags != 0x804) && (
> + flags != (ifmgd->flags & (IEEE80211_STA_DISABLE_HT |
>
> and the result is a working link with
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?
Stanislaw
^ permalink raw reply
* [PATCH 5/5] ath10k: fix failpath in MSI-X setup
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
pci_disable_msi() must be called if the initial
request_irq() fails.
Also add a warning message so it's possible to
distinguish request_irq() failure and
pci_enable_msi() failure.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index c71b488..d95439b 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1990,8 +1990,13 @@ static int ath10k_pci_start_intr_msix(struct ath10k *ar, int num)
ret = request_irq(ar_pci->pdev->irq + MSI_ASSIGN_FW,
ath10k_pci_msi_fw_handler,
IRQF_SHARED, "ath10k_pci", ar);
- if (ret)
+ if (ret) {
+ ath10k_warn("request_irq(%d) failed %d\n",
+ ar_pci->pdev->irq + MSI_ASSIGN_FW, ret);
+
+ pci_disable_msi(ar_pci->pdev);
return ret;
+ }
for (i = MSI_ASSIGN_CE_INITIAL; i <= MSI_ASSIGN_CE_MAX; i++) {
ret = request_irq(ar_pci->pdev->irq + i,
--
1.7.9.5
^ permalink raw reply related
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