LinuxLists.cc - [BUG] P2P setup timeout

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:

> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:

Obviously :)

> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
> this working, and the devices are really nice apart from this bug. I
> will keep you up to date, but if you have any hints where to continue
> digging, lemme know. Until it's fixed, I'll just work on
> wired-displays via ethernet instead of wifi-displays..

Based on what Oleksij said, these issues are likely not even related -
maybe ath9k_htc can't even set the rates to exclude CCK, so even if that
call were to succeed it wouldn't work?

The issue here doesn't seem to be that call anyway, since that call was
for the data frames on the p2p-wlan1-0 interface, but rather seems to be
that ath9k_htc ignores the no-CCK parameter for the NL80211_CMD_FRAME
command (in mac80211, this would be IEEE80211_TX_CTL_NO_CCK_RATE)

johannes

2013-12-16 13:45:32

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

On Mon, 2013-12-16 at 14:39 +0100, David Herrmann wrote:

> > Can you check in a sniffer what the frame bitrates are that go out? This
> > seems suspicious:
> >
> > nl80211: Set TX rates failed: ret=-100 (Network is down)
>
> I looked at the sniffer data and all I see is a huge amount of p2p
> probe requests from my local device, the successful p2p-invitation and
> invitation response and then lots of go-negotiation requests that
> never get any response.

Right, and I suspect they don't get a response because (as the sniffer
trace tells me) they're sent with 1 Mbps (a CCK rate), which is invalid
in the P2P spec (must use OFDM).

Thus something is wrong with the TX bitrates stuff, but I can't tell you
where that would be ...

johannes

2013-12-17 05:50:24

by Ujjal Roy

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Hi Johannes,

On 12/16/2013 07:15 PM, Johannes Berg wrote:
> On Mon, 2013-12-16 at 14:39 +0100, David Herrmann wrote:
>
> Right, and I suspect they don't get a response because (as the sniffer
> trace tells me) they're sent with 1 Mbps (a CCK rate), which is invalid
> in the P2P spec (must use OFDM).
>

Can you please let me know, is the P2P spec freely available to read or
download? If so, please provide some info from where I can able to get
the document. Actually, I need to know - how to add P2P_DEVICE support
in a driver.

Thanks,
UjjaL

2013-12-09 14:03:19

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Am 06.12.2013 11:18, schrieb David Herrmann:
> Hi
>
> I am currently working on user-space helpers for P2P setup as part of
> an Open-Source Miracast implementation (openwfd). I can set up a
> P2P-group with my Android test-device just fine, however, it only
> works if initiated by the GNU/Linux host. Once I initiate the
> p2p-connect from the Android device, it creates a group and sends me a
> p2p-invitation which I am unable to accept.
>
> I am running wpa_supplicant-git from today (but also tried older
> versions), ath9k-htc from linus-git (3.13-rc2) and the relevant log
> files are appended.
>
> My wpa-config is:
> ctrl_interface=/var/run/wpa_supplicant
> update_config=1
> p2p_go_ht40=1
>
> And I do nothing else than open wpa_cli and run:
> p2p_find
> p2p_connect <peer> pbc
>
> This works perfectly well if I don't touch the Android device before
> issuing the p2p_connect. However, if I initiate the first connect on
> the Android device, my linux host gets a p2p-invitation:
> <3>P2P-INVITATION-RECEIVED sa=12:68:3f:4e:39:f2
> go_dev_addr=12:68:3f:4e:39:f2 bssid=12:68:3f:4e:b9:f2 unknown-network
>
> I tried accepting this invitation via p2p_connect, but just nothing
> happens. I also tried any combination of arguments
> (auth/join/persistent, pbc/pin/PIN#, playing with go_intent=), didn't
> help..
>
> Looking at the wpa-log, I see a timeout firing repeatedly:
> P2P: GO Negotiation Request TX callback: success=1
> P2P: State CONNECT -> CONNECT
> P2P: Set timeout (state=CONNECT): 0.500000 sec
> P2P: Timeout (state=CONNECT)
> Below you can see the whole sequence of wpa-messages that repeat over
> and over again until I cancel the connection-request.
>
> For WFD I need to initiate the connect from the Android device,
> otherwise their WFD stack won't recognize the connection. So if anyone
> has hints what might be wrong here, I'd gladly try out any patches or
> configurations.
> I cannot test whether this happens with other drivers, too, as I
> couldn't get my hands on a device other than ath9k-htc which supports
> p2p on linux.
>
> If anyone is interested, I'll be presenting OpenWFD at FOSDEM in the
> graphics-devroom. It would be awesome if I can get my Nexus-4 as a
> working demo until then. Otherwise, it'll be just linux<->linux demos
> (non-android), which is already working fine.

Is it related to your "Atheros AR9280: NULL-deref during P2P setup"
issue? Or it is not reproducible any more?

--
Regards,
Oleksij

2013-12-16 15:38:02

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Am 16.12.2013 16:29, schrieb Johannes Berg:
> On Mon, 2013-12-16 at 16:26 +0100, Oleksij Rempel wrote:
>> Am 16.12.2013 16:15, schrieb Johannes Berg:
>>> On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
>>>
>>>> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:
>>>
>>> Obviously :)
>>>
>>>> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
>>>> this working, and the devices are really nice apart from this bug. I
>>>> will keep you up to date, but if you have any hints where to continue
>>>> digging, lemme know. Until it's fixed, I'll just work on
>>>> wired-displays via ethernet instead of wifi-displays..
>>>
>>> Based on what Oleksij said, these issues are likely not even related -
>>> maybe ath9k_htc can't even set the rates to exclude CCK, so even if that
>>> call were to succeed it wouldn't work?
>>
>> Hmm.. WMI_BITRATE_MASK should do it.
>> ieee80211_ops->set_bitrate_mask is set, so theoretically we should be
>> able to exclude CCK. Today i won't be able to check it.
>
> There are two things:
> * the issue at hand, which is only for some certain management frames
> that I
> believe are sent over the normal wlan0 netdev/vif, but still must not
> use CCK
> even though wlan0 allows CCK
> * the issue about the set tx-rate on the p2p netdev/vif, which is how I
> noticed
> this, but which is actually not related to the current bug
>
> It sounds to me like only the latter can be solved with WMI_BITRATE_MASK
> since you can't generally disable CCK on wlan0 when doing P2P (you might
> be connected to an 11b AP at the same time)
>
> For the latter issue, you really need a per-frame "disable CCK" flag in
> the firmware, or you need to use a P2P_DEVICE vif.

Ah.. there is comment which clarify the situation with
ieee80211_ops->set_bitrate_mask in ath9k_htc:
/*
* Currently, this is used only for selecting the minimum rate
* for management frames, rate selection for data frames remain
* unaffected.
*/

--
Regards,
Oleksij

2013-12-16 12:05:34

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Hi

Anyone with ideas? Or hints whether it's driver or wpa_supplicant related?

Thanks
David

On Fri, Dec 6, 2013 at 11:18 AM, David Herrmann <[email protected]> wrote:
> Hi
>
> I am currently working on user-space helpers for P2P setup as part of
> an Open-Source Miracast implementation (openwfd). I can set up a
> P2P-group with my Android test-device just fine, however, it only
> works if initiated by the GNU/Linux host. Once I initiate the
> p2p-connect from the Android device, it creates a group and sends me a
> p2p-invitation which I am unable to accept.
>
> I am running wpa_supplicant-git from today (but also tried older
> versions), ath9k-htc from linus-git (3.13-rc2) and the relevant log
> files are appended.
>
> My wpa-config is:
> ctrl_interface=/var/run/wpa_supplicant
> update_config=1
> p2p_go_ht40=1
>
> And I do nothing else than open wpa_cli and run:
> p2p_find
> p2p_connect <peer> pbc
>
> This works perfectly well if I don't touch the Android device before
> issuing the p2p_connect. However, if I initiate the first connect on
> the Android device, my linux host gets a p2p-invitation:
> <3>P2P-INVITATION-RECEIVED sa=12:68:3f:4e:39:f2
> go_dev_addr=12:68:3f:4e:39:f2 bssid=12:68:3f:4e:b9:f2 unknown-network
>
> I tried accepting this invitation via p2p_connect, but just nothing
> happens. I also tried any combination of arguments
> (auth/join/persistent, pbc/pin/PIN#, playing with go_intent=), didn't
> help..
>
> Looking at the wpa-log, I see a timeout firing repeatedly:
> P2P: GO Negotiation Request TX callback: success=1
> P2P: State CONNECT -> CONNECT
> P2P: Set timeout (state=CONNECT): 0.500000 sec
> P2P: Timeout (state=CONNECT)
> Below you can see the whole sequence of wpa-messages that repeat over
> and over again until I cancel the connection-request.
>
> For WFD I need to initiate the connect from the Android device,
> otherwise their WFD stack won't recognize the connection. So if anyone
> has hints what might be wrong here, I'd gladly try out any patches or
> configurations.
> I cannot test whether this happens with other drivers, too, as I
> couldn't get my hands on a device other than ath9k-htc which supports
> p2p on linux.
>
> If anyone is interested, I'll be presenting OpenWFD at FOSDEM in the
> graphics-devroom. It would be awesome if I can get my Nexus-4 as a
> working demo until then. Otherwise, it'll be just linux<->linux demos
> (non-android), which is already working fine.
>
> Any hints welcome!
> David
>
>
> The repeating log-messages from wpa-supplicant are (see attached file
> for the whole log):
>
> Off-channel: Action frame sequence done notification
> nl80211: Cancel TX frame wait: cookie=0xffff88008fddae00
> nl80211: wait cancel failed: ret=-2 (No such file or directory)
> P2P: State CONNECT -> CONNECT_LISTEN
> P2P: Starting short listen state (state=CONNECT_LISTEN)
> WPS: * Version (hardcoded 0x10)
> P2P: WPS IE Device Password ID: 4
> WPS: * UUID-E
> P2P: * P2P IE header
> P2P: * Capability dev=25 group=00
> P2P: * Device Info
> nl80211: Probe Request reporting already on!
> nl_preq=0x888888888ab37c09
> nl80211: Remain-on-channel cookie 0xa7 for freq=2437 MHz duration=204
> nl80211: Drv Event 55 (NL80211_CMD_REMAIN_ON_CHANNEL) received for wlan1
> nl80211: Remain-on-channel event (cancel=0 freq=2437 channel_type=0
> duration=204 cookie=0xa7 (match))
> wlan1: Event REMAIN_ON_CHANNEL (22) received
> Off-channel: Send Action callback (without_roc=0
> pending_action_tx=(nil))
> P2P: Starting Listen timeout(0,204800) on freq=2437 based on callback
> P2P: Set timeout (state=CONNECT_LISTEN): 0.224800 sec
> nl80211: Drv Event 56 (NL80211_CMD_CANCEL_REMAIN_ON_CHANNEL) received
> for wlan1
> nl80211: Remain-on-channel event (cancel=1 freq=2437 channel_type=0
> duration=0 cookie=0xa7 (match))
> wlan1: Event CANCEL_REMAIN_ON_CHANNEL (23) received
> P2P: Cancel remain-on-channel callback (p2p_long_listen=0 ms
> pending_action_tx=(nil))
> P2P: Driver ended Listen state (freq=2437)
> P2P: Skip stop_listen since not in listen_only state.
> P2P: Timeout (state=CONNECT_LISTEN)
> P2P: State CONNECT_LISTEN -> CONNECT
> P2P: * Dialog Token: 1
> P2P: * P2P IE header
> P2P: * Capability dev=25 group=08
> P2P: * GO Intent: Intent 7 Tie breaker 0
> P2P: * Configuration Timeout: GO 255 (*10ms) client 20 (*10ms)
> P2P: * Listen Channel: Regulatory Class 81 Channel 6
> P2P: * Intended P2P Interface Address 12:6f:3f:7a:7c:24
> P2P: * Channel List - hexdump(len=16): 58 58 04 51 0b 01 02 03 04 05
> 06 07 08 09 0a 0b
> P2P: * Device Info
> P2P: * Operating Channel: Regulatory Class 81 Channel 6
> WPS: * Version (hardcoded 0x10)
> P2P: WPS IE Device Password ID: 4
> P2P: Sending GO Negotiation Request
> P2P: State CONNECT -> CONNECT
> Off-channel: Send action frame: freq=2437 dst=12:68:3f:4e:39:f2
> src=10:6f:3f:7a:7c:24 bssid=12:68:3f:4e:39:f2 len=113
> nl80211: Send Action frame (ifindex=14, freq=2437 MHz wait=500 ms
> no_cck=1)
> nl80211: Drv Event 60 (NL80211_CMD_FRAME_TX_STATUS) received for wlan1
> nl80211: Frame TX status event
> nl80211: Action TX status: cookie=0ffff88008fddb100 (match) (ack=1)
> wlan1: Event TX_STATUS (18) received
> wlan1: EVENT_TX_STATUS dst=12:68:3f:4e:39:f2 type=0 stype=13
> Off-channel: Delete matching pending action frame
> Off-channel: TX status result=0 cb=0x42eaf0
> P2P: Action frame TX callback (state=1 freq=2437 dst=12:68:3f:4e:39:f2
> src=10:6f:3f:7a:7c:24 bssid=12:68:3f:4e:39:f2 result=0
> P2P: GO Negotiation Request TX callback: success=1
> P2P: State CONNECT -> CONNECT
> P2P: Set timeout (state=CONNECT): 0.500000 sec
> P2P: Timeout (state=CONNECT)
> Off-channel: Action frame sequence done notification
>
>
> wpa_cli log/interaction is this:
>
> wpa_cli v2.1-devel
> Copyright (c) 2004-2013, Jouni Malinen <[email protected]> and contributors
>
> This software may be distributed under the terms of the BSD license.
> See README for more details.
>
> Interactive mode
>
>> p2p_find
> OK
> <3>P2P-DEVICE-FOUND 12:68:3f:4e:39:f2 p2p_dev_addr=12:68:3f:4e:39:f2
> pri_dev_type=10-0050F204-5 name='dvdhrm-nx' config_methods=0x188
> dev_capab=0x25 group_capab=0x0
> <3>P2P-INVITATION-RECEIVED sa=12:68:3f:4e:39:f2
> go_dev_addr=12:68:3f:4e:39:f2 bssid=12:68:3f:4e:b9:f2 unknown-network
>> p2p_connect 12:68:3f:4e:39:f2 pbc
> OK
> <3>P2P-FIND-STOPPED

2013-12-17 07:20:08

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

On Tue, 2013-12-17 at 11:20 +0530, Ujjal Roy wrote:
> Hi Johannes,
>
> On 12/16/2013 07:15 PM, Johannes Berg wrote:
> > On Mon, 2013-12-16 at 14:39 +0100, David Herrmann wrote:
> >
> > Right, and I suspect they don't get a response because (as the sniffer
> > trace tells me) they're sent with 1 Mbps (a CCK rate), which is invalid
> > in the P2P spec (must use OFDM).
> >
>
> Can you please let me know, is the P2P spec freely available to read or
> download? If so, please provide some info from where I can able to get
> the document. Actually, I need to know - how to add P2P_DEVICE support
> in a driver.

No, it isn't. However, P2P_DEVICE support is not described in the spec
anyway since it's a Linux thing.

johannes

2013-12-16 13:39:12

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Hi

On Mon, Dec 16, 2013 at 1:36 PM, Johannes Berg
<[email protected]> wrote:
> On Fri, 2013-12-06 at 11:18 +0100, David Herrmann wrote:
>> Hi
>>
>> I am currently working on user-space helpers for P2P setup as part of
>> an Open-Source Miracast implementation (openwfd). I can set up a
>> P2P-group with my Android test-device just fine, however, it only
>> works if initiated by the GNU/Linux host. Once I initiate the
>> p2p-connect from the Android device, it creates a group and sends me a
>> p2p-invitation which I am unable to accept.
>>
>> I am running wpa_supplicant-git from today (but also tried older
>> versions), ath9k-htc from linus-git (3.13-rc2) and the relevant log
>> files are appended.
>
> Can you check in a sniffer what the frame bitrates are that go out? This
> seems suspicious:
>
> nl80211: Set TX rates failed: ret=-100 (Network is down)

I looked at the sniffer data and all I see is a huge amount of p2p
probe requests from my local device, the successful p2p-invitation and
invitation response and then lots of go-negotiation requests that
never get any response.

I don't know which information you're interested in specifically, so I
appended the data (I hope I'm allowed to do that?)
Anything else I can try?

The Android device is: 12:68:3f:4e:39:f2
My local device is: 10:6f:3f:7a:7c:24 / Buffalo_7a:7c:24

Thanks
David

Attachments:

p2p.pcapng (58.04 kB)

2013-12-16 15:26:58

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Am 16.12.2013 16:15, schrieb Johannes Berg:
> On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
>
>> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:
>
> Obviously :)
>
>> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
>> this working, and the devices are really nice apart from this bug. I
>> will keep you up to date, but if you have any hints where to continue
>> digging, lemme know. Until it's fixed, I'll just work on
>> wired-displays via ethernet instead of wifi-displays..
>
> Based on what Oleksij said, these issues are likely not even related -
> maybe ath9k_htc can't even set the rates to exclude CCK, so even if that
> call were to succeed it wouldn't work?

Hmm.. WMI_BITRATE_MASK should do it.
ieee80211_ops->set_bitrate_mask is set, so theoretically we should be
able to exclude CCK. Today i won't be able to check it.

> The issue here doesn't seem to be that call anyway, since that call was
> for the data frames on the p2p-wlan1-0 interface, but rather seems to be
> that ath9k_htc ignores the no-CCK parameter for the NL80211_CMD_FRAME
> command (in mac80211, this would be IEEE80211_TX_CTL_NO_CCK_RATE)
>
> johannes
>

--
Regards,
Oleksij

2013-12-16 15:30:02

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

On Mon, 2013-12-16 at 16:26 +0100, Oleksij Rempel wrote:
> Am 16.12.2013 16:15, schrieb Johannes Berg:
> > On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
> >
> >> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:
> >
> > Obviously :)
> >
> >> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
> >> this working, and the devices are really nice apart from this bug. I
> >> will keep you up to date, but if you have any hints where to continue
> >> digging, lemme know. Until it's fixed, I'll just work on
> >> wired-displays via ethernet instead of wifi-displays..
> >
> > Based on what Oleksij said, these issues are likely not even related -
> > maybe ath9k_htc can't even set the rates to exclude CCK, so even if that
> > call were to succeed it wouldn't work?
>
> Hmm.. WMI_BITRATE_MASK should do it.
> ieee80211_ops->set_bitrate_mask is set, so theoretically we should be
> able to exclude CCK. Today i won't be able to check it.

There are two things:
* the issue at hand, which is only for some certain management frames
that I
believe are sent over the normal wlan0 netdev/vif, but still must not
use CCK
even though wlan0 allows CCK
* the issue about the set tx-rate on the p2p netdev/vif, which is how I
noticed
this, but which is actually not related to the current bug

It sounds to me like only the latter can be solved with WMI_BITRATE_MASK
since you can't generally disable CCK on wlan0 when doing P2P (you might
be connected to an 11b AP at the same time)

For the latter issue, you really need a per-frame "disable CCK" flag in
the firmware, or you need to use a P2P_DEVICE vif.

johannes

2013-12-16 12:36:59

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

On Fri, 2013-12-06 at 11:18 +0100, David Herrmann wrote:
> Hi
>
> I am currently working on user-space helpers for P2P setup as part of
> an Open-Source Miracast implementation (openwfd). I can set up a
> P2P-group with my Android test-device just fine, however, it only
> works if initiated by the GNU/Linux host. Once I initiate the
> p2p-connect from the Android device, it creates a group and sends me a
> p2p-invitation which I am unable to accept.
>
> I am running wpa_supplicant-git from today (but also tried older
> versions), ath9k-htc from linus-git (3.13-rc2) and the relevant log
> files are appended.

Can you check in a sniffer what the frame bitrates are that go out? This
seems suspicious:

nl80211: Set TX rates failed: ret=-100 (Network is down)

johannes

2013-12-16 13:51:16

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Hi

On Mon, Dec 16, 2013 at 2:45 PM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2013-12-16 at 14:39 +0100, David Herrmann wrote:
>
>> > Can you check in a sniffer what the frame bitrates are that go out? This
>> > seems suspicious:
>> >
>> > nl80211: Set TX rates failed: ret=-100 (Network is down)
>>
>> I looked at the sniffer data and all I see is a huge amount of p2p
>> probe requests from my local device, the successful p2p-invitation and
>> invitation response and then lots of go-negotiation requests that
>> never get any response.
>
> Right, and I suspect they don't get a response because (as the sniffer
> trace tells me) they're sent with 1 Mbps (a CCK rate), which is invalid
> in the P2P spec (must use OFDM).
>
> Thus something is wrong with the TX bitrates stuff, but I can't tell you
> where that would be ...

Ok, I will try hooking into the ath9k driver then and see why setting
TX rates fails. Thanks a lot! Maybe Oleksij has some more ideas on
that.

Thanks
David

2013-12-16 15:53:38

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Hi

On Mon, Dec 16, 2013 at 4:37 PM, Oleksij Rempel <[email protected]> wrote:
> Am 16.12.2013 16:29, schrieb Johannes Berg:
>> On Mon, 2013-12-16 at 16:26 +0100, Oleksij Rempel wrote:
>>> Am 16.12.2013 16:15, schrieb Johannes Berg:
>>>> On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
>>>>
>>>>> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:
>>>>
>>>> Obviously :)
>>>>
>>>>> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
>>>>> this working, and the devices are really nice apart from this bug. I
>>>>> will keep you up to date, but if you have any hints where to continue
>>>>> digging, lemme know. Until it's fixed, I'll just work on
>>>>> wired-displays via ethernet instead of wifi-displays..
>>>>
>>>> Based on what Oleksij said, these issues are likely not even related -
>>>> maybe ath9k_htc can't even set the rates to exclude CCK, so even if that
>>>> call were to succeed it wouldn't work?
>>>
>>> Hmm.. WMI_BITRATE_MASK should do it.
>>> ieee80211_ops->set_bitrate_mask is set, so theoretically we should be
>>> able to exclude CCK. Today i won't be able to check it.
>>
>> There are two things:
>> * the issue at hand, which is only for some certain management frames
>> that I
>> believe are sent over the normal wlan0 netdev/vif, but still must not
>> use CCK
>> even though wlan0 allows CCK
>> * the issue about the set tx-rate on the p2p netdev/vif, which is how I
>> noticed
>> this, but which is actually not related to the current bug
>>
>> It sounds to me like only the latter can be solved with WMI_BITRATE_MASK
>> since you can't generally disable CCK on wlan0 when doing P2P (you might
>> be connected to an 11b AP at the same time)
>>
>> For the latter issue, you really need a per-frame "disable CCK" flag in
>> the firmware, or you need to use a P2P_DEVICE vif.
>
> Ah.. there is comment which clarify the situation with
> ieee80211_ops->set_bitrate_mask in ath9k_htc:
> /*
> * Currently, this is used only for selecting the minimum rate
> * for management frames, rate selection for data frames remain
> * unaffected.
> */

Yeah, I read that, but couldn't really understand it's meaning.. So it
seems unless we add fw-support to ignore CCK rates for p2p mgmt
frames, I'm screwed? Wouldn't it work to set >11mbits as lowest rate
which should exclude CCK, right? I'm fine with breaking other stuff if
I can get this running for a test environment. Or would it help trying
p2p on 5ghz? Not sure which rates are used there, though..

I will try to look into the ath9k-htc firmware. But given the
complexity, I guess I won't be able to do that in <1month. And my
80211 knowledge is not that comprehensive.. Maybe I'll find time for
it during my next semester.

Thanks!
David

2013-12-09 14:30:10

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Hi

On Mon, Dec 9, 2013 at 3:03 PM, Oleksij Rempel <[email protected]> wrote:
> Am 06.12.2013 11:18, schrieb David Herrmann:
>> Hi
>>
>> I am currently working on user-space helpers for P2P setup as part of
>> an Open-Source Miracast implementation (openwfd). I can set up a
>> P2P-group with my Android test-device just fine, however, it only
>> works if initiated by the GNU/Linux host. Once I initiate the
>> p2p-connect from the Android device, it creates a group and sends me a
>> p2p-invitation which I am unable to accept.
>>
>> I am running wpa_supplicant-git from today (but also tried older
>> versions), ath9k-htc from linus-git (3.13-rc2) and the relevant log
>> files are appended.
>>
>> My wpa-config is:
>> ctrl_interface=/var/run/wpa_supplicant
>> update_config=1
>> p2p_go_ht40=1
>>
>> And I do nothing else than open wpa_cli and run:
>> p2p_find
>> p2p_connect <peer> pbc
>>
>> This works perfectly well if I don't touch the Android device before
>> issuing the p2p_connect. However, if I initiate the first connect on
>> the Android device, my linux host gets a p2p-invitation:
>> <3>P2P-INVITATION-RECEIVED sa=12:68:3f:4e:39:f2
>> go_dev_addr=12:68:3f:4e:39:f2 bssid=12:68:3f:4e:b9:f2 unknown-network
>>
>> I tried accepting this invitation via p2p_connect, but just nothing
>> happens. I also tried any combination of arguments
>> (auth/join/persistent, pbc/pin/PIN#, playing with go_intent=), didn't
>> help..
>>
>> Looking at the wpa-log, I see a timeout firing repeatedly:
>> P2P: GO Negotiation Request TX callback: success=1
>> P2P: State CONNECT -> CONNECT
>> P2P: Set timeout (state=CONNECT): 0.500000 sec
>> P2P: Timeout (state=CONNECT)
>> Below you can see the whole sequence of wpa-messages that repeat over
>> and over again until I cancel the connection-request.
>>
>> For WFD I need to initiate the connect from the Android device,
>> otherwise their WFD stack won't recognize the connection. So if anyone
>> has hints what might be wrong here, I'd gladly try out any patches or
>> configurations.
>> I cannot test whether this happens with other drivers, too, as I
>> couldn't get my hands on a device other than ath9k-htc which supports
>> p2p on linux.
>>
>> If anyone is interested, I'll be presenting OpenWFD at FOSDEM in the
>> graphics-devroom. It would be awesome if I can get my Nexus-4 as a
>> working demo until then. Otherwise, it'll be just linux<->linux demos
>> (non-android), which is already working fine.
>
> Is it related to your "Atheros AR9280: NULL-deref during P2P setup"
> issue? Or it is not reproducible any more?

The NULL-deref happens very sporadically. I wasn't able to figure out
how to trigger it reliably. This timeout happens *all* the time. So I
think the NULL deref is not directly related. Btw., I added some debug
statements to the ath9k sources in case the NULL deref happens again.
However, I haven't seen it yet so I kinda get the feeling it's a
timing/locking issue.

Thanks
David

2013-12-16 14:57:52

[permalink] [raw]

Subject: Re: [BUG] P2P setup timeout

Am 16.12.2013 14:51, schrieb David Herrmann:
> Hi
>
> On Mon, Dec 16, 2013 at 2:45 PM, Johannes Berg
> <[email protected]> wrote:
>> On Mon, 2013-12-16 at 14:39 +0100, David Herrmann wrote:
>>
>>>> Can you check in a sniffer what the frame bitrates are that go out? This
>>>> seems suspicious:
>>>>
>>>> nl80211: Set TX rates failed: ret=-100 (Network is down)
>>>
>>> I looked at the sniffer data and all I see is a huge amount of p2p
>>> probe requests from my local device, the successful p2p-invitation and
>>> invitation response and then lots of go-negotiation requests that
>>> never get any response.
>>
>> Right, and I suspect they don't get a response because (as the sniffer
>> trace tells me) they're sent with 1 Mbps (a CCK rate), which is invalid
>> in the P2P spec (must use OFDM).
>>
>> Thus something is wrong with the TX bitrates stuff, but I can't tell you
>> where that would be ...
>
> Ok, I will try hooking into the ath9k driver then and see why setting
> TX rates fails. Thanks a lot! Maybe Oleksij has some more ideas on
> that.

ath9k_htc has it own rate controller insight of firmware. We wont to
move this functionality to the host and use minstreal-rt, but currently
this project is not started and currently there is no clear start time
:( Beside, there are more problems with FWs rate controller.

David, if you need to fix this bug, i would you suggest you to
investigate in firmware. I will help you as match as i can.

--
Regards,
Oleksij

2013-12-16 15:09:38