Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
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 usedif 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 Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
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 wrote: > > > On 05/12/2015 03:14 AM, Michal Kazior wrote: >> >> On 12 May 2015 at 11:31, s prasad 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 majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com -- S Prasad Kandregula -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
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 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 usedif 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 > Candela Technologies Inc http://www.candelatech.com > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
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 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 usedif 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 >> Candela Technologies Inc http://www.candelatech.com >> > -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ath10 firmware crashing in Monitor mode(Sniffer mode)
On 10 May 2015 at 22:56, s prasad 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.15] ath10k_pci: Unknown symbol ath10k_warn (err 0) > [791495.16] ath10k_pci: Unknown symbol ath10k_err (err 0) > [791495.17] ath10k_pci: Unknown symbol ath10k_print_driver_info (err 0) > [791495.17] ath10k_pci: Unknown symbol > ath10k_debug_get_new_fw_crash_data (err 0) > [791495.18] ath10k_pci: Unknown symbol ath10k_core_create (err 0) > [791495.19] ath10k_pci: Unknown symbol ath10k_core_destroy (err 0) > [791495.19] ath10k_pci: Unknown symbol ath10k_core_register (err 0) > [791495.20] ath10k_pci: Unknown symbol ath10k_info (err 0) > [791495.21] ath10k_pci: Unknown symbol ath10k_core_unregister (err 0) > [791504.60] ath10k_pci :01:00.0: pci irq legacy interrupts 0 > irq_mode 0 reset_mode 0 > [791504.82] ath10k_pci :01:00.0: Direct firmware load for > ath10k/cal-pci-:01:00.0.bin failed with error -2 > [791504.83] ath10k_pci :01:00.0: Falling back to user helper > [791504.90] firmware ath10k!cal-pci-:01:00.0.bin: > firmware_loading_store: map pages failed > [791505.06] ath10k_pci :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.91] ath10k_pci :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.92] ath10k_pci :01:00.0: debug 0 debugfs 1 tracing 0 > dfs 1 testmode 1 > [791506.03] ath: EEPROM regdomain: 0x0 > [791506.03] ath: EEPROM indicates default country code should be used > [791506.03] ath: doing EEPROM country->regdmn map search > [791506.03] ath: country maps to regdmn code: 0x3a > [791506.03] ath: Country alpha2 being used: US > [791506.03] ath: Regpair used: 0x3a > [791551.53] ath10k_pci :01:00.0: otp stream is empty, using > board.bin contents > [791718.13] device wlan1 entered promiscuous mode > [791718.34] ath10k_pci :01:00.0: firmware crashed! (uuid > b4593209-111f-446c-a134-120ce3b2e37d) > [791718.35] ath10k_pci :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.36] ath10k_pci :01:00.0: debug 0 debugfs 1 tracing 0 > dfs 1 testmode 1 > [791718.37] ath10k_pci :01:00.0: firmware register dump: > [791718.38] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 > 0x0099A132 0x00955B31 > [791718.38] ath10k_pci :01:00.0: [04]: 0x0099A132 0x00060730 > 0x001E 0x0005 > [791718.39] ath10k_pci :01:00.0: [08]: 0x0043DD84 0x > 0x004159AC 0x2D00 > [791718.40] ath10k_pci :01:00.0: [12]: 0x0009 0x0004 > 0x00958018 0x00958027 > [791718.41] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D > 0x 0x > [791718.42] ath10k_pci :01:00.0: [20]: 0x4099A132 0x0040AD14 > 0x0040 0x4987F39C > [791718.42] ath10k_pci :01:00.0: [24]: 0x8099A22E 0x0040AD74 > 0x0001 0xC099A132 > [791718.43] ath10k_pci :01:00.0: [28]: 0x809AB96B 0x0040AD94 > 0x0043DD84 0x0002 > [791718.44] ath10k_pci :01:00.0: [32]: 0x809A80FA 0x0040ADD4 > 0x0040 0x004159AC > [791718.45] ath10k_pci :01:00.0: [36]: 0x809A7885 0x0040AE24 > 0x0040AE48 0x0041116C > [791718.46] ath10k_pci :01:00.0: [40]: 0x809486FA 0x0040AE44 > 0x0001 0x > [791718.47] ath10k_pci :01:00.0: [44]: 0x80948E2C 0x0040AEA4 > 0x0041D728 0x00411778 > [791718.47] ath10k_pci :01:00.0: [48]: 0x80942EB3 0x0040AEC4 > 0x0041D728 0x0001 > [791718.48] ath10k_pci :01:00.0: [52]: 0x80940F18 0x0040AF14 > 0x0010 0x00403AC0 > [791718.49] ath10k_pci :01:00.0: [56]: 0x80940EEA 0x0040AF44 > 0x0040 0x [...] > 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ł -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
