airo-linux-gen80211 Mailing List for Linux 802.11 Aironet driver (Page 100)
Status: Inactive
Brought to you by:
breed
You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(20) |
Oct
(10) |
Nov
(19) |
Dec
(55) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(29) |
Feb
(70) |
Mar
(53) |
Apr
(23) |
May
(21) |
Jun
(27) |
Jul
(33) |
Aug
(67) |
Sep
(94) |
Oct
(100) |
Nov
(95) |
Dec
(45) |
2001 |
Jan
(143) |
Feb
(84) |
Mar
(79) |
Apr
(97) |
May
(96) |
Jun
(95) |
Jul
(85) |
Aug
(143) |
Sep
(85) |
Oct
(105) |
Nov
(130) |
Dec
(86) |
2002 |
Jan
(72) |
Feb
(66) |
Mar
(108) |
Apr
(67) |
May
(6) |
Jun
(31) |
Jul
(3) |
Aug
(23) |
Sep
(27) |
Oct
(18) |
Nov
(10) |
Dec
(2) |
2003 |
Jan
(29) |
Feb
(7) |
Mar
(6) |
Apr
(13) |
May
(12) |
Jun
(3) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
(4) |
Nov
|
Dec
(4) |
2004 |
Jan
(6) |
Feb
(8) |
Mar
(2) |
Apr
(9) |
May
(4) |
Jun
(11) |
Jul
|
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
(2) |
2005 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
|
May
(3) |
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(6) |
Oct
(6) |
Nov
(2) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
From: Karl M Y. <kmy...@co...> - 1999-12-28 01:42:41
|
Hi. I was reading README.airo_cs today and i had a question. Should i get the latest version of pcmcia card services or 3.0.9 or 3.0.10 specifically? I downloaded and compiled 3.0.14 --Is that okay? _____________ Karl M Yerkes |
From: Bernard V. (D. O. Ltd) <be...@di...> - 1999-12-26 23:33:57
|
Roman, I had this problem also and solved it by setting up my network card as being eth1 leaving eth0 for the Aironet card in modules.conf something like alias ne eth1 (not sure bu something like that) Bernard Varaine Digital Objects Ltd Phone:+64 25 2777 843 152 Lone Kauri Road Fax : +64 9 8128 368 Karekare www.digitalobjects.co.nz Auckland, New Zealand -- Thawte web of Trust Notary ( http://www.thawte.com )-- ----- Original Message ----- From: R Dostick <do...@us...> To: <ai...@cs...> Cc: <pr...@ma...> Sent: Monday, December 27, 1999 12:51 PM Subject: [Aironet] Please Help this problem at once! > Hello, > > I have a problem similar to someone > had already, and there was message in October > list archive, but it wasnt nswered, > so please help this problem at once! > > Redhat 6.1 > ISA 4800 on P133 16 MB > board works just fine on same PC under DOS. > > gcc -O -c airo.c > depmod... > insmod irq=5 io=0x140 > no errors, no unresolved symbols. > lsmod show that airo is there [unused] > > then when I try ifconfig eth1 x.x.x.x it say that board not found > eth0 is ne2000 board (no irq or io conflicts) > I tried ifconfig eth1, rad0, airo0, anything, it doesnt work, can't find the > board. > /proc/aironet is empty dir, though it ws created by driver. > after reboot lsmod show airo is still there, unused. > i can rmmmod it and insmod again, so far it goes. > sometimes airo besome "used" in lsmod output, but ifconfig doesnt show > anything about it. > > ISP who sold us this board know how to make it work > but they wouldn't tell us how because they want us to use it under DOS/win > due to marketing reasons. > So because of small problem with airo.c, we must to stop using linux > and use Dos-based ugly iproute.exe > > > Help!!! > > Thanks in advance. this is our last hope. > Roman. > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > > _______________________________________________ > Aironet mailing list - Ai...@cs... > http://csl.cse.ucsc.edu/mailman/listinfo/aironet > |
From: R D. <do...@us...> - 1999-12-26 21:50:44
|
Hello, I have a problem similar to someone had already, and there was message in October list archive, but it wasnt nswered, so please help this problem at once! Redhat 6.1 ISA 4800 on P133 16 MB board works just fine on same PC under DOS. gcc -O -c airo.c depmod... insmod irq=5 io=0x140 no errors, no unresolved symbols. lsmod show that airo is there [unused] then when I try ifconfig eth1 x.x.x.x it say that board not found eth0 is ne2000 board (no irq or io conflicts) I tried ifconfig eth1, rad0, airo0, anything, it doesnt work, can't find the board. /proc/aironet is empty dir, though it ws created by driver. after reboot lsmod show airo is still there, unused. i can rmmmod it and insmod again, so far it goes. sometimes airo besome "used" in lsmod output, but ifconfig doesnt show anything about it. ISP who sold us this board know how to make it work but they wouldn't tell us how because they want us to use it under DOS/win due to marketing reasons. So because of small problem with airo.c, we must to stop using linux and use Dos-based ugly iproute.exe Help!!! Thanks in advance. this is our last hope. Roman. ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 |
From: Dale S. <ds...@is...> - 1999-12-26 17:53:38
|
This massage is a solicitation for wireless advise for a complete = wireless ignoramiss. If you do not wish to help I appoligize for = waisting your time. If you do, I apreaciate your help and thank you in = advance. My effort is to connect to my ISP who is aprox. 2,500ft. away. = Line of site is possible (branch clippers) but not preffered as this = would require permission from neighbors. Idealy I'm looking for 56-128k = full duplex any more would incure extra cost from my ISP (unless he can = regulate my throughput on his internet connection on his end, I did not = ask.). My ISP will alow an access point on his eithernet. I'm currently = running a win98 pc and I will be purchasing a new pc with corel linux. = I am an intermediat user of both windows and unix. My question is if any = of you wireless tech. professionals/gurus where in my shoes what would = you do given a budget of up to $1000(less is better)? Thanks agian, Dale |
From: john d. <de...@ka...> - 1999-12-24 19:12:43
|
On Wed, 22 Dec 1999, john derry wrote: >... > > I understand the /proc interface still isn't working, that fits my > experience because I've never seen the darn thing! > >... I see the /proc interface is working much better now on my 2.0.35 with the 0.98sb driver. I can view all the entries under the interface (eth1 in my case) and I can set the SSID. If there's a problem now I can't seem to see it. John |
From: john d. <de...@ka...> - 1999-12-22 21:40:12
|
On Sat, 11 Dec 1999 br...@al... wrote: > > Tonight I posted an updated airo.c to the web site (.98pa). It allows the ... > > Note, there is an outstanding bug: under 2.0 kernels the /proc interface > isn't working properly. Still tracking down a 2.0 machine... > Sorry Ben, but I only have brief periods to play with your driver because my real job is management... But I'm going to download the latest driver and set up a test machine to run it on a 2.0.35 kernel again. I understand the /proc interface still isn't working, that fits my experience because I've never seen the darn thing! Is there anyway I can provide feedback that might help you? Let me know. John Derry |
From: cybercom <nqu...@cy...> - 1999-12-22 12:56:44
|
From: Bernard V. (D. O. Ltd) <be...@di...> - 1999-12-21 22:56:49
|
Well I fixed this one. Seems it was coming from the PCI4800 card. we tried another one and it is now working. Another question. How do I setup the node name; Do I have to chnage the Config file in the proc/aironet/eth0 directory or is it a value I can setup in the modules.conf as per ssids, datarate ..etc regards Bernard Varaine Digital Objects Ltd Phone:+64 25 2777 843 152 Lone Kauri Road Fax : +64 9 8128 368 Karekare www.digitalobjects.co.nz Auckland, New Zealand -- Thawte web of Trust Notary ( http://www.thawte.com )-- ----- Original Message ----- From: Bernard Varaine (Digital Objects Ltd) <be...@di...> To: <ai...@cs...> Sent: Sunday, December 19, 1999 11:51 PM Subject: [Aironet] PCI4800 ; Caldera 2.2 . and lock up > Hi, > > Is anybody experienced problem like this with the 4800 PCI card. > I just downloaded airo.c last week, so I guess it is the latest version. > > When insmod and IPConfig the pc/card will work for a minute or two then he pc > will lock up. > > I have a feeling it could eb a problem with this particular "old" pc , but > would like your opinion before trying with another hardware, or ? > > > Any idea. > Bernard Varaine Digital Objects Ltd > > Phone:+64 25 2777 843 152 Lone Kauri Road > Fax : +64 9 8128 368 Karekare > www.digitalobjects.co.nz Auckland, New Zealand > > -- Thawte web of Trust Notary ( http://www.thawte.com )-- > |
From: Karl M Y. <kmy...@co...> - 1999-12-21 22:18:15
|
I do not know anything really about the 802.11 spec, but my understanding of the behavior of these cards is this. When a station is put in adhoc mode with an ssid of "foo" and a channel of "x" the card will scan _all_ channels for packets/beacons with ssid "foo". If it finds one on channel "y" , it will set it's channel to "y". One reliable way to insure that channel "x" is used instead of "y" is to start with all stations using different ssid's and channel "x", then change all stations to the same ssid. echo 859450 > /proc/aironet/eth1/SSID sleep 5 echo Mode: adhoc > /proc/aironet/eth1/Config echo NodeName: "`hostname`" >/proc/aironet/eth1/Config echo PowerMode: CAM > /proc/aironet/eth1/Config echo DataRates: 2 4 11 150 0 0 0 0 > /proc/aironet/eth1/Config echo WEP: open > /proc/aironet/eth1/Config echo XmitPower: 100 > /proc/aironet/eth1/Config echo Channel: 11 > /proc/aironet/eth1/Config echo kitten > /proc/aironet/eth1/SSID _____________ Karl M Yerkes On Tue, 21 Dec 1999, Jean-Pierre Ebert wrote: > Hi all, > > I have to linux mobiles running in adhoc mode. > > I tried to change the Channel from 0 to one of the other 11 channels. > Looking the proc-files up after the change, the channel and frequency > did not change. > > Any idea how to do that? > Might be, that only channel 0 can be used for ad hoc mode. > > Cheers > jp > > _______________________________________________ > Aironet mailing list - Ai...@cs... > http://csl.cse.ucsc.edu/mailman/listinfo/aironet > |
From: Jean-Pierre E. <eb...@ee...> - 1999-12-21 20:22:56
|
Hi all, I have to linux mobiles running in adhoc mode. I tried to change the Channel from 0 to one of the other 11 channels. Looking the proc-files up after the change, the channel and frequency did not change. Any idea how to do that? Might be, that only channel 0 can be used for ad hoc mode. Cheers jp |
From: Jean-Pierre E. <eb...@ee...> - 1999-12-21 20:17:06
|
Could someone shed light on the following: I used a Aironet PC4800 System and a UDP traffic generator to get some simple perfomance figures of the Aironet devices. In my first configuration I had a laptop communicating via a AP (infrastructure mode) to a PC, which is connected to the AP via Ethernet. I send very large UDP packets (1472 Byte -> 1514 Byte Ethernet packets) as fast as my laptop can generate and send the packets (it is definitely fast enough for the Aironet devices) at 11 Mbit/s and at a good position (signal level is 63/64). I get a throughput of around 700-750Kbyte/s (6MBit/s). Now I use the adhoc mode (just Laptop to Laptop communication) with the same measurement setup and conditions. I get a throughput of around 3.3MBit/s. Has someone a good explaination for that? To my knowledge, the difference between adhoc and infrastructure mode is, that the AP takes over some cell/network management things (they still use the same medium access protocol), but I would not await, that it cuts half of the bandwidth. What is the problem? There is another strange thing in infrastructure mode. Then transmitting UDP packets from the PC to the laptop a can achieve about 700Kbyte/s. In the other direction (from laptop to the PC) I get 100Kbyte less. Any ideas here? Cheers Jean-Pierre |
From: Gavin D H. <gho...@cs...> - 1999-12-20 19:56:53
|
>> The RTS threshold IS the parameter that distinguishes long from short. >> So, if the threshold is 512, then all packets >= 512 will be sent using >> an RTS/CTS exchange, and packets < 512 will not (basic CSMA/CA access). >> To get the Aironet defaults, you will have to interrogate the card. The >> standard specifies a threshold of 3000 (seems too large to me). > >You are right, the default threshold of 3000 Byte makes no real sence, >in particular if you have the maximum number of data byte in a MAC >packet in mind. But my interpretation of the 3000 Byte default value is, >that the RTS/CTS mechanism is switched of by default. As you may know, >the RTS/CTS mechanism makes only sense, if you have a high collision >probability and the packets are large. But when do you have high >collision probabilities. This can only occur, if you have a large number >of stations and high load conditions. > >If you think of such a situation in longer terms, then the WLAN network >is not usable anymore, since the access delays grow nearly infinite. If >you think in short terms of such a situation the RTS/CTS-parameter >should be dynamically controlable, depending on the actual situation. >The problem one have is, that one can not differentiate between >collisions and transmission failure. So switching off RTS/CTS mechanism >by default (3000Byte) is a good idea. > >Some people may claim, that RTS/CTS might be useful considering a hidden >terminal scenario. But it is not really helpful (see >http://www-tkn.ee.tu-berlin.de/~ebert/papers/PWC-new.ps.gz, see >http://www-tkn.ee.tu-berlin.de/~ebert/publication.html and >http://www-tkn.ee.tu-berlin.de/publications/pub.html for some more >research on WLANs) I'm not sure I agree with you, but I'll take a look at your papers and consider your point. However, I do agree with your interpretation of the threshold; I'm sure that was what the spec designers intended (in fact, they probably say that somewhere and I just didn't see it). -Gavin |
From: Jean-Pierre E. <eb...@ee...> - 1999-12-20 18:08:17
|
Hi Gavin, hi all, > >- I could not find any paramter to control differentiation between long > >and short packets. Does anybody know what the default assumption is > >(e.g. all packets < 300 Byte are short packets)? Or is this paramter > >coupled to the RTS-Threshold? > > The RTS threshold IS the parameter that distinguishes long from short. > So, if the threshold is 512, then all packets >= 512 will be sent using > an RTS/CTS exchange, and packets < 512 will not (basic CSMA/CA access). > To get the Aironet defaults, you will have to interrogate the card. The > standard specifies a threshold of 3000 (seems too large to me). You are right, the default threshold of 3000 Byte makes no real sence, in particular if you have the maximum number of data byte in a MAC packet in mind. But my interpretation of the 3000 Byte default value is, that the RTS/CTS mechanism is switched of by default. As you may know, the RTS/CTS mechanism makes only sense, if you have a high collision probability and the packets are large. But when do you have high collision probabilities. This can only occur, if you have a large number of stations and high load conditions. If you think of such a situation in longer terms, then the WLAN network is not usable anymore, since the access delays grow nearly infinite. If you think in short terms of such a situation the RTS/CTS-parameter should be dynamically controlable, depending on the actual situation. The problem one have is, that one can not differentiate between collisions and transmission failure. So switching off RTS/CTS mechanism by default (3000Byte) is a good idea. Some people may claim, that RTS/CTS might be useful considering a hidden terminal scenario. But it is not really helpful (see http://www-tkn.ee.tu-berlin.de/~ebert/papers/PWC-new.ps.gz, see http://www-tkn.ee.tu-berlin.de/~ebert/publication.html and http://www-tkn.ee.tu-berlin.de/publications/pub.html for some more research on WLANs) Cheers, Jean-Pierre > > >- For measurement reason I would like to switch of retransmissions > >completely. > >That is to say, a packet is only transmitted once and if there was a > >transmission error, the packet won't be resent. This is left to the > >higher layer protocols. Then I set LongRetryLimit or ShortRetryLimit to > >the value 0, the Config file entries are reseted to the value 16. The > >value 1 is the smallest value I can use. The device driver indicates > >that the value 0 should not be a problem, so I guess that the entries > >are somehow reset by the PCMCIA-Card default entries. > >My questions are: > > > >Is there a workaround for that (set value to zero)? > >What is the semantic of the LongRetryLimit, ShortRetryLimit variables. > >Does the value 1 means that the first send operation of a packet is > >already counted as retransmission or only packet send retries are > >counted as retransmissions? > >What is the smallest supported retry count of the Aironet NIC at all? > > The names for the retry limits are a little misleading. According to > the 802.11 spec, the retry limits inidicate the maximum number of > transmission attempts, not REtransmission attempts. Thus, a value of > 1 for either limit will result in a single transmission attempt. If > that fails, then the counter is incremented (0->1) resulting in a > failure indication since the limit (=1) has now been reached. It > sounds like the Aironet card is using 0 to indicate that defaults > should be used, since 0 is a meaningless value for the limits. > > -Gavin > > _______________________________________________ > Aironet mailing list - Ai...@cs... > http://csl.cse.ucsc.edu/mailman/listinfo/aironet |
From: Gavin D H. <gho...@cs...> - 1999-12-20 16:10:33
|
>2. There are to controable Paramters (LongRetryLimit, ShortRetryLimit) >in the /proc/aironet/eth0/Config file. From the IEEE 802.11 standard >Specification is looked up, that these paramters describe the maximum >retry number for short MAC packtes and long MAC packets. The values of >these paramters my range from 1 to 255. > >- I could not find any paramter to control differentiation between long >and short packets. Does anybody know what the default assumption is >(e.g. all packets < 300 Byte are short packets)? Or is this paramter >coupled to the RTS-Threshold? The RTS threshold IS the parameter that distinguishes long from short. So, if the threshold is 512, then all packets >= 512 will be sent using an RTS/CTS exchange, and packets < 512 will not (basic CSMA/CA access). To get the Aironet defaults, you will have to interrogate the card. The standard specifies a threshold of 3000 (seems too large to me). >- For measurement reason I would like to switch of retransmissions >completely. >That is to say, a packet is only transmitted once and if there was a >transmission error, the packet won't be resent. This is left to the >higher layer protocols. Then I set LongRetryLimit or ShortRetryLimit to >the value 0, the Config file entries are reseted to the value 16. The >value 1 is the smallest value I can use. The device driver indicates >that the value 0 should not be a problem, so I guess that the entries >are somehow reset by the PCMCIA-Card default entries. >My questions are: > >Is there a workaround for that (set value to zero)? >What is the semantic of the LongRetryLimit, ShortRetryLimit variables. >Does the value 1 means that the first send operation of a packet is >already counted as retransmission or only packet send retries are >counted as retransmissions? >What is the smallest supported retry count of the Aironet NIC at all? The names for the retry limits are a little misleading. According to the 802.11 spec, the retry limits inidicate the maximum number of transmission attempts, not REtransmission attempts. Thus, a value of 1 for either limit will result in a single transmission attempt. If that fails, then the counter is incremented (0->1) resulting in a failure indication since the limit (=1) has now been reached. It sounds like the Aironet card is using 0 to indicate that defaults should be used, since 0 is a meaningless value for the limits. -Gavin |
From: Sam K. <skh...@le...> - 1999-12-20 06:17:43
|
Could someone please help me get this aironet up. So I modified the config file, I placed the airo_cs.o and the airo.o files in the pcmcia directory, and rebooted. I get the following messages: Dec 19 22:04:55 localhost cardmgr[393]: initializing socket 0 Dec 19 22:04:55 localhost cardmgr[393]: socket 0: Aironet PC4800 Dec 19 22:04:55 localhost cardmgr[393]: executing: 'insmod /lib/modules/2.2.12-20/pcmcia/airo_cs.o' Dec 19 22:04:55 localhost cardmgr[393]: + /lib/modules/2.2.12-20/pcmcia/airo_cs.o: can't handle sections of type 1677721 Dec 19 22:04:55 localhost cardmgr[393]: insmod exited with status 1 Dec 19 22:04:55 localhost cardmgr[393]: executing: 'modprobe airo_cs' Dec 19 22:04:55 localhost cardmgr[393]: + no dependency information for module: "/lib/modules/2.2.12-20/pcmcia/airo_cs.o" Dec 19 22:04:55 localhost cardmgr[393]: modprobe exited with status 1 Dec 19 22:04:56 localhost cardmgr[393]: get dev info on socket 0 failed: Resource temporarily unavailable also, the /proc system doesn't contain an aironet directory. Thanks, Sam |
From: Bernard V. (D. O. Ltd) <be...@di...> - 1999-12-19 10:48:35
|
Hi, Is anybody experienced problem like this with the 4800 PCI card. I just downloaded airo.c last week, so I guess it is the latest version. When insmod and IPConfig the pc/card will work for a minute or two then he pc will lock up. I have a feeling it could eb a problem with this particular "old" pc , but would like your opinion before trying with another hardware, or ? Any idea. Bernard Varaine Digital Objects Ltd Phone:+64 25 2777 843 152 Lone Kauri Road Fax : +64 9 8128 368 Karekare www.digitalobjects.co.nz Auckland, New Zealand -- Thawte web of Trust Notary ( http://www.thawte.com )-- |
From: <br...@al...> - 1999-12-19 07:25:32
|
It seems that an effort to secure some of the mailing lists were a bit too over reaching and most of the world (not me) was cut off from the archives. That has been fixed and the aironet mail list archive should be available again. Sorry about the inconvenience. ben |
From: <br...@al...> - 1999-12-18 23:10:30
|
The web site http://www.cse.ucsc.edu/~breed/airo.html now has a new version of the driver: 0.98sa. There are now two new files in the /proc/aironet directory that contain statistics from the card. (They are tersely explained in the readme.) BTW, I would really like to work with someone who has a big endian linux machine to get the driver "bigendian compliant". Any volunteers? thanx ben |
From: <br...@al...> - 1999-12-17 15:37:52
|
1) This is definately a FAQ. The thing everyone misses (including me) is that in adhoc mode the SSID must be set and must be the same between the machines running in adhoc mode. 2) I'm not that familiar with 802.11. Basically I have been putting parameters in as people have asked for them, and sometimes the ranges are under specified. Could someone in the know comment on these? 3) Aironet had 11Mbs before anything was standardized. Their original modulation was "mok" and now that the draft(?) is out they also support cck. That is why you can choose either. 4) You get the transmit status in the interrupt handler. If the transmit header isn't in there already, I will put a structure in so that you can see it. Actually, I have been thinking of a nice way to expose the exhaustive list of statistics in the card. Hopefully I can get something in this weekend. 5) If all the transmit buffers in the card are full, the packet is dropped (and the dropped packet count gets incremented). Hope this helps. ben Jean-Pierre Ebert <eb...@ee...>@csl.cse.ucsc.edu on 12/17/99 04:46:07 AM Sent by: air...@cs... To: ai...@cs... cc: Subject: [Aironet] My subscription: Some questions to start with ... Hello everybody, I subscribed to this mailing list because - I use the Aironet PC4800 system (11 MBit/s), - I'm running linux (SuSE6.2), - I will try to contribute some improvements of the driver, and - elaborate a bit more on the performance of this type of WLANs (Direct Sequence Spread Spectrum and the used MAC protocol). I start with installation of the driver and testing it (Dec.99 version of the driver and PCMCIAcard services version 3.1.6). This went fine so far. Up to now I spent two hours to understand the device driver. At the moment this looks a bit mystic (I have to admit, that this is my very first contact with kernel programming). To get into the stuff and make it more usable for me some questions (and hopfully some answer from you). 1. Did anyone tried the ad-hoc operation mode? I configured it changing the *Mode* entry in the in the /proc/aironet/eth0/Config file to *adhoc*. But I could not communicate to any other in the same way configured laptop. Did I miss something? 2. There are to controable Paramters (LongRetryLimit, ShortRetryLimit) in the /proc/aironet/eth0/Config file. From the IEEE 802.11 standard Specification is looked up, that these paramters describe the maximum retry number for short MAC packtes and long MAC packets. The values of these paramters my range from 1 to 255. - I could not find any paramter to control differentiation between long and short packets. Does anybody know what the default assumption is (e.g. all packets < 300 Byte are short packets)? Or is this paramter coupled to the RTS-Threshold? - For measurement reason I would like to switch of retransmissions completely. That is to say, a packet is only transmitted once and if there was a transmission error, the packet won't be resent. This is left to the higher layer protocols. Then I set LongRetryLimit or ShortRetryLimit to the value 0, the Config file entries are reseted to the value 16. The value 1 is the smallest value I can use. The device driver indicates that the value 0 should not be a problem, so I guess that the entries are somehow reset by the PCMCIA-Card default entries. My questions are: Is there a workaround for that (set value to zero)? What is the semantic of the LongRetryLimit, ShortRetryLimit variables. Does the value 1 means that the first send operation of a packet is already counted as retransmission or only packet send retries are counted as retransmissions? What is the smallest supported retry count of the Aironet NIC at all? 3. What does *mok* means as the modulation scheme for higher transmission rates? As I understand from the IEEE802.11b standard spec. *cck* (Complementary Code Keying) is the standard conform modulation scheme for high bit rates. 4. Can anybody point me to the right piece of code in the driver, there the MAC packets are physically transmitted and there I can obtain the status of the sent process (e.g. successful packet transmission, successful packet transmission with x retries, unsuccessful tranmission) 5. The 5th and last question, regarding buffer management. As I understand Linux there is a global packet queue (e.g. IP queue) from which the packets are distributed to the device queues (e.g. aironet). Could it happen, that a packet in the device queue will be overriden by a packet from the global queue, because the device buffer is already full. Is there another possibility there packets can be lost because of the buffer management? A stop for now. I apologies for the naiv questions in advance (remember I'm novice in kernel programming). Would be good to get your feedbacks. Thank you. Cheers, Jean-Pierre _______________________________________________ Aironet mailing list - Ai...@cs... http://csl.cse.ucsc.edu/mailman/listinfo/aironet |
From: Jean-Pierre E. <eb...@ee...> - 1999-12-17 12:46:15
|
Hello everybody, I subscribed to this mailing list because - I use the Aironet PC4800 system (11 MBit/s), - I'm running linux (SuSE6.2), - I will try to contribute some improvements of the driver, and - elaborate a bit more on the performance of this type of WLANs (Direct Sequence Spread Spectrum and the used MAC protocol). I start with installation of the driver and testing it (Dec.99 version of the driver and PCMCIAcard services version 3.1.6). This went fine so far. Up to now I spent two hours to understand the device driver. At the moment this looks a bit mystic (I have to admit, that this is my very first contact with kernel programming). To get into the stuff and make it more usable for me some questions (and hopfully some answer from you). 1. Did anyone tried the ad-hoc operation mode? I configured it changing the *Mode* entry in the in the /proc/aironet/eth0/Config file to *adhoc*. But I could not communicate to any other in the same way configured laptop. Did I miss something? 2. There are to controable Paramters (LongRetryLimit, ShortRetryLimit) in the /proc/aironet/eth0/Config file. From the IEEE 802.11 standard Specification is looked up, that these paramters describe the maximum retry number for short MAC packtes and long MAC packets. The values of these paramters my range from 1 to 255. - I could not find any paramter to control differentiation between long and short packets. Does anybody know what the default assumption is (e.g. all packets < 300 Byte are short packets)? Or is this paramter coupled to the RTS-Threshold? - For measurement reason I would like to switch of retransmissions completely. That is to say, a packet is only transmitted once and if there was a transmission error, the packet won't be resent. This is left to the higher layer protocols. Then I set LongRetryLimit or ShortRetryLimit to the value 0, the Config file entries are reseted to the value 16. The value 1 is the smallest value I can use. The device driver indicates that the value 0 should not be a problem, so I guess that the entries are somehow reset by the PCMCIA-Card default entries. My questions are: Is there a workaround for that (set value to zero)? What is the semantic of the LongRetryLimit, ShortRetryLimit variables. Does the value 1 means that the first send operation of a packet is already counted as retransmission or only packet send retries are counted as retransmissions? What is the smallest supported retry count of the Aironet NIC at all? 3. What does *mok* means as the modulation scheme for higher transmission rates? As I understand from the IEEE802.11b standard spec. *cck* (Complementary Code Keying) is the standard conform modulation scheme for high bit rates. 4. Can anybody point me to the right piece of code in the driver, there the MAC packets are physically transmitted and there I can obtain the status of the sent process (e.g. successful packet transmission, successful packet transmission with x retries, unsuccessful tranmission) 5. The 5th and last question, regarding buffer management. As I understand Linux there is a global packet queue (e.g. IP queue) from which the packets are distributed to the device queues (e.g. aironet). Could it happen, that a packet in the device queue will be overriden by a packet from the global queue, because the device buffer is already full. Is there another possibility there packets can be lost because of the buffer management? A stop for now. I apologies for the naiv questions in advance (remember I'm novice in kernel programming). Would be good to get your feedbacks. Thank you. Cheers, Jean-Pierre |
From: Kunlun Ma <K....@gm...> - 1999-12-17 10:21:34
|
hallo, i am making a experiment, which measure the packeterror during datatransmit with aironet card. I must cancel the retry on the MAC interface, but i can´t edit the `/proc/aironet/ethX/Config´,perhaps i must change something in the driver or kernel. Can you help me? thanks !! bye -- Sent through Global Message Exchange - http://www.gmx.net |
From: <br...@al...> - 1999-12-16 07:52:18
|
There is a bug in version .98pa and .98pb of the driver that causes the kernel to crash when you try to write to the Config file. I have posted .98pc, which fixes it, to the web page. (It may also fix the /proc problem on 2.0 kernels... Let me know.) BTW, I am trying to identify why we can't get to the mailing list archive web page. thanx ben |
From: Rob T. <dp...@vo...> - 1999-12-16 02:16:12
|
Any one know what happened to the archives? Rob... DataPro & Vom.Com http://www.vom.com=20 |
From: Karl M Y. <kmy...@co...> - 1999-12-15 17:13:55
|
6.2 what? |
From: epluck <ep...@ne...> - 1999-12-15 14:08:27
|
Anyone play with the driver on 6.2 yet? I work for the the company that aironet spun off of. But now they are being gobbled up by that little company called cisco. I know some of the top support people and development people here in the area. So I hope to be more of a help then a tax of this list. |