From: Steve deRosier <derosier@gmail.com>
To: Bob Marcan <bob.marcan@gmail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [RFC 0/4] Allow live MAC address change
Date: Tue, 17 Sep 2019 12:11:35 -0700 [thread overview]
Message-ID: <CALLGbR+1Pryv2z6m3caP9LuvGpY5BSFM8i+kyC2DX2vNpmQGNQ@mail.gmail.com> (raw)
In-Reply-To: <20190917204419.41235404@smicro.local.lan>
On Tue, Sep 17, 2019 at 11:44 AM Bob Marcan <bob.marcan@gmail.com> wrote:
>
> On Tue, 17 Sep 2019 10:40:49 -0500
> Denis Kenzior <denkenz@gmail.com> wrote:
>
> > Hi Kalle,
> >
> > > For user experience scanning and DHCP are also important, what kind of > numbers you get when those are included? No need to have anything> precise, I would like just to get an understanding where we are> nowadays.
> >
> > Scanning heavily depends on the RF environment and the hardware. In our testing ath9k takes stupid long to scan for example.
> >
> > But in a sort of best case scenario, using limited scan and no mac change, iwd connects in ~300ms. People have reported that they have not finished opening their laptop screen and they're connected, so at that level of latency, every millisecond is important and totally worth fighting for. Randomizing the MAC would penalize our connection times by 2X (300 ms at least). And Android folks have reported the penalty to be as high as 3 seconds. So this needs to be fixed. And do note that this is a feature every modern OS implements by default.
>
> Randomizing the MAC is a stupid decision.
> Do you realy expect that this will add something to the security?
>
Hi Bob,
Thank you for your post, but this is an opinion and adds nothing to
the technical discussion underway. Let's discuss the patches please.
Thanks,
- Steve
next prev parent reply other threads:[~2019-09-17 19:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 19:11 [RFC 0/4] Allow live MAC address change James Prestwood
2019-09-04 19:11 ` [RFC 1/4] nl80211: Add LIVE_ADDR_CHANGE feature James Prestwood
2019-09-04 19:11 ` [RFC 2/4] {nl|cfg}80211: Support mac change as part of SME Connect James Prestwood
2019-09-04 19:11 ` [RFC 3/4] mac80211: Support LIVE_ADDRESS_CHANGE feature James Prestwood
2019-09-04 19:11 ` [RFC 4/4] {nl,cfg}nl80211: Support mac change for mlme_authenticate James Prestwood
2019-09-11 9:09 ` [RFC 0/4] Allow live MAC address change Johannes Berg
2019-09-11 15:54 ` James Prestwood
2019-09-11 18:25 ` Johannes Berg
2019-09-11 19:20 ` James Prestwood
2019-09-13 10:24 ` Kalle Valo
2019-09-13 16:17 ` James Prestwood
2019-09-17 7:46 ` Kalle Valo
2019-09-17 15:40 ` Denis Kenzior
2019-09-17 18:44 ` Bob Marcan
2019-09-17 18:47 ` Ben Greear
2019-09-17 19:05 ` Marcel Holtmann
2019-09-17 19:11 ` Steve deRosier [this message]
2019-09-17 16:11 ` James Prestwood
2019-09-13 18:49 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALLGbR+1Pryv2z6m3caP9LuvGpY5BSFM8i+kyC2DX2vNpmQGNQ@mail.gmail.com \
--to=derosier@gmail.com \
--cc=bob.marcan@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).