From: Bastien Nocera <hadess@hadess.net>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>,
linux-input@vger.kernel.org, Jiri Kosina <jkosina@suse.cz>
Subject: Re: [RFC][PATCH] Input: define keys for WWAN and SES
Date: Thu, 28 Nov 2013 14:01:46 +0100 [thread overview]
Message-ID: <1385643706.17991.9.camel@nuvo> (raw)
In-Reply-To: <CACna6rz58KybJ4dMPWUwXzR6QkQXnkdu_5zvQWteBaepikS0UA@mail.gmail.com>
On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote:
> 2013/11/28 Hauke Mehrtens <hauke@hauke-m.de>:
> > On 11/28/2013 12:48 PM, Rafał Miłecki wrote:
> >> This is just a RFC, so be nice to this "patch", please ;)
> >>
> >> My goal is to add support for buttons on bcm47xx arch. However after
> >> analyzing existing database of devices I realized I don't know what code
> >> I should assign to some buttons.
> >>
> >> First of all, older routers often have a "SES" button. SES stands for
> >> SecureEasySetup and is Broadcom's proprietary protocol which was later
> >> replaced with WPS (Wi-Fi Protected Setup).
> >> Btw. WPS appeared to be broken because it's easy to attack it with
> >> brutal-force method.
> >
> > Only a badly implemented WPS pin authentication is vulnerable to the
> > brute force attack, as far as I know.
>
> Oh, indeed, I missed that. Thanks!
>
> >> I'm not sure if any distribution have any interest
> >> in using that buttons, but it still would be nice to have support for
> >> them in kernel. One option is to add KEY_SES for this purpose.
> >> Is this the right way? It's similar to the KEY_WPS_BUTTON, but I wanted
> >> to somehow distinct them. Is there any other option? Should I use
> >> KEY_UNKNOWN or BTN_MISC or BTN_n?
> >
> > I do not think you or someone else plans to implement SecureEasySetup on
> > a device running current Linux kernel, why not use the WPS button key
> > for for these button. If someone wants to implement this just use the
> > WPS button key for that.
>
> I'm just not sure about possible scenarios. I imagined end-user
> pressing SES button router and SES button on a device and complaining
> it's not working (because of SES being interpreted as WPS).
>
> If you guys think we should just use WPS for the SES button, I'm OK with that.
Isn't the fact that it returns WPS or SES an implementation detail?
Is WPS vs. SES just a software choice, or a hardware one? If it's a
hardware one, you'd expect to have other ways to discover whether SES or
WPS was requested (because that's the one supported by the hardware). If
it's a software choice, then you'd expect the button to one or the other
based on the software stack.
Or are both possible at the same time, and there are devices with both
buttons?
Seems that adding a note that other similar "pairing" methods for Wi-Fi
could be triggered when the button is used, in input.h would be enough.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-11-28 13:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 11:48 [RFC][PATCH] Input: define keys for WWAN and SES Rafał Miłecki
2013-11-28 12:06 ` Hauke Mehrtens
2013-11-28 12:32 ` Rafał Miłecki
2013-11-28 13:01 ` Bastien Nocera [this message]
2013-11-28 14:06 ` Rafał Miłecki
2013-11-28 14:14 ` Bastien Nocera
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=1385643706.17991.9.camel@nuvo \
--to=hadess@hadess.net \
--cc=hauke@hauke-m.de \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=zajec5@gmail.com \
/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).