* [RFC][PATCH] Input: define keys for WWAN and SES
@ 2013-11-28 11:48 Rafał Miłecki
2013-11-28 12:06 ` Hauke Mehrtens
0 siblings, 1 reply; 6+ messages in thread
From: Rafał Miłecki @ 2013-11-28 11:48 UTC (permalink / raw)
To: linux-input, Jiri Kosina; +Cc: Hauke Mehrtens, Rafał Miłecki
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. 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?
Another thing is WWAN key. Some routers support mobile networks (for
example Linksys 54G3G) and they may have button for enabling/disabling
such connection. We already have KEY_BLUETOOTH, KEY_WLAN and KEY_UWB,
but nothing for WWAN device control. I guess in future KEY_WWAN could
be also supported in rfkill by mapping it to the RFKILL_TYPE_WWAN.
What do you think about this?
---
include/uapi/linux/input.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 4649ee3..a06c8bf 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -749,6 +749,9 @@ struct input_keymap_entry {
#define BTN_TRIGGER_HAPPY39 0x2e6
#define BTN_TRIGGER_HAPPY40 0x2e7
+#define KEY_WWAN 0x2e8 /* Wireless WAN (LTE, UMTS, GSM, etc.) */
+#define KEY_SES 0x2e9 /* SecureEasySetup */
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.7.10.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [RFC][PATCH] Input: define keys for WWAN and SES
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
0 siblings, 1 reply; 6+ messages in thread
From: Hauke Mehrtens @ 2013-11-28 12:06 UTC (permalink / raw)
To: Rafał Miłecki, linux-input, Jiri Kosina
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.
> 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.
> Another thing is WWAN key. Some routers support mobile networks (for
> example Linksys 54G3G) and they may have button for enabling/disabling
> such connection. We already have KEY_BLUETOOTH, KEY_WLAN and KEY_UWB,
> but nothing for WWAN device control. I guess in future KEY_WWAN could
> be also supported in rfkill by mapping it to the RFKILL_TYPE_WWAN.
>
> What do you think about this?
> ---
> include/uapi/linux/input.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 4649ee3..a06c8bf 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -749,6 +749,9 @@ struct input_keymap_entry {
> #define BTN_TRIGGER_HAPPY39 0x2e6
> #define BTN_TRIGGER_HAPPY40 0x2e7
>
> +#define KEY_WWAN 0x2e8 /* Wireless WAN (LTE, UMTS, GSM, etc.) */
> +#define KEY_SES 0x2e9 /* SecureEasySetup */
> +
> /* We avoid low common keys in module aliases so they don't get huge. */
> #define KEY_MIN_INTERESTING KEY_MUTE
> #define KEY_MAX 0x2ff
>
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC][PATCH] Input: define keys for WWAN and SES
2013-11-28 12:06 ` Hauke Mehrtens
@ 2013-11-28 12:32 ` Rafał Miłecki
2013-11-28 13:01 ` Bastien Nocera
0 siblings, 1 reply; 6+ messages in thread
From: Rafał Miłecki @ 2013-11-28 12:32 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-input, Jiri Kosina
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.
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
2013-11-28 12:32 ` Rafał Miłecki
@ 2013-11-28 13:01 ` Bastien Nocera
2013-11-28 14:06 ` Rafał Miłecki
0 siblings, 1 reply; 6+ messages in thread
From: Bastien Nocera @ 2013-11-28 13:01 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Hauke Mehrtens, linux-input, Jiri Kosina
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
2013-11-28 13:01 ` Bastien Nocera
@ 2013-11-28 14:06 ` Rafał Miłecki
2013-11-28 14:14 ` Bastien Nocera
0 siblings, 1 reply; 6+ messages in thread
From: Rafał Miłecki @ 2013-11-28 14:06 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Hauke Mehrtens, linux-input, Jiri Kosina
2013/11/28 Bastien Nocera <hadess@hadess.net>:
> On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote:
>> 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.
I think it's just a software thing (some EAP messages probably).
Thanks for your comments!
What about KEY_WWAN. Does it make sense to add it?
--
Rafał
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC][PATCH] Input: define keys for WWAN and SES
2013-11-28 14:06 ` Rafał Miłecki
@ 2013-11-28 14:14 ` Bastien Nocera
0 siblings, 0 replies; 6+ messages in thread
From: Bastien Nocera @ 2013-11-28 14:14 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Hauke Mehrtens, linux-input, Jiri Kosina
On Thu, 2013-11-28 at 15:06 +0100, Rafał Miłecki wrote:
> 2013/11/28 Bastien Nocera <hadess@hadess.net>:
> > On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote:
> >> 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.
>
> I think it's just a software thing (some EAP messages probably).
>
> Thanks for your comments!
>
> What about KEY_WWAN. Does it make sense to add it?
If there are "keys" with that sort of label, it would make sense to me.
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-28 14:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2013-11-28 14:06 ` Rafał Miłecki
2013-11-28 14:14 ` Bastien Nocera
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).