Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[jpo]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Michal Kazior]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Adrian Chadd]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Joerg Pommnitz]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Adrian Chadd]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Ben Greear]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Adrian Chadd]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Ben Greear]

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

Re: Please don't puke: Modifying Frame Version, Beacon and Probe-Response values

[Ben Greear]

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