ieee80211-devel Mailing List for Generic 802.11 Networking Subsystem (Page 4)

Status: Abandoned

Brought to you by: jketreno, johill, rchatre, yizhu

ieee80211-devel — List for discussing development of ieee80211 subsystem

You can subscribe to this list here.

2005	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul (14)	_Aug (46)	_Sep (117)	_Oct (24)	_Nov (10)	_Dec (1)
2006	_Jan (11)	_Feb (2)	_Mar (1)	_Apr (1)	_May	_Jun (1)	_Jul	_Aug (2)	_Sep (2)	_Oct (1)	_Nov	_Dec
2007	_Jan (1)	_Feb	_Mar	_Apr (1)	_May	_Jun	_Jul (1)	_Aug	_Sep	_Oct	_Nov	_Dec
2008	_Jan	_Feb	_Mar (3)	_Apr (3)	_May (1)	_Jun (5)	_Jul (7)	_Aug (1)	_Sep (8)	_Oct (2)	_Nov (27)	_Dec (33)
2009	_Jan (11)	_Feb (10)	_Mar (10)	_Apr (16)	_May (4)	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec

Flat | Threaded

<< < 1 2 3 4 5 6 .. 11 > >> (Page 4 of 11)

[Ieee80211-devel] [PATCH ieee80211] fix TX skb allocation flags and size

From: Michael B. <mb...@fr...> - 2005-10-13 21:44:00

Attachments: ieee80211_fix_flags_and_size.diff

ieee80211 subsystem:
* Use GFP mask on TX skb allocation.
* Allocate TX skb memory DMA mappable.
* Use the tx_headroom and reserve requested space.

--- linux-2.6.14-rc4-git2/net/ieee80211/ieee80211_tx.c.orig 2005-10-13 22:45:13.000000000 +0200
+++ linux-2.6.14-rc4-git2/net/ieee80211/ieee80211_tx.c 2005-10-13 22:56:43.000000000 +0200
@@ -207,7 +207,7 @@ void ieee80211_txb_free(struct ieee80211
 }
 
 static struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_size,
-       gfp_t gfp_mask)
+       int headroom, gfp_t gfp_mask)
 {
  struct ieee80211_txb *txb;
  int i;
@@ -221,11 +221,13 @@ static struct ieee80211_txb *ieee80211_a
  txb->frag_size = txb_size;
 
 	for (i = 0; i < nr_frags; i++) {
-		txb->fragments[i] = dev_alloc_skb(txb_size);
+		txb->fragments[i] = __dev_alloc_skb(txb_size + headroom,
+						    gfp_mask | GFP_DMA);
 		if (unlikely(!txb->fragments[i])) {
 			i--;
    break;
   }
+  skb_reserve(txb->fragments[i], headroom);
  }
  if (unlikely(i != nr_frags)) {
   while (i >= 0)
@@ -350,7 +352,8 @@ int ieee80211_xmit(struct sk_buff *skb, 
  /* When we allocate the TXB we allocate enough space for the reserve
   * and full fragment bytes (bytes_per_frag doesn't include prefix,
   * postfix, header, FCS, etc.) */
- txb = ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC);
+ txb = ieee80211_alloc_txb(nr_frags, frag_size,
+      ieee->tx_headroom, GFP_ATOMIC);
  if (unlikely(!txb)) {
   printk(KERN_WARNING "%s: Could not allocate TXB\n",
          ieee->dev->name);

Signed-off-by: Michael Buesch <mb...@fr...>

-- 
Greetings Michael.

[Ieee80211-devel] Re: [Bcm43xx-dev] Re: ieee80211 txb problems with bcm430x driver

From: Michael B. <mb...@fr...> - 2005-10-13 20:37:25

On Thursday 13 October 2005 20:33, James Ketrenos wrote:
> >* The txb fragment memory is not guaranteed to be DMA mappable (lacks
> >of GFP_DMA allocation flag.
> > =20
> >
> Makes sense.  Per a random google search, it appears we would also need
> to specifiy GFP_KERNEL or GFP_ATOMIC with GFP_DMA (vs. GFP_DMA by itself)=
=2E=20
>=20
> >* We need to add a device specific header to the data before posting it
> >on the chip. So we need some headroom in the skbs we get from the
> >80211 subsys (82 bytes).
> >There is a variable "int tx_headroom" in the main ieee80211 structure, b=
ut this
> >variable is not checked by the 80211 subsys. Indeed, grep tells me it is
> >referenced nowhere within 80211 subsys.
> > =20
> >
> Used to be there; we must have missed porting that code forward as
> various patches went in.
>=20
> >I think something like this is needed:
> > =20
> >
> If it does the trick for what you need, it looks reasonable on my side.=20
> Let us know once you've tested it with your code and if it does what you
> need, we can merge it in.

Ok, I will do a patch, test it with our code and submit it to you (James).

=2D-=20
Greetings Michael.

[Ieee80211-devel] ieee80211 txb problems with bcm430x driver

From: Michael B. <mb...@fr...> - 2005-10-11 21:54:25

Hi,

(Please CC: the bcm430x list on replies, as we are not on the ieee80211 lis=
t)

I am a developer of the bcm430x driver project.
http://bcm43xx.berlios.de/

We are using the ieee80211 stack as of linux-2.6.14-pre in our
driver. Two major problems raise for the bcm430x device:

* The txb fragment memory is not guaranteed to be DMA mappable (lacks
of GFP_DMA allocation flag.
* We need to add a device specific header to the data before posting it
on the chip. So we need some headroom in the skbs we get from the
80211 subsys (82 bytes).
There is a variable "int tx_headroom" in the main ieee80211 structure, but =
this
variable is not checked by the 80211 subsys. Indeed, grep tells me it is
referenced nowhere within 80211 subsys.

I think something like this is needed:

=2D-- linux-2.6.14-rc4/net/ieee80211/ieee80211_tx.c.orig 2005-10-11 23:41:4=
7.000000000 +0200
+++ linux-2.6.14-rc4/net/ieee80211/ieee80211_tx.c 2005-10-11 23:46:48.00000=
0000 +0200
@@ -207,7 +207,7 @@
 }
=20
 static struct ieee80211_txb *ieee80211_alloc_txb(int nr_frags, int txb_siz=
e,
=2D       gfp_t gfp_mask)
+       int headroom, gfp_t gfp_mask)
 {
  struct ieee80211_txb *txb;
  int i;
@@ -221,11 +221,12 @@
  txb->frag_size =3D txb_size;
=20
  for (i =3D 0; i < nr_frags; i++) {
=2D  txb->fragments[i] =3D dev_alloc_skb(txb_size);
+  txb->fragments[i] =3D __dev_alloc_skb(txb_size + headroom, GFP_DMA);
   if (unlikely(!txb->fragments[i])) {
    i--;
    break;
   }
+  skb_reserve(txb->fragments[i], headroom);
  }
  if (unlikely(i !=3D nr_frags)) {
   while (i >=3D 0)
@@ -350,7 +351,7 @@
  /* When we allocate the TXB we allocate enough space for the reserve
   * and full fragment bytes (bytes_per_frag doesn't include prefix,
   * postfix, header, FCS, etc.) */
=2D txb =3D ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC);
+ txb =3D ieee80211_alloc_txb(nr_frags, frag_size, ieee->tx_headroom, GFP_A=
TOMIC);
  if (unlikely(!txb)) {
   printk(KERN_WARNING "%s: Could not allocate TXB\n",
          ieee->dev->name);


This is not tested. Just to better show you what I mean.

=2D-=20
Greetings Michael.

[Ieee80211-devel] Re: [PATCH 0/5] IEEE80211 fixes

From: Jeff G. <jg...@po...> - 2005-10-04 12:26:32

James Ketrenos wrote:
> For those that want to pull these changes, I have applied 3-5 to the GIT
> overlay at rsync://bughost.org/repos/ieee80211-delta/.git/

I pulled these into the 'upstream' branch of netdev-2.6.git.

	Jeff

[Ieee80211-devel] Re: [PATCH 0/5] IEEE80211 fixes

From: Randy.Dunlap <rd...@xe...> - 2005-10-03 15:21:04

On Mon, 3 Oct 2005, James Ketrenos wrote:

> Ivo van Doorn wrote:
>
> >Hi,
> >
> >Here are following a small series of patches for the ieee80211 stack,
> >branch upstream: 2759c8d536efe3b853867f345627d89fb64c37af.
> >
> >The patches depend on each other, so they should be applied in the correct
> >provided order. I have placed an explanation on each patch.
> >The first 3 patches are relatively small and simple, only the last 2 need a
> >bit more explanation.
> >
> >
> For those that want to pull these changes, I have applied 3-5 to the GIT
> overlay at rsync://bughost.org/repos/ieee80211-delta/.git/
>
> Patch 1/5 I had already applied when Michael Wu sent that patch out earlier.
>
> Patch 2/5 will not be applied.
>
> I have also applied Randy's type cast patch.

which needs a "__nocast" added to it.  :(
I'll be resending it tonight.

-- 
~Randy

Re: [Ieee80211-devel] probe request capability

From: Ivo v. D. <iv...@gm...> - 2005-10-02 21:00:53

On Sunday 2 October 2005 20:53, Jouni Malinen wrote:
> On Fri, Sep 30, 2005 at 05:12:42PM +0200, Ivo van Doorn wrote:
> > According to the details about ieee80211 located here:
> > http://grouper.ieee.org/groups/802/11/Tutorial/MAC.pdf
>
> Which is a presentation from 1996, i.e., before IEEE 802.11 was
> approved..
>
> > A probe request should also contain the capabilities of the requestor.
> > Was there a specific reason why the ieee80211 stack does not have this
> > field, or did I misinterpreted the details?
>
> There is no such field in IEEE 802.11 ProbeReq. Please use a proper
> source, i.e., the standard, when verifying whether the implementation is
> correct.

Will do. :)

IvD

[Ieee80211-devel] Re: probe request capability

From: Ivo v. D. <iv...@gm...> - 2005-10-02 20:15:38

Hi,

> According to the details about ieee80211 located here:
> http://grouper.ieee.org/groups/802/11/Tutorial/MAC.pdf
>
> A probe request should also contain the capabilities of the requestor.
> Was there a specific reason why the ieee80211 stack does not have this
> field, or did I misinterpreted the details?
>
> In case if was just forgotten, patch is below. ;)

Ok, my fault, the file I had read was wrong about the capability field in t=
he=20
probe request. This patch can be completely ignored. :)

IvD

> Signed-off-by: Ivo van Doorn <Iv...@gm...>
>
> --- ieee80211.h	2005-09-25 16:20:45.000000000 +0200
> +++ ieee80211_cap.h	2005-09-30 17:05:02.000000000 +0200
> @@ -617,6 +617,7 @@
>
>  struct ieee80211_probe_request {
>  	struct ieee80211_hdr_3addr header;
> +	__le16 capability;
>  	/* SSID, supported rates */
>  	struct ieee80211_info_element info_element[0];
>  } __attribute__ ((packed));

Re: [Ieee80211-devel] probe request capability

From: Jouni M. <jkm...@cc...> - 2005-10-02 18:59:24

On Fri, Sep 30, 2005 at 05:12:42PM +0200, Ivo van Doorn wrote:

> According to the details about ieee80211 located here:
> http://grouper.ieee.org/groups/802/11/Tutorial/MAC.pdf

Which is a presentation from 1996, i.e., before IEEE 802.11 was
approved..

> A probe request should also contain the capabilities of the requestor.
> Was there a specific reason why the ieee80211 stack does not have this field,
> or did I misinterpreted the details?

There is no such field in IEEE 802.11 ProbeReq. Please use a proper
source, i.e., the standard, when verifying whether the implementation is
correct.

-- 
Jouni Malinen                                            PGP id EFC895FA

[Ieee80211-devel] probe request capability

From: Ivo v. D. <iv...@gm...> - 2005-10-02 17:27:59

Hi,


According to the details about ieee80211 located here:
http://grouper.ieee.org/groups/802/11/Tutorial/MAC.pdf

A probe request should also contain the capabilities of the requestor.
Was there a specific reason why the ieee80211 stack does not have this fiel=
d,
or did I misinterpreted the details?

In case if was just forgotten, patch is below. ;)

Signed-off-by: Ivo van Doorn <Iv...@gm...>

=2D-- ieee80211.h	2005-09-25 16:20:45.000000000 +0200
+++ ieee80211_cap.h	2005-09-30 17:05:02.000000000 +0200
@@ -617,6 +617,7 @@
=20
 struct ieee80211_probe_request {
 	struct ieee80211_hdr_3addr header;
+	__le16 capability;
 	/* SSID, supported rates */
 	struct ieee80211_info_element info_element[0];
 } __attribute__ ((packed));

[Ieee80211-devel] [PATCH] ieee80211: fix typo ieee82011_deauth -> ieee80211_deauth

From: Michael Wu <fla...@so...> - 2005-09-28 20:01:05

This patch fixes a typo in ieee80211.h:
ieee82011_deauth -> ieee80211_deauth

Signed-off-by: Michael Wu <fla...@so...>

diff --git a/include/net/ieee80211.h
b/include/net/ieee80211.h
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -613,7 +613,7 @@ struct ieee80211_disassoc {
 } __attribute__ ((packed));

 /* Alias deauth for disassoc */
-#define ieee82011_deauth ieee80211_disassoc
+#define ieee80211_deauth ieee80211_disassoc

 struct ieee80211_probe_request {
        struct ieee80211_hdr_3addr header;