[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Dear Experts,
WiFi-BT Coexistence:
To let wireless LAN systems coexist with Bluetooth system, a hardware Packet Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire coexistence , BT_ACTIVE and WL_ACTIVE. When BT wants to use the medium, it will assert the BT_ACTIVE line, during which WLAN cannot perform any transactions. When WLAN is in client mode, during this assertion period waiting for a packet from WLAN router (AP) to be received , WLAN packet will be lost !!! Let us call this window during which WiFi being stomped ?by BT as stomping window. WLAN device in client mode considered here is based on AR9287 chipset and let us call this as Apple accessory?
Bonjour discovery:Apple devices connect to the same WiFi router to which the Apple accessory is also connected. Apple device is also connected in WiFi client mode. ?In order to determine other clients (Apple compatible) in the same network, it performs Bonjour discovery which is based on mDNS broadcast.
Concern/Query:-?The mDNS query is a broadcast query received from Apple device and sent by the WiFi AP to the WiFi network (to which the apple accessory is also connected) only once. The period of reception of this broadcast query can coincide with the stomping window. Hence the broadcast query can be lost by Apple accessory. This might result in discovery, pair verify (later) from apple devices to fail. Apple devices implement a back-off strategy and as per this the next discovery will be after 10s of minutes. During this long period the WiFi client based apple accessory will be offline!!!!?
Is the understanding and concern correct? If so, how can this be solved via ath9k drivers and/or settings in WiFi AP?
Regards
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160327/eb6300be/attachment.htm 

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[Adrian Chadd]

On 27 March 2016 at 09:43, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Dear Experts,
>
> WiFi-BT Coexistence:
> To let wireless LAN systems coexist with Bluetooth system, a hardware Packet
> Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire
> coexistence , BT_ACTIVE and WL_ACTIVE. When BT wants to use the medium, it
> will assert the BT_ACTIVE line, during which WLAN cannot perform any
> transactions. When WLAN is in client mode, during this assertion period
> waiting for a packet from WLAN router (AP) to be received , WLAN packet will
> be lost !!! Let us call this window during which WiFi being stomped  by BT
> as stomping window. WLAN device in client mode considered here is based on
> AR9287 chipset and let us call this as Apple accessory
>
> Bonjour discovery:
> Apple devices connect to the same WiFi router to which the Apple accessory
> is also connected. Apple device is also connected in WiFi client mode.  In
> order to determine other clients (Apple compatible) in the same network, it
> performs Bonjour discovery which is based on mDNS broadcast.
>
> Concern/Query:-
> The mDNS query is a broadcast query received from Apple device and sent by
> the WiFi AP to the WiFi network (to which the apple accessory is also
> connected) only once. The period of reception of this broadcast query can
> coincide with the stomping window. Hence the broadcast query can be lost by
> Apple accessory. This might result in discovery, pair verify (later) from
> apple devices to fail. Apple devices implement a back-off strategy and as
> per this the next discovery will be after 10s of minutes. During this long
> period the WiFi client based apple accessory will be offline!!!!

> Is the understanding and concern correct? If so, how can this be solved via
> ath9k drivers and/or settings in WiFi AP?

Well, sure. I mean, the bluetooth coexistence code is just designed to
ensure that they stomp predictably and can be controlled. I didn't
think the pair/discovery would take so long though, so I'd go and
figure out what's going on there.

You can set up the weights and stomping preference for controlling
bluetooth and wifi. I think at the moment ath9k (and freebsd) just use
a static weight matrix and prefer bt? I forget.

There's some extensions to 802.11 (802.11aa, at least) which allows
for reliable multicast. That means it gets replicated to each device
that asks for it, and it gets ACKed/retransmitted/etc. I don't know of
anything open source that implements all of that.



-adrian

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[Dave Taht]

These folk claim an open source prototype.

http://www.sigcomm.org/sites/default/files/ccr/papers/2014/January/2567561-2567567.pdf

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Hello Adrian,? ? ? Thanks for your response. Currently with 2-wire coexistence, BT has higher priority when compared to WiFi. You had shared the following different bitfields that can be configured with different weights:
WLAN:-wait_beacon | qcu_priority| rx_clear | wlan level
BT:-
bt_priority | bt freq | bt_tx_rx | bt_level

I have the following queries, please help:
1. ?wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will be set. If the weights during this state is kept the highest, then even if BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to catch the beacon. Am I correct in my understanding??
2. What happens if BT wants to transmit during this time when wait_beacon = TRUE; will the BT transmission be suppressed?
3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT module communicate if it will be transmitting or receiving to WLAN module? Because BT_PRIORITY will only indicate High or Low priority.
4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is there any way to indicate only Rx activities (E.g. Beacon reception etc) ?
5. ?Regarding your comment on dynamically changing weights. AR9287 and the BT chipsets are separate and connected to a Host controller running linux. ?As for different states of BT, if there is a need for different weights, I do not think at runtime the weights can be changed (by sending a command from BT to Host and then weight change from Host to WLAN)as we might not be able to meet the short timings. WHat is your opinion on this?

 Thanks & regards
Sandeep.

    On Monday, 28 March 2016 4:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 On 27 March 2016 at 09:43, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Dear Experts,
>
> WiFi-BT Coexistence:
> To let wireless LAN systems coexist with Bluetooth system, a hardware Packet
> Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire
> coexistence , BT_ACTIVE and WL_ACTIVE. When BT wants to use the medium, it
> will assert the BT_ACTIVE line, during which WLAN cannot perform any
> transactions. When WLAN is in client mode, during this assertion period
> waiting for a packet from WLAN router (AP) to be received , WLAN packet will
> be lost !!! Let us call this window during which WiFi being stomped? by BT
> as stomping window. WLAN device in client mode considered here is based on
> AR9287 chipset and let us call this as Apple accessory
>
> Bonjour discovery:
> Apple devices connect to the same WiFi router to which the Apple accessory
> is also connected. Apple device is also connected in WiFi client mode.? In
> order to determine other clients (Apple compatible) in the same network, it
> performs Bonjour discovery which is based on mDNS broadcast.
>
> Concern/Query:-
> The mDNS query is a broadcast query received from Apple device and sent by
> the WiFi AP to the WiFi network (to which the apple accessory is also
> connected) only once. The period of reception of this broadcast query can
> coincide with the stomping window. Hence the broadcast query can be lost by
> Apple accessory. This might result in discovery, pair verify (later) from
> apple devices to fail. Apple devices implement a back-off strategy and as
> per this the next discovery will be after 10s of minutes. During this long
> period the WiFi client based apple accessory will be offline!!!!

> Is the understanding and concern correct? If so, how can this be solved via
> ath9k drivers and/or settings in WiFi AP?

Well, sure. I mean, the bluetooth coexistence code is just designed to
ensure that they stomp predictably and can be controlled. I didn't
think the pair/discovery would take so long though, so I'd go and
figure out what's going on there.

You can set up the weights and stomping preference for controlling
bluetooth and wifi. I think at the moment ath9k (and freebsd) just use
a static weight matrix and prefer bt? I forget.

There's some extensions to 802.11 (802.11aa, at least) which allows
for reliable multicast. That means it gets replicated to each device
that asks for it, and it gets ACKed/retransmitted/etc. I don't know of
anything open source that implements all of that.



-adrian


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160329/1c2cd180/attachment.htm 

[ath9k-devel] Fw: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Hello Adrian,


? ? ? Thanks for your response. Currently with 2-wire coexistence, BT has higher priority when compared to WiFi. You had shared the following different bitfields that can be configured with different weights:
WLAN:-wait_beacon | qcu_priority| rx_clear | wlan level
BT:-
bt_priority | bt freq | bt_tx_rx | bt_level

I have the following queries, please help:
1. ?wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will be set. If the weights during this state is kept the highest, then even if BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to catch the beacon. Am I correct in my understanding??
2. What happens if BT wants to transmit during this time when wait_beacon = TRUE; will the BT transmission be suppressed?
3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT module communicate if it will be transmitting or receiving to WLAN module? Because BT_PRIORITY will only indicate High or Low priority.
4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is there any way to indicate only Rx activities (E.g. Beacon reception etc) ?
5. ?Regarding your comment on dynamically changing weights. AR9287 and the BT chipsets are separate and connected to a Host controller running linux. ?As for different states of BT, if there is a need for different weights, I do not think at runtime the weights can be changed (by sending a command from BT to Host and then weight change from Host to WLAN)as we might not be able to meet the short timings. WHat is your opinion on this?

 Thanks & regards
Sandeep.

    On Monday, 28 March 2016 4:13 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 On 27 March 2016 at 09:43, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Dear Experts,
>
> WiFi-BT Coexistence:
> To let wireless LAN systems coexist with Bluetooth system, a hardware Packet
> Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire
> coexistence , BT_ACTIVE and WL_ACTIVE. When BT wants to use the medium, it
> will assert the BT_ACTIVE line, during which WLAN cannot perform any
> transactions. When WLAN is in client mode, during this assertion period
> waiting for a packet from WLAN router (AP) to be received , WLAN packet will
> be lost !!! Let us call this window during which WiFi being stomped? by BT
> as stomping window. WLAN device in client mode considered here is based on
> AR9287 chipset and let us call this as Apple accessory
>
> Bonjour discovery:
> Apple devices connect to the same WiFi router to which the Apple accessory
> is also connected. Apple device is also connected in WiFi client mode.? In
> order to determine other clients (Apple compatible) in the same network, it
> performs Bonjour discovery which is based on mDNS broadcast.
>
> Concern/Query:-
> The mDNS query is a broadcast query received from Apple device and sent by
> the WiFi AP to the WiFi network (to which the apple accessory is also
> connected) only once. The period of reception of this broadcast query can
> coincide with the stomping window. Hence the broadcast query can be lost by
> Apple accessory. This might result in discovery, pair verify (later) from
> apple devices to fail. Apple devices implement a back-off strategy and as
> per this the next discovery will be after 10s of minutes. During this long
> period the WiFi client based apple accessory will be offline!!!!

> Is the understanding and concern correct? If so, how can this be solved via
> ath9k drivers and/or settings in WiFi AP?

Well, sure. I mean, the bluetooth coexistence code is just designed to
ensure that they stomp predictably and can be controlled. I didn't
think the pair/discovery would take so long though, so I'd go and
figure out what's going on there.

You can set up the weights and stomping preference for controlling
bluetooth and wifi. I think at the moment ath9k (and freebsd) just use
a static weight matrix and prefer bt? I forget.

There's some extensions to 802.11 (802.11aa, at least) which allows
for reliable multicast. That means it gets replicated to each device
that asks for it, and it gets ACKed/retransmitted/etc. I don't know of
anything open source that implements all of that.



-adrian


   

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160329/bd9eb7ff/attachment-0001.htm 

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[Adrian Chadd]

On 28 March 2016 at 21:22, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Adrian,
>       Thanks for your response. Currently with 2-wire coexistence, BT has
> higher priority when compared to WiFi. You had shared the following
> different bitfields that can be configured with different weights:
>
> WLAN:-
> wait_beacon | qcu_priority | rx_clear | wlan level
>
> BT:-
> bt_priority | bt freq | bt_tx_rx | bt_level
>
> I have the following queries, please help:
> 1.  wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will
> be set. If the weights during this state is kept the highest, then even if
> BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to
> catch the beacon. Am I correct in my understanding?

Right. The idea is that the STA wants to hear a beacon, so if it's
important to do this ,you want to have WLAN stomp BT.

> 2. What happens if BT wants to transmit during this time when wait_beacon =
> TRUE; will the BT transmission be suppressed?

If you set the weight appropriately then yeah, WLAN stomps BT.

> 3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is
> transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT
> module communicate if it will be transmitting or receiving to WLAN module?
> Because BT_PRIORITY will only indicate High or Low priority.

I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have to
check the PHY docs.

> 4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is
> there any way to indicate only Rx activities (E.g. Beacon reception etc) ?

On two/three-wire coex, no, I don't think so. The whole point is that
you just need to know "is the BT wanting to do stuff", "is the wlan
wanting to do stuff" and "who wins".
The wlan chip is the arbiter of who wins, it has the weights
programmed in to figure out what to do when.

> 5.  Regarding your comment on dynamically changing weights. AR9287 and the
> BT chipsets are separate and connected to a Host controller running linux.

> As for different states of BT, if there is a need for different weights, I
> do not think at runtime the weights can be changed (by sending a command
> from BT to Host and then weight change from Host to WLAN)as we might not be
> able to meet the short timings. WHat is your opinion on this?

No, the BT doesn't get to send the host commands like that. The driver
layer (ath9k) could be extended to include smarts about traffic
patterns and which BT profiles are active, so you can tune the weights
based on it.

The ath9k driver can also do things to "tune" how much of the channel
it uses - eg, by using the quiet time timers to control TX duty cycle
so BT has more of a chance to work.

The later chips (MCI?) implement a control protocol between the wlan
side and the bt side. I haven't yet ported that functionality to
freebsd so I don't have any operational experience with that!


-adrian

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Hello Adrian,Thanks for your quick response. Specifically 3 follow-up queries:a. Based on your comment, "I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have tocheck the PHY docs.". Can you please check this and confirm/let me know? Based on your comment, bt_tx_rx = 1 when BT_ACTIVE = 1 and 0 otherwise.b. Regarding the comment on BT indicating that it is only in receive mode. As we understand there are multicast/ broadcast packets sent from WiFi AP to WiFi STA (my WiFi device). There are cameras which does udp streaming. So, if BT can inform WLAN that it is only in receive mode, then WLAN can also receive the multicast/ broadcast packets and hence the throughput of WLAN will increase. ?What is your opinion?c. Next, in a 2-wire coexistence scheme, if BT_ACTIVE can we inform WLAN to enter into power save mode? As I understand with this, the WiFi AP will buffer all multicast/broadcast packets. When BT_ACTIVE is de-asserted, then WLAN can exit power save mode and get the buffered packets. Is this realistic? And if Yes, how can this be achieved?
Thanks & regardsSandeep 

    On Wednesday, 30 March 2016 1:59 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 On 28 March 2016 at 21:22, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Adrian,
>? ? ? Thanks for your response. Currently with 2-wire coexistence, BT has
> higher priority when compared to WiFi. You had shared the following
> different bitfields that can be configured with different weights:
>
> WLAN:-
> wait_beacon | qcu_priority | rx_clear | wlan level
>
> BT:-
> bt_priority | bt freq | bt_tx_rx | bt_level
>
> I have the following queries, please help:
> 1.? wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will
> be set. If the weights during this state is kept the highest, then even if
> BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to
> catch the beacon. Am I correct in my understanding?

Right. The idea is that the STA wants to hear a beacon, so if it's
important to do this ,you want to have WLAN stomp BT.

> 2. What happens if BT wants to transmit during this time when wait_beacon =
> TRUE; will the BT transmission be suppressed?

If you set the weight appropriately then yeah, WLAN stomps BT.

> 3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is
> transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT
> module communicate if it will be transmitting or receiving to WLAN module?
> Because BT_PRIORITY will only indicate High or Low priority.

I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have to
check the PHY docs.

> 4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is
> there any way to indicate only Rx activities (E.g. Beacon reception etc) ?

On two/three-wire coex, no, I don't think so. The whole point is that
you just need to know "is the BT wanting to do stuff", "is the wlan
wanting to do stuff" and "who wins".
The wlan chip is the arbiter of who wins, it has the weights
programmed in to figure out what to do when.

> 5.? Regarding your comment on dynamically changing weights. AR9287 and the
> BT chipsets are separate and connected to a Host controller running linux.

> As for different states of BT, if there is a need for different weights, I
> do not think at runtime the weights can be changed (by sending a command
> from BT to Host and then weight change from Host to WLAN)as we might not be
> able to meet the short timings. WHat is your opinion on this?

No, the BT doesn't get to send the host commands like that. The driver
layer (ath9k) could be extended to include smarts about traffic
patterns and which BT profiles are active, so you can tune the weights
based on it.

The ath9k driver can also do things to "tune" how much of the channel
it uses - eg, by using the quiet time timers to control TX duty cycle
so BT has more of a chance to work.

The later chips (MCI?) implement a control protocol between the wlan
side and the bt side. I haven't yet ported that functionality to
freebsd so I don't have any operational experience with that!


-adrian


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160330/305106e9/attachment.htm 

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[Adrian Chadd]

Hi!

I don't know if you can do simulaneous wlan and BT RX - especially
since WLAN RX sometimes requires ACKs to be sent. :) But for
multicast, sure. You'd have to check the NIC schematic and antenna
switch programming to see if you can do simultaneous wlan RX (with no
TXing, eg RTS/CTS, ACK, etc) whilst also doing BT RX.

As for BT_ACTIVE -> powersave; I don't think you can get interrupts
based on that, but you can poll the gpio pin yourself and then tell
the driver to not transmit and/or enter sleep state. Entering sleep
state requires that you send some frame anyway to tell the AP you're
going to sleep.


-a

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Hello Adrian,Thanks for the response. Regarding your comment, "I don't think you can get interrupts?based on that, but you can poll the gpio pin yourself?"In any MCU, we should be able generate an interrupt on rising/falling edge of GPIO and execute the ISR. Simillary, isn't it possible in ath9k to trigger a rising edge interrupt on BT_ACTIVE and in the respective ISR send a packet with power save management mode bit set. Similarly on the falling edge send a packet with power save management mode bit reset? Because polling for GPIOs every milliseconds will consume too much of CPU and not performance friendly for any system.RegardsSandeep. 

    On Thursday, 31 March 2016 1:32 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 Hi!

I don't know if you can do simulaneous wlan and BT RX - especially
since WLAN RX sometimes requires ACKs to be sent. :) But for
multicast, sure. You'd have to check the NIC schematic and antenna
switch programming to see if you can do simultaneous wlan RX (with no
TXing, eg RTS/CTS, ACK, etc) whilst also doing BT RX.

As for BT_ACTIVE -> powersave; I don't think you can get interrupts
based on that, but you can poll the gpio pin yourself and then tell
the driver to not transmit and/or enter sleep state. Entering sleep
state requires that you send some frame anyway to tell the AP you're
going to sleep.


-a


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160331/af90af21/attachment.htm 

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[Adrian Chadd]

On 30 March 2016 at 18:33, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Adrian,
> Thanks for the response. Regarding your comment, "I don't think you can get
> interrupts based on that, but you can poll the gpio pin yourself "
> In any MCU, we should be able generate an interrupt on rising/falling edge
> of GPIO and execute the ISR. Simillary, isn't it possible in ath9k to
> trigger a rising edge interrupt on BT_ACTIVE and in the respective ISR send
> a packet with power save management mode bit set. Similarly on the falling
> edge send a packet with power save management mode bit reset? Because
> polling for GPIOs every milliseconds will consume too much of CPU and not
> performance friendly for any system.

I know. There's apparently GPIO interrupt support in the ath9k
hardware but I've never used it. All of the register definition should
be there though!

I just don't know if you'll get them if it's being wired as a
BT_ACTIVE pin instead of a GPIO pin..


-adrian

> Regards
> Sandeep.
>
>
> On Thursday, 31 March 2016 1:32 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>
>
> Hi!
>
> I don't know if you can do simulaneous wlan and BT RX - especially
> since WLAN RX sometimes requires ACKs to be sent. :) But for
> multicast, sure. You'd have to check the NIC schematic and antenna
> switch programming to see if you can do simultaneous wlan RX (with no
> TXing, eg RTS/CTS, ACK, etc) whilst also doing BT RX.
>
> As for BT_ACTIVE -> powersave; I don't think you can get interrupts
> based on that, but you can poll the gpio pin yourself and then tell
> the driver to not transmit and/or enter sleep state. Entering sleep
> state requires that you send some frame anyway to tell the AP you're
> going to sleep.
>
>
>
> -a
>
>

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Hello Adrian,Thanks for your response. Two follow-up queries:a. Regarding your comment, "I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have to?check the PHY docs." Can you please check this and let me know?
b. Regarding power save mode. As I understand, as per the legacy power save mode, buffered unicast messages can be retrived by a wifi-client after it wakes-up by issueing a PS-Poll command. And buffered multicast/broadcast will be asynchronously sent from WiFi-AP after reaching DTIM = 0. Is there any mechanism available with ath9k WiFi-client to perform the following:-Before going to sleep a WiFi-Client informs by a command to buffer all multicast/broadcast messages to WiFi-AP. The Wifi client sleep and wake-up say after a maximum duration of 25ms. Then it sends another command to WiFi-AP to transmit all buffered multicast/broadcast packets.?
RegardsSandeep. 

    On Friday, 1 April 2016 3:34 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 On 30 March 2016 at 18:33, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Adrian,
> Thanks for the response. Regarding your comment, "I don't think you can get
> interrupts based on that, but you can poll the gpio pin yourself "
> In any MCU, we should be able generate an interrupt on rising/falling edge
> of GPIO and execute the ISR. Simillary, isn't it possible in ath9k to
> trigger a rising edge interrupt on BT_ACTIVE and in the respective ISR send
> a packet with power save management mode bit set. Similarly on the falling
> edge send a packet with power save management mode bit reset? Because
> polling for GPIOs every milliseconds will consume too much of CPU and not
> performance friendly for any system.

I know. There's apparently GPIO interrupt support in the ath9k
hardware but I've never used it. All of the register definition should
be there though!

I just don't know if you'll get them if it's being wired as a
BT_ACTIVE pin instead of a GPIO pin..


-adrian

> Regards
> Sandeep.
>
>
> On Thursday, 31 March 2016 1:32 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>
>
> Hi!
>
> I don't know if you can do simulaneous wlan and BT RX - especially
> since WLAN RX sometimes requires ACKs to be sent. :) But for
> multicast, sure. You'd have to check the NIC schematic and antenna
> switch programming to see if you can do simultaneous wlan RX (with no
> TXing, eg RTS/CTS, ACK, etc) whilst also doing BT RX.
>
> As for BT_ACTIVE -> powersave; I don't think you can get interrupts
> based on that, but you can poll the gpio pin yourself and then tell
> the driver to not transmit and/or enter sleep state. Entering sleep
> state requires that you send some frame anyway to tell the AP you're
> going to sleep.
>
>
>
> -a
>
>


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160401/530ac074/attachment.htm 

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[Adrian Chadd]

Hi,

ath9k has support for station powersave, and it's driven by mac80211.
You should be able to implement that policy in mac80211 and then add
hooks so your bluetooth code can get notifications about it.


-a

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep suresh]

Hello,?as I understand?behavior in WiFi-AP is as follows (for any wifi clients in power save mode):1. Buffered unicast messages to be sent to a STA via "Power-save POLL" command from STA.2. Buffered multicast/broadcast messages to be sent?out?following the beacon containing DTIM=0.How can changes in WiFi-Client at ath9k mac80211 influence any third party router to send even multi-cast/broadcast messages after a "Power Save Poll"?ThanksSandeep. 

    On Saturday, 2 April 2016 1:59 AM, Adrian Chadd <adrian@freebsd.org> wrote:
 

 Hi,

ath9k has support for station powersave, and it's driven by mac80211.
You should be able to implement that policy in mac80211 and then add
hooks so your bluetooth code can get notifications about it.


-a


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160402/38a4bd0c/attachment.htm 

[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

[sandeep]

sandeep suresh <sandeep.suresh <at> yahoo.co.in> writes:

> 
> 
> Hello,?as I understand?behavior in WiFi-AP is as follows (for any wifi 
clients in power save mode):
> 1. Buffered unicast messages to be sent to a STA via "Power-save POLL" 
command from STA.
> 2. Buffered multicast/broadcast messages to be sent?out?following the 
beacon containing DTIM=0.
> How can changes in WiFi-Client at ath9k mac80211 influence any third 
party router to send even multi-cast/broadcast messages after a "Power 
Save Poll"?
> Thanks
> Sandeep. 
> 
> 
>     On Saturday, 2 April 2016 1:59 AM, Adrian Chadd <adrian <at> 
freebsd.org> wrote:
>   Hi,ath9k has support for station powersave, and it's driven by 
mac80211.You should be able to implement that policy in mac80211 and 
then addhooks so your bluetooth code can get notifications about it.
> -a
> 
> 
>      
> 
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel <at> lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 


Hello, as I understand behavior in WiFi-AP is as follows (for any wifi 
clients in power save mode):
1. Buffered unicast messages to be sent to a STA via "Power-save POLL" 
command from STA.
2. Buffered multicast/broadcast messages to be sent out following the 
beacon containing DTIM=0.
How can changes in WiFi-Client at ath9k mac80211 influence any third 
party router to send even multi-cast/broadcast messages after a "Power 
Save Poll"?
Thanks
Sandeep.