Sourcecode Index: v1.0.1, v1.0.2, v1.0.3,
v1.0.4, v1.0.5,
v1.1.0, v2.0.1,
v2.0.2, v2.0.3,
v3.0.1, v3.0.2,
v3.0.3, v3.0.4,
v3.0.5 v.3.0.6 v5.0.1
Archive of Sourcecode: ZIP
file
Generally speaking, MAC controller is a chip, which provide an interface
(Host interface) to the CPU. Those interface includes some registers (command
register, etc), transmit and receiver FIFOs which is accessible by CPU.
CPU can send bytes (words) through the interface to issue a command, set
and clear interrupts , and send data to chip tx buffers, etc. Also, CPU
read the values of registers and know the status of chip, know the interrupt
vector... etc.
Those detail issues shoud be in a technical specification of the chip.
however , currently those important information for developer seems unavailable
for public.
In spite of this adversity, we still get to know a lot form the source code airo.c which is enclosed in the linux-2.4.18 package.
Some Detail Descriptions of how the driver works is listed below
1. Initialize
When a device is to be initialized, a " airo_init_module " is
called. In this function, "init_airo_card" is executed to hook many
functions implemented locally in the driver to the general calls in the
net_device. For example, "airo_start_xmit" is hooked to "hard_start-xmit"
of the device. This ensures that the transimission will be performed according
to the codes of this driver.
2. Transmit
When the system is going to transmit a packet using this device , he will
put the packet data in a "sk_buff" structure. This parameter
and another
parameter "dev", which is a pointer of "net_device" structure,
are passed to the "airo_start_xmit" function to begin a transmit.
When getting access to the skb, the length and other important
information can be obtained . Also, the skb includes a pointer to "dev",
which means
actually, only this parameter is enough! This feature is utilized when
I wrote the function for "airo_delay_xmit", I use only one parameter.
The underlying communication to the chip (mac controller ) is fully
encapsulated in the function "transmit_802_3_packet"
3 Receiver
There are no specific reciver functions. Reception of the packets are
handled in the interruput handler. An interrupt will be generated when
a packet
arrives and the driver program will access interrupt registers to handle
it.
4. Using Timer
A good way to set timers in MAC layer is using kernel timers.
There is a structure of "timer_list". Set the timer with timer.expire
parameter, and using "add_timer " to start the timer. When timer is out,
it will call the function you specified in "timer_list" structuer and the
parameters of the
function is just the "data" , another variable in the structure.
Although it is named a timer_list. I don't use it as a list. I use it
as a single timer. The "data" I specified is the "skb" pointer. So, when
timeout happens, this "skb" will be used for transmitting. Another
way to specify "data" is just use "dev" or "airo_info" structure's pointer,
then everything you need to read or write is handily available, too. Following
is an example of timer, compiled in Linux-2.4.21.
struct airo_info {
|
5. Access private data
The private data in the net_device is very important. it is an airo_info
structure.
If we are design mechanisms to distinguish different flows to different
destinations. This require multiple Queues for one server ( the MAC controller
chip). For this purpose, we have to implement following:
struct * airo info |
The enqueue function and its call
static int enqueue (struct airo_info *priv, struct sk_buff *skb ) |
Dequeue funcuton is also implemented as:
static int dequeue (struct airo_info *priv, char * data) |
typedef struct {
|
typedef struct {
|
When you do "make" and "make install" in the source directory of Linux.
A module ario.o will appear in the /lib/modules/2.4.18/kernel/drivers/net/wireless
directory. And ario_cs.o is the module for cardservice.
Airo module is a loadable module which can be loaded with "insmod" command.
It is Also, this module (airo.o) will be loaded when you insert the
card into PCMCIA slot and will be removed if the card is removed.
struct airo_info *apriv = (struct airo_info *)data; |
Airo.c Difference Between 2.4.17 and 2.4.18-14
The driver program of Cisco Aironet Card for Linux 2.4.18.THe only difference
of this C program from the one in 2.4.17 is that:
it adds function to handling of an wireless tool ioctl. The funciton
is "static int netdev_ethtool_ioctl". Another difference is that in Line
4248-4251
it adds an switch to call this function as below:
case SIOCETHTOOL:
return netdev_ethtool_ioctl(dev, (void *) rq->ifr_data);
Version 1.0.1 ( print RSSI value with "printk")
THis version will include the files to monitor RSSI value by sending N
packers per second.
The monitor program will only be called when "xmit" function is called.
airo.c: from original 2.4.18 version, the only change is to add "printk"
in "xmit" function.
test_tx programming is keeping sending N packets per second. the packet
length is random, and read from the file "rn1.dat".
However, the message contents is filled with 0x7e.
N is taken as an argument from command prompt.
Thus, the test program should be run as:
$test_tx 200
UDP packets are bound to sending to 10.0.0.1:4950. No receiving programming
is running at that IP address.
|
...... /* ZHIBIN WU Mobnets */ |
Version 1.0.2 ( 100ms delay)
--------------------------------------------
Jan.27 version 1.0.2 w
airo.c: from original 2.4.18 version,
in this version, airo.c includes a short delay 100ms based on RSSI value
and packet length. To test this program , test_tx in version 0.0.5 could
be used.
The whole new function "airo_delay_xmit" is a clone of the old function
"airo_start_xmit", because I have to make some changes in the original
old funciton, this new function is only called by the "timer2_function"
This version 1.0.3 differs from the 1.0.2 version only because it's based
on 2.4.17 version of Linux driver program .
airo.c: from original 2.4.17 version,
in this version, airo.c includes a short delay 100ms based on RSSI value
and packet length.
to test this program , test_tx in version 0.0.5 could be used.
The new version 1.0.4 is buffered when RSSI is <=100,
in 1.0.4 only one packet is buffered and send after 100ms
the only difference form 1.0.3 is that a new approach to access for
"skb" is tried and when timer function is called, a message is printed
with "printk"!
The new version 1.0.5 differed from 1.0.4 is that it could buffer up to
10 packets in delay. However, those buffers are not circular buffers,
which means that all the buffered packets will be send after 100ms no
matter what RSSI is.
Until the buffered packets are sent, we cannot buffer new packets.
this version is used for Linux 2.4.17. if some "comment out" are deleted,
then it would also apply for 2.4.18.
In this version 1.1.0
Airo.c is performing an basic scheduling function as discarding long
packets with low RSSI value.
test_ap.c is the Rx program which calculating the channel throughput.
In this version, test_ap program will first send "START" message to
slave node to negotiate with test parameters.
test_fn.c is the Tx program which is running on the slave node who is
sending unidirectional packets.
The slave node is synced with START message and the 1 sec SIGNAL in
this program to ensure the test period is ~60 seconds.
test_rn_gen.c is the C program who is generating random numbers and
store them in a file, because the rand() function in C is requiring that
each random number is produced every second, it is so slow for real-time
purpose, so we'd better have a handy RN table already.
Version 2.0.1
this is an obsolete version
the purpose of this source code "io_test.c" is to see if "ioctl" is
good at handling requests from user-space program to get access to data
structure within the driver. the result is not optimistic, there are many
problems existing.
|
//------------------ CODE ----------------------// |
this version 2.0.2 has nothing to do with 2.0.1
this is an temporary trail version fro know how the driver will be called
if an application send a packet to his own IP address.
The answer is NO. Which means that if the application wants to talk
with the local driver, it must create a packet with destination other
than itself, to let the driver intercept this packets. Otherwise, it has
to call ioctl() to control the driver.
Version 2.0.3 is obsolete.
this airo.c driver program tries to loop back the packets from Tx to
Rx direct by swapping the MAC address of the packet. But it does not work.
This change entails disastrous consequence to the kernel and the system
must reset.
the file is from airo_18. and the modification is to modify Tx and Rx
to adding
RSSI value in the last byte of packets, because both IP and UDP does
not contain any Checksum (except header)
it is feasible for a test program running UDP. UDP does has check sum,
but we can set it to 0x0000,
so, packets are actually modified , but the IP and UDP does not detect
it.
then, our user space program get a chance to see the results. of RSSI
also, Retry_count as Statistics from hardware is also written as the
last second byte in the packet, then user program could see it.
test_tx and test_rx is derived from version 0.0.7
the simple change in test_tx.c is that the packet length is at least
50 bytes.
the change in test_rx.c is that we will record RSSI and RETRY_COUNT
in two files as" rssi.dat" and "collison.dat" to view how it change during
the test.
Version 3.0.2
ZHIBIN WU Apr. 3rd
-----------------------
This version 3.0.2 is going to handle Retry-count based packet delay:
A buffers will be used to buffer up to 100 packets.
packet delay will be handle in the "airo_delay_xmit" function and raw
data will be copied to the buffer.
the buffer is like a link-list, with a head and tail, new packets are
placed in the position tail and when timer is up, packet in the head position
will always be transmitted.
The delay is triggered by the condition:
1. retry_count increase at least 5
2. retry_count increase < 100 ( it is impossible without card error,
however sometime card register provide such weird values)
The same procedure is something link 1.0.5, especially the part handling
the timer2.
When the delay is triggered, there will be some messages appeared in
/var/log/messages, becasue I use printk functions.
ZHIBIN WU MAY 10
Airo.c: This is the final version used for IAB demo.
the idea is still keep two separate queues, and make decision
based on the head of the queue address.
In IAB demo, Netperf is used instead of my own socket test program.
ZHiBIN WU May 19th,2003
3.0.4 is an optimal version than 3.0.3
the codes in function "airo_delay_xmit" are optimized.
3- queues are kept, 2 for major receivers and another queue for all
other and broadcasting packets.
ZHIBIN WU may 28th,
Version 3.0.5 is a final version used for IAB demo.
The bug of abnormal retry_count increase is cleaned in this version
ZHIBIN WU Aug. 2003
Version 3.0.6 uses a generized way to handle multiple queues.
ZHIBIN WU Feb 6, 2004
Version 5.0.1 implements a way to dynamically adjust TX-power of the Cisco
card. The power adjust is controlled by a timer. The code is compiled in Linux
Kernel 2.4.21