Re: Power Save for Multi-VIF

[Gucea Doru]

On Tue, Feb 14, 2017 at 9:41 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
> Hello, everyone
>
> I try to design a Power Save Algorithm in the case of a mobile client
> that has multiple virtual interfaces [1] and is connected to multiple
> Access Points simultaneously. My implementation is for the Atheros
> AR9271 WiFi chip.
>
> The biggest challenge in implementing this algorithm is waking up the
> WiFi chip for RX traffic. E.g.: the WiFi chip is in the sleep state
> and it has to wake up in order to receive beacons from all the APs
> that the client is connected to.
>
> Reading the AR9271 datasheet [2] I noticed that the chip is equipped
> with hardware timers for waking up the hardware. The registers for
> programming these hardware timers are MAC_PCU_SLP1 and MAC_PCU_SLP2.
> After the registers have been programmed, the RTC_FORCE_WAKE bit has
> to be cleared in order to allow the card to enter sleep mode (at least
> this is how is done in the existing implementation for the single VIF
> scenario).
>
> I used the logic above for programming the hardware to wake up for
> beacons from multiple APs. I used a power device for measuring the
> energy consumption and it seems that the WiFi card wakes up
> periodically to receive beacons from multiple APs. The problem is that
> after a time, out of nowhere, the WiFi card refuses to enter sleep
> mode and stays just in the awake state, although the logic for
> programming the hardware timers does not change.
>
> Could someone give more details about the FORCE_WAKE signal and what
> is the relation between this signal and the MAC and RTC layers? I
> believe that the problem comes from here. The AR9271 datasheet just
> references this signal (page 106) but it offers no details about it.

Is there any Atheros developer that could help me with a clarification
about the FORCE_WAKE signal?

Thanks,
Doru


>
> [1] https://github.com/doru91/linux-stable/wiki/Two-Interfaces-Power-Save
> [2] https://wikidevi.com/wiki/Atheros_AR9271
> [3] 
> http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.9#L2068
>
> Regards,
> Doru

Re: [RFC-PATCH] ath9k_htc: Adjust beacon timers for Power Save

[Gucea Doru]

On Wed, Feb 15, 2017 at 11:02 AM, Kalle Valo  wrote:
> Doru  writes:
>
>> From: Doru Gucea 
>>
>> Each time we receive a beacon we need to adjust the hardware
>> timers for next DTIM and next TBTT.
>>
>> Before this commit, the Power Save behaviour was incorrect.
>> The scenario was:
>> - STA receives a beacon from AP with TIM unset;
>> - mac80211 layers puts the chip to sleep;
>> - chip is woken up by mac80211's software timer reponsible for
>> beacon miss after 7 * beacon_interval period.
>>
>> Normally the chip should sleep at most DTIM period. This commit
>> configures hardware timers for waking up the chip correctly.
>>
>> More details on the wiki:
>> https://github.com/doru91/linux-stable/wiki/Single-Interface-Power-Save
>>
>> Signed-off-by: Doru Gucea 
>> ---
>>  drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 
>>  net/mac80211/mlme.c   | 6 ++
>>  2 files changed, 10 insertions(+)
>
> [...]
>
>> --- a/net/mac80211/mlme.c
>> +++ b/net/mac80211/mlme.c
>> @@ -3536,6 +3536,12 @@ static void ieee80211_rx_mgmt_beacon(struct 
>> ieee80211_sub_if_data *sdata,
>>   sdata->vif.bss_conf.sync_dtim_count = 0;
>>   }
>>
>> + /* trigger hardware timers adjustment
>> +  * this needs to be done before beacon filtering
>> +  */
>> + changed |= BSS_CHANGED_BEACON_INFO;
>> + ieee80211_bss_info_change_notify(sdata, changed);
>
> You shouldn't mix driver and mac80211 changes in the same patch, I
> suspect Johannes didn't even notice this change because of that. Create
> a new patchset with two patches, one for ath9k and another for mac80211.

Thanks, I've just sent two patches as you suggested.

>
> --
> Kalle Valo

Re: Qualcomm: Power Save Algorithm in STA+STA mode

[Gucea Doru]

On Tue, Sep 20, 2016 at 8:27 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
> Hello, everyone
>
> I'm a master student and I currently work on designing an algorithm
> for reducing the power consumption when a mobile device is associated
> to multiple Access Points that operate on the same channel.
>
> I tried to design my algorithm around the prima driver [1] but I
> noticed that the power save feature is fully implemented in the
> firmware (Beacon Mode Power Save). Unfortunately, the firmware is
> closed-source and I can't do any modifications.
>
> Is there any Qualcomm representative reading this mailing list that
> could help me get a possible solution for the above problem?
>
>
> [1] https://source.codeaurora.org/quic/la
>
> Thank you,
> Doru

Is there any Qualcomm-Atheros developer who could help me/redirect to
the right person?

Thanks,
Doru

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Tue, Oct 11, 2016 at 10:12 PM, Arend van Spriel
<arend.vanspr...@broadcom.com> wrote:
> On 07-10-16 16:33, Gucea Doru wrote:
>> On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel
>> <arend.vanspr...@broadcom.com> wrote:
>>> On 6-10-2016 10:07, Gucea Doru wrote:
>>>> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
>>>> <arend.vanspr...@broadcom.com> wrote:
>>>>> On 4-10-2016 13:39, Gucea Doru wrote:
>>>>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>>>>> <arend.vanspr...@broadcom.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.d...@gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>>>>> request message and the Null frame that announces the exit from the 
>>>>>>>>>> PS
>>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any help would be highly appreciated :)
>>>>>>>>
>>>>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>>>>
>>>>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>>>>> drivers. Regardless your question is more for firmware running on the
>>>>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>>>>> with same firmware.
>>>>>>>>
>>>>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>>>>> exits the PS mode without waiting for a beacon.
>>>>>>>>
>>>>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>>>>> should be in power-save at any other time. So it is difficult to say
>>>>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>>>>> just not connected. wpa_supplicant will do intermittent scan or 
>>>>>>>> initiate
>>>>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>>>>> is just some things I can come up with and I am sure there are more.
>>>>>>
>>>>>> I agree that there may be some events belonging to the regular STA
>>>>>> interface that could trigger the Null Frame (which includes the exit
>>>>>> from PS Mode). However, I would expect to see some management frames
>>>>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>>>>> of a scheduled scan). But in my case the trigger for the Null frame
>>>>>> seems to be the ping request packet, the scenario is the same every
>>>>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>>>>> confirms this behavior).
>>>>>>
>>>>>> I thought that you had a power save optimization algorithm that keeps
>>>>>> the card on a few milliseconds just to see if we can have a fast reply
>>>>>> from the peer. Does this ring a bell? :)
>>>>>
>>>>> It does not. That would be implemented in firmware. As said I am working
>>>>> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise.
>>>>>
>>>>
>>>> Arend, could you please redirect me to a Broadcom firmware maintainer?
>>>
>>> Can you please elaborate on your platform, broadcom chipset, and what
>>> version of bcmdhd you are using.
>>>
>>
>> Platform: Nexus 5 running CM13 (Android 6.0.1)
>> Broadcom chipset: BCM4339 Wi-Fi Chipset
>> bcmdhd version:Dongle Host Driver, version 1.88.45 (r)
>>
>> Do you need more information?
>
> So can you indicate the mac addresses of the two nexus devices and which
> one is P2P-GO. I entered the wpa key you mentioned in your initial
> email, but my wireshark does not seem to be able to decrypt the packets,
> which makes it a bit harder to analyze.

Do you have a wpa-pwd entry "JYdrhZp3:DIRECT-35-Android_Intel" inside
Edit->Preferences->Protocols->IEEE 802.11->Decryption Keys? I use
Wireshark 2.0.4.

P2P-GO MAC: 66:89:9a:81:0d:95
P2P Client MAC: 66:89:9a:81:0f:20

Thanks,
Doru

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel
<arend.vanspr...@broadcom.com> wrote:
> On 6-10-2016 10:07, Gucea Doru wrote:
>> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
>> <arend.vanspr...@broadcom.com> wrote:
>>> On 4-10-2016 13:39, Gucea Doru wrote:
>>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>>> <arend.vanspr...@broadcom.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.d...@gmail.com> 
>>>>>>> wrote:
>>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>>>> mode.
>>>>>>>
>>>>>>>
>>>>>>> Any help would be highly appreciated :)
>>>>>>
>>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>>
>>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>>> drivers. Regardless your question is more for firmware running on the
>>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>>> with same firmware.
>>>>>>
>>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>>> exits the PS mode without waiting for a beacon.
>>>>>>
>>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>>> should be in power-save at any other time. So it is difficult to say
>>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>>> is just some things I can come up with and I am sure there are more.
>>>>
>>>> I agree that there may be some events belonging to the regular STA
>>>> interface that could trigger the Null Frame (which includes the exit
>>>> from PS Mode). However, I would expect to see some management frames
>>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>>> of a scheduled scan). But in my case the trigger for the Null frame
>>>> seems to be the ping request packet, the scenario is the same every
>>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>>> confirms this behavior).
>>>>
>>>> I thought that you had a power save optimization algorithm that keeps
>>>> the card on a few milliseconds just to see if we can have a fast reply
>>>> from the peer. Does this ring a bell? :)
>>>
>>> It does not. That would be implemented in firmware. As said I am working
>>> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise.
>>>
>>
>> Arend, could you please redirect me to a Broadcom firmware maintainer?
>
> Can you please elaborate on your platform, broadcom chipset, and what
> version of bcmdhd you are using.
>

Platform: Nexus 5 running CM13 (Android 6.0.1)
Broadcom chipset: BCM4339 Wi-Fi Chipset
bcmdhd version:Dongle Host Driver, version 1.88.45 (r)

Do you need more information?

Thank you,
Doru

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
<arend.vanspr...@broadcom.com> wrote:
> On 4-10-2016 13:39, Gucea Doru wrote:
>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>> <arend.vanspr...@broadcom.com> wrote:
>>>>
>>>>
>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>> mode.
>>>>>
>>>>>
>>>>> Any help would be highly appreciated :)
>>>>
>>>> Actually though I already sent you are reply, but alas here it is.
>>>>
>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>> drivers. Regardless your question is more for firmware running on the
>>>> device. So like the same behavior would be observed when using brcmfmac
>>>> with same firmware.
>>>>
>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>> exits the PS mode without waiting for a beacon.
>>>>
>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>> should be in power-save at any other time. So it is difficult to say
>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>> is just some things I can come up with and I am sure there are more.
>>
>> I agree that there may be some events belonging to the regular STA
>> interface that could trigger the Null Frame (which includes the exit
>> from PS Mode). However, I would expect to see some management frames
>> in the air before/after the Null Packet (e.g.: a Probe request in case
>> of a scheduled scan). But in my case the trigger for the Null frame
>> seems to be the ping request packet, the scenario is the same every
>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>> confirms this behavior).
>>
>> I thought that you had a power save optimization algorithm that keeps
>> the card on a few milliseconds just to see if we can have a fast reply
>> from the peer. Does this ring a bell? :)
>
> It does not. That would be implemented in firmware. As said I am working
> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise.
>

Arend, could you please redirect me to a Broadcom firmware maintainer?

Thank you,
Doru

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
<chaitanya.m...@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>> <arend.vanspr...@broadcom.com> wrote:
>>>>
>>>>
>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>> mode.
>>>>>
>>>>>
>>>>> Any help would be highly appreciated :)
>>>>
>>>> Actually though I already sent you are reply, but alas here it is.
>>>>
>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>> drivers. Regardless your question is more for firmware running on the
>>>> device. So like the same behavior would be observed when using brcmfmac
>>>> with same firmware.
>>>>
>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>> exits the PS mode without waiting for a beacon.
>>>>
>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>> should be in power-save at any other time. So it is difficult to say
>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>> is just some things I can come up with and I am sure there are more.
>>
>> I agree that there may be some events belonging to the regular STA
>> interface that could trigger the Null Frame (which includes the exit
>> from PS Mode). However, I would expect to see some management frames
>> in the air before/after the Null Packet (e.g.: a Probe request in case
>> of a scheduled scan). But in my case the trigger for the Null frame
>> seems to be the ping request packet, the scenario is the same every
>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>> confirms this behavior).
>>
>> I thought that you had a power save optimization algorithm that keeps
>> the card on a few milliseconds just to see if we can have a fast reply
>> from the peer. Does this ring a bell? :)
>>
>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>> <chaitanya.m...@gmail.com> wrote:
>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>
>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>> "When an AP is informed that a STA has changed to the Active mode,
>> then the AP shall send buffered BUs (if any exist) to the STA without
>> waiting for a PS Poll"
> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
> so AP should set TIM/DTIM...

The STA _did_ inform the AP.

If you take a look at the packet traces you'll see that the STA sends
a NULL frame saying that it will exit Power Save Mode. According to
the specification the AP can send the buffered frames.

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>>
>>
>> On 29-09-16 13:32, Gucea Doru wrote:
>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
>>>> What is the decision triggering the exit from the PS mode immediately
>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>> specifies that the client should wait for a beacon with TIM set in
>>>> order to wake up: in my case, there is no beacon between the ping
>>>> request message and the Null frame that announces the exit from the PS
>>>> mode.
>>>
>>>
>>> Any help would be highly appreciated :)
>>
>> Actually though I already sent you are reply, but alas here it is.
>>
>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>> drivers. Regardless your question is more for firmware running on the
>> device. So like the same behavior would be observed when using brcmfmac
>> with same firmware.
>>
>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>> shall issue a PS Poll". In my capture there are cases when the STA
>>> exits the PS mode without waiting for a beacon.
>>
>> It is a bit tricky, but the standard does not explicitly say the STA
>> should be in power-save at any other time. So it is difficult to say
>> what event occurred on the STA side to exit PS mode. Also STA means
>> P2P-Client as you say. That means that you have multiple interfaces:
>> regular STA and P2P-Client. So is the STA connected to some other AP or
>> just not connected. wpa_supplicant will do intermittent scan or initiate
>> scheduled scan by which firmware will scan at a certain interval. That
>> is just some things I can come up with and I am sure there are more.

I agree that there may be some events belonging to the regular STA
interface that could trigger the Null Frame (which includes the exit
from PS Mode). However, I would expect to see some management frames
in the air before/after the Null Packet (e.g.: a Probe request in case
of a scheduled scan). But in my case the trigger for the Null frame
seems to be the ping request packet, the scenario is the same every
time: ping request -> Block ACK -> Null Frame (Wireshark trace
confirms this behavior).

I thought that you had a power save optimization algorithm that keeps
the card on a few milliseconds just to see if we can have a fast reply
from the peer. Does this ring a bell? :)

On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
<chaitanya.m...@gmail.com> wrote:
> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.

Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
"When an AP is informed that a STA has changed to the Active mode,
then the AP shall send buffered BUs (if any exist) to the STA without
waiting for a PS Poll"

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.d...@gmail.com> wrote:
> What is the decision triggering the exit from the PS mode immediately
> after the ping request? I am asking this because 802.11 PS legacy
> specifies that the client should wait for a beacon with TIM set in
> order to wake up: in my case, there is no beacon between the ping
> request message and the Null frame that announces the exit from the PS
> mode.


Any help would be highly appreciated :)

IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
detects that the bit corresponding to its AID is 1 i the TIM, the STA
shall issue a PS Poll". In my capture there are cases when the STA
exits the PS mode without waiting for a beacon.

Thanks!

bcmdhd: Strange Power Save messages

[Gucea Doru]

Hello,

I am analyzing the Power Save algorithm used on a pair of Nexus 5
devices. The devices use the bcmdhd Broadcom driver and are Wi-Fi
Direct connected.

My test is very simple: I send ping packets from the P2P client
towards the P2P GO. Before sending a ping packet the P2P client enters
PS mode (it sends a Null frame with the PWR MGT bit set). A few
miliseconds later, the P2P client sends the ping request message. Once
the ping request is ACKed the P2P client exits the PS mode (it sends a
Null frame with the PWR MGT bit unset) and the P2P GO decides to send
him the ping reply.

What is the decision triggering the exit from the PS mode immediately
after the ping request? I am asking this because 802.11 PS legacy
specifies that the client should wait for a beacon with TIM set in
order to wake up: in my case, there is no beacon between the ping
request message and the Null frame that announces the exit from the PS
mode.

For reference, the Wireshark trace can be found at [1].
SSID: DIRECT-35-Android_Intel
WPA pass: JYdrhZp3

[1] 
https://drive.google.com/file/d/0B5SBH08PU_ChQk95LWpzekh3VU0/view?usp=sharing

Thank you,
Doru

Qualcomm: Power Save Algorithm in STA+STA mode

[Gucea Doru]

Hello, everyone

I'm a master student and I currently work on designing an algorithm
for reducing the power consumption when a mobile device is associated
to multiple Access Points that operate on the same channel.

I tried to design my algorithm around the prima driver [1] but I
noticed that the power save feature is fully implemented in the
firmware (Beacon Mode Power Save). Unfortunately, the firmware is
closed-source and I can't do any modifications.

Is there any Qualcomm representative reading this mailing list that
could help me get a possible solution for the above problem?


[1] https://source.codeaurora.org/quic/la

Thank you,
Doru

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

On Sun, Apr 10, 2016 at 1:28 PM, Grumbach, Emmanuel
<emmanuel.grumb...@intel.com> wrote:
>> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
>> Is the iwlwifi driver capable of capturing data frames when the channel
>> bonding is set to 80Mhz?
>
> dev  set freq  [20|40|80|80+80|160] [] 
> []
>
> You can take center_freq1 from the output of iw dev on a device that is 
> associated to the same AP.

Thanks a lot, Emmanuel. My iw binary that came default with my Ubuntu
distribution was very old (3.4) and it didn't have support for channel
bonding larger than 40Mhz.
I compiled the latest iw version from sources then I took the
center_freq1 from the beacon advertised by the AP. That's because the
iw dev on a device associated to the same AP gave me the control
frequency. After that, I was able to capture the data frames.

One more question that I promise to be the last one:
- I am trying to capture the Wi-Fi Direct traffic between two
smartphones: iw shows me that the p2p interface from one of the
smartphones uses 2.4Ghz, channel 1 so I set the monitor interface on
2.4, channel 1. The problem is that, again, I can't see the data
frames. Instead, I can see the Association/Authentication Request,
RTS/CTS, Block ACK (I attached the Wireshark capture at [1]).

Analyzing the capture, I noticed that the HT capabilities advertised
in the beacon frames indicates 802.11n D1.10. Does this trigger any
indication for you on how to setup the monitor interface?

[1] 
https://drive.google.com/file/d/0B5SBH08PU_ChNllaVHRienBSVlE/view?usp=sharing

Regards,
Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

On Tue, Apr 5, 2016 at 4:34 PM, Grumbach, Emmanuel
<emmanuel.grumb...@intel.com> wrote:
> On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
>> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>> <emmanuel.grumb...@intel.com> wrote:
>> > >
>> > > Hello,
>> > >
>> > > I am trying to capture packets that are exchanged between an AP
>> > > and a
>> > > smartphone on the 5Ghz frequency. For generating traffic, I
>> > > upload UDP
>> > > traffic from a laptop PC towards the smartphone using iperf.
>> > >
>> > > The problem is that I can see _only_ the control frames like
>> > > RTS/CTS, Block
>> > > ACK, while the data packets are not captured. I uploaded the
>> > > Wireshark
>> > > capture files at [1] (located inside the folders whose name
>> > > starts with 5Ghz).
>> >
>> > Most likely the packets on A band have a VHT preamble and your SKU
>> > is 11N only.
>>
>> My card, Intel 7260 [1]  supports 802.11 ac. So it should also
>> support
>> VHT, right? Is there any interface in user-space for checking after
>> VHT?
>
> 7260 has several flavors. The one you have doesn't support VHT:
>> iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 7260
>
> Dual Band means you have support for 5.2GHz, but Wireless N, means no
> VHT.

One of my colleagues had an Intel 7260 AC card so I repeated the experiments:
- if I set the channel width to 20Mhz from the AP and the monitor
interface using the command iw wlan0 set freq 5240 HT20+ I can see
data frames and the Block ACKs for these frames;
- if I set the channel width to 40Mhz from the AP and the monitor
interface using the command iw wlan0 set freq 5240 HT40- I can see
data frames and the Block ACKs for these frames;
- If I set the channel width to 80Mhz from the AP I don't how to set
up the monitor interface. I tried with iw wlan0 set freq 5240 HT40+
but it tells me that the argument is invalid.

Is the iwlwifi driver capable of capturing data frames when the
channel bonding is set to 80Mhz?

>
>>
>> However, I noticed a "failure" message in dmesg:
>> [4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
>> [4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
>> [4.030760] iwlwifi :04:00.0: Direct firmware load for
>> iwlwifi-7260-10.ucode failed with error -2
>> [4.035509] iwlwifi :04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> [4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
>> Wireless N 7260, REV=0x144
>> [4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>>
>> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
>> assumption is that the card can't enter into the 802.11 ac mode, it
>> just stays into 802.11n.
>>
>> doru@doru-N551JK:~$ iwconfig wlan0
>> wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
>>   Mode:Managed  Frequency:5.24 GHz  Access Point:
>> C4:6E:1F:4B:10:A2
>>   Bit Rate=150 Mb/s   Tx-Power=22 dBm
>>   Retry short limit:7   RTS thr:off   Fragment thr:off
>>   Power Management:on
>>   Link Quality=70/70  Signal level=-36 dBm
>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>   Tx excessive retries:0  Invalid misc:22   Missed beacon:0
>>
>>
>> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-ban
>> d-wireless-ac-7260-bluetooth-brief.html
>>
>> > Another option is that the traffic uses LDPC encoding and this
>> > device doesn't support it.
>> >
>> >
>> > >
>> > > If I use the 2.4 frequency, all the frames are captured. I also
>> > > uploaded the
>> > > Wireshark packet traces for 2.4Ghz at [1] (located inside the
>> > > folders whose
>> > > name starts with 2.4 Ghz).
>> > >
>> > > Is this a known bug or am I doing something wrong?
>> > >
>> > > Additional details:
>> > > Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band
>> > > Wireless N 7260,
>> > > REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware
>> > > version
>> > > 25.228.9.0 op_mode iwlmvm
>> > > Traffic encryption: WPA & WPA2 Personal
>> > > Setting up the card in wireless mode:
>> > > ip link set dev wlan0 down
>> > > iw wlan0 set type monitor
>> > > ip link set dev wlan0 up
>> > > iw wlan0 set freq 5240
>> > >
>> > > [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>> > >
>> > > Thank you, Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

On Wed, Apr 6, 2016 at 12:39 AM, Reinoud Koornstra
<reinoudkoorns...@gmail.com> wrote:
> On Tue, Apr 5, 2016 at 7:25 AM, Gucea Doru <gucea.d...@gmail.com> wrote:
>> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>> <emmanuel.grumb...@intel.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I am trying to capture packets that are exchanged between an AP and a
>>>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>>>> traffic from a laptop PC towards the smartphone using iperf.
>>>>
>>>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>>>> ACK, while the data packets are not captured. I uploaded the Wireshark
>>>> capture files at [1] (located inside the folders whose name starts with 
>>>> 5Ghz).
>>>
>>> Most likely the packets on A band have a VHT preamble and your SKU is 11N 
>>> only.
>>
>> My card, Intel 7260 [1]  supports 802.11 ac. So it should also support
>> VHT, right? Is there any interface in user-space for checking after
>> VHT?
>>
>> However, I noticed a "failure" message in dmesg:
>> [4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
>> [4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
>> [4.030760] iwlwifi :04:00.0: Direct firmware load for
>> iwlwifi-7260-10.ucode failed with error -2
>> [4.035509] iwlwifi :04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> [4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
>> Wireless N 7260, REV=0x144
>> [4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>
> The ucode failure isn't a problem, you'll likely find that another
> firmware does load.
> I've got also a 7620, but mine does support 11ac, so mine does support VHT.
>
> [9.820637] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7260, REV=0x144
>
> I also got a firmware load failure, but that's ok
>
> [8.399101] iwlwifi :04:00.0: Direct firmware load for
> iwlwifi-7260-17.ucode failed with error -2
>
> Cause here it does load the one it needs:
>
> [9.110486] iwlwifi :04:00.0: loaded firmware version
> 16.242414.0 op_mode iwlmvm
>
> I did fetch recent firmware by git to be up to date.
> I also added some instrumentation to get to see the unsupported splx
> structure and in my case it's just because of the package.count isn't
> what it should be.
> This isn't a problem as well really.
>
> Mar 14 00:32:36 router-dev kernel: [8.273274] iwlwifi
> :04:00.0: Unsupported splx structure
> Mar 14 00:32:36 router-dev kernel: [8.273276] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->type is 0x04
> Mar 14 00:32:36 router-dev kernel: [8.273277] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->package.count is 4
> Mar 14 00:32:36 router-dev kernel: [8.273277] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->package.elements[0].type is 0x01
> Mar 14 00:32:36 router-dev kernel: [8.273278] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: splx->package.elements[0].integer.value is 0
> Mar 14 00:32:36 router-dev kernel: [8.273279] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->type is 0x04
> Mar 14 00:32:36 router-dev kernel: [8.273280] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->package.count is 3
> Mar 14 00:32:36 router-dev kernel: [8.273281] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->package.elements[0].type is 0x01
> Mar 14 00:32:36 router-dev kernel: [8.273281] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: limits->package.elements[1].type is 0x01
> Mar 14 00:32:36 router-dev kernel: [8.273282] iwlwifi
> :04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
> splx_get_pwr_limit: WiFi power is not limited,
> domain_type->integer.value is 0
>
> I compiled wpa_supplicant and it connects without trouble to several
> access points.
> I mostly do it this way, because I maintain the mtk driver I use in
> the access point here so I get to see extensive info from both s

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
 wrote:
>>
>> Hello,
>>
>> I am trying to capture packets that are exchanged between an AP and a
>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>> traffic from a laptop PC towards the smartphone using iperf.
>>
>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>> ACK, while the data packets are not captured. I uploaded the Wireshark
>> capture files at [1] (located inside the folders whose name starts with 
>> 5Ghz).
>
> Most likely the packets on A band have a VHT preamble and your SKU is 11N 
> only.

My card, Intel 7260 [1]  supports 802.11 ac. So it should also support
VHT, right? Is there any interface in user-space for checking after
VHT?

However, I noticed a "failure" message in dmesg:
[4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
[4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
[4.030760] iwlwifi :04:00.0: Direct firmware load for
iwlwifi-7260-10.ucode failed with error -2
[4.035509] iwlwifi :04:00.0: loaded firmware version
25.228.9.0 op_mode iwlmvm
[4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless N 7260, REV=0x144
[4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
[4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
[   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
[   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled

Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
assumption is that the card can't enter into the 802.11 ac mode, it
just stays into 802.11n.

doru@doru-N551JK:~$ iwconfig wlan0
wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
  Mode:Managed  Frequency:5.24 GHz  Access Point: C4:6E:1F:4B:10:A2
  Bit Rate=150 Mb/s   Tx-Power=22 dBm
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:on
  Link Quality=70/70  Signal level=-36 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:22   Missed beacon:0


[1] 
http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth-brief.html

> Another option is that the traffic uses LDPC encoding and this device doesn't 
> support it.
>
>
>>
>> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
>> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
>> name starts with 2.4 Ghz).
>>
>> Is this a known bug or am I doing something wrong?
>>
>> Additional details:
>> Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 
>> 7260,
>> REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> Traffic encryption: WPA & WPA2 Personal
>> Setting up the card in wireless mode:
>> ip link set dev wlan0 down
>> iw wlan0 set type monitor
>> ip link set dev wlan0 up
>> iw wlan0 set freq 5240
>>
>> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>>
>> Thank you, Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

Hello,

I am trying to capture packets that are exchanged between an AP and a
smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
traffic from a laptop PC towards the smartphone using iperf.

The problem is that I can see _only_ the control frames like RTS/CTS,
Block ACK, while the data packets are not captured. I uploaded the
Wireshark capture files at [1] (located inside the folders whose name
starts with 5Ghz).

If I use the 2.4 frequency, all the frames are captured. I also
uploaded the Wireshark packet traces for 2.4Ghz at [1] (located inside
the folders whose name starts with 2.4 Ghz).

Is this a known bug or am I doing something wrong?

Additional details:
Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless N 7260, REV=0x144
Firmware version: iwlwifi :04:00.0: loaded firmware version
25.228.9.0 op_mode iwlmvm
Traffic encryption: WPA & WPA2 Personal
Setting up the card in wireless mode:
ip link set dev wlan0 down
iw wlan0 set type monitor
ip link set dev wlan0 up
iw wlan0 set freq 5240

[1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE

Thank you, Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Android with mac80211

[Gucea Doru]

Hello folks,

Is there any Android smartphone that uses the mac80211 framework for
Wi-Fi management (e.g: driver with support for mac80211)?

After searching several hours, the only result that I have is that the
wcn36xx driver [1] can be used on some Android devices. The problem is
that the driver is not yet upstreamed and it does lack a lot of
features.

If this is not the bestplace for asking this question, please link me
to the correct mailing list.

[1] https://github.com/KrasnikovEugene/wcn36xx

Thank you,
Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: bcmdhd: Concurrent use of wlan0 and virtual interface in managed mode

[Gucea Doru]

On Tue, Sep 8, 2015 at 12:01 AM, Arend van Spriel  wrote:

> The BCM4339 chip does not rely on mac80211. Instead, there is an
> 802.11 stack running on the device, ie. in firmware. The driver creates the
> primary interface, ie. wlan0. Additional P2P interfaces are created by
> wpa_supplicant.
>

Hm, BCM4339 uses the bcmdhd driver.
So the bcmdhd driver is not a softmac[1] driver and the the 802.11
processing is not done in software, right?

[1] 
https://wireless.wiki.kernel.org/en/developers/documentation/glossary#softmac

Regards,
Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: bcmdhd: Concurrent use of wlan0 and virtual interface in managed mode

[Gucea Doru]

Hello,

Thanks for helping me. I have some more questions related to parallel
usage of p2p and STA (station) interface.

I use a Nexus 5 device which has a BCM4339 [1] chip and it seems that
it's possible to transfer data in parallel using two connections: one
based on Wi-Fi direct(p2p, 2.4Ghz) and the other one based on a
connection to AP (wlan0, 5Ghz).

This is done by _time-sharing_ the wireless interface radio? From my
understanding the mac80211 layer have support for multiple virtual
interfaces and the switching between this interfaces is done inside
mac80211. Does the driver creates multiple virtual interfaces (one for
p2p and one for the connection to the AP) and the mac80211 manages the
time-sharing between them?

I am interested in understanding the code that decides how much the
radio should stay on a specific channel. I would be really grateful if
you could give me some details about the architecture.

[1] http://www.broadcom.com/press/release.php?id=s766879

Thanks,
Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bcmdhd: Concurrent use of wlan0 and virtual interface in managed mode

[Gucea Doru]

Hello, Arend

On Mon, Aug 24, 2015 at 11:08 AM, Arend van Spriel ar...@broadcom.com wrote:
 On 08/23/2015 05:15 PM, Gucea Doru wrote:

 Hello, community


 As you are using bcmdhd I don't think this particular community cares a lot
 about it. But I will take the bait ;-)


Thanks for taking the bait :). Should we move this discussion to a
bcmdhd specific mail-list?

 I started with the simplest use-case where I have only two APs (AP1
 and AP2) and an Android client  - a Nexus 5 device running the Kernel
 from [1]. For the connection with AP1 I used the already present
 interface wlan0. For the connection with AP2 I tried to use a newly
 created virtual interface but the wpa_supplicant connection is not
 successful. I'm not sure if this is a driver limitation or a driver
 bug.


 I am not sure either. For the upstream brcmfmac we don't allow it at the
 moment. I am kinda surprised you were able to create the additional
 interface.

As you can see at [1], the .max_interface inside
sta_p2p_iface_combinations is set to 3 so I assume that's the reason
for being able to create a new virtual interface in the managed mode.
However, the driver  needs a new virtual interface only for the case
when during P2P-GO removal, P2P-GO is first changed to STA and later
only removed [2]. I don't think it's there for concurrent use with the
wlan0 interface or with the p2p interface. So, the concurrent usage of
wlan0 and a new vif seems to be a driver limitation, at least.

 There are a couple of things that I can think of here which may
 cause issues:

 - APs operating on different channels.
Actually I use the same AP both for the connection using the wla0
interface and the newly created virtual interface.
So, both interfaces are connecting using the same channel.

 - Both STA interfaces have powersave enabled.
How could I disable powesave mode?

 - Firmware/driver do not support multi STA.

Considering what I said above, it seems to be at least a driver
limitation.  How could I discover if it's also a firmware limitation?
(I CC-ed Ecco Park who has a lot of patches in the driver but he
didn't respond :)
From my research, it seems that the firmware for BCM4330 (wireless
chip from Nexus 5) is closed-source. In this case, how does the driver
know how to communicate with the firmware? I assume there is an API
exposed by the firmware and the API is open-source. I would be really
grateful if you could give me more details about the communication
with the firmware.


 If APs are operating on the same channel it may work, but you probably won't
 have advantage of MP-TCP because of medium use.

Wow, I'm pleasantly surprised that you know about MP-TCP. That's
exactly what I will use. Connection to multiple APs was already
implemented on Linux and MP-TCP proved to have multiple advantages/
If we disregard WiFi interference between APs, the theoretically
optimal mobility solution is to always connect to every visible AP,
and let MPTCP handle load balancing at the transport layer: if an AP
has poor signal strength, its loss rate will be higher (because of
lower bandwidth and similar RTTs) and the MPTCP congestion controller
will simply migrate most of the traffic to the APs with better
connectivity to the client. This way, handover delays are eliminated
and the mobile enjoys continuous connectivity. But, yout're right,
medium use interferences can be a major issue, and you can read more
about at [3].

On Mon, Aug 24, 2015 at 2:08 PM, Gautam (Gautam Kumar) Shukla
gaut...@broadcom.com wrote:
 I guess you can achieve the same by starting p2p client or gc and connect it
 with p2p go device. So you have 2 interface , one your wlan interface and
 another one is gc interface.


Yep, I already did this using a setup composed of two Nexus 5, a
laptop and an AP:

wlan0: Nexus5_1 - AP -- Laptop (on 5 Ghz)
First Nexus 5 is connected to the AP on 5Ghz. Also, the laptop is
connected with the AP on 5Ghz.


p2p: Nexus5_1  (WiFi Direct on 2.4 Ghz) --- Nexus5_2  AP (on 5
Ghz) --- Laptop:
First Nexus 5 is connected with the second Nexus 5 using WIFi Direct
on the 2.4 Ghz. Both the laptop and the second Nexus 5 are connected
to the AP on 5Ghz.
When I use just the wlan0 interface for an iperf test I get a high
throughput (~60Mbits/s). When I just connect the phones with WiFi
Direct (no iperf data transmitted on p2p) I get an iperf throughput
three times lower.
What are the possible explanations?

Do you have any numbers for the time needed for a switch between a the
2.4 Ghz and 5Ghz for bcmdhd?


Best regards,
Doru

[1] 
https://github.com/gdetal/mptcp_nexus5/blob/eb8eded8a6986e1ac94976ae206c74351abd0d1b/drivers/net/wireless/bcmdhd/wl_cfg80211.c#L195-L202
[2] 
https://github.com/gdetal/mptcp_nexus5/blob/eb8eded8a6986e1ac94976ae206c74351abd0d1b/drivers/net/wireless/bcmdhd/wl_cfg80211.c#L161-L163
[3] http://nets.cs.pub.ro/~costin/files/multi-wifi.pdf
--
To unsubscribe from this list: send the line unsubscribe linux-wireless

bcmdhd: Concurrent use of wlan0 and virtual interface in managed mode

[Gucea Doru]

Hello, community

I'm a Master student doing my research on a subject related to Android
and multiple paths between two nodes. What I try to do now is to allow
a client to connect to multiple APs (Access Points).

I started with the simplest use-case where I have only two APs (AP1
and AP2) and an Android client  - a Nexus 5 device running the Kernel
from [1]. For the connection with AP1 I used the already present
interface wlan0. For the connection with AP2 I tried to use a newly
created virtual interface but the wpa_supplicant connection is not
successful. I'm not sure if this is a driver limitation or a driver
bug.

I will detail what I've done. After killing the wpa_supplicant process
I followed the steps:
--- Created a virtual interface in the station mode ---
root@hammerhead:/ # iw phy phy0 interface add vif_AP2 type station
root@hammerhead:/ # ip link set dev vif_AP2 address 64:89:9a:81:0f:22
root@hammerhead:/ # ip link set dev vif_AP2 up

 Connection to AP1 - SUCCESS 
root@hammerhead:/data # wpa_supplicant -iwlan0 -c/data/tmp/preshared_key_AP1
The dmesg log from [2] proved that the connection was successful.

 Connection to AP2 - FAILED 
root@hammerhead:/ # wpa_supplicant -ivif_AP2 -c/data/tmp/preshared_key_AP2
The dmesg log from [3] proved that the connection failed.

It seems that the connection error is due to a failed PNO setup [3].
Also, the failed PNO setup seems to prevent the AP scanning process
from running. More accurate, what is this PNO setup? I looked into the
Kernel code [4] but I can't figure it out how I could avoid this
error.

[1] https://github.com/gdetal/mptcp_nexus5
[2] 
https://drive.google.com/file/d/0B5SBH08PU_ChYzNIV3VxUWlqWGs/view?usp=sharing
[3] 
https://drive.google.com/file/d/0B5SBH08PU_ChNHdOck5UbjNERjQ/view?usp=sharing
[4] 
https://github.com/gdetal/mptcp_nexus5/blob/master/drivers/net/wireless/bcmdhd/dhd_pno.c

Any help is greatly appreciated,
Doru
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html