Hi,
When we are trying to send De-authentication packets using
aireplay-ng(aircrack tools) firmware getting crashed in sniffer mode.
Kernel: "3.18.1"
Drivers: "compat-wireless-2015-03-09"
Please find given below logs:
[791495.150000] ath10k_pci: Unknown symbol ath10k_warn (err 0)
[791495.160000] ath10k_pci: Unknown symbol ath10k_err (err 0)
[791495.170000] ath10k_pci: Unknown symbol ath10k_print_driver_info (err 0)
[791495.170000] ath10k_pci: Unknown symbol
ath10k_debug_get_new_fw_crash_data (err 0)
[791495.180000] ath10k_pci: Unknown symbol ath10k_core_create (err 0)
[791495.190000] ath10k_pci: Unknown symbol ath10k_core_destroy (err 0)
[791495.190000] ath10k_pci: Unknown symbol ath10k_core_register (err 0)
[791495.200000] ath10k_pci: Unknown symbol ath10k_info (err 0)
[791495.210000] ath10k_pci: Unknown symbol ath10k_core_unregister (err 0)
[791504.600000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0
irq_mode 0 reset_mode 0
[791504.820000] ath10k_pci 0000:01:00.0: Direct firmware load for
ath10k/cal-pci-0000:01:00.0.bin failed with error -2
[791504.830000] ath10k_pci 0000:01:00.0: Falling back to user helper
[791504.900000] firmware ath10k!cal-pci-0000:01:00.0.bin:
firmware_loading_store: map pages failed
[791505.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using
board.bin contents
[791505.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
[791505.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
dfs 1 testmode 1
[791506.030000] ath: EEPROM regdomain: 0x0
[791506.030000] ath: EEPROM indicates default country code should be used
[791506.030000] ath: doing EEPROM country->regdmn map search
[791506.030000] ath: country maps to regdmn code: 0x3a
[791506.030000] ath: Country alpha2 being used: US
[791506.030000] ath: Regpair used: 0x3a
[791551.530000] ath10k_pci 0000:01:00.0: otp stream is empty, using
board.bin contents
[791718.130000] device wlan1 entered promiscuous mode
[791718.340000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
b4593209-111f-446c-a134-120ce3b2e37d)
[791718.350000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
[791718.360000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
dfs 1 testmode 1
[791718.370000] ath10k_pci 0000:01:00.0: firmware register dump:
[791718.380000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x0099A132 0x00955B31
[791718.380000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
0x0000001E 0x00000005
[791718.390000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
0x004159AC 0x00002D00
[791718.400000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
0x00958018 0x00958027
[791718.410000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[791718.420000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
0x00400000 0x4987F39C
[791718.420000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
0x00000001 0xC099A132
[791718.430000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
0x0043DD84 0x00000002
[791718.440000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
0x00400000 0x004159AC
[791718.450000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
0x0040AE48 0x0041116C
[791718.460000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
0x00000001 0x00000000
[791718.470000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
0x0041D728 0x00411778
[791718.470000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
0x0041D728 0x00000001
[791718.480000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
0x00000010 0x00403AC0
[791718.490000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
0x00400000 0x00000000
[791718.600000] ieee80211 phy3: Hardware restart was requested
[791718.600000] ath10k_pci 0000:01:00.0: failed to to request monitor
vdev 0 stop: -143
[791718.610000] ath10k_pci 0000:01:00.0: failed to synchronize monitor
vdev 0 stop: -143
[791718.620000] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
[791718.970000] ath10k_pci 0000:01:00.0: otp stream is empty, using
board.bin contents
[791719.820000] ath10k_pci 0000:01:00.0: device successfully recovered
[791719.900000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
7c004867-7f8c-411f-83a8-b4aa69da1ee8)
[791719.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
[791719.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
dfs 1 testmode 1
[791719.930000] ath10k_pci 0000:01:00.0: firmware register dump:
[791719.930000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x0099A132 0x00955B31
[791719.940000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
0x0000001E 0x00000005
[791719.950000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
0x004159AC 0x00002D00
[791719.960000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
0x00958018 0x00958027
[791719.970000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[791719.970000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
0x00400000 0xDF7BC310
[791719.980000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
0x00000001 0xC099A132
[791719.990000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
0x0043DD84 0x00000002
[791720.000000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
0x00400000 0x004159AC
[791720.010000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
0x0040AE48 0x0041116C
[791720.010000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
0x00000001 0x00000000
[791720.020000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
0x0041D728 0x00411778
[791720.030000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
0x0041D728 0x00000001
[791720.040000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
0x00000010 0x00403AC0
[791720.050000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
0x00400000 0x00000000
[791723.140000] ath10k_pci 0000:01:00.0: failed to transmit management
frame via WMI: -143
[791723.240000] ieee80211 phy3: Hardware restart was requested
[791723.240000] ath10k_pci 0000:01:00.0: failed to put down monitor vdev 0: -143
[791723.250000] ath10k_pci 0000:01:00.0: failed to to request monitor
vdev 0 stop: -143
[791723.260000] ath10k_pci 0000:01:00.0: failed to synchronize monitor
vdev 0 stop: -143
[791723.260000] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
[791723.620000] ath10k_pci 0000:01:00.0: otp stream is empty, using
board.bin contents
[791724.470000] ath10k_pci 0000:01:00.0: device successfully recovered
[791724.580000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
521f6876-093d-4741-a3c4-33bc85470260)
[791724.590000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
[791724.600000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
dfs 1 testmode 1
[791724.610000] ath10k_pci 0000:01:00.0: firmware register dump:
[791724.620000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x0099A132 0x00955B31
[791724.630000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
0x0000001E 0x00000005
[791724.640000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
0x004159AC 0x00002D00
[791724.640000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
0x00958018 0x00958027
[791724.650000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[791724.660000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
0x00400000 0x4987F39C
[791724.670000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
0x00000001 0xC099A132
[791724.680000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
0x0043DD84 0x00000002
[791724.680000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
0x00400000 0x004159AC
[791724.690000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
0x0040AE48 0x0041116C
[791724.700000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
0x00000001 0x00000000
[791724.710000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
0x0041D728 0x00411778
[791724.720000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
0x0041D728 0x00000001
[791724.720000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
0x00000010 0x00403AC0
[791724.730000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
0x00400000 0x00000000
[791732.500000] ath10k_pci 0000:01:00.0: failed to transmit management
frame via WMI: -143
[791732.600000] ieee80211 phy3: Hardware restart was requested
[791732.600000] ath10k_pci 0000:01:00.0: failed to put down monitor vdev 0: -143
[791732.610000] ath10k_pci 0000:01:00.0: failed to to request monitor
vdev 0 stop: -143
[791733.020000] ath10k_warn: 2 callbacks suppressed
[791733.020000] ath10k_pci 0000:01:00.0: otp stream is empty, using
board.bin contents
[791733.880000] ath10k_pci 0000:01:00.0: device successfully recovered
Please let me know if any further information required.
On 05/12/2015 03:14 AM, Michal Kazior wrote:
> On 12 May 2015 at 11:31, s prasad <[email protected]> wrote:
>> May I know, is this firmware or driver constraint?
>> If somebody have patch for this, am ready to test it.
>
> Short answer: There's nothing, yet.
>
> Long answer:
>
> From what I know official firmware doesn't support injecting packets
> via monitor vdev. This is a firmware limitation.
>
> A way around this may be creating and using an additional vdev, e.g.
> AP. This will be rather ugly but may work. There's no patch for it.
>
> An alternative would be to ask Ben to modify his CT-firmware branch.
I gave this a decent try a month or two ago, and had no luck. The hardware
(from what I can tell), just will not send a frame to an unknown peer.
I noticed the other day that ANQP will not work on ath10k, and I suspect
similar issues..so I will be in that code again. Maybe I'll learn
how to trick it into sending arbitrary frames.
All that said, there is no way to specify rate-ctrl info on a per-pkt
basis when injecting frames, so I don't know what good injecting frames
on a mgt device will accomplish.
Thanks,
Ben
> Also there's a problem with submitting raw 802.11 frames to firmware.
> There's some work ongoing [1].
>
> [1]: http://lists.infradead.org/pipermail/ath10k/2015-May/005144.html
>
>
> Michał
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Michal Kazior <[email protected]> writes:
> On 12 May 2015 at 14:19, Kalle Valo <[email protected]> wrote:
>> Michal Kazior <[email protected]> writes:
>>
>>> On 11 May 2015 at 23:27, s prasad <[email protected]> wrote:
>>>> Tested as you suggested, however didn't help. Please find attached log
>>>> files for each firmware type.
>>>>
>>>> While executing following commands in sequence, captured dmesg. I hope
>>>> those logs will help. If not please let me know.
>>>
>>> Thanks!
>>>
>>> Apparently I've missed from your original email the fact that you're
>>> trying to inject packets. This isn't supported in ath10k.
>>
>> IMHO we should somehow warn the user or prevent that happening. Is there
>> a way to do that?
>
> We could add an extra condition in ath10k_tx() to drop/free packets
> immediately and warn if an injection attempt is made.
Yeah, that would be really good to have.
--
Kalle Valo
On 10 May 2015 at 22:56, s prasad <[email protected]> wrote:
> Hi,
>
> When we are trying to send De-authentication packets using
> aireplay-ng(aircrack tools) firmware getting crashed in sniffer mode.
>
> Kernel: "3.18.1"
> Drivers: "compat-wireless-2015-03-09"
>
> Please find given below logs:
>
> [791495.150000] ath10k_pci: Unknown symbol ath10k_warn (err 0)
> [791495.160000] ath10k_pci: Unknown symbol ath10k_err (err 0)
> [791495.170000] ath10k_pci: Unknown symbol ath10k_print_driver_info (err 0)
> [791495.170000] ath10k_pci: Unknown symbol
> ath10k_debug_get_new_fw_crash_data (err 0)
> [791495.180000] ath10k_pci: Unknown symbol ath10k_core_create (err 0)
> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_destroy (err 0)
> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_register (err 0)
> [791495.200000] ath10k_pci: Unknown symbol ath10k_info (err 0)
> [791495.210000] ath10k_pci: Unknown symbol ath10k_core_unregister (err 0)
> [791504.600000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0
> irq_mode 0 reset_mode 0
> [791504.820000] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/cal-pci-0000:01:00.0.bin failed with error -2
> [791504.830000] ath10k_pci 0000:01:00.0: Falling back to user helper
> [791504.900000] firmware ath10k!cal-pci-0000:01:00.0.bin:
> firmware_loading_store: map pages failed
> [791505.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
You're probably using OpenWRT, aren't you? Are you positive you have
proper board.bin, i.e. based of NAND flash partition containing
calibration data?
> [791505.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
> [791505.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
> dfs 1 testmode 1
> [791506.030000] ath: EEPROM regdomain: 0x0
> [791506.030000] ath: EEPROM indicates default country code should be used
> [791506.030000] ath: doing EEPROM country->regdmn map search
> [791506.030000] ath: country maps to regdmn code: 0x3a
> [791506.030000] ath: Country alpha2 being used: US
> [791506.030000] ath: Regpair used: 0x3a
> [791551.530000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
> [791718.130000] device wlan1 entered promiscuous mode
> [791718.340000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> b4593209-111f-446c-a134-120ce3b2e37d)
> [791718.350000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
> [791718.360000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
> dfs 1 testmode 1
> [791718.370000] ath10k_pci 0000:01:00.0: firmware register dump:
> [791718.380000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x0099A132 0x00955B31
> [791718.380000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
> 0x0000001E 0x00000005
> [791718.390000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
> 0x004159AC 0x00002D00
> [791718.400000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
> 0x00958018 0x00958027
> [791718.410000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [791718.420000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
> 0x00400000 0x4987F39C
> [791718.420000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
> 0x00000001 0xC099A132
> [791718.430000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
> 0x0043DD84 0x00000002
> [791718.440000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
> 0x00400000 0x004159AC
> [791718.450000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
> 0x0040AE48 0x0041116C
> [791718.460000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
> 0x00000001 0x00000000
> [791718.470000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
> 0x0041D728 0x00411778
> [791718.470000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
> 0x0041D728 0x00000001
> [791718.480000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
> 0x00000010 0x00403AC0
> [791718.490000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
> 0x00400000 0x00000000
[...]
> Please let me know if any further information required.
Can you get debug logs or traces, please?
Does 10.2-00082 or 10.2.4.xx crash as well?
Michał
On 11 May 2015 at 23:27, s prasad <[email protected]> wrote:
> Tested as you suggested, however didn't help. Please find attached log
> files for each firmware type.
>
> While executing following commands in sequence, captured dmesg. I hope
> those logs will help. If not please let me know.
Thanks!
Apparently I've missed from your original email the fact that you're
trying to inject packets. This isn't supported in ath10k.
Michał
Michal Kazior <[email protected]> writes:
> On 11 May 2015 at 23:27, s prasad <[email protected]> wrote:
>> Tested as you suggested, however didn't help. Please find attached log
>> files for each firmware type.
>>
>> While executing following commands in sequence, captured dmesg. I hope
>> those logs will help. If not please let me know.
>
> Thanks!
>
> Apparently I've missed from your original email the fact that you're
> trying to inject packets. This isn't supported in ath10k.
IMHO we should somehow warn the user or prevent that happening. Is there
a way to do that?
--
Kalle Valo
On 12 May 2015 at 14:19, Kalle Valo <[email protected]> wrote:
> Michal Kazior <[email protected]> writes:
>
>> On 11 May 2015 at 23:27, s prasad <[email protected]> wrote:
>>> Tested as you suggested, however didn't help. Please find attached log
>>> files for each firmware type.
>>>
>>> While executing following commands in sequence, captured dmesg. I hope
>>> those logs will help. If not please let me know.
>>
>> Thanks!
>>
>> Apparently I've missed from your original email the fact that you're
>> trying to inject packets. This isn't supported in ath10k.
>
> IMHO we should somehow warn the user or prevent that happening. Is there
> a way to do that?
We could add an extra condition in ath10k_tx() to drop/free packets
immediately and warn if an injection attempt is made.
Michał
Hello all.
I have the same issue on OpenWRT, when using horst for sniffer mode,
but different behaviour, reported here:
https://dev.openwrt.org/ticket/15738
BR,
M?rio Lopes.
Quoting s prasad <[email protected]>:
> Hi,
>
> When we are trying to send De-authentication packets using
> aireplay-ng(aircrack tools) firmware getting crashed in sniffer mode.
>
> Kernel: "3.18.1"
> Drivers: "compat-wireless-2015-03-09"
>
> Please find given below logs:
>
> [791495.150000] ath10k_pci: Unknown symbol ath10k_warn (err 0)
> [791495.160000] ath10k_pci: Unknown symbol ath10k_err (err 0)
> [791495.170000] ath10k_pci: Unknown symbol ath10k_print_driver_info (err 0)
> [791495.170000] ath10k_pci: Unknown symbol
> ath10k_debug_get_new_fw_crash_data (err 0)
> [791495.180000] ath10k_pci: Unknown symbol ath10k_core_create (err 0)
> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_destroy (err 0)
> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_register (err 0)
> [791495.200000] ath10k_pci: Unknown symbol ath10k_info (err 0)
> [791495.210000] ath10k_pci: Unknown symbol ath10k_core_unregister (err 0)
> [791504.600000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0
> irq_mode 0 reset_mode 0
> [791504.820000] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/cal-pci-0000:01:00.0.bin failed with error -2
> [791504.830000] ath10k_pci 0000:01:00.0: Falling back to user helper
> [791504.900000] firmware ath10k!cal-pci-0000:01:00.0.bin:
> firmware_loading_store: map pages failed
> [791505.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
> [791505.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
> [791505.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
> dfs 1 testmode 1
> [791506.030000] ath: EEPROM regdomain: 0x0
> [791506.030000] ath: EEPROM indicates default country code should be used
> [791506.030000] ath: doing EEPROM country->regdmn map search
> [791506.030000] ath: country maps to regdmn code: 0x3a
> [791506.030000] ath: Country alpha2 being used: US
> [791506.030000] ath: Regpair used: 0x3a
> [791551.530000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
> [791718.130000] device wlan1 entered promiscuous mode
> [791718.340000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> b4593209-111f-446c-a134-120ce3b2e37d)
> [791718.350000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
> [791718.360000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
> dfs 1 testmode 1
> [791718.370000] ath10k_pci 0000:01:00.0: firmware register dump:
> [791718.380000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x0099A132 0x00955B31
> [791718.380000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
> 0x0000001E 0x00000005
> [791718.390000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
> 0x004159AC 0x00002D00
> [791718.400000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
> 0x00958018 0x00958027
> [791718.410000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [791718.420000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
> 0x00400000 0x4987F39C
> [791718.420000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
> 0x00000001 0xC099A132
> [791718.430000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
> 0x0043DD84 0x00000002
> [791718.440000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
> 0x00400000 0x004159AC
> [791718.450000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
> 0x0040AE48 0x0041116C
> [791718.460000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
> 0x00000001 0x00000000
> [791718.470000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
> 0x0041D728 0x00411778
> [791718.470000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
> 0x0041D728 0x00000001
> [791718.480000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
> 0x00000010 0x00403AC0
> [791718.490000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
> 0x00400000 0x00000000
> [791718.600000] ieee80211 phy3: Hardware restart was requested
> [791718.600000] ath10k_pci 0000:01:00.0: failed to to request monitor
> vdev 0 stop: -143
> [791718.610000] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> vdev 0 stop: -143
> [791718.620000] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> [791718.970000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
> [791719.820000] ath10k_pci 0000:01:00.0: device successfully recovered
> [791719.900000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 7c004867-7f8c-411f-83a8-b4aa69da1ee8)
> [791719.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
> [791719.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
> dfs 1 testmode 1
> [791719.930000] ath10k_pci 0000:01:00.0: firmware register dump:
> [791719.930000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x0099A132 0x00955B31
> [791719.940000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
> 0x0000001E 0x00000005
> [791719.950000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
> 0x004159AC 0x00002D00
> [791719.960000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
> 0x00958018 0x00958027
> [791719.970000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [791719.970000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
> 0x00400000 0xDF7BC310
> [791719.980000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
> 0x00000001 0xC099A132
> [791719.990000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
> 0x0043DD84 0x00000002
> [791720.000000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
> 0x00400000 0x004159AC
> [791720.010000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
> 0x0040AE48 0x0041116C
> [791720.010000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
> 0x00000001 0x00000000
> [791720.020000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
> 0x0041D728 0x00411778
> [791720.030000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
> 0x0041D728 0x00000001
> [791720.040000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
> 0x00000010 0x00403AC0
> [791720.050000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
> 0x00400000 0x00000000
> [791723.140000] ath10k_pci 0000:01:00.0: failed to transmit management
> frame via WMI: -143
> [791723.240000] ieee80211 phy3: Hardware restart was requested
> [791723.240000] ath10k_pci 0000:01:00.0: failed to put down monitor
> vdev 0: -143
> [791723.250000] ath10k_pci 0000:01:00.0: failed to to request monitor
> vdev 0 stop: -143
> [791723.260000] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> vdev 0 stop: -143
> [791723.260000] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> [791723.620000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
> [791724.470000] ath10k_pci 0000:01:00.0: device successfully recovered
> [791724.580000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 521f6876-093d-4741-a3c4-33bc85470260)
> [791724.590000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
> [791724.600000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
> dfs 1 testmode 1
> [791724.610000] ath10k_pci 0000:01:00.0: firmware register dump:
> [791724.620000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x0099A132 0x00955B31
> [791724.630000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
> 0x0000001E 0x00000005
> [791724.640000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
> 0x004159AC 0x00002D00
> [791724.640000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
> 0x00958018 0x00958027
> [791724.650000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [791724.660000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
> 0x00400000 0x4987F39C
> [791724.670000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
> 0x00000001 0xC099A132
> [791724.680000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
> 0x0043DD84 0x00000002
> [791724.680000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
> 0x00400000 0x004159AC
> [791724.690000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
> 0x0040AE48 0x0041116C
> [791724.700000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
> 0x00000001 0x00000000
> [791724.710000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
> 0x0041D728 0x00411778
> [791724.720000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
> 0x0041D728 0x00000001
> [791724.720000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
> 0x00000010 0x00403AC0
> [791724.730000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
> 0x00400000 0x00000000
> [791732.500000] ath10k_pci 0000:01:00.0: failed to transmit management
> frame via WMI: -143
> [791732.600000] ieee80211 phy3: Hardware restart was requested
> [791732.600000] ath10k_pci 0000:01:00.0: failed to put down monitor
> vdev 0: -143
> [791732.610000] ath10k_pci 0000:01:00.0: failed to to request monitor
> vdev 0 stop: -143
> [791733.020000] ath10k_warn: 2 callbacks suppressed
> [791733.020000] ath10k_pci 0000:01:00.0: otp stream is empty, using
> board.bin contents
> [791733.880000] ath10k_pci 0000:01:00.0: device successfully recovered
>
>
>
> Please let me know if any further information required.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
May I know, is this firmware or driver constraint?
If somebody have patch for this, am ready to test it.
Thanks and Regards,
S Prasad
On Tue, May 12, 2015 at 1:03 AM, Michal Kazior <[email protected]> wrote:
> On 11 May 2015 at 23:27, s prasad <[email protected]> wrote:
>> Tested as you suggested, however didn't help. Please find attached log
>> files for each firmware type.
>>
>> While executing following commands in sequence, captured dmesg. I hope
>> those logs will help. If not please let me know.
>
> Thanks!
>
> Apparently I've missed from your original email the fact that you're
> trying to inject packets. This isn't supported in ath10k.
>
>
> Michał
--
S Prasad Kandregula
Hi,
On Mon, May 11, 2015 at 1:50 AM, Michal Kazior <[email protected]> wrote:
> On 10 May 2015 at 22:56, s prasad <[email protected]> wrote:
>> Hi,
>>
>> When we are trying to send De-authentication packets using
>> aireplay-ng(aircrack tools) firmware getting crashed in sniffer mode.
>>
>> Kernel: "3.18.1"
>> Drivers: "compat-wireless-2015-03-09"
>>
>> Please find given below logs:
>>
>> [791495.150000] ath10k_pci: Unknown symbol ath10k_warn (err 0)
>> [791495.160000] ath10k_pci: Unknown symbol ath10k_err (err 0)
>> [791495.170000] ath10k_pci: Unknown symbol ath10k_print_driver_info (err 0)
>> [791495.170000] ath10k_pci: Unknown symbol
>> ath10k_debug_get_new_fw_crash_data (err 0)
>> [791495.180000] ath10k_pci: Unknown symbol ath10k_core_create (err 0)
>> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_destroy (err 0)
>> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_register (err 0)
>> [791495.200000] ath10k_pci: Unknown symbol ath10k_info (err 0)
>> [791495.210000] ath10k_pci: Unknown symbol ath10k_core_unregister (err 0)
>> [791504.600000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0
>> irq_mode 0 reset_mode 0
>> [791504.820000] ath10k_pci 0000:01:00.0: Direct firmware load for
>> ath10k/cal-pci-0000:01:00.0.bin failed with error -2
>> [791504.830000] ath10k_pci 0000:01:00.0: Falling back to user helper
>> [791504.900000] firmware ath10k!cal-pci-0000:01:00.0.bin:
>> firmware_loading_store: map pages failed
>> [791505.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using
>> board.bin contents
>
> You're probably using OpenWRT, aren't you? Are you positive you have
> proper board.bin, i.e. based of NAND flash partition containing
> calibration data?
>
>
Yes I am using OpenWrt
I got board.bin from the following git path:
https://github.com/kvalo/ath10k-firmware/tree/master/ath10k/QCA988X/hw2.0/
About board.bin, checked md5sum of both OpenWrt and from above git
path, both have same md5sum.
>> [791505.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
>> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
>> [791505.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
>> dfs 1 testmode 1
>> [791506.030000] ath: EEPROM regdomain: 0x0
>> [791506.030000] ath: EEPROM indicates default country code should be used
>> [791506.030000] ath: doing EEPROM country->regdmn map search
>> [791506.030000] ath: country maps to regdmn code: 0x3a
>> [791506.030000] ath: Country alpha2 being used: US
>> [791506.030000] ath: Regpair used: 0x3a
>> [791551.530000] ath10k_pci 0000:01:00.0: otp stream is empty, using
>> board.bin contents
>> [791718.130000] device wlan1 entered promiscuous mode
>> [791718.340000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>> b4593209-111f-446c-a134-120ce3b2e37d)
>> [791718.350000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
>> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
>> [791718.360000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
>> dfs 1 testmode 1
>> [791718.370000] ath10k_pci 0000:01:00.0: firmware register dump:
>> [791718.380000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>> 0x0099A132 0x00955B31
>> [791718.380000] ath10k_pci 0000:01:00.0: [04]: 0x0099A132 0x00060730
>> 0x0000001E 0x00000005
>> [791718.390000] ath10k_pci 0000:01:00.0: [08]: 0x0043DD84 0x00000000
>> 0x004159AC 0x00002D00
>> [791718.400000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000004
>> 0x00958018 0x00958027
>> [791718.410000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>> 0x00000000 0x00000000
>> [791718.420000] ath10k_pci 0000:01:00.0: [20]: 0x4099A132 0x0040AD14
>> 0x00400000 0x4987F39C
>> [791718.420000] ath10k_pci 0000:01:00.0: [24]: 0x8099A22E 0x0040AD74
>> 0x00000001 0xC099A132
>> [791718.430000] ath10k_pci 0000:01:00.0: [28]: 0x809AB96B 0x0040AD94
>> 0x0043DD84 0x00000002
>> [791718.440000] ath10k_pci 0000:01:00.0: [32]: 0x809A80FA 0x0040ADD4
>> 0x00400000 0x004159AC
>> [791718.450000] ath10k_pci 0000:01:00.0: [36]: 0x809A7885 0x0040AE24
>> 0x0040AE48 0x0041116C
>> [791718.460000] ath10k_pci 0000:01:00.0: [40]: 0x809486FA 0x0040AE44
>> 0x00000001 0x00000000
>> [791718.470000] ath10k_pci 0000:01:00.0: [44]: 0x80948E2C 0x0040AEA4
>> 0x0041D728 0x00411778
>> [791718.470000] ath10k_pci 0000:01:00.0: [48]: 0x80942EB3 0x0040AEC4
>> 0x0041D728 0x00000001
>> [791718.480000] ath10k_pci 0000:01:00.0: [52]: 0x80940F18 0x0040AF14
>> 0x00000010 0x00403AC0
>> [791718.490000] ath10k_pci 0000:01:00.0: [56]: 0x80940EEA 0x0040AF44
>> 0x00400000 0x00000000
> [...]
>> Please let me know if any further information required.
>
> Can you get debug logs or traces, please?
>
Sure, will send them, If possible may I know how to enable debug logs or traces.
> Does 10.2-00082 or 10.2.4.xx crash as well?
Will check and let you know.
>
>
> Michał
Thanks and Regards,
S Prasad Kandregula
Thank you Ben , Michal and Kalle.
Please let us know if you find any.
Thank you so much.
Regards,
S Prasad
On Tue, May 12, 2015 at 10:41 AM, Ben Greear <[email protected]> wrote:
>
>
> On 05/12/2015 03:14 AM, Michal Kazior wrote:
>>
>> On 12 May 2015 at 11:31, s prasad <[email protected]> wrote:
>>>
>>> May I know, is this firmware or driver constraint?
>>> If somebody have patch for this, am ready to test it.
>>
>>
>> Short answer: There's nothing, yet.
>>
>> Long answer:
>>
>> From what I know official firmware doesn't support injecting packets
>> via monitor vdev. This is a firmware limitation.
>>
>> A way around this may be creating and using an additional vdev, e.g.
>> AP. This will be rather ugly but may work. There's no patch for it.
>>
>> An alternative would be to ask Ben to modify his CT-firmware branch.
>
>
> I gave this a decent try a month or two ago, and had no luck. The hardware
> (from what I can tell), just will not send a frame to an unknown peer.
>
> I noticed the other day that ANQP will not work on ath10k, and I suspect
> similar issues..so I will be in that code again. Maybe I'll learn
> how to trick it into sending arbitrary frames.
>
> All that said, there is no way to specify rate-ctrl info on a per-pkt
> basis when injecting frames, so I don't know what good injecting frames
> on a mgt device will accomplish.
>
> Thanks,
> Ben
>
>> Also there's a problem with submitting raw 802.11 frames to firmware.
>> There's some work ongoing [1].
>>
>> [1]: http://lists.infradead.org/pipermail/ath10k/2015-May/005144.html
>>
>>
>> Michał
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
--
S Prasad Kandregula
On 11 May 2015 at 10:52, Mário Lopes <[email protected]> wrote:
> Hello all.
>
> I have the same issue on OpenWRT, when using horst for sniffer mode, but
> different behaviour, reported here: https://dev.openwrt.org/ticket/15738
Firmware 999.999.0.636 has very poor monitor support and is known to
crash very often. It is advised to use 10.x firmware for
monitor/sniffing.
Michał
On 11 May 2015 at 12:51, s prasad <[email protected]> wrote:
> Hi,
>
> On Mon, May 11, 2015 at 1:50 AM, Michal Kazior <[email protected]> wrote:
>> On 10 May 2015 at 22:56, s prasad <[email protected]> wrote:
>>> Hi,
>>>
>>> When we are trying to send De-authentication packets using
>>> aireplay-ng(aircrack tools) firmware getting crashed in sniffer mode.
>>>
>>> Kernel: "3.18.1"
>>> Drivers: "compat-wireless-2015-03-09"
>>>
>>> Please find given below logs:
>>>
>>> [791495.150000] ath10k_pci: Unknown symbol ath10k_warn (err 0)
>>> [791495.160000] ath10k_pci: Unknown symbol ath10k_err (err 0)
>>> [791495.170000] ath10k_pci: Unknown symbol ath10k_print_driver_info (err 0)
>>> [791495.170000] ath10k_pci: Unknown symbol
>>> ath10k_debug_get_new_fw_crash_data (err 0)
>>> [791495.180000] ath10k_pci: Unknown symbol ath10k_core_create (err 0)
>>> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_destroy (err 0)
>>> [791495.190000] ath10k_pci: Unknown symbol ath10k_core_register (err 0)
>>> [791495.200000] ath10k_pci: Unknown symbol ath10k_info (err 0)
>>> [791495.210000] ath10k_pci: Unknown symbol ath10k_core_unregister (err 0)
>>> [791504.600000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0
>>> irq_mode 0 reset_mode 0
>>> [791504.820000] ath10k_pci 0000:01:00.0: Direct firmware load for
>>> ath10k/cal-pci-0000:01:00.0.bin failed with error -2
>>> [791504.830000] ath10k_pci 0000:01:00.0: Falling back to user helper
>>> [791504.900000] firmware ath10k!cal-pci-0000:01:00.0.bin:
>>> firmware_loading_store: map pages failed
>>> [791505.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using
>>> board.bin contents
>>
>> You're probably using OpenWRT, aren't you? Are you positive you have
>> proper board.bin, i.e. based of NAND flash partition containing
>> calibration data?
>>
>>
>
> Yes I am using OpenWrt
> I got board.bin from the following git path:
> https://github.com/kvalo/ath10k-firmware/tree/master/ath10k/QCA988X/hw2.0/
>
> About board.bin, checked md5sum of both OpenWrt and from above git
> path, both have same md5sum.
This is the wrong way to do it. You're using your card without correct
calibration data. No wonder it crashes. I bet you have a
00:03:07:12:34:56 mac address on your ath10k wlan interface.
You need to extract board.bin from NAND flash of the router you have.
OpenWRT does this automatically for some devices (e.g. TP-Link Archer
C5/C7) as far as I know. You should either allow OpenWRT to extract
the file itself (probably deleting the existing board.bin and
rebooting the system) or look at script responsible for that and do it
yourself.
>>> [791505.910000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
>>> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
>>> [791505.920000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
>>> dfs 1 testmode 1
>>> [791506.030000] ath: EEPROM regdomain: 0x0
>>> [791506.030000] ath: EEPROM indicates default country code should be used
>>> [791506.030000] ath: doing EEPROM country->regdmn map search
>>> [791506.030000] ath: country maps to regdmn code: 0x3a
>>> [791506.030000] ath: Country alpha2 being used: US
>>> [791506.030000] ath: Regpair used: 0x3a
>>> [791551.530000] ath10k_pci 0000:01:00.0: otp stream is empty, using
>>> board.bin contents
>>> [791718.130000] device wlan1 entered promiscuous mode
>>> [791718.340000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>>> b4593209-111f-446c-a134-120ce3b2e37d)
>>> [791718.350000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
>>> 0x043202ff) fw 10.1.467.2-1 api 4 htt 2.1 wmi 2 cal otp max_sta 128
>>> [791718.360000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0
>>> dfs 1 testmode 1
>> [...]
>>> Please let me know if any further information required.
>>
>> Can you get debug logs or traces, please?
>>
>
> Sure, will send them, If possible may I know how to enable debug logs or traces.
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing
>From the driver info string it looks you'll need to recompile the driver.
>> Does 10.2-00082 or 10.2.4.xx crash as well?
>
> Will check and let you know.
Before you start getting traces or testing 10.2 firmware make sure you
fix your board.bin first, please.
Michał
On 12 May 2015 at 11:31, s prasad <[email protected]> wrote:
> May I know, is this firmware or driver constraint?
> If somebody have patch for this, am ready to test it.
Short answer: There's nothing, yet.
Long answer:
>From what I know official firmware doesn't support injecting packets
via monitor vdev. This is a firmware limitation.
A way around this may be creating and using an additional vdev, e.g.
AP. This will be rather ugly but may work. There's no patch for it.
An alternative would be to ask Ben to modify his CT-firmware branch.
Also there's a problem with submitting raw 802.11 frames to firmware.
There's some work ongoing [1].
[1]: http://lists.infradead.org/pipermail/ath10k/2015-May/005144.html
Michał
On 08/13/2015 01:35 PM, s prasad wrote:
> Hi Ben,
>
> did you get a chance to look into this issue(injecting frames when
> device in monitor mode).
Injection works in a limited fashion in my latest firmware.
I'd like to figure out how to pass rate-ctrl (and other info?) down to the
firmware on a per-pkt basis..but I don't see a way yet.
Probably I have to hack the htt header or something like that
to give some extra space. That sort of thing might allow a host-based
rate-ctrl algorithm to be used....if someone is interested in working on
the driver/kernel side of things for this effort let me know.
I am not aware of any crashes related to monitor mode in my
firmware..but if you can crash it, send me the crash dump and
I'll take a look.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Thank you Ben for immediate response,
Don't mind, could you please share your firmware path.
Sorry I didn't change old subject line.
Thanks & Regards,
S Prasad
> On Aug 13, 2015, at 4:43 PM, Ben Greear <[email protected]> wrote:
>
>> On 08/13/2015 01:35 PM, s prasad wrote:
>> Hi Ben,
>>
>> did you get a chance to look into this issue(injecting frames when
>> device in monitor mode).
>
> Injection works in a limited fashion in my latest firmware.
>
> I'd like to figure out how to pass rate-ctrl (and other info?) down to the
> firmware on a per-pkt basis..but I don't see a way yet.
>
> Probably I have to hack the htt header or something like that
> to give some extra space. That sort of thing might allow a host-based
> rate-ctrl algorithm to be used....if someone is interested in working on
> the driver/kernel side of things for this effort let me know.
>
> I am not aware of any crashes related to monitor mode in my
> firmware..but if you can crash it, send me the crash dump and
> I'll take a look.
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
Hi Ben,
did you get a chance to look into this issue(injecting frames when
device in monitor mode).
Thanks and Regards,
S Prasad
On Tue, May 12, 2015 at 10:41 AM, Ben Greear <[email protected]> wrote:
>
>
> On 05/12/2015 03:14 AM, Michal Kazior wrote:
>>
>> On 12 May 2015 at 11:31, s prasad <[email protected]> wrote:
>>>
>>> May I know, is this firmware or driver constraint?
>>> If somebody have patch for this, am ready to test it.
>>
>>
>> Short answer: There's nothing, yet.
>>
>> Long answer:
>>
>> From what I know official firmware doesn't support injecting packets
>> via monitor vdev. This is a firmware limitation.
>>
>> A way around this may be creating and using an additional vdev, e.g.
>> AP. This will be rather ugly but may work. There's no patch for it.
>>
>> An alternative would be to ask Ben to modify his CT-firmware branch.
>
>
> I gave this a decent try a month or two ago, and had no luck. The hardware
> (from what I can tell), just will not send a frame to an unknown peer.
>
> I noticed the other day that ANQP will not work on ath10k, and I suspect
> similar issues..so I will be in that code again. Maybe I'll learn
> how to trick it into sending arbitrary frames.
>
> All that said, there is no way to specify rate-ctrl info on a per-pkt
> basis when injecting frames, so I don't know what good injecting frames
> on a mgt device will accomplish.
>
> Thanks,
> Ben
>
>> Also there's a problem with submitting raw 802.11 frames to firmware.
>> There's some work ongoing [1].
>>
>> [1]: http://lists.infradead.org/pipermail/ath10k/2015-May/005144.html
>>
>>
>> Michał
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
--
S Prasad Kandregula
On 08/13/2015 02:01 PM, S Prasad Kandregula wrote:
> Thank you Ben for immediate response,
>
> Don't mind, could you please share your firmware path.
Grab one of the beta-15 builds linked from this page:
http://www.candelatech.com/ath10k.php
If you want the mgt-htt version, be sure to patch your kernel per
the release notes or use one of my kernels also linked from the page.
Thanks,
Ben
>
> Sorry I didn't change old subject line.
>
> Thanks & Regards,
> S Prasad
>
>> On Aug 13, 2015, at 4:43 PM, Ben Greear <[email protected]> wrote:
>>
>>> On 08/13/2015 01:35 PM, s prasad wrote:
>>> Hi Ben,
>>>
>>> did you get a chance to look into this issue(injecting frames when
>>> device in monitor mode).
>>
>> Injection works in a limited fashion in my latest firmware.
>>
>> I'd like to figure out how to pass rate-ctrl (and other info?) down to the
>> firmware on a per-pkt basis..but I don't see a way yet.
>>
>> Probably I have to hack the htt header or something like that
>> to give some extra space. That sort of thing might allow a host-based
>> rate-ctrl algorithm to be used....if someone is interested in working on
>> the driver/kernel side of things for this effort let me know.
>>
>> I am not aware of any crashes related to monitor mode in my
>> firmware..but if you can crash it, send me the crash dump and
>> I'll take a look.
>>
>> Thanks,
>> Ben
>>
>>
>> --
>> Ben Greear <[email protected]>
>> Candela Technologies Inc http://www.candelatech.com
>>
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com