modified wmwave for Aironet driver
Jake Khuon
khuon at NEEBU.Net
Mon Jan 12 18:10:17 PST 2004
When I used to have a laptop with an Orinoco card, one of my most treasured
dockapps was wmwave. Since moving on to a Cisco 350 MPI card, I have hunted
high and low for something similar to no avail. I tried wmWiFi but all it
did was spit out ioctl() failures and I really did prefer the look of
wmwave. So after looking at the differences between the driver header
files, I decided last night to just hack wmwave.
I must admit that I was lazy and didn't bother to formally convert this
port. I just simply hacked the main file. Perhaps when I have more time
I'll clean things up and make it nicer. Of course if someone wants to do
that for me, I'm not going to stop them. |8^) The file can be found at:
http://www.neebu.net/~khuon/codebits/wmwave.c
Here's a summary of the list of changes I made:
[0] I grabbed a copy of the net/wmwave ports and extracted it into /tmp to
do the work while not contaminating my own ports tree.
[a] I just performed a make (not make install) to get the files into
a state for hacking.
[b] After I finished, I renamed wmwave to wmairo and copied it
manually to /usr/local/bin instead of doing a make install. As
I said above, if I happen to find some copious free time, I'll
make this a nice and clean port.
[1] Most of the definitions were similar so I started out doing a global
replace on a lot of variable and structure names.
[2] For some reason the signal cache (ANCACHE) for the aironet drivers never
get properly populated. Either that or I'm interrogating the structure
wrong. However "ancontrol -i an0 -Q" always returns a blank for me.
After playing around with it for a while, I ditched the idea and just
grabbed the information out of the an_ltv_status structure instead.
[a] The signal quality seemed to be reversed. Even ancontrol
reports what I think is opposite. In other words, as I move
closer to the AP, I saw the value of an_cur_signal_quality going
down. I decided to do a quick hack on the value to reverse it.
It now _seems_ correct.
[b] The scaling seemed wrong with the original code. Perhaps it was
correct given values as reported in wi_sigcache. I removed all
the scaling modifiers and the values seem to line up better.
[3] I changed the name of the labels so that they make a little more sense.
[a] The general status label used to show either "Quality" (card
present) or "No Card" (card not available) followed by a
coloured dot to indicate general signal quality (red = bad,
yellow = mediocre, green = good). The actual "Link" bargraph
showed the quality in a more graduated manner.
I decided I could make better use of the label area so I added
some code to display the channel number (an_cur_channel)
instead. It will still display "No Card" when a card can't be
found. My intent was to give me a better sense of which AP I
was associated with. I thought about using the value of
an_ap_name but my experi4ence is that it's unreliable. Many APs
don't have it properly set and actually my config tools for my
APs don't seem to have a way to set them. Additionally, I'm not
sure they're ever transmitted. Then again I'm not an 802.11
guru. I also thought about using the MAC address off the AP but
I didn't think it would fit nicely.
[b] I renamed "Level" to say "Strength" since I'm grabbing the value
of an_normalized_strength and thus seemed to make more sense. I
also fixed scaling.
[c] I left the "Noise" label alone but I'm not sure I'm retrieving
the correct element. I'm looking at an_noise_prev_sec_pc which
should be giving me the noise in percentage but I've never seen
it anything but 1% although every once in a while I will see a
slight flash to around 20% but that may just be an anomaly in
the polling. Perhaps I should try firing up one of my cordless
phones and sticking it next to my laptop. I also added the
ability to report SNR instead of noise. Compile with -DSNR to
enable this.
Well, I think that's about it... I hope it's useful to someone other than me.
--
/*===================[ Jake Khuon <khuon at NEEBU.Net> ]======================+
| Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- |
| for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S |
+=========================================================================*/
More information about the freebsd-mobile
mailing list