Re: linux-wireless mailing list

Re: linux-wireless mailing list

[Jeff Garzik]

Pavel Roskin wrote:
> Hello!
> 
> I believe the developers of Linux wireless drivers need a separate mailing
> list, preferably called linux-wireless at vger.kernel.org.  I don't expect
> it to have heavy traffic, but there should be a definitive forum for
> discussing issues common for wireless drivers on Linux.

I do not object to such a list, but I would respectfully request that 
all development matters be cross-posted to netdev@oss.sgi.com.  That's 
where the network developers hang out.

Now I present my opinions :)

> I expect following topics to be discussed:
> 
> Wireless Extensions.  I highly respect Jean Tourrilhes who is doing this
> work.  I believe that driver and userspace developers should use this
> forum to discuss their needs and to provide feedback to Jean.

The wireless extensions are utility -- they work, but are not beautiful. 
  I am presently writing the driver for the RealTek wireless card, and 
in the process creating a small wireless driver API.  The ideal is to 
avoid ioctls, and instead to present extensible, type-safe interfaces. 
This is what I would like wireless extensions to morph into.


> Handling of 802.11 frames.  We may need common code to convert 802.11
> frames to 802.3 and possibly other standards.  Maybe some standards for
> 802.11 encapsulation and bridging could be discussed as well.

Absolutely.  David Miller, Arnaldo Carvalho de Melo, and myself all seem 
to feel that a net/802_11 directory and associated code would be useful. 
  There is definitely an area for code commonality across drivers.


> Sniffing.  We need a common standard how to pass raw frames and additional
> information to the userspace.  There are several de facto standards, but
> the lack of communication between developers makes those standards less
> useful.  For example, Prism2 headers were meant as highly extensible, but
> libpcap expects them to be of fixed size.  It's an obvious failure to
> communicate the intentions of the standard.

Agreed.


> Encryption.  There are wireless specific encryption issues.  Host based
> WEP support needs RC4 cipher in the kernel.  There's not much to discuss
> here, but the lack of RC4 in the kernel may indicate that Linux wireless
> developers are not acting together to make it happen.  The patch does
> exist.

Send the patch to netdev!  ;-)  This should be the easy part.


> Other interfaces between drivers and the userspace.  There should be one
> place to discuss whether wireless drivers should be using
> netif_carrier_on/off, ethtool and mii-tool support.  Again, there is not
> much to discuss, but it's much much worse if the same questions are
> discussed in different forums and every driver takes its own approach.

netdev is that place ;-)

Best regards and welcome,

	Jeff

Re: linux-wireless mailing list

[Jean Tourrilhes]

On Wed, Mar 03, 2004 at 10:08:17PM -0500, Jeff Garzik wrote:
> 
> The wireless extensions are utility -- they work, but are not beautiful. 
>  I am presently writing the driver for the RealTek wireless card, and 
> in the process creating a small wireless driver API.  The ideal is to 
> avoid ioctls, and instead to present extensible, type-safe interfaces. 
> This is what I would like wireless extensions to morph into.

	Just for the record. The new driver API of WE is no longer
tied to ioctls. The goal was to change the external API to RtNetlink,
but I got distracted. But, you could imagine plugging the driver API
to a file system (there is so many of them, take your pick).
	I believe that migrating the external API to RtNetlink would
address 99% of your concerns, isn't it ? If this is the case, then we
could work to make this happen.
	I've always say that the mechanism of the API does not matter,
what matter is the standardisation of the parameters and data types.

> Absolutely.  David Miller, Arnaldo Carvalho de Melo, and myself all seem 
> to feel that a net/802_11 directory and associated code would be useful. 
>  There is definitely an area for code commonality across drivers.

	1) Please don't start from scratch.
	2) Please keep the 802.2 and 802.11 part separated. Actually,
getting 802.2 alone would be so useful.

> Best regards and welcome,
> 
> 	Jeff

	Jean

Re: linux-wireless mailing list

[Jean Tourrilhes]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Wed, Mar 03, 2004 at 10:08:17PM -0500, Jeff Garzik wrote:
> 
> The wireless extensions are utility -- they work, but are not beautiful. 
>  I am presently writing the driver for the RealTek wireless card, and 
> in the process creating a small wireless driver API.  The ideal is to 
> avoid ioctls, and instead to present extensible, type-safe interfaces. 
> This is what I would like wireless extensions to morph into.

	Just to check if we are on the same page, I dusted an old
patch to add a RtNetlink API to Wireless Extensions. This completely
avoids ioctls, is type safe, and still extensible. The patch is fully
functional and tested but not finished (no support for GET and private
requests).
	Of course, it won't work on drivers using the old API, such as
orinoco.c. Don't blame me, I sent the orinoco patch to David 2 years
ago.
	Please coment on that. If this is what you want, I could
accelerate its release.

	Jean

[-- Attachment #2: iw264_api_rtnetlink.diff --]
[-- Type: text/plain, Size: 7273 bytes --]

diff -u -p linux/net/core/rtnetlink.j1.c linux/net/core/rtnetlink.c
--- linux/net/core/rtnetlink.j1.c	Thu Mar  4 16:14:02 2004
+++ linux/net/core/rtnetlink.c	Thu Mar  4 19:52:47 2004
@@ -50,6 +50,10 @@
 #include <net/udp.h>
 #include <net/sock.h>
 #include <net/pkt_sched.h>
+#ifdef CONFIG_NET_RADIO
+#include <linux/wireless.h>		/* Note : will define WIRELESS_EXT */
+#include <net/iw_handler.h>
+#endif	/* CONFIG_NET_RADIO */
 
 DECLARE_MUTEX(rtnl_sem);
 
@@ -269,6 +273,16 @@ static int do_setlink(struct sk_buff *sk
 		memcpy(dev->broadcast, RTA_DATA(ida[IFLA_BROADCAST - 1]),
 		       dev->addr_len);
 	}
+
+#ifdef WIRELESS_EXT
+	if (ida[IFLA_WIRELESS - 1]) {
+		printk(KERN_DEBUG "Calling wireless stuff\n");
+		/* Device validity/presence checked in there */
+		err = wireless_process_rtnetlink(dev, RTA_DATA(ida[IFLA_WIRELESS - 1]), ida[IFLA_WIRELESS - 1]->rta_len);
+		if (err)
+			goto out;
+	}
+#endif	/* WIRELESS_EXT */
 
 	err = 0;
 
diff -u -p linux/net/core/wireless.j1.c linux/net/core/wireless.c
--- linux/net/core/wireless.j1.c	Thu Mar  4 16:13:52 2004
+++ linux/net/core/wireless.c	Thu Mar  4 18:39:49 2004
@@ -75,6 +75,7 @@
 
 /* Debugging stuff */
 #undef WE_IOCTL_DEBUG		/* Debug IOCTL API */
+#define WE_RTNETLINK_DEBUG	/* Debug RtNetlink API */
 #undef WE_EVENT_DEBUG		/* Debug Event dispatcher */
 #undef WE_SPY_DEBUG		/* Debug enhanced spy support */
 
@@ -941,6 +942,199 @@ int wireless_process_ioctl(struct ifreq 
 	}
 	/* Not reached */
 	return -EINVAL;
+}
+
+/************************ RTNETLINK SUPPORT ************************/
+/*
+ * The alternate user space API to configure all those Wireless Extensions
+ * is through RtNEtlink.
+ * This API support only the new driver API (iw_handler).
+ * This is still experimental.
+ */
+
+/* ---------------------------------------------------------------- */
+/*
+ * Wrapper to call a standard Wireless Extension handler.
+ * We do various checks and also take care of moving data between
+ * user space and kernel space.
+ */
+static inline int rtnetlink_standard_call(struct net_device *	dev,
+					  struct iw_event *	request,
+					  int			request_len,
+					  iw_handler		handler)
+{
+	const struct iw_ioctl_description *	descr = NULL;
+	unsigned int				cmd;
+	union iwreq_data *			wrqu;
+	int					hdr_len;
+	struct iw_request_info			info;
+	int					ret = -EINVAL;
+
+	/* Get the description of the IOCTL */
+	cmd = request->cmd;
+	if((cmd - SIOCIWFIRST) >= standard_ioctl_num)
+		return -EOPNOTSUPP;
+	descr = &(standard_ioctl[cmd - SIOCIWFIRST]);
+
+#ifdef WE_RTNETLINK_DEBUG
+	printk(KERN_DEBUG "%s (WE) : Found standard handler for 0x%04X\n",
+	       dev->name, cmd);
+	printk(KERN_DEBUG "%s (WE) : Header type : %d, Token type : %d, size : %d, token : %d\n", dev->name, descr->header_type, descr->token_type, descr->token_size, descr->max_tokens);
+#endif	/* WE_IOCTL_DEBUG */
+
+	/* Extract fixed header from request */
+	wrqu = (union iwreq_data *) &request->u;
+
+	/* Prepare the call */
+	info.cmd = cmd;
+	info.flags = 0;
+
+	/* Check if wrqu is complete */
+	hdr_len = event_type_size[descr->header_type];
+	if(request_len < hdr_len) {
+#ifdef WE_RTNETLINK_DEBUG
+		printk(KERN_DEBUG "%s (WE) : Wireless request too short (%d)\n",
+		       dev->name, request_len);
+		return -EINVAL;
+#endif	/* WE_RTNETLINK_DEBUG */
+	}
+
+	/* Check if we have extra data in the request or not */
+	if(descr->header_type != IW_HEADER_TYPE_POINT) {
+
+		/* No extra arguments. Trivial to handle */
+		ret = handler(dev, &info, wrqu, NULL);
+
+#ifdef WE_SET_EVENT
+		/* Generate an event to notify listeners of the change */
+		if((descr->flags & IW_DESCR_FLAG_EVENT) &&
+		   ((ret == 0) || (ret == -EIWCOMMIT)))
+			wireless_send_event(dev, cmd, wrqu, NULL);
+#endif	/* WE_SET_EVENT */
+	} else {
+		char *	extra;
+		int	extra_len;
+
+		/* Check what user space is giving us */
+		if(IW_IS_SET(cmd)) {
+			/* Check if number of token fits within bounds */
+			if(wrqu->data.length > descr->max_tokens)
+				return -E2BIG;
+			if(wrqu->data.length < descr->min_tokens)
+				return -EINVAL;
+		}
+
+#ifdef WE_RTNETLINK_DEBUG
+		printk(KERN_DEBUG "%s (WE) : Malloc %d bytes\n",
+		       dev->name, descr->max_tokens * descr->token_size);
+#endif	/* WE_IOCTL_DEBUG */
+
+		/* Always allocate for max space. Easier, and won't last
+		 * long... */
+		extra = kmalloc(descr->max_tokens * descr->token_size,
+				GFP_KERNEL);
+		if (extra == NULL) {
+			return -ENOMEM;
+		}
+
+		/* If it is a SET, copy data to the aligned buffer */
+		if(IW_IS_SET(cmd) && (wrqu->data.length != 0)) {
+
+			/* Length of extra (what's after the fixed header) */
+			extra_len = request_len - hdr_len;
+
+			/* Check if we have enough of it */
+			if(extra_len < (wrqu->data.length *
+					descr->token_size)) {
+#ifdef WE_RTNETLINK_DEBUG
+				printk(KERN_DEBUG "%s (WE) : Wireless request data too short (%d)\n",
+				       dev->name, extra_len);
+				return -EINVAL;
+#endif	/* WE_RTNETLINK_DEBUG */
+			}
+
+			memcpy(extra, ((char *) request) + hdr_len,
+			       extra_len);
+		}
+
+		/* Call the handler */
+		ret = handler(dev, &info, wrqu, extra);
+
+		/* If we have something to return to the user */
+		if (!ret && IW_IS_GET(cmd)) {
+			// TODO
+		}
+
+#ifdef WE_SET_EVENT
+		/* Generate an event to notify listeners of the change */
+		if((descr->flags & IW_DESCR_FLAG_EVENT) &&
+		   ((ret == 0) || (ret == -EIWCOMMIT))) {
+			if(descr->flags & IW_DESCR_FLAG_RESTRICT)
+				/* If the event is restricted, don't
+				 * export the payload */
+				wireless_send_event(dev, cmd, wrqu, NULL);
+			else
+				wireless_send_event(dev, cmd, wrqu,
+						    extra);
+		}
+#endif	/* WE_SET_EVENT */
+
+		/* Cleanup - I told you it wasn't that long ;-) */
+		kfree(extra);
+	}
+
+	/* Call commit handler if needed and defined */
+	if(ret == -EIWCOMMIT)
+		ret = call_commit_handler(dev);
+
+	return ret;
+}
+
+/* ---------------------------------------------------------------- */
+/*
+ * Main RtNetlink dispatcher. Called from the main networking code
+ * (do_setlink() in net/core/rtnetlink.c).
+ * Check the type of Request and call the appropriate wrapper...
+ */
+int wireless_process_rtnetlink(struct net_device *	dev,
+			       char *			data,
+			       int			len)
+{
+	struct iw_event *	request = (struct iw_event *) data;
+	iw_handler		handler;
+
+	/* Check length */
+	if(len < IW_EV_LCP_LEN) {
+		printk(KERN_DEBUG "%s (WE) : RtNetlink request too short (%d)\n",
+		       dev->name, len);
+		return -EINVAL;
+	}
+
+	/* ReCheck length (len may have padding) */
+	if(request->len > len) {
+		printk(KERN_DEBUG "%s (WE) : RtNetlink request len invalid (%d-%d)\n",
+		       dev->name, request->len, len);
+		return -EINVAL;
+	}
+
+	// TODO : Handle special cases
+
+	/* Basic check */
+	if (!netif_device_present(dev))
+		return -ENODEV;
+
+	/* New driver API : try to find the handler */
+	handler = get_handler(dev, request->cmd);
+	if(handler != NULL) {
+		/* Standard and private are not the same */
+		if(request->cmd < SIOCIWFIRSTPRIV)
+			return rtnetlink_standard_call(dev,
+						       request,
+						       request->len,
+						       handler);
+		// TODO : support for Private Requests
+	}
+	return -EOPNOTSUPP;
 }
 
 /************************* EVENT PROCESSING *************************/

Re: linux-wireless mailing list

[Jeff Garzik]

Jean Tourrilhes wrote:
> +static inline int rtnetlink_standard_call(struct net_device *	dev,
> +					  struct iw_event *	request,
> +					  int			request_len,
> +					  iw_handler		handler)
> +{
> +	const struct iw_ioctl_description *	descr = NULL;
> +	unsigned int				cmd;
> +	union iwreq_data *			wrqu;
> +	int					hdr_len;
> +	struct iw_request_info			info;
> +	int					ret = -EINVAL;
> +
> +	/* Get the description of the IOCTL */
> +	cmd = request->cmd;
> +	if((cmd - SIOCIWFIRST) >= standard_ioctl_num)
> +		return -EOPNOTSUPP;
> +	descr = &(standard_ioctl[cmd - SIOCIWFIRST]);


OK, this patch looks good to me.

There is one piece we need to change though, that will cause the size of 
this patch to increase a bit.

Look at ethtool_ops, and net/core/ethtool.c, in the current upstream 2.4 
and 2.6 trees.

A key goal of mine is to completely eliminate the union and the 
iw_handler type.  To increase type-safety, and to decrease the pain of 
going through 32<->64-bit translation layers, each wireless hook needs 
to have a specific (not generic) interface (a la ethtool_ops).

	Jeff

Re: linux-wireless mailing list

[Jean Tourrilhes]

On Wed, Mar 10, 2004 at 12:46:09PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >+static inline int rtnetlink_standard_call(struct net_device *	dev,
> >+					  struct iw_event *	request,
> >+					  int			request_len,
> >+					  iw_handler		handler)
> >+{
> >+	const struct iw_ioctl_description *	descr = NULL;
> >+	unsigned int				cmd;
> >+	union iwreq_data *			wrqu;
> >+	int					hdr_len;
> >+	struct iw_request_info			info;
> >+	int					ret = -EINVAL;
> >+
> >+	/* Get the description of the IOCTL */
> >+	cmd = request->cmd;
> >+	if((cmd - SIOCIWFIRST) >= standard_ioctl_num)
> >+		return -EOPNOTSUPP;
> >+	descr = &(standard_ioctl[cmd - SIOCIWFIRST]);
> 
> 
> OK, this patch looks good to me.

	Thanks. I'll try to work on the missing parts.

> There is one piece we need to change though, that will cause the size of 
> this patch to increase a bit.
> 
> Look at ethtool_ops, and net/core/ethtool.c, in the current upstream 2.4 
> and 2.6 trees.
> 
> A key goal of mine is to completely eliminate the union and the 
> iw_handler type.  To increase type-safety, and to decrease the pain of 
> going through 32<->64-bit translation layers, each wireless hook needs 
> to have a specific (not generic) interface (a la ethtool_ops).

	The current API is already completely 32<->64-bit
safe. Wireless Tools have been used on Alpha since the end of the
90's. The code to support 32 bit user space on 64 bit kernel was
trivial and concern only a single pointer, and such pointer would not
exist when using RtNetlink. So, I claim that when using RtNetlink, the
API would be entirely 32<->64-bit safe.

	You point about type safety is perfectly valid.
	I believe that this is a tradeoff. The design reason to have a
single type of handler, apart from the space saving, was to allow a
driver to hook a common handler to multiple commands. I've used that
in a few cases, because it made the driver code simpler.
	So far, we never had any problem with regards to type
safety. Maybe it's because wireless driver authors are very clever ;-)

> 	Jeff

	Jean

Re: linux-wireless mailing list

[Jeff Garzik]

Jean Tourrilhes wrote:
> 	The current API is already completely 32<->64-bit
> safe. Wireless Tools have been used on Alpha since the end of the
> 90's. The code to support 32 bit user space on 64 bit kernel was
> trivial and concern only a single pointer, and such pointer would not
> exist when using RtNetlink. So, I claim that when using RtNetlink, the
> API would be entirely 32<->64-bit safe.

Yes, I agree.


> 	You point about type safety is perfectly valid.
> 	I believe that this is a tradeoff. The design reason to have a
> single type of handler, apart from the space saving, was to allow a
> driver to hook a common handler to multiple commands. I've used that
> in a few cases, because it made the driver code simpler.
> 	So far, we never had any problem with regards to type
> safety. Maybe it's because wireless driver authors are very clever ;-)

A type-specific wireless_ops is something that I definitely want to see.

It reduces code in the drivers, by increasing the amount of code that 
can be made generic.  It's much better to, for example, have all the 
user data (length, etc.) validate checks, and capable(CAP_xxx) security 
checks all in one place.  And perhaps more importantly, a type-specific 
wireless_ops makes it harder for driver writers to screw up ;-)  That's 
an important attribute in a driver API, I've come to learn...

	Jeff

Re: linux-wireless mailing list

[Jean Tourrilhes]

On Wed, Mar 10, 2004 at 01:25:48PM -0500, Jeff Garzik wrote:
> 
> A type-specific wireless_ops is something that I definitely want to see.
> 
> It reduces code in the drivers, by increasing the amount of code that 
> can be made generic.  It's much better to, for example, have all the 
> user data (length, etc.) validate checks, and capable(CAP_xxx) security 
> checks all in one place.  And perhaps more importantly, a type-specific 
> wireless_ops makes it harder for driver writers to screw up ;-)  That's 
> an important attribute in a driver API, I've come to learn...

	You could define a set of wrapper that would convert from
iw_handler to a type specific call. This is already what is done in
the case of iwspy support ; the driver just adds in the iw_handler
table the generic spy handlers provided in wireless.c. You can check
in airo.c around line 6823.
	But honestly, I believe that there are other more urgent
things to do (such as WPA support for example).

> 	Jeff

	Jean

Re: linux-wireless mailing list

[Jean Tourrilhes]

On Wed, Mar 10, 2004 at 12:46:09PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >+static inline int rtnetlink_standard_call(struct net_device *	dev,
> >+					  struct iw_event *	request,
> >+					  int			request_len,
> >+					  iw_handler		handler)
> >+{
> >+	const struct iw_ioctl_description *	descr = NULL;
> >+	unsigned int				cmd;
> >+	union iwreq_data *			wrqu;
> >+	int					hdr_len;
> >+	struct iw_request_info			info;
> >+	int					ret = -EINVAL;
> >+
> >+	/* Get the description of the IOCTL */
> >+	cmd = request->cmd;
> >+	if((cmd - SIOCIWFIRST) >= standard_ioctl_num)
> >+		return -EOPNOTSUPP;
> >+	descr = &(standard_ioctl[cmd - SIOCIWFIRST]);
> 
> 
> OK, this patch looks good to me.

	Jeff (and others),

	I'm hitting a problem with migrating Wireless Extensions to
RtNetlink.

	The basic model of Wireless Extensions is Query/Reply. I ask
for the ESSID, the card returns the ESSID, I ask for a scan, the card
returns the scan results.
	This doesn't work well with RtNetlink. RtNetlink supports only
Set and Dump. Set doesn't allow to return data, and Dump doesn't take
any input arguments, so always return everything. Using Dump doesn't
make sense, I don't want the card to perform a Wireless Scan every
time I want to check the ESSID (each Wireless Scan takes a few
seconds).
	The RtNetlink interface was clearly not designed for hardware
devices where the retrieval of each piece of information has a
significant cost/overhead.

	I'm also suspicious of the interaction with the device
notifiers and link flag setting. But that may not be as bad.

	The option I'm leaning toward is to define a new Netlink
socket type for Wireless Extensions, which would allow me to use the
Query/Reply model.

	Thanks...

	Jean

Re: linux-wireless mailing list

[Pavel Roskin]

On Wed, 3 Mar 2004, Jean Tourrilhes wrote:

> On Wed, Mar 03, 2004 at 05:28:30PM -0500, Pavel Roskin wrote:
> > Hello!
> >
> > I believe the developers of Linux wireless drivers need a separate mailing
> > list, preferably called linux-wireless at vger.kernel.org.  I don't expect
> > it to have heavy traffic, but there should be a definitive forum for
> > discussing issues common for wireless drivers on Linux.
>
[snip]
> 	Why does this matter ? If those driver maintainers don't feel
> part of the Kernel, they probably won't feel part of the "Linux
> wireless driver" group that you are trying to create.
> 	Those maintainers are already busy with bug reports and
> users. They would need a good incentive too coordinate such
> activities across drivers.

Avoiding more work later is a pretty good incentive.  If the driver turns
out to be inconsistent with others, it will have to be changed, perhaps
retaining the original code for backward compatibility.

> 	Fortunately, those maintainers know about the common good and
> always take the path of least resistance. If someone provide the
> infrastructure, they will eventually buy into it. Actually, the new
> developpers are more likely to use it than those who already have
> working solutions.
> 	Look at the firmware download support. Manuel did a good job
> of talking with the various driver authors and come up with a useful
> solution, and it's a great success.

Firmware download support was a major achievement, and it was not limited
to networking, let alone wireless networking.  Manuel did a great job.

There are often much smaller issues, often so minor that I don't want to
bother you personally.  Today's example - when the card connects to an
access point and changes its ESSID (because the desired ESSID is "any"),
should the driver send an wireless event for BSSID only or also for ESSID?

I know, you are a great guy and you will answer me, but I don't want to be
the fifth person to ask you that in private.  I don't want to check
drivers for the hardware I don't have trying to understand what they would
do in this situation.

> 	Coming back to your point. It seems to me that what we need is
> motivated people willing to push specific cross-driver activities and
> coordinate those with the driver maintainers.

It would be natural for userspace developers and distribution maintainers
to promote specific interfaces and standards, but it would be too much to
expect them to negotiate with different driver developers trying to
explain the same thing over an over again.

It would be easier for them to post to linux-wireless and see the
discussion.  If I as a driver (co-)maintainer don't read that list, the
decision will be made without me, and then (kismet|airsnort|xsupplicant)
maintainers with came to harass me so I implement what other _driver_
developers have agreed to.  Seems like a good incentive to pay attention
:-)

> 	The mailing list you propose may help those people to acheive
> their goal. But, without such people, it probably won't take off,
> because driver maintainers are just too busy.
> 	But, of course, I would be happy to be wrong ;-)

Having a list will help less motivated and more busy people reach the
audience they want to reach and achieve the goals they want to achieve.
I hope so.

> > I expect following topics to be discussed:
> >
> > Wireless Extensions.  I highly respect Jean Tourrilhes who is doing this
> > work.  I believe that driver and userspace developers should use this
> > forum to discuss their needs and to provide feedback to Jean.
>
> 	I can tell you already : WPA.

Yes.

Also, since Wireless Extensions define monitor mode (as one of the modes),
I would expect to see a definition of what it is, including frame format.
Maybe I want too much.

> > Handling of 802.11 frames.  We may need common code to convert 802.11
> > frames to 802.3 and possibly other standards.  Maybe some standards for
> > 802.11 encapsulation and bridging could be discussed as well.
>
> 	Yes, this is a sore point. Rather than starting from scratch I
> believe you should start from code in an existing driver (such as
> HostAP or MadWifi).
> 	Note that there are two separate parts, support of 802.2 (all
> the SNAP encapsualtion business), which is also useful for 802.3
> networks, and support of 802.11 framing. I believe that Arnaldo was
> working on 802.2 support (as part of IPX stuff).

That's the part I don't know well.  I feel uneasy that David Gibson tries
to invent something in the Orinoco driver, and I'm one of very few people
who can comment early on those efforts, yet I know too little about the
networking site of things to provide useful feedback.  If the
linux-wireless list existed, I would have some assurance that we are not
doing something that's not going to be accepted by other drivers.

> 	Actually, you remind me that I should ask Jouni to push his
> driver in the kernel.

I believe it can happen after RC4 goes to the kernel and HostAP uses
crypto API (optionally in the standalone version to keep Linux 2.4
compatibility).

> > Sniffing.  We need a common standard how to pass raw frames and additional
> > information to the userspace.  There are several de facto standards, but
> > the lack of communication between developers makes those standards less
> > useful.  For example, Prism2 headers were meant as highly extensible, but
> > libpcap expects them to be of fixed size.  It's an obvious failure to
> > communicate the intentions of the standard.
>
> 	Software never get it right on the first try. That's a bug
> report on libpcap. If you break libpcap, they will notice soon enough.

I don't want somebody to tell me that Orinoco does it wrong because all
other drivers use 144 bytes per header.  If it happens, I want to show a
link to a thread where it was discussed.  Sure, it's not a as good as a
written standard, but if it's the official linux-wireless list, interested
persons are supposed to comment before it's to late.

Without the list, I'll have to ask linux-wlan-ng team to write a standard,
then go to libpcap guys to persuade them to implement the standard as
described by the inventors of Prism2 headers.

> > Encryption.  There are wireless specific encryption issues.  Host based
> > WEP support needs RC4 cipher in the kernel.  There's not much to discuss
> > here, but the lack of RC4 in the kernel may indicate that Linux wireless
> > developers are not acting together to make it happen.  The patch does
> > exist.
>
> 	I've never seen this patch. Was it sent to the Crypto guys ?

http://sourceforge.net/mailarchive/message.php?msg_id=7298902

I'll ask Jon Oberheide where he sent it.

> > I believe linux-net@vger.kernel.org is the right place to ask because
> > Wireless almost inevitably assumes networking.  I'll appreciate if
> > somebody with enough weight in the kernel development supports this issue.
> > Or at least please let me know where else I should ask and whose support I
> > need to have.
>
> 	Don't get me wrong, I'm supportive, I just wanted to set a bit
> of context. I can't host mailing lists at HP, and SourceForge is not
> really reliable.

I posted this proposal because I felt that many people think this way and
somebody should post it.

-- 
Regards,
Pavel Roskin

Re: linux-wireless mailing list

[Jouni Malinen]

On Thu, Mar 04, 2004 at 02:08:08AM -0500, Pavel Roskin wrote:

> On Wed, 3 Mar 2004, Jean Tourrilhes wrote:
> > 	Actually, you remind me that I should ask Jouni to push his
> > driver in the kernel.

> I believe it can happen after RC4 goes to the kernel and HostAP uses
> crypto API (optionally in the standalone version to keep Linux 2.4
> compatibility).

Yes, it is quite easy for me to replace the HostAP-internal
implementation of WEP with CRC32+RC4 with crypto API. However, the
encryption algorithm itself is not everything that is needed for IEEE
802.11 encryption. With WEP, the additional work is quite limited (add
IV, verify ICV), but both TKIP and CCMP add quite a bit of more
processing for the header (like authentication of pseudo header, replay
protection, etc.).

Host AP driver uses a structure which allows multiple algorithms to be
registered for both encrypting and decrypting skb's with IEEE 802.11
headers. This structure is likely to remain even when the encryption
parts themselves are replaced with crypto API. In addition, these
functions are completely separate from the rest of the Host AP driver,
so it should be easy for other drivers to use them, if desired.

Some wlan chipsets use hardware acceleration for the
WEP/TKIP/CCMP(AES-CCM), but require the driver to process the IV/ICV/MIC
addition/verification. These drivers would also benefit if there were
generic functions that would support both software and hwaccel versions
for the encryption/decryption.

I was looking into pushing Host AP code for the kernel tree, but since
non-trivial amount of work would have been required with crypto parts,
this was delayed. Then came WPA and I wanted to get it working first..
But maybe now that it is mostly done, I could try to allocate enough
time to go through what is needed to get Host AP driver in acceptable
shape to be included into the kernel tree.

> > > Encryption.  There are wireless specific encryption issues.  Host based
> > > WEP support needs RC4 cipher in the kernel.  There's not much to discuss
> > > here, but the lack of RC4 in the kernel may indicate that Linux wireless
> > > developers are not acting together to make it happen.  The patch does
> > > exist.
> >
> > 	I've never seen this patch. Was it sent to the Crypto guys ?
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=7298902

That's nice to see. However, I would like to know whether any
performance testing has been done with that kind of design? It looks
like the encryption function (arc4_crypt()) is being called for each
byte of the encrypted area. That looks like a major extra work compared
to a tight loop going through the data (e.g., compared to the integrated
CRC32+RC4 implementation in Host AP driver).

With IEEE 802.11b, I don't really are that much about the extra work,
but with throughput of IEEE 802.11a/g, this might become considerable.
Then again, most modern cards seem to include hardware acceleration and
some of them are even able to do this at full data rate. Anyway,
software encryption might still be needed for some configuration (like
individual keys or some of more exotic things one can do with IEEE
802.11). For these cases, it would be nice to have crypto API support
for scatter-gather lists and going through each fragment with one
function call.

I'll try to get some time to test this with Host AP driver with WEP and
TKIP (by first implementing Michael MIC with crypto API). I will also
need to do some experimenting with AES and CCMP. With good luck, that
could be enough to replace internal crypto algorithm code in the Host AP
driver.

-- 
Jouni Malinen                                            PGP id EFC895FA