* Please don't puke: Modifying Frame Version, Beacon and Probe-Response values @ 2016-05-31 8:44 jpo 2016-05-31 10:50 ` Michal Kazior 0 siblings, 1 reply; 9+ messages in thread From: jpo @ 2016-05-31 8:44 UTC (permalink / raw) To: ath10k Hello all, to implement a "Stealth feature", e.g. the WLAN network does not show up in normal Scans, we modified the Frame version, Beacon and Probe-Response values for an old ATH5K card running on the now dormant Madwifi driver. Question: Is the same thing even POSSIBLE with ath10k? My main concern is, that the firmware just won't handle non-standard values. Can somebody who understands the division of labor between mac80211, ath10k, the firmware and the hardware suppress his or her gag reflex long enough to think about this? Thanks in advance Joerg _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-05-31 8:44 Please don't puke: Modifying Frame Version, Beacon and Probe-Response values jpo @ 2016-05-31 10:50 ` Michal Kazior 2016-05-31 15:53 ` Adrian Chadd 0 siblings, 1 reply; 9+ messages in thread From: Michal Kazior @ 2016-05-31 10:50 UTC (permalink / raw) To: jpo; +Cc: ath10k@lists.infradead.org On 31 May 2016 at 10:44, jpo <pommnitz@yahoo.com> wrote: > Hello all, > to implement a "Stealth feature", e.g. the WLAN network does not show up in > normal Scans, we modified the Frame version, Beacon and Probe-Response > values for an old ATH5K card running on the now dormant Madwifi driver. > Question: Is the same thing even POSSIBLE with ath10k? My main concern is, > that the firmware just won't handle non-standard values. > > Can somebody who understands the division of labor between mac80211, ath10k, > the firmware and the hardware suppress his or her gag reflex long enough to > think about this? First and foremost you'll need to use firmware with "raw-mode" support - otherwise firmware just craps over frame headers. Some 10.2.4 support it - you can look into the mailing list archive for some discussions. Not sure if Rx will work though as firmware-controlled Rx filters may prevent you from receiving frames with crazy frame_control values. You'll need to check this out yourself. Some firmware revisions might have RX_FILTER wmi command support but this isn't used/documented anywhere and it's questionable how much it allows you to override. Whatever you find it'd be nice if you post whatever you find out (for posterity :) Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-05-31 10:50 ` Michal Kazior @ 2016-05-31 15:53 ` Adrian Chadd 2016-06-01 11:34 ` Joerg Pommnitz 0 siblings, 1 reply; 9+ messages in thread From: Adrian Chadd @ 2016-05-31 15:53 UTC (permalink / raw) To: Michal Kazior; +Cc: ath10k@lists.infradead.org, jpo Hi, The other thing to keep in mind is the hardware assist for things like TIM parsing, wakeup, etc will likely not work. :) -a On 31 May 2016 at 03:50, Michal Kazior <michal.kazior@tieto.com> wrote: > On 31 May 2016 at 10:44, jpo <pommnitz@yahoo.com> wrote: >> Hello all, >> to implement a "Stealth feature", e.g. the WLAN network does not show up in >> normal Scans, we modified the Frame version, Beacon and Probe-Response >> values for an old ATH5K card running on the now dormant Madwifi driver. >> Question: Is the same thing even POSSIBLE with ath10k? My main concern is, >> that the firmware just won't handle non-standard values. >> >> Can somebody who understands the division of labor between mac80211, ath10k, >> the firmware and the hardware suppress his or her gag reflex long enough to >> think about this? > > First and foremost you'll need to use firmware with "raw-mode" support > - otherwise firmware just craps over frame headers. Some 10.2.4 > support it - you can look into the mailing list archive for some > discussions. > > Not sure if Rx will work though as firmware-controlled Rx filters may > prevent you from receiving frames with crazy frame_control values. > You'll need to check this out yourself. Some firmware revisions might > have RX_FILTER wmi command support but this isn't used/documented > anywhere and it's questionable how much it allows you to override. > > Whatever you find it'd be nice if you post whatever you find out (for > posterity :) > > > Michał > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-05-31 15:53 ` Adrian Chadd @ 2016-06-01 11:34 ` Joerg Pommnitz 2016-06-01 19:18 ` Adrian Chadd 0 siblings, 1 reply; 9+ messages in thread From: Joerg Pommnitz @ 2016-06-01 11:34 UTC (permalink / raw) To: Adrian Chadd, Michal Kazior; +Cc: ath10k@lists.infradead.org Hi Adrian, does "hardware assist...will likely not work" mean "forget it, won't work" or "so it would have to be implemented in software instead"? -- Regards Joerg > Adrian Chadd <adrian@freebsd.org> schrieb am 17:53 Dienstag, 31.Mai 2016: > > Hi, > > The other thing to keep in mind is the hardware assist for things like > TIM parsing, wakeup, etc will likely not work. :) > > > > -a > > > > On 31 May 2016 at 03:50, Michal Kazior <michal.kazior@tieto.com> wrote: >> On 31 May 2016 at 10:44, jpo <pommnitz@yahoo.com> wrote: >>> Hello all, >>> to implement a "Stealth feature", e.g. the WLAN network does > not show up in >>> normal Scans, we modified the Frame version, Beacon and Probe-Response >>> values for an old ATH5K card running on the now dormant Madwifi driver. >>> Question: Is the same thing even POSSIBLE with ath10k? My main concern > is, >>> that the firmware just won't handle non-standard values. >>> >>> Can somebody who understands the division of labor between mac80211, > ath10k, >>> the firmware and the hardware suppress his or her gag reflex long > enough to >>> think about this? >> >> First and foremost you'll need to use firmware with > "raw-mode" support >> - otherwise firmware just craps over frame headers. Some 10.2.4 >> support it - you can look into the mailing list archive for some >> discussions. >> >> Not sure if Rx will work though as firmware-controlled Rx filters may >> prevent you from receiving frames with crazy frame_control values. >> You'll need to check this out yourself. Some firmware revisions might >> have RX_FILTER wmi command support but this isn't used/documented >> anywhere and it's questionable how much it allows you to override. >> >> Whatever you find it'd be nice if you post whatever you find out (for >> posterity :) >> >> >> Michał >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-06-01 11:34 ` Joerg Pommnitz @ 2016-06-01 19:18 ` Adrian Chadd 2016-06-01 19:29 ` Ben Greear 0 siblings, 1 reply; 9+ messages in thread From: Adrian Chadd @ 2016-06-01 19:18 UTC (permalink / raw) To: Joerg Pommnitz; +Cc: Michal Kazior, ath10k@lists.infradead.org Hi, Likely a mix of both. Eg, the RX filter stuff as mentioned above may mean that you need to listen to /all/ frames for a BSS, rather than just say data and beacon frames. If the beacon frame matching logic checks the frame version, you need to listen to /all/ of the frames. For power management things, it's likely none of that will work, so you can't use things like auto-sleep based on beacon traffic / timers / TIM bitmap - you'd have to keep the NIC awake all the time. -adrian On 1 June 2016 at 04:34, Joerg Pommnitz <pommnitz@yahoo.com> wrote: > Hi Adrian, > does "hardware assist...will likely not work" mean "forget it, won't work" > or "so it would have to be implemented in software instead"? > > > -- Regards Joerg > > > >> Adrian Chadd <adrian@freebsd.org> schrieb am 17:53 Dienstag, 31.Mai 2016: >> > Hi, >> >> The other thing to keep in mind is the hardware assist for things like >> TIM parsing, wakeup, etc will likely not work. :) >> >> >> >> -a >> >> >> >> On 31 May 2016 at 03:50, Michal Kazior <michal.kazior@tieto.com> wrote: >>> On 31 May 2016 at 10:44, jpo <pommnitz@yahoo.com> wrote: >>>> Hello all, >>>> to implement a "Stealth feature", e.g. the WLAN network does >> not show up in >>>> normal Scans, we modified the Frame version, Beacon and Probe-Response >>>> values for an old ATH5K card running on the now dormant Madwifi driver. >>>> Question: Is the same thing even POSSIBLE with ath10k? My main concern >> is, >>>> that the firmware just won't handle non-standard values. >>>> >>>> Can somebody who understands the division of labor between mac80211, >> ath10k, >>>> the firmware and the hardware suppress his or her gag reflex long >> enough to >>>> think about this? >>> >>> First and foremost you'll need to use firmware with >> "raw-mode" support >>> - otherwise firmware just craps over frame headers. Some 10.2.4 >>> support it - you can look into the mailing list archive for some >>> discussions. >>> >>> Not sure if Rx will work though as firmware-controlled Rx filters may >>> prevent you from receiving frames with crazy frame_control values. >>> You'll need to check this out yourself. Some firmware revisions might >>> have RX_FILTER wmi command support but this isn't used/documented >>> anywhere and it's questionable how much it allows you to override. >>> >>> Whatever you find it'd be nice if you post whatever you find out (for >>> posterity :) >>> >>> >>> Michał >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >> _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-06-01 19:18 ` Adrian Chadd @ 2016-06-01 19:29 ` Ben Greear 2016-06-01 19:33 ` Adrian Chadd 0 siblings, 1 reply; 9+ messages in thread From: Ben Greear @ 2016-06-01 19:29 UTC (permalink / raw) To: Adrian Chadd, Joerg Pommnitz; +Cc: Michal Kazior, ath10k@lists.infradead.org On 06/01/2016 12:18 PM, Adrian Chadd wrote: > Hi, > > Likely a mix of both. Eg, the RX filter stuff as mentioned above may > mean that you need to listen to /all/ frames for a BSS, rather than > just say data and beacon frames. If the beacon frame matching logic > checks the frame version, you need to listen to /all/ of the frames. > > For power management things, it's likely none of that will work, so > you can't use things like auto-sleep based on beacon traffic / timers > / TIM bitmap - you'd have to keep the NIC awake all the time. I'm guessing little of this is in hardware, aside from rx filters, so probably a few tweaks to the firmware would handle much of this... And, if for AP mode, then the NIC is always awake anyway, right? Thanks, Ben > > > > -adrian > > > On 1 June 2016 at 04:34, Joerg Pommnitz <pommnitz@yahoo.com> wrote: >> Hi Adrian, >> does "hardware assist...will likely not work" mean "forget it, won't work" >> or "so it would have to be implemented in software instead"? >> >> >> -- Regards Joerg >> >> >> >>> Adrian Chadd <adrian@freebsd.org> schrieb am 17:53 Dienstag, 31.Mai 2016: >>>> Hi, >>> >>> The other thing to keep in mind is the hardware assist for things like >>> TIM parsing, wakeup, etc will likely not work. :) >>> >>> >>> >>> -a >>> >>> >>> >>> On 31 May 2016 at 03:50, Michal Kazior <michal.kazior@tieto.com> wrote: >>>> On 31 May 2016 at 10:44, jpo <pommnitz@yahoo.com> wrote: >>>>> Hello all, >>>>> to implement a "Stealth feature", e.g. the WLAN network does >>> not show up in >>>>> normal Scans, we modified the Frame version, Beacon and Probe-Response >>>>> values for an old ATH5K card running on the now dormant Madwifi driver. >>>>> Question: Is the same thing even POSSIBLE with ath10k? My main concern >>> is, >>>>> that the firmware just won't handle non-standard values. >>>>> >>>>> Can somebody who understands the division of labor between mac80211, >>> ath10k, >>>>> the firmware and the hardware suppress his or her gag reflex long >>> enough to >>>>> think about this? >>>> >>>> First and foremost you'll need to use firmware with >>> "raw-mode" support >>>> - otherwise firmware just craps over frame headers. Some 10.2.4 >>>> support it - you can look into the mailing list archive for some >>>> discussions. >>>> >>>> Not sure if Rx will work though as firmware-controlled Rx filters may >>>> prevent you from receiving frames with crazy frame_control values. >>>> You'll need to check this out yourself. Some firmware revisions might >>>> have RX_FILTER wmi command support but this isn't used/documented >>>> anywhere and it's questionable how much it allows you to override. >>>> >>>> Whatever you find it'd be nice if you post whatever you find out (for >>>> posterity :) >>>> >>>> >>>> Michał >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> ath10k@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>> > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-06-01 19:29 ` Ben Greear @ 2016-06-01 19:33 ` Adrian Chadd 2016-06-01 19:37 ` Ben Greear [not found] ` <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com> 0 siblings, 2 replies; 9+ messages in thread From: Adrian Chadd @ 2016-06-01 19:33 UTC (permalink / raw) To: Ben Greear; +Cc: Michal Kazior, ath10k@lists.infradead.org, Joerg Pommnitz On 1 June 2016 at 12:29, Ben Greear <greearb@candelatech.com> wrote: > On 06/01/2016 12:18 PM, Adrian Chadd wrote: >> >> Hi, >> >> Likely a mix of both. Eg, the RX filter stuff as mentioned above may >> mean that you need to listen to /all/ frames for a BSS, rather than >> just say data and beacon frames. If the beacon frame matching logic >> checks the frame version, you need to listen to /all/ of the frames. >> >> For power management things, it's likely none of that will work, so >> you can't use things like auto-sleep based on beacon traffic / timers >> / TIM bitmap - you'd have to keep the NIC awake all the time. > > > I'm guessing little of this is in hardware, aside from rx filters, > so probably a few tweaks to the firmware would handle much of this... Right. > And, if for AP mode, then the NIC is always awake anyway, right? Right. But say, P2P/STA mode and no AP mode? Different story. (I'm assuming he has clients AND APs..) Also, for ath10k chips, maybe it'll all need to be in raw mode? I don't know what the hardware encap/decap engines will do if you try passing it intentionally different frames like this. -adrian _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values 2016-06-01 19:33 ` Adrian Chadd @ 2016-06-01 19:37 ` Ben Greear [not found] ` <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com> 1 sibling, 0 replies; 9+ messages in thread From: Ben Greear @ 2016-06-01 19:37 UTC (permalink / raw) To: Adrian Chadd; +Cc: Michal Kazior, ath10k@lists.infradead.org, Joerg Pommnitz On 06/01/2016 12:33 PM, Adrian Chadd wrote: > On 1 June 2016 at 12:29, Ben Greear <greearb@candelatech.com> wrote: >> On 06/01/2016 12:18 PM, Adrian Chadd wrote: >>> >>> Hi, >>> >>> Likely a mix of both. Eg, the RX filter stuff as mentioned above may >>> mean that you need to listen to /all/ frames for a BSS, rather than >>> just say data and beacon frames. If the beacon frame matching logic >>> checks the frame version, you need to listen to /all/ of the frames. >>> >>> For power management things, it's likely none of that will work, so >>> you can't use things like auto-sleep based on beacon traffic / timers >>> / TIM bitmap - you'd have to keep the NIC awake all the time. >> >> >> I'm guessing little of this is in hardware, aside from rx filters, >> so probably a few tweaks to the firmware would handle much of this... > > Right. > >> And, if for AP mode, then the NIC is always awake anyway, right? > > Right. But say, P2P/STA mode and no AP mode? Different story. (I'm > assuming he has clients AND APs..) Yeah, I'm less sure about that. I still bet a few firmware tweaks would resolve issues...surely the hardware is not baking a lot of wifi frame constants into it's ROM... > Also, for ath10k chips, maybe it'll all need to be in raw mode? I > don't know what the hardware encap/decap engines will do if you try > passing it intentionally different frames like this. Beacons and probe responses are not encrypted anyway, so probably doesn't need to disable hw-crypt. Might be a fairly long tail of effort to find every last place that makes some assumption on the values though... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com>]
* Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values [not found] ` <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com> @ 2016-06-01 19:43 ` Ben Greear 0 siblings, 0 replies; 9+ messages in thread From: Ben Greear @ 2016-06-01 19:43 UTC (permalink / raw) To: Jörg Pommnitz, Adrian Chadd Cc: Michal Kazior, ath10k@lists.infradead.org, Joerg Pommnitz On 06/01/2016 12:38 PM, Jörg Pommnitz wrote: > This is about IBSS mode. The nodes form an ad-hoc backbone. Clients use normal, standard conforming APs. So, about IBSS. Only ancient QCA firmware and 'CT' firmware supports IBSS as far as I know. I was never able to get RSN to work with IBSS reliably in CT firmware, so it would have to be un-encrypted traffic. And, AMSDU + IBSS has hardware bugs, evidently, so firmware will disable AMSDU for you. That said, adding a few more hacks for fake beacon ids might not make it any worse :) Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-06-01 20:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-31 8:44 Please don't puke: Modifying Frame Version, Beacon and Probe-Response values jpo
2016-05-31 10:50 ` Michal Kazior
2016-05-31 15:53 ` Adrian Chadd
2016-06-01 11:34 ` Joerg Pommnitz
2016-06-01 19:18 ` Adrian Chadd
2016-06-01 19:29 ` Ben Greear
2016-06-01 19:33 ` Adrian Chadd
2016-06-01 19:37 ` Ben Greear
[not found] ` <CAEvAWuHgna4cdgkhQrQY4xo4XyaCAhkkf1zo8iDA_Gqgjc1Jeg@mail.gmail.com>
2016-06-01 19:43 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.