nl80211: allow user-space to determine address for P2P_DEVICE

PATCH In review Arend van Spriel 2 participants 5 messages Jan 8, 2013 – Jan 21, 2013 802.11 (including cfg80211/NL80211)

lore

Share & tools

lore

Arend van Spriel

author

2013-01-08 09:17 UTC #0 lore raw

PATCH 1/1 nl80211: allow user-space to determine address for P2P_DEVICE

As per email discussion Jouni Malinen pointed out that:

"P2P message exchanges can be executed on the current operating channel of any operation (both P2P and non-P2P station). These can be on 5 GHz and even on 60 GHz (so yes, you _can_ do GO Negotiation on 60 GHz).

As an example, it would be possible to receive a GO Negotiation Request frame on a 5 GHz only radio and then to complete GO Negotiation on that band. This can happen both when connected to a P2P group (through client discoverability mechanism) and when connected to a legacy AP (assuming the station receive Probe Request frame from full scan in the beginning of P2P device discovery)."

This means that P2P messages can be sent over different radio devices. However, these should use the same P2P device address so it should be able to provision this from user-space. This patch adds a parameter for this to struct vif_params which should only be used during creation of the P2P device interface.

Cc Jouni Malinen <[email protected]>

Cc Greg Goldman <[email protected]>

Cc Jithu Jance <[email protected]>

Signed-off-by Arend van Spriel <[email protected]>

---
Hi Johannes,

Best wishes. Found this patch catching dust on my shelf/branch. Cleaning up in 2013 so here you have it :-)

Regards,
Arend

---
 include/net/cfg80211.h |    4 ++++
 net/wireless/nl80211.c |    4 ++++
 2 files changed, 8 insertions(+)

include/net/cfg80211.h +4 -0

index e5f085c..f9e4833 100644
@@ -281,9 +281,13 @@ struct ieee80211_supported_band {
 /**
  * struct vif_params - describes virtual interface parameters
  * @use_4addr: use 4-address frames
+ * @macaddr: address to use for this virtual interface. This will only
+ * 	be used for non-netdevice interfaces. If this parameter is set
+ * 	to zero address the driver may determine the address as needed.
  */
 struct vif_params {
        int use_4addr;
+       u8 macaddr[ETH_ALEN];
 };
 
 /**

net/wireless/nl80211.c +4 -0

index 9bd8340..42858eb 100644
@@ -2079,6 +2079,10 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
 	    !(rdev->wiphy.interface_modes & (1 << type)))
 		return -EOPNOTSUPP;
 
+	if (type == NL80211_IFTYPE_P2P_DEVICE && info->attrs[NL80211_ATTR_MAC])
+		nla_memcpy(&params.macaddr[0], info->attrs[NL80211_ATTR_MAC],
+			   ETH_ALEN);
+
 	if (info->attrs[NL80211_ATTR_4ADDR]) {
 		params.use_4addr = !!nla_get_u8(info->attrs[NL80211_ATTR_4ADDR]);
 		err = nl80211_valid_4addr(rdev, NULL, params.use_4addr, type);

Signature · 1 line

1.7.10.4

Arend van Spriel

author

2013-01-08 09:17 UTC #1 lore raw

PATCH 1/1 iw: additional mac parameter for add interface primitive

When adding a P2P Device interface user-space may provide the address for it. This should allow user-space to exchange P2P messages over multiple radios using the same address.

Signed-off-by Arend van Spriel <[email protected]>

---
 interface.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

interface.c +11 -2

index 26e72dc..f03c079 100644
@@ -168,6 +168,7 @@ static int handle_interface_add(struct nl80211_state *state,
 	char *name;
 	char *mesh_id = NULL;
 	enum nl80211_iftype type;
+	unsigned char mac_addr[ETH_ALEN];
 	int tpset;
 
 	if (argc < 1)

@@ -207,6 +208,14 @@ static int handle_interface_add(struct nl80211_state *state,
 				fprintf(stderr, "flags error\n");
 				return 2;
 			}
+		} else if (strcmp(argv[0], "mac") == 0) {
+			argc--;
+			argv++;
+			if (mac_addr_a2n(mac_addr, argv[0])) {
+				fprintf(stderr, "invalid mac address\n");
+				return 2;
+			}
+			NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr);
 		} else {
 			return 1;
 		}

@@ -224,14 +233,14 @@ static int handle_interface_add(struct nl80211_state *state,
  nla_put_failure:
 	return -ENOBUFS;
 }
-COMMAND(interface, add, "<name> type <type> [mesh_id <meshid>] [4addr on|off] [flags <flag>*]",
+COMMAND(interface, add, "<name> type <type> [mesh_id <meshid>] [4addr on|off] [flags <flag>*] [mac <MAC address>]",
 	NL80211_CMD_NEW_INTERFACE, 0, CIB_PHY, handle_interface_add,
 	"Add a new virtual interface with the given configuration.\n"
 	IFACE_TYPES "\n\n"
 	"The flags are only used for monitor interfaces, valid flags are:\n"
 	VALID_FLAGS "\n\n"
 	"The mesh_id is used only for mesh mode.");
-COMMAND(interface, add, "<name> type <type> [mesh_id <meshid>] [4addr on|off] [flags <flag>*]",
+COMMAND(interface, add, "<name> type <type> [mesh_id <meshid>] [4addr on|off] [flags <flag>*] [mac <MAC address>]",
 	NL80211_CMD_NEW_INTERFACE, 0, CIB_NETDEV, handle_interface_add, NULL);
 
 static int handle_interface_del(struct nl80211_state *state,

Signature · 1 line

1.7.10.4

Johannes Berg

maintainer

2013-01-16 22:17 UTC #2 lore raw

In reply to Arend van Spriel

Quoted 23 lines · Arend van Spriel

As per email discussion Jouni Malinen pointed out that:
"P2P message exchanges can be executed on the current operating channel of any operation (both P2P and non-P2P station). These can be on 5 GHz and even on 60 GHz (so yes, you _can_ do GO Negotiation on 60 GHz).
As an example, it would be possible to receive a GO Negotiation Request frame on a 5 GHz only radio and then to complete GO Negotiation on that band. This can happen both when connected to a P2P group (through client discoverability mechanism) and when connected to a legacy AP (assuming the station receive Probe Request frame from full scan in the beginning of P2P device discovery)."
This means that P2P messages can be sent over different radio devices. However, these should use the same P2P device address so it should be able to provision this from user-space. This patch adds a parameter for this to struct vif_params which should only be used during creation of the P2P device interface.
Cc Jouni Malinen <[email protected]>
Cc Greg Goldman <[email protected]>
Cc Jithu Jance <[email protected]>
Signed-off-by Arend van Spriel <[email protected]>

Quoted 5 lines

---
Hi Johannes,
Best wishes. Found this patch catching dust on my shelf/branch. Cleaning up in 2013 so here you have it :-)

:-)

net/wireless/nl80211.c static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) · line 2084

Quoted 9 lines

net/wireless/nl80211.c +3 -0

@@ -2079,6 +2079,10 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
 	    !(rdev->wiphy.interface_modes & (1 << type)))
 		return -EOPNOTSUPP;
 
+	if (type == NL80211_IFTYPE_P2P_DEVICE && info->attrs[NL80211_ATTR_MAC])
+		nla_memcpy(&params.macaddr[0], info->attrs[NL80211_ATTR_MAC],
+			   ETH_ALEN);

It seems like this might need a capability parameter or something, so wpa_s knows this will take effect. OTOH, wpa_s can query the MAC address afterwards, so it's not really needed, so I applied it.

(I changed the subject to say "configure", "determine" seems a bit vague to me, the way I read it it could possibly also mean "allow to get" it)

I would also like to see a mac80211 change though to make it take effect there.

johannes

Arend van Spriel

author

2013-01-21 09:54 UTC #3 lore raw

Quoted 7 lines · Johannes Berg

Quoted 6 lines · Arend van Spriel

net/wireless/nl80211.c +0 -0

@@ -2079,6 +2079,10 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
 	    !(rdev->wiphy.interface_modes & (1 << type)))
 		return -EOPNOTSUPP;

Quoted 7 lines

net/wireless/nl80211.c static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) · line 2084
Quoted 3 lines
net/wireless/nl80211.c +3 -0
+	if (type == NL80211_IFTYPE_P2P_DEVICE && info->attrs[NL80211_ATTR_MAC])
+		nla_memcpy(&params.macaddr[0], info->attrs[NL80211_ATTR_MAC],
+			   ETH_ALEN);
It seems like this might need a capability parameter or something, so wpa_s knows this will take effect. OTOH, wpa_s can query the MAC address afterwards, so it's not really needed, so I applied it.

Not sure if I can follow. I did submit wpa_s patch for flagging the P2P device capability. Are you suggesting an additional flag here to indicate whether the MAC address can be configured by wpa_s?

Quoted 2 lines

(I changed the subject to say "configure", "determine" seems a bit vague to me, the way I read it it could possibly also mean "allow to get" it)

Potaitoe, Patatoe, fine by me ;-)

Quoted 2 lines

I would also like to see a mac80211 change though to make it take effect there.

See what I can do. I guess it does involve mac80211 device drivers as well, right?

Gr. AvS

Quoted 3 lines

johannes

Johannes Berg

maintainer

2013-01-21 10:02 UTC #4 lore raw

Quoted 11 lines · Arend van Spriel

Quoted 7 lines
net/wireless/nl80211.c static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) · line 2084
Quoted 3 lines
net/wireless/nl80211.c +3 -0
+	if (type == NL80211_IFTYPE_P2P_DEVICE && info->attrs[NL80211_ATTR_MAC])
+		nla_memcpy(&params.macaddr[0], info->attrs[NL80211_ATTR_MAC],
+			   ETH_ALEN);
It seems like this might need a capability parameter or something, so wpa_s knows this will take effect. OTOH, wpa_s can query the MAC address afterwards, so it's not really needed, so I applied it.
Not sure if I can follow. I did submit wpa_s patch for flagging the P2P device capability. Are you suggesting an additional flag here to indicate whether the MAC address can be configured by wpa_s?

Yes, or maybe it's not needed as wpa_s could read the address back after the interface is created, and see whether it stuck. Right now, for example, with mac80211 it wouldn't be used at all.

Quoted 5 lines

Quoted 2 lines
I would also like to see a mac80211 change though to make it take effect there.
See what I can do. I guess it does involve mac80211 device drivers as well, right?

Oh, I think there's no mac80211 driver using P2P device yet. :-) I have a patch for iwlwifi but I'm not merging it until wpa_s gets "more ready"

johannes