Rt2x00Wiki - New pages [en]

AP-mode Howto

Mikko — Sat, 20 Sep 2008 08:32:14 GMT

Summary: minor clarifications

This is a short guide to setting up AP-mode on rt2x00 chips. Note that this '''will not work with Ralink's USB chips''' because we don't know how to get status messages (ACK/FAIL) for sent packets.

This howto is not aimed for beginners.

== Installing needed software ==
First install the stuff you need (may be incomplete, package names are from a debian/ubuntu based system)
* build-essentials git libnl-dev libssl-dev dhcp3-server

== Hostapd ==
Hostapd is a userspace daemon that handles the configuration, association etc for WLAN Access Points.

=== Get the latest version of hostapd ===
* git clone git://w1.fi/srv/git/hostap.git
* cd hostap/hostapd
* cp defconfig .config
* edit .config to CONFIG_DRIVER_NL80211=y and CFLAGS += -I#WHERE YOUR KERNEL HEADERS ARE#
* make

Check that a hostapd binary was created in that directory. It will be used in the final step.

=== edit hostapd.conf ===
* change the ssid to something more fun :)
* set country_code to match your contry
* change hw_mode=g
* set channel to something more suitable

For wpa you also need to change some wpa settings. Here are some examples of settings to change/uncomment:
* wpa=2
* wpa_passphrase=somepassword
* wpa_pairwise=TKIP CCMP

== Configure dhcpd to hand out ip addresses ==
edit /etc/dhcp3/dhcpd.conf to hand out suitable ip addresses. For testing you can for example find the part which corresponds to the one below and uncomment three of the lines.

<pre>
subnet 10.254.239.0 netmask 255.255.255.224 {
range 10.254.239.10 10.254.239.20;
# option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
}
</pre>

== Final steps ==
* disable wireless in network manager
* assign wlan0 an ip address: ifconfig wlan0 10.254.239.1
* run /etc/init.d/dhcp3-server restart
* start hostapd: ./hostapd -dd hostapd.conf

Note, this will not get your clients (machines connecting to your AP) a connection to the internet. After these steps the ap should be visible, clients should be able to connect to it and once connected clients can ping your AP and ssh in to it. Routing the traffic from the AP to eth0 is not configured by the steps above. Feel free to add it if you want.

Test

Serialmonkey — Wed, 20 Aug 2008 16:01:25 GMT

Summary:

Test
2

Todo

Serialmonkey — Sat, 09 Aug 2008 15:10:39 GMT

Summary: /* rt2x00 bugs */

=rt2x00 Master Todo List=

==Support==

* Review contents of wiki (mostly done) (Mikko)
* Automated testing framework (Mark)

==rt2x00 code checklist==
* Make sure sparse is completely happy (make -sj4, make C=1 CF=-D__CHECK_ENDIAN__)
* scripts/checkstack.pl should be happy
* Follow kernel codingstyle rules (80 character limit etc.)

==rt2x00 features==

* Implement rt61pci/rt73usb/rt2800pci/rt2800usb aggregation support
* Implement rt61pci/rt73usb pre-n suppport
* Implement rt61pci HW antenna diversity for RF2529
* Implement ACK handling for rt2500usb/rt73usb/rt2800usb

==rt2x00 bugs==
* Fedora bug: [https://bugzilla.redhat.com/show_bug.cgi?id=426777 426777] rt73usb fails within minutes of connecting
* Fedora bug: [https://bugzilla.redhat.com/show_bug.cgi?id=443203 443203] Fedora rawhide + ralink = slow bit rate
* Fedora bug: [https://bugzilla.redhat.com/show_bug.cgi?id=457441 457441] Wifi connection problem with rt2500pci.
* Kernel bug: [http://bugzilla.kernel.org/show_bug.cgi?id=9273 9273] rt2500pci: low TCP throughput
* Kernel bug: [http://bugzilla.kernel.org/show_bug.cgi?id=10475 10475] rfkill switch doesn't work for rt2500pci
* Kernel bug: [http://bugzilla.kernel.org/show_bug.cgi?id=10754 10754] No Driver for Ralink RT2860 Wireless interface, the source is available on their website
* Kernel bug: [http://bugzilla.kernel.org/show_bug.cgi?id=12006 12006] GN-WMKG PCMCIA card (based on Ralink RT2500) doesn't work
* Kernel bug: [http://bugzilla.kernel.org/show_bug.cgi?id=13009 13009] Very slow download with Ralink rt2400 card and kernel 2.6.27 or newer

Firmware license

Luis — Sat, 05 Apr 2008 09:18:26 GMT

Summary:

This Firmware LICENSE text applies to the following firmware files, required by their respective drivers:

<pre>
rt61:
rt2561.bin
rt2561s.bin
rt2661.bin

rt73:
rt73.bin

future driver rt2800:
rt2860.bin

</pre>

The original "LICENSE.ralink-firmware.txt" can be obtained inside zip files at the following links ([http://www.ralinktech.com.tw/data/RT61_Firmware_V1.2.zip rt61] and [http://www.ralinktech.com.tw/data/RT71W_Firmware_V1.8.zip rt73]).
<br>
<br>
LICENSE.ralink-firmware.txt contents:

----
<pre>
Copyright (c) 2007, Ralink Technology Corporation
All rights reserved.

Redistribution. Redistribution and use in binary form, without
modification, are permitted provided that the following conditions are
met:

* Redistributions must reproduce the above copyright notice and the
following disclaimer in the documentation and/or other materials
provided with the distribution.
* Neither the name of Ralink Technology Corporation nor the names of its
suppliers may be used to endorse or promote products derived from this
software without specific prior written permission.
* No reverse engineering, decompilation, or disassembly of this software
is permitted.

Limited patent license. Ralink Technology Corporation grants a world-wide,
royalty-free, non-exclusive license under patents it now or hereafter
owns or controls to make, have made, use, import, offer to sell and
sell ("Utilize") this software, but solely to the extent that any
such patent is necessary to Utilize the software alone, or in
combination with an operating system licensed under an approved Open
Source license as listed by the Open Source Initiative at
http://opensource.org/licenses. The patent license shall not apply to
any other combinations which include this software. No hardware per
se is licensed hereunder.

DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
</pre>
----

Meetings

Luis — Sun, 07 Oct 2007 11:49:22 GMT

Summary: 2010, december 19 dev meeting

== Developer's meeting - December 19, 2010 ==

Topics discussed were about some of the RFC's Helmut sent to the mailing list.

Comments were made about queues, specially the order which seems to be reversed in some devices, subtle changes in register use.

The infamous MCU problem currently present in some rt2800pci devices was again discussed.

Also some discussion about converting irq to tasklets.

it is all here:

<pre>
<hschaa> JFI: Johannes Stezenbach wrote me a mail yesterday that he cannot participate
<ivd> ok
<ivd> So I guess everybody is here?
<lfcorreia> guess so :) the 'usual suspects'
<hschaa> :)
<ivd> So with which subject shall we begin?
<lfcorreia> we can start with the first one on the topic list
<lfcorreia> Asynchronous tx status handling in rt2800usb.
<hschaa> Fine with me. Although Ivo merged that already , right?
<lfcorreia> (I'm just following the list :))
<ivd> Yeah, I merged it a couple of days ago, I will test it today on my system
<lfcorreia> ok then
<hschaa> yeah, ok, I guess it is a step in the right direction and I think Johannes will further work on improving the tx status reporting in rt2800usb
<ivd> Although there are some parts I still would like to change (especially see if we can share more code with rt2800pci)
<lfcorreia> we can move to the next one on the list, TX queue priorization.- Discuss how the hw handles that on USB and PCI -> differences?
<hschaa> ok, let me quickly summarize what we've got:
<hschaa> the newer ralink devices have multiple tx queues (one per AC and two more for MGMT and HCCA)
<hschaa> the channel access parameters (like cwmin, aifs ...) can be configured (only for the AC queues) with specific registers
<hschaa> WMM_* or something
<hschaa> however, as we heard (and as far as I understood) from Jay there seems to be a static priorization of the DMA queues
<hschaa> and that priorization is inverted to how we currently use the queues
<ivd> But only for USB
<ivd> Or are also the QUEUE0, QUEUE1 registers inversed?
<ivd> (As far as I understood, we have only inverted the urbs)
<hschaa> to be honest, I'm not sure :(
<ivd> And even then it is still unclear if the same inversion is present in RT73usb
<hschaa> right
<hschaa> The info from ralink regarding the PCI devices was a bit less informative then the answer about rt2800usb
<hschaa> on rt2800usb we know for sure that we have an inversion somehow
<hschaa> on rt2800pci we are not sure (or are you sure? ;) )
<ivd> true
<hschaa> and on older devices we don't know either
<ivd> Perhaps we should just synchronize the code with the legacy driver, and assume rt73usb and rt2800usb assign the same endpoints to the queues
<hschaa> does inverting the enpoints mean we will still use the mac80211 queue ids but just send it to a different endpoint?
<ivd> yes, because the QID from mac80211, is never passed as-value to a register. So we don't need any mapping on that
<hschaa> let me have a quick look ...
* Jusic (~email@dslb-088-077-204-064.pools.arcor-ip.net) has joined #rt2x00
<hschaa> on PCI devices how does the hw know which DMA queue is used for which AC?
<ivd> Because of the queues with AIFSN configuration?
<hschaa> if that's the case everything should be fine on rt2800pci
<ivd> yeah, but what is the assignment in the legacy driver? is QUEUE there BE, BK, or VO?
<hschaa> Did you mean QUEUE==QSEL?
<ivd> Is that a register?
<hschaa> no, part of the TXD
<hschaa> for the "second stage scheduler"
<ivd> hmm, and let me guess we are sending the QID to that?
<ivd> So that means we do need some mapping... :(
<hschaa> nope, we always use QSEL:2
<hschaa> and that should be fine (at least for now)
<ivd> ah right. But QSEL 2 means EDCA.
<hschaa> yep
<ivd> So indeed, we don't need anything on that
<hschaa> ok, only the endpoint inversion on USB
<hschaa> btw. here's what jay wrote about the DMA queues on rt2800pci:
<hschaa> "yes, scheduler will refer WMM_&_CFG in SCH/DMA register to decide next frame "
<hschaa> so, if at least seems to have no static priorization but uses the configured aifsn, cwmin ... values
<hschaa> Anyone plans to make use of the MGMT queue somewhen?
<ivd> No we can't make use of the MGMT queue.
<gwingerde> Wouldn't that require support from mac80211?
<ivd> we shouldn't filter out MGMT frames from mac80211, and neither can we add the queue to mac80211 due to the hardlimit of 4 queues
<hschaa> Yeah, if would require work in mac80211
<ivd> and I am not sure if Johannes Berg would agree on such a special queue
<gwingerde> Do we know if other HW has such special MGMT queues as well?
<hschaa> not sure if other devices have similar queues?
<hschaa> we could send a mail to linux-wireless and just ask :)
<ivd> Ok, perhaps he changed his mind, because I asked it a couple of years ago as well :P
<hschaa> aha, ok
<gwingerde> I guess the alternative is to check the incoming TX frames to see if they are mgmt frames, and then send them on the MGMT queue.
<ivd> Anyway, for USB, does it mean that endpoint0, is attached to QUEUE0 registers?
<gwingerde> Not sure if that breaks things, though.
<hschaa> we've discussed that on the mailing list but that could reorder tx status reports
<ivd> no that should not be done, we did that in the past, and Johannes requested that to be removed
<hschaa> (since the MGMT queue has a higher prio)
<gwingerde> OK. Didn't know the past of this ;-)
<hschaa> If enpoint0 is attached to QUEUE0 registers, no idea, sorry
<hschaa> I've just got one possible use case for the MGMT queue:
<ivd> Well for safety I will just reorder those registers as well to be in sync with legacy
<hschaa> ok
<hschaa> on PCI devices we've got a TBTT interrupt that gets issues when the beacon is sent out
<hschaa> and during TBTT processing we should send out all buffered multi- and broadcast frames (if DTIM == 0)
<hschaa> and 802.11-2007 tells us that there should be no unicast (data?) frame between the beacon and the buffered frames
<hschaa> at the moment, that could happen because there might still be some frames in the queue after the beacon was sent out
<hschaa> but if we put the buffered frames into the MGMT queue they should get sent out before the AC* queues get transmited, right?
<hschaa> (that's still racy due to the hw design relying on the interrupt processing but it might improve things)
<ivd> Doesn't mac80211 call flush()?
<ivd> And does the MGMT queue guarentee the TX status register to be filled?
<hschaa> nope, mac80211 doesn't interfere with beacon handling at all
<hschaa> not sure if the MGMT queue will issue proper status reports
<hschaa> anyway, that was just a quick idea
<hschaa> (and I'm not even sure if it is really that important)
<ivd> ok
<lfcorreia> diverting a bit from the current topic
<lfcorreia> phy0 -> rt2800pci_mcu_status: Error - MCU request failed
<lfcorreia> does any of you with rt2800pci devices also get this error while loading the driver?
<gwingerde> On some of my devices. However, I do believe I know where this one comes from.
<gwingerde> It is the policy on rt2800pci to always first issue a SLEEP MCU command before sending the WAKEUP command.
<gwingerde> in rt2800pci_set_state.
<lfcorreia> on recent rt2x00 git kernel, the device seems to work fine, although I think it will never sleep or use otherwise the powersaving functions
<gwingerde> I had it confirmed a long time ago if that SLEEP was not done than that MCU error doesn't occur.
<gwingerde> However, I do not know why we are always issueing a SLEEP, so I have refrained from sending in a patch.
<gwingerde> Ivo, do you know why we do wake-up this way?
<hschaa> hmm, what are the legacy drivers doing?
<lfcorreia> well yes, but this really happens right after the firmware is loaded into the device
<lfcorreia> so, if the MCU is not working, it won't accept any commands IMHO
<ivd> I think this code is synchronized with the legacy driver, which contains the comment that WAKUP is only valid after the SLEEP command
<gwingerde> Hmmm, I think this was only at start-up, but I'll check that. If I find something then I'll send a patch.
<gwingerde> The other thing is that we don't wait for the MCU status after the SLEEP command, while we do for the WAKEUP command. Should we also wait for the SLEEP command?>
<ivd> Not sure, perhaps we should, but I can't recall if legacy driver did it as well
<gwingerde> OK. I'll check that as well.
<lfcorreia> AFAIR, we replicate all processes from the legacy code
<gwingerde> And the legacy drivers have changed quite a bit since their first releases, so it doesn't harm to re-check.
<hschaa> yep, makes sense
<lfcorreia> I specifically analised the first rt2800 legacy code and compared it with ours
<lfcorreia> but that might need to be done again :)
<gwingerde> Yeah, will do that ;-)
<hschaa> ok, let's move on?
<lfcorreia> sure
<hschaa> Further optimization of hotpaths (RX/TX)
<hschaa> I don't know why but rt2x00+mac80211 seems to have quite some more overhead then the legacy drivers
<hschaa> so, I thought about ways to improve the hotpaths in rt2x00
<gwingerde> Do we know where this overhead is?
<hschaa> Nope, I was unable to get profiling to work on the ralink soc
<hschaa> However, we are doing quite some unnecessary work in rt2x00
<hschaa> for example, the tx descriptor contains values for all ralink devices
<hschaa> example:
<hschaa> length_high and length_low are set for every device but only a few need them
<ivd> But how can we cleanly optimize that?
<hschaa> hehe, no comes the fun part :)
<hschaa> I thought about removing the biggest parts of the tx descriptor
<hschaa> rt2x00queue_create_tx_descriptor_plcp fills in the plcp values into the tx descriptor
* Ju5ic (~email@dslb-088-077-204-064.pools.arcor-ip.net) has joined #rt2x00
<hschaa> but when we remove all plcp related values from the descriptor
<hschaa> we could simply add a call to rt2x00queue_create_tx_descriptor_plcp from the individual drivers write_tx_desc callbacks
<hschaa> so, in short, remove most values in the tx descriptor and provide the drivers functions to retrieve these values
<ivd> I think there is an old TODO for mac80211 that this is moved to mac80211
<hschaa> the plcp stuff
<ivd> yeah
<hschaa> but of course, there are other fields like all the ht related stuff that isn't needed on legacy devices
<hschaa> but if you want to run rt61 and rt2800 with the same kernel the ht fields are also filled in for rt61
<hschaa> does that approach sound somehow reasonable?
<ivd> Perhaps we should have the drivers indicate which TX descriptor stuff they want during init. Then we still have a simple write_tx_descriptor function in the drivers
<gwingerde> From my side it does, in one form or the other, but to be honest, I don't feel that these things are major overhead generators.
<hschaa> ivd: that would mean introducing quite a number of new flags, don't think I like that ...
<hschaa> gwingerde: I don't expect to gain much from it but on these slow embedded machines every cycle counts
<gwingerde> True, I guess I'm quite spoiled running on high-end Intel x86_64 HW :-)
<hschaa> yep :) a 380Mhz MIPS CPU is really slow
<hschaa> ivd: if we just replace every (set of) fields in the tx descirptor with a corresponding function that shoul leave the write_tx_desc callback quite simple
<hschaa> something like
<hschaa> rt2x00_set_field32(&word, TXWI_W1_BW_WIN_SIZE, txdesc->ba_size);
<hschaa> would become
<hschaa> rt2x00_set_field32(&word, TXWI_W1_BW_WIN_SIZE, rt2x00_txdesc_get_ba_size(xxx));
<ivd> That won't work for most fields, since a lot of values can only be determined in groups
<ivd> e.g. PLCP cannot be done individually
<hschaa> ok, but that could do something like:
<ivd> And you can reduce the number of if-statements in other cases by getting the values in a group
<hschaa> rt2x00_txdesc_get_plcp(plcp_settings)
<hschaa> rt2x00_set_field32(&word, plcp1, xx)
<hschaa> rt2x00_set_field32(&word, plcp2, xx)
<hschaa> of course we need to review which fields need to be grouped together
<ivd> I guess most stuff which are currently already in different functions
<gwingerde> What is your end-goal here? Complete removal of the pre-processing and struct txentry_desc?
<gwingerde> And only do "on-demand" processing?
<hschaa> Not the complete removal, but to only keep data in txentry_desc that is used by every driver
<hschaa> and all the hw specific stuff would be generated on-demand, yes
<gwingerde> Maybe it would be good if you can provide an overview of what it is that you would keep, and what would go "on-demand".
<hschaa> ok, I'm going to do a more deep review and come up with a list of possible changes?
<gwingerde> Sounds good.
<lfcorreia> btw
<hschaa> ok, and one more thing regarding the rx descriptor
<lfcorreia> trading the large descriptor for functions, won't that be an overhead as well?
<lfcorreia> copy large chunks of memory vs more calls?
<hschaa> yes, it would but if they are just inlined functions (or maybe macros) that life in rt2x00queue.h
<lfcorreia> ah, ok then
<gwingerde> I guess we should prefer in-line functions over macros, but yes, making them inline would reduce the overhead of function calls.
<hschaa> at the moment drivers are calling rt2x00lib_rxdone and that in turn calls back into the drivers with fill_rxdone
<hschaa> wouldn't it be possible to already pass the rxdesc to rt2x00lib_rxdone?
<ivd> Don't think so, or at least not without moving a lot of logic back into the drivers again
<gwingerde> Maybe, however, please note that the rxdone functions are currently called from the generic pci and usb code, not from the drivers themselves.
<hschaa> right
* yanook (~yanook@58.211.96.179) has joined #rt2x00
<hschaa> ok, I'll try to first come up with some stuff regarding the tx desc and if we agree on one of the possible alternatives I can look into the tx handling as well :)
<lfcorreia> moving on?
<hschaa> sure
<lfcorreia> Remaining questions regarding the tasklet conversion of PCI drivers
<gwingerde> Before we go into the details, can someone explain what it is that we are trying to achieve with using tasklets?
<hschaa> ok
<gwingerde> (sorry couldn't keep up with all the discussions on the mailing-list).
<hschaa> before the irq thread conversion rt2x00 handled all interrupts in hard irq context
<hschaa> I've introduced the irq thread mainly to periodically update the beacon (in AP and mesh mode for example)
<hschaa> this is required to get the correct DTIM count from mac80211 and to sent out buffered multi-and broadcast traffic after the beacon
<hschaa> since the beacon update code is/was mutex protected I thought the interrupt thread is a good idea sind it runs in process context
<hschaa> b43 already handled its interrupts in that way
<hschaa> the hard irq handler reads which interrupts triggerd and schedules the irq thread but keeps all interrupts masked out
<hschaa> the interrupt thread processes all interrupts and unmasks the interrupts again
<hschaa> on reasonable fast machines that works just fine
<hschaa> but again on the SoC devices
<hschaa> the rx and tx processing (when pushing a lot of traffic) caused for example a TBTT interrupt to get lost because the rx/tx processing took too long
<hschaa> the legacy drivers do the following:
<hschaa> the hard irq handler checks which interrupt triggerd and only masks out exactly these interrupts and schedules a tasklet for the according interrupt
<hschaa> the tasklet after processing reenabled the irq in the device
<hschaa> so, for example during rx processing only the rx irq is disabled
<hschaa> but the others can still happen
<hschaa> so, the goal is to process each interrupt individually while the other interrupts are still enabled
<hschaa> such that rx processing cannot block other interrupts
<gwingerde> OK. And I guess this requires tasklets, as otherwise the other interrupts can happen without being able to handle them as the thread is still busy?
<hschaa> exactly ;) and there is no way to have multiple irq threads (at least not yet)
<gwingerde> OK. Got it.
<hschaa> Any remaining questions :P ?
<gwingerde> Not from my side.
<ivd> Neither from here
<hschaa> My current RFC series works quite well for me but I'm unable to test older devices :(
<hschaa> So, I hope to get the conversion right on these as well
<hschaa> k, let's move on
<ivd> btw helmut
<ivd> when you refactor your patches, yout could perhaps move the patches which you think can be merged early to the start of the series. Then we can review and apply them before the rest of the series (if the rest is not ready yet)
<hschaa> makes sense, yes, however, Gertjan already obsoleted one of the patches ;)
<ivd> yeah, I know :P
<ivd> But that was one of the patches which could have been applied before the rest of the series ;)
<hschaa> right
<hschaa> ok, I'll move the patches in a more clever order for the next iteration
<ivd> ok thanks
<gwingerde> Maybe send the intf locking patches as a separate batch, as they seem to be quite independent.
<hschaa> yep, they are independent, I just had them pending in my tree on top of the others
<gwingerde> So, I guess these could even go in right now, as they don't have to depend on the tasklet conversion.
<hschaa> correct
<ivd> right
<hschaa> How to avoid start- and stop queue locking for the beacon queue
<ivd> What was the exact problem with the locking?
<hschaa> None yet ;)
<hschaa> But the beaconing updates I've made for the PCI devices
<hschaa> update the beacon from within a tasklet
<hschaa> that's alright since I've made sure that that's the only beacon update point for PCI devices
<hschaa> => no locking needed
<ivd> but they do start_queue and stop_queue in there?
<hschaa> Nope :)
<ivd> Then no locking is happening right?
<hschaa> Yep, but that is fine because stop_queue will wait for the beacon_tasklet to finish
<hschaa> But ...
<hschaa> Johannes pointed out that the code in the drivers write_beacon callback could be simplified if rt2x00queue
<hschaa> if rt2x00queue would stop the beacon queue before the beacon update and start if afterwards again
<ivd> ok, but what if we make it use pause_queue and unpause queue then?
<hschaa> and this start and stop is not possible right now from within the periodic beacon update (tasklet -> atomic context)
<hschaa> hmm
<hschaa> pause_queue does nothing on the beacon queue right now?
<ivd> at the moment not
<ivd> But the entire queue refactoring was never focussed on the Beacon queue ;()
<ivd> ;)
<hschaa> might be a good idea
<hschaa> I'll check that
<hschaa> but currently the definition of pause/unpause-queue is to stop the queue in mac80211 ;)
<hschaa> and if it would do something different for the beacon queues that could be confusing
<ivd> true, or we move the register changes into a function and simply call those from the driver callback function, that way rt2x00lib doesn
<ivd> 't need to do anything
<hschaa> yeah, I guess that's ok for now
<hschaa> I mean, it is really just setting a bit in the beaconing register, updating the beacon and resetting the bit again
<ivd> right
<hschaa> ok
<hschaa> Last topic, from my point of view at least :)
<hschaa> Pushing functionality down into drivers to allow easier modification
<hschaa> of newer drivers without affecting older ones?
<hschaa> We had at least one case where rt2800 behaved differently then older drivers and while fixing the bssid-register setup on rt2800 we broke the older devices
<hschaa> At the moment, we have to be very careful when changing core code logic
<hschaa> to not break older known-good devices
<ivd> True, but we can't really escape that without duplicating code by moving code to the registers
<hschaa> Yeah, that's why I wanted to discuss what we could do to mitigate these problems
<hschaa> I mean, most core code is hw independant, and thus fine
<hschaa> but some parts of the core code seem to depend on device specific behavior
<hschaa> (as we had with the bssid register setup, and no I don't have another example :P )
<gwingerde> Guys, sorry to break in, but unfortunately I have to go now. I'll check the log later for the remaining discussions.
<ivd> ok
<hschaa> ok, have nice day
* gwingerde has quit (Remote host closed the connection)
<hschaa> hmm, have _a_ nice day sounds more correct
<ivd> hehe
<hschaa> Any good ideas how we can ensure that core code changes don't break older devices?
<ivd> no, because it is very unclear when some action is device specific or not. I mean the BSSID thing worked for 5 devices, and only in the latest device they changed something quite subtle
<hschaa> yep, unfortunatley
<ivd> The code which was in rt2x00lib wasn't even obviously broken, since it was logical to do it that way
<hschaa> right
<ivd> SO we can't really resolve the issues in advance I'm afraid
<ivd> I mean, the next time something in the TX descriptor handling can change... SO how could we anticipate that?
<hschaa> ok, and I guess nobody has the time to always run regression tests with the older devices
<hschaa> at least I don't
<lfcorreia> and at the moment, neither can I
<ivd> nope, I have a setup to test rt61pci and rt2500pci, but I focus so much on rt2800usb nowadays, that the PCI drivers are tested too little
<lfcorreia> maybe at the end of this first semester, some time next February I can do something
<hschaa> ok, so let's just hope that we've got enough users to notice bugs as soon as possible
<hschaa> oh, and to report them as well
<lfcorreia> I can always test my rt2800pci, as it sits on my machine
<hschaa> same for me, rt2800pci is well tested from my side
<hschaa> ok, do we have anything else to discuss?
<lfcorreia> yes, but my rt2800pci is a true PCI card, not the SoC
<hschaa> right, that makes a difference sometimes
<lfcorreia> the MCU thing is a good example
<lfcorreia> and btw, as a good joke
<lfcorreia> my last patch sent to the kernel was April first :)
<ivd> hehe
<hschaa> hehe
<hschaa> so, are we done? Anything else?
<lfcorreia> from my side, yes
<ivd> I don't think so
<hschaa> Nice, so we can finally have lunch ;)
<ivd> helmut do you need a review on the RFC you send this week, or did you want to send an updated series today?
<lfcorreia> so, no objections to declare this meeting done?
<hschaa> I don't have any changes in the series yet, so if you've got some times left a quick review would be nice, ye
<hschaa> s
<ivd> ok. :)
<hschaa> thanks
<ivd> Well then the meeting is over I guess. :)
<ivd> Have a nice day guys
<hschaa> yep, cya in a while
<lfcorreia> have a nice day, guys!
</pre>

== Developer's meeting - August 9, 2008 ==

Topics discussed were mainly about our recent request that Ralink should stop to provide the legacy drivers and work full time on rt2x00.

It then evolved into getting some payment from Ralink for our work in building and supporting the drivers (things we now do for free).

More documentation, better code examples and stop backporting the windows driver to Linux.

A forum overhaul was decided, with mostly some name changes.

Meanwhile, the [[Todo]] page was created, with recent topics, known bugs and such.

The meeting full log follows:

----
<pre>
<ivd> Ok: Is my understanding correct that outgoing frames have both the IV data inside the TXD descriptor as well as inside the frame?
<lfcorreia> hi all, sorry for being late :)
<ivd> When I follow the TX path, it almost looks like it generates the IV/EIV into the TXD and copies it into the frame as well
* lfcorreia has changed the topic to: rt2x00 developers meeting, right now :)
<ivd> lfcorreia: Late? half hour early :P
<gwingerde> Luis, I guess you're early, as 15:00 GMT is not for another 45 minutes
<gwingerde> (GMT doesn't have summer time)
<lfcorreia> eheh, then it's my timezone misunderstanding
<lfcorreia> as always
<lfcorreia> never mind then
<ivd> There are a lot of early birds today, Mark made a miscalculation, hence his reason for being an hour early as well. :P
* lfcorreia has changed the topic to: rt2x00 developers meeting, starting soon
<ivd> But he is off for coffee to stay awake. ;)
<lfcorreia> ivd, lol, as always, being an aussie has its perks :)=
<gwingerde> Ivo, give me some time to check your question out. Don't know the answer without looking at the code ;-)
<ivd> :)
<ivd> Don't worry, even if the IV is copied into the frame, more questions are standing by, since I still can't get HW crypto going on rt2500usb. And I did try the IV included and excluded from the frame. ;)
<gwingerde> OK. I'll check it out anyway.
<ivd> thanks
<lfcorreia> ivd: can you summarise a quick order of business for today, or we'll just talk?
<ivd> lfcorreia did you make those debugfs dumps with encryption enabled in rt2570/rt2500usb?
<ivd> lfcorreia: Mark had set some points he wanted to discuss. They are mostly summing up what issues there are at the moment, which should get some attention, and where he can start focussing on.
<lfcorreia> actually, no. I was unable to connect with WEP using the legacy driver. it's probably an AP issue, but i was unable to dedicate more time to it
<lfcorreia> ivd, ok, i'll wait for Mark to return
<ivd> ok, alternatively you could try TKIP, that would normally be step 2 but it could at least uncover some general register problems with HW crypto
<ivd> (but WEP has preference since it is the most simple form of encryption)
<lfcorreia> let me try that again now
<ivd> thanks
<gwingerde> ivd: I think you're right in the legacy rt2570 driver, it is both setting the IV and EIV in the TXD and the output buffer.
<ivd> Hmm, thats odd, because it seems they are adding the IV length to the TXLength twice
<gwingerde> yes, and there are comments as well stating that the ASIC adds IV/EIV to the frame as well. Really odd.
<ivd> Perhaps it is overriding it. That the hardware isn't doing the exact same as rt61pci and rt73usb, and that the data they add to the frame is required to make room for the IV/EIV
<ivd> Something like: driver makes room for IV/EIV manually to let HW copy it into that room later.
<ivd> Which is kind of stupid.
<ivd> But somehow expected from rt2570 which is a slighly buggy chipset
<gwingerde> That's what I was thinking as well.
<gwingerde> Wrt the TXLength, I don't think there is an issue there, as they seem to recalculate the frame size after they have copied all data.
<ivd> Yes, but what length to they send to the TX descriptor?
<ivd> Is that a length which includes the IV length twice?
<gwingerde> Not that I can see. It the size they calculate after all the copying, and only contains the IV/EIV length once.
<ivd> ALthough I do believe to have tested with a loop adding 0 to 50 bytes to the length to see when it would start out to send out frames.
<ivd> hmm ok, so they are doing that right.,
<ivd> I must be missing something else then.. :S
<ivd> Too bad the USB drivers don't have a true TXdone reporting. That made things so much easier for rt61pci HW crypto :S
<lfcorreia> be back in ten minutes
<gwingerde> Yeah. I guess that also has something to do with USB. It's somewhat harder to have the status returned to the host from the USB device.
<ivd> All that I am seeing now is a blinking TX activity led that tells the device is apparently trying to transmit something, but nothing appears in wireshark.
<ivd> yeah, that is definately something the ratecontrol module of mac80211 enjoys. ;)
<gwingerde> Hmmm, and our debugfs queue does show the frame?
<ivd> Yes, the frames are being uploaded successfully. Hence the reason the TX led blinks as well.
<gwingerde> True.
<ivd> But wireshark on another system doesn't detect any of the frames.
<gwingerde> Hmm. One of the problems can be that by default our drivers disable reception of "ToDS" frames. Maybe you can turn that on to see what the rt2570 sends to the AP?
<ivd> The ToDS filter is automatically enabled by mac80211 when running in monitor mode.
<ivd> The wireshark + rt61pci interface I use for monitoring is working since I had used it when debugging rt61pci and rt73usb HW crypto.
<ivd> And I can see Assoc + Auth requests coming from the rt2500usb device.
<gwingerde> Really? I thought I needed to patch that when I was testing the PCI mapping patches I did.
<gwingerde> Guess I was wrong at the time
* bbatten (n=chatzill@adsl-71-154-211-29.dsl.sndg02.sbcglobal.net) has joined #rt2x00
<ivd> Well I don't know about all drivers, but at least rt61pci seems to work well in monitor mode.
<ivd> It previously had some quirks when returning from monitor mode to managed mode, but those have been fixes
<gwingerde> OK. Maybe I was handling it differently at the time (I wasn't really using wireshark at the time).
<ivd> ah, that might be it, wiresharks enables promisc mode and mac80211 will convert that into the correct fitlers
<ivd> \filters
<ivd> And rt2x00 will listen exactly to those filters
<gwingerde> Yep, i'll remember that for next time.
<serialmonkey> Ugh, I'm regretting suggesting a 1am meeting in winter at the moment :-)
<ivd> Hehe :P
<bbatten> You're a brute for punishment, Mark
<ivd> Shall we trade the Dutch summer for you Winter :P
<serialmonkey> I'm the odd-one-out timezone wise so you think I would be used to it
<serialmonkey> hehe
<ivd> Not sure where the temperature would be higher :P
<serialmonkey> So, basically, it's been awhile since we all caught up. I thought it would be a good time to discuss where things are at, what the major things on the list are and who we are all currently working on
<serialmonkey> I honestly have not been keeping track of things, and SF seems to be pretty out-of-date as far as 'bugs' and the like
<ivd> Well Bryan seems to have closed some bugs on sf.net recently
* sn9 (n=danielg4@gimpelevich.san-francisco.ca.us) has joined #rt2x00
<ivd> Or at least I saw the counter change a couple of times. ;)
<bbatten> Who all of us "core" developers are still active? Ibrahim, Robin?
<ivd> I usually close rt2x00 items or at least marking those bugs as invalid. ;)
<ivd> Eh, well Ibrahim and Robin are definitely not active.
<serialmonkey> The only people active are those here, minus myself who hasn't been active at all
<bbatten> I think I've marked one bug as fixed, and another was fixed as a side effect.
<ivd> Not sure when they send out their last mail to any rt2x00 mailinglist. ;)
<ivd> Heh, I love bugs that fix themselves ;)
<gwingerde> To be honest, I'm not that active as well (currently quite busy with my job :-()
<ivd> Well I am way behind with rt2800 development, and my takslist for rt2x00 is growing fast. :S
<serialmonkey> Any chance of getting that tasklist published ?
<serialmonkey> then we can add to it from there with other items we are aware of
<ivd> Eh yes that would be a good idea. The list on the wiki is outdated.
<gwingerde> Yes. Maybe we should set up a TODO area on the wiki, so that people can assign themselves to it.
<ivd> Well for rt2x00 we had such a list
<serialmonkey> Absolutely. Lets not just restrict it to dev tasks other - there are things that need addressing regarding doco, support, etc as well
<ivd> http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00_beta
<gwingerde> Yep, it's time to revive it.
<lfcorreia> ... an I'm back
<serialmonkey> Isn't it about time we dropped the 'beta' as well ?
<bbatten> Speaking of dropping beta, would it be a good idea to add additional nextgen sections to the forum for chip-specific drivers?
<lfcorreia> sorry, doze off five more minutes then it was predicted
<ivd> It is about time we dropped that entire page :P
<ivd> As well as the alpha page
<serialmonkey> So, if we had to sum up the rt2x00 drivers in one word, what would it be Ivo ?
<gwingerde> Yep, and in the forum we should rename rt2x00beta to just rt2x00 as well.
<serialmonkey> obviously they are still marked as 'experimental' in the kernel
<ivd> Well the first request to remove the CONFIG_EXPERIMENTAL dependency has been raised already
<serialmonkey> for all chipsets ?
<ivd> That has been rejected by me, mostly because of the different opinions on the meaning of CONFIG_EXPERIMENTAL
<bbatten> I would think dropping "beta" designation and replace testing with per-chpset sections wouild be good.
<ivd> yes
<serialmonkey> OK, I'm going to start the todo wiki page now, and that can be the first item
<ivd> rt2x00 support doesn't need to be split up into different sections yet.
<ivd> But the titles could indeed change
<bbatten> OK. I raise it because I seem to notice more postings having to do with chip- specific impementations, but that could just be me.
<serialmonkey> http://rt2x00.serialmonkey.com/wiki/index.php/Todo
<ivd> yes but the setup of the rt2x00 drivers makes most bugs be common to all chips. ;)
<serialmonkey> OK, I've just listed the item then as rename and re-describe
<bbatten> Your call, obviously.
<serialmonkey> Anything else forum or website related that people have on their minds while we are there ?
<bbatten> Just my perennial favoriet - huge font size.
<lfcorreia> we need to do something about the legacy rt2800 driver
<ivd> Why, we hardly have developers?
<ivd> And unless Bryan wants to maintain 2 more legacy drivers...
<lfcorreia> we would only go as far as setting up the debugfs patches to compare
<bbatten> I don't think there's anything there that's remotely functional?
<lfcorreia> the last time I tried it, it did work, but produced a very large kernel driver
<serialmonkey> That would be something worthwhile passing around the developers, but we wouldn't release it I imagine
<ivd> yes, some patches need to be collected for debugging purposes. But we need to google a bit for patches from other people as well, since there are quite a lot of issues with the driver
<lfcorreia> ivd, at least we would state our position regarding legacy rt2800
<bbatten> To be honest, folks, I'm trying to constrain my involvement here. Two more drivers doesn't sound good.
<gwingerde> Might be difficult to get to know the rt28xx drivers, as they are completely different from the other drivers (due to the 802.11n support)
<lfcorreia> as i've always said we wouldn't support it
<serialmonkey> How about we just update the wiki to post our official call on rt2800 (no legacy, just rt2x00)
<ivd> Well I should still add 802.11n support to rt2x00lib, but like I said I am way behind schedule with the drivers.
<bbatten> Maybe tap Ralink for involvement in the project?
<lfcorreia> as we all know Ralink 'may' be interested in working with us in the future
<gwingerde> Side note: did we get any data sheets of the rt2800 chipsets?
<ivd> I have problems with the TX power, antenna and queue handling.
<ivd> Yes, we have the rt2860 sheets
<gwingerde> Could you send that around? I don't think I have it?
<ivd> but not the rt2870 one, but rt2860==rt2870 without any differences other then different bus
<bbatten> Oh, and did Ralink ever respond about RT2500 ISR masking?
<lfcorreia> which are mostly useless, when making the register definition setup file, i've already spotted differences...
<ivd> gwingerde: send
<ivd> Well I never got the response to that mail (and you were in the CC so you would have gotten it as well)
<lfcorreia> gwingerde, ralink even made some very strange errors in the docs, as usual
<ivd> lfcorreia: but your register headers were bugged as well
<lfcorreia> things like, stuff that should be PCI only and had USB related strings
<ivd> I reverted several things to get it back in line with the legacy driver
<serialmonkey> ivd: how much involvement do you want from us in 11n support - aren't you engaged as part of your coursework for that ?
<ivd> They used the same register file for both drivers :P
<lfcorreia> ivd, sure, it was really my first time at it
<ivd> The entire rt2800 project including 802.11n is coursework. But also the testing documents.
<gwingerde> How much 802.11n support do we need in the driver, as mac80211 already contains support for it?
<ivd> And with current rate I won't be able to finish everything in time I am afraid.
<ivd> Well I am still collecting the pieces I need to get from mac80211. I can't find the way to detect if BW_20 or BW_40 is enabled for example.
<ivd> Also the rates to 108Mbs are a bit unclear.
<ivd> On the other hand, those things should have been in rt61pci and rt73usb as well since those are pre-n devices.
<serialmonkey> I see you have added the feature requests to the TODO page Ivo. Do you have a list of bugs as well ?
<gwingerde> Hmm, maybe the support in mac80211 isn't complete, and only sufficient for the Intel chips.
<ivd> Some of the 802.11n fields are still a bit unclear, since I do get a flag BANDWITH but what it means... :S
<ivd> serialmonkey: buglist is a bit harder, I'll try to think of some main issues and add those later.
<serialmonkey> no worries
<lfcorreia> ivd, yes, we both have a pre-n device which is rt61 based
<lfcorreia> and have different radio chips
<ivd> True, but I have never added support for it. Hopefully it can be added when rt2800 is done
<gwingerde> Hmm, hard to believe that rt61 is pre-n.
<ivd> There are some pre-n versions.
<gwingerde> Although, it might be possible with the right driver.
<lfcorreia> gwingerde, it actually is
<ivd> I got a MIMO card, the legacy driver is a big vague about it hence it was never really implemented. But hopefully with rt2800 I can fill in the missing pieces
<lfcorreia> gwingerde, i never got it working in the past as my device has a dud eeprom
<ivd> Check the rt61 legacy code, they do mention rates up to 108 Mbs
<bbatten> When Ralink says mimo, I'm not always sure whether they're talking diversity, or true mimo - shared data channels.
<gwingerde> OK. I guess I've only seen rt2800 based pre-n devices.
<ivd> lfcorreia: dud eeproms are fixed in rt2x00 it autodetects that and fixes the values. Same as legacy driver
<lfcorreia> gwingerde, but now that I have a 11n AP, it may be possible to test it, as ivd says
<lfcorreia> ivd, yes but remember that it never detected the proper radio chip?
<lfcorreia> it always assumed the default was another
<ivd> lfcorreia: that belongs to the same fix. It now recovers and defaults to the RF chipset defined by Ralink.
<ivd> serialmonkey: Several items on the rt2x00 TODO list aren't hard for coding, but are purely investigation things.
<lfcorreia> ivd, in that case, i'm taking a note to try that one again in the near future
<ivd> serialmonkey: especially the WDS and Mesh modes, since all I need to know is what those modes do and what is required for support and what limitations there are (can they run concurrently with other interfaces)
<serialmonkey> requirements gathering basically
<serialmonkey> ok, assigned
<serialmonkey> ivd: when you go through your notes regarding bugs, do you want to just email them to me and I'll raise them in SF so we can track them ?
<ivd> Well the most important bugs are those raised in the kernel and fedora bugzilla. So they are already tracked. But some of them have pending fixes and are waiting for John to push patches upstream. I'll set some links to the bug reports.
<ivd> (regardless of the state)
* free-zombie is now known as tjol
<serialmonkey> No worries- we don't want to be tracking them in two places. Perhaps we should just try and keep a list of the links in the wiki for reference
<bbatten> Might be good to provide forum members an area to post bugs to, though, and the Sourceforge project seems a good candidate for that.
<ivd> Well they are already free to do so, so far all rt2x00 bugs in sf.net that have been raised were marked as invalid or fixed
<serialmonkey> so, are there any support/documentation tasks that need to be addressed ?
<serialmonkey> for example - I assume the whole wiki needs a review
<bbatten> Silence? Are we going to talk about the Ralink proposal?
<serialmonkey> Has gone abit silent yes. I was impressed with their response
<bbatten> Ivo, could you flesh out goals wrt. Ralink working directly with the rt2x00 project?
<lfcorreia> bbatten, talks have started
<lfcorreia> Ralink is assessing it atm
<ivd> Well what I asked from them is stopping with those Legacy drivers. They should focus directly on the in-kernel rt2x00 drivers expanding rt2x00lib and adding new drivers directly for rt2x00lib.
<ivd> When some protocol things are missing from mac80211 they should implement that
<bbatten> I mean our business goals. e.g. Do we want payment? Do we want their developers on the core team?
<lfcorreia> bbatten, that is a nasty subject, we've discussed it a while ago
<bbatten> Oh? And what did we say?
<ivd> Payment would be very nice. When they are interested in providing the in-kernel drivers directly and thus developing rt2x00lib then perhaps they can be added to the project, but I don't think it would come that far.
<serialmonkey> It just means we will work with them, kind of like Intel works with the wireless developers now
<lfcorreia> bbatten, the talk was done internally between me Mark and Ivo
<ivd> Well my position remains unchanged on the matter: as far as I am concerned Ralink can pay us for the support and work we have on this project.
<lfcorreia> serialmonkey, more like they work with us :)
<serialmonkey> and my position was that it's all too complicated and I didn't mind what you all did :-)
<bbatten> OK. But what do we envisage the nature of their contribution to be? -- and, could you provide a summary of the internal talks you refer to?
<ivd> lfcorreia: Some of it was internal, but that was mostly after contact was made with Ralink about how they felt about it.
<lfcorreia> I don't do that much work as such, and I personally don't want money from Ralink
<lfcorreia> the best think Ralink would do is provide more then just documentation and crappy drivers
<gwingerde> Same here. I would envisage Ralink just donating code to us and to the Linux wireless community.
<serialmonkey> gwingerde: agreed
<lfcorreia> because we don't have any docs from the radio chips (except for the one that comes with rt2400)
<bbatten> That's basically what they do now, isn't it?
<gwingerde> And yes it would be appreciated if they could give us more than just crappy documentation and crappy code.
<gwingerde> bbatten: Nope, I would envisage them contributing actual code to the rt2x00 driver, not a crappy coded own driver.
<lfcorreia> there are a lot of issues from very simple things that if Ralink was present and active, would get proper responses and faster problem solving
<bbatten> Ah. Looks like item one is better documentation from them.
<bbatten> Looks like item two is direct involvement by Ralink staff in RT2x00 project code development.
<ivd> As far as I am concerned better drivers. rt2x00 drivers instead of ported windows drivers.
<lfcorreia> and also engineer support, stuff like 'application notes', that I normally see from other hardware
* tjol is now known as tjol0
<lfcorreia> which translates to, better docs, better code, better examples on how to sort stuff out
<bbatten> Does Ralink have that available to their customers, even? say under NDA?
* tjol0 is now known as freezombie
<ivd> I can live without the documentation, but I can't keep porting their drivers to rt2x00. That is simply taking too much time.
<lfcorreia> bbatten, i know that ralink does sell AP code (crap code) to some major software developers
* freezombie is now known as tjol
<serialmonkey> basically we are asking them to cut their losses, dump the support of the legacy drivers and dump developing any new 'legacy' style drivers - and instead take some stake in the rt2x00 driver
<lfcorreia> the dd-wrt guy got a contract that allowed him to access such code
<ivd> lfcorreia: But that is simply the legacy code with additional tweaks
<serialmonkey> I'm probably going to have to go offline in 10 minutes guys sorry.
<ivd> serialmonkey: ok
<lfcorreia> ivd, kind of, it's actually the AP code Asus leaked out some years ago, things havent' changed much
<ivd> lfcorreia: did ASUS leak the code? I thought they only released the closed source blob?
<bbatten> Basically, I think there needs to be some development of a proposal if Ralink responds further; specifics on what we envisage from them
<lfcorreia> ivd, the code was available in their website for months, but only for their rt2400 card
<ivd> In any case, rt2800 contains master mode support. And I am not impressed by it. Most of the new features in the rt2800 legacy driver have already been brought to all earlier rt2x00 drivers (virtual interfaces, master mode)
<ivd> bbatten: Well that is what I had written in the mail which I had BCC'ed to coredev.
<ivd> serialmonkey: All bugs from kernel.org and fedora are not listed on the todo wiki page
<lfcorreia> ivd, /s/not/now/g/ ??
<serialmonkey> I think us developing a 'proposal' and presenting it to Ralink asking them to comply is going to be way too official, and possibly scare them off. Open Source development is all about community, not proposals
<serialmonkey> ivd: thanks for that
<lfcorreia> serialmonkey, think of it as a co-op instead of a commitment to do stuff
<ivd> well you saw the mail, and they responded that they will investigate it. Next step will be up to them.
<lfcorreia> serialmonkey, phrase it in simple english terms as we don't want to have the language barrier to get in the way
<bbatten> The email is basically a general statement. We need specific bullet items to have in minde in case Ralink responds.
<serialmonkey> Exactly - and hopefully from that they will assign a person to lead their side of the ongoing work and we can 'suggest' to them the steps they should be taking (getting involved in the linux-wireless mailing lists, etc)
<bbatten> ... at least so *we* understand what we want.
<ivd> If I am not mistaken, some other guy with connections to Ralink will recommend them for sttarting to pay us, but I am not sure if he already send out that recommendation or not.
<gwingerde> But what would that mean: "pay us"?
<ivd> bbatten: Well I am not sure what more you want to know, the list of end goals have been given to Ralink. When they are interested we can guide them towards that goal.
<ivd> gwingerde: That they should see if there is any form which they see fit to provide financial backing to this project.
<ivd> gwingerde: He is going to ask that Ralink comes up with an offer for further cooperation between Ralink and this project.
<serialmonkey> Ideally, if they want to follow Intel's example, they may even offer to take ownership (in a responsibility sense) for rt2x00 and that means there will be nothing left for us todo anyway
<ivd> but that will be finally up to Ralink
<serialmonkey> Then they will probably turn around and want to hire Ivo todo the actual work, lol
<bbatten> serial: Great, maybe they'll need our help
<ivd> serialmonkey: that will be the ideal situation, but we end up probably providing support and maintenance of the older drivers.
<ivd> Which is fine, as long as the dreaded "driver porting" is no longer needed.
<bbatten> Basicaly, if they pay the piper, they call the tune.
<lfcorreia> lets wait and see
<serialmonkey> Whatever happens, I would be more comfortable with them coming to arrangement with individuals rather than the "group". "Group" payment introduces all sorts of other issues
<ivd> true
<gwingerde> Yep.
<bbatten> True
<lfcorreia> agree
<serialmonkey> OK, so I ask that everyone adds items to the Todo page now we have it
<gwingerde> And, as I've mentioned before, I'm not in it to get paid. They will never be able to pay be equally as my current job does.
<lfcorreia> I also don't want money, new devices are fine, but that is how fa I would go
<lfcorreia> fa=far
<serialmonkey> lol, paid in hardware ;-)
<ivd> hehe
<bbatten> Although, if we want increased participation from Ralink, we need to understand that that is a cost to them, and think about how to motivate them to pay that cost.
<lfcorreia> serialmonkey, right, at least i can then send the devices to whoever needs them most, like I already did
<serialmonkey> It was good talking to you all again, it's been too long. Can someone post a log to the mailing list when your all done chatting ?
<ivd> Well their drivers would be in the kernel sooner, meaning that general usage of the driver occurs faster. They already agreed that rt2800 usage in Linux is slow because of the lack of in-kernel drivers.
<bbatten> What devices? Oh, and how's the test lab setup dong?
<ivd> serialmonkey: cya
<gwingerde> Guys, I need to sign off soon as well.
<lfcorreia> bbatten, like the rt73 device I sent you
<serialmonkey> bbatten: The server is online with all the hardware installed, I just haven't found a way to automate any tests
<lfcorreia> serialmonkey, bye
<serialmonkey> I'll add it to the todo
<serialmonkey> cyas
* serialmonkey has quit ()
<lfcorreia> gwingerde, nice talking to you again
<ivd> bbatten: Donated hardware is send around to various developers when requested.
<gwingerde> Just one final note from my side: from next week on I will be away for 4 weeks (combined business trip and holidays).
<ivd> bbatten: Usually when we have a lot of hardware a mail is send to coredev to see who wants it.
<ivd> gwingerde: Have fun on your semi-holiday then. ;)
<bbatten> gwingerde: Happy holidays!
<lfcorreia> gwingerde, have fun!
<ivd> Guys, my time is up as well.
<lfcorreia> ok, i'm also going to cut this one short
<ivd> Cya
<bbatten> OK. Looks like we're done. Are we?
<gwingerde> Ciao.
<ivd> Well with everyone leaving. ;)
<bbatten> bye
<lfcorreia> I'll post the developers log in the wiki, as i did in the past
* bbatten (n=chatzill@adsl-71-154-211-29.dsl.sndg02.sbcglobal.net) has left #rt2x00
<ivd> (Y)
* ivd has quit ("using sirc version 2.211+KSIRC/1.3.12")
* gwingerde (n=gwingerd@ip565776e0.direct-adsl.nl) has left #rt2x00 ("Leaving")
</pre>

== Developer's meeting - October 7, 2007 ==

We started off with a proposed agenda:

1) legacy support
2) current issues with rt2x00:
3) upcoming chipset support in rt2x00 (802.11n)

Since no one objected to it we started off.

After the meeting we agreed with this summary of discussed items:

1) legacy should be provided 'as-is' after rt2x00 has reached mainline kernel and at least one distro has released a version containing 2.6.24. in the meanwhile, we should keep it.
2) mac80211 API is causing some breakage to our driver.
3) 802.11n drivers: legacy driver should exist but not for end users. this means that the driver won't have any kind of development effort besides helping rt2x00.

The meeting full log follows:

----

<pre>
**** BEGIN LOGGING AT Sun Oct 7 10:23:31 2007

Oct 07 10:23:44 * lfcorreia is testing log recording for the session.
Oct 07 10:24:20 * lfcorreia confirms, loggins works :P
Oct 07 10:40:01 * lfcorreia has changed the topic to: rt2x00 - Hack-a-thon on rt2x00, comming up in a few minutes
Oct 07 10:53:02 <lfcorreia> ivd: do you have any changes you need to make on the git repo? if no, then we could all sync to it ans have it ready
Oct 07 10:54:47 <ivd> give me 2 minutes and I'll commit the software diversity code
Oct 07 10:55:04 <lfcorreia> ok
Oct 07 11:00:00 * AdamBaker (n=aab@userch028.dsl.pipex.com) has joined #rt2x00
Oct 07 11:00:37 <lfcorreia> AdamBaker: welcome!
Oct 07 11:01:10 <ivd> I have committed the software diversity to git/cvs
Oct 07 11:02:04 <ivd> rt61 and rt73usb antenna setup is still a little/average/completely broken
Oct 07 11:02:45 <sum> *G*
Oct 07 11:03:01 <sum> is it correct, that i need to make "cg update" now?
Oct 07 11:03:06 <ivd> But since the antenna setup code is still pending for a complete review, I hope that with the SW diversity code in, we at least have some progress on link quality/transfer speed
Oct 07 11:03:11 <sum> (i have previously checked out "upstream")
Oct 07 11:03:13 <ivd> yup
Oct 07 11:03:23 <sum> ok, thx
Oct 07 11:03:39 <AdamBaker> Hi, I haven't got time to follow what's going on here all afternoon but I'll drop by as and when I can
Oct 07 11:04:17 <lfcorreia> AdamBaker: no problem, we're still some time from the actual meeting start
Oct 07 11:05:11 <lfcorreia> ivd: regarding antenna setup, there is something we can't forget, most of the PCI devices only have one true antenna, but it is very difficult to actually know which is which
Oct 07 11:06:11 <lfcorreia> because miniPCI devices (and probably USB also) can have from one to three antennas, whereas an internal PCI card will have ony one (unless it's a MIMO...)
Oct 07 11:06:14 <ivd> I think we can assume that when there is only 1 antenna, then the EEPROM will indicate the default antenna is A or B. Or in any case not DIVERSITY
Oct 07 11:07:17 <sum> when is the meeting start?
Oct 07 11:07:21 <ivd> And the eeprom also indicates the number of available antenna's, so perhaps we should do something with that as well. But like I said, the antenna code must be reviewed anyway.
Oct 07 11:07:39 <ivd> I feel there are still too many differences between legacy and rt2x00
Oct 07 11:08:01 <ivd> And each of those differences could be the case of poor sensitivity or low transfer speeds
Oct 07 11:08:52 <lfcorreia> and unfortunately not all manufacturers care much about properly setting EEPROM parameters, so we're kinda stuck here
Oct 07 11:09:20 <ivd> Well if that is the case, then the legacy driver wouldn't work either.
Oct 07 11:09:23 <lfcorreia> sum: we'll wait some more minutes for Mark to show up
Oct 07 11:09:46 <ivd> And since that is usually working we can assume rt2x00 is still doing something wrong/
Oct 07 11:09:55 <lfcorreia> ivd: yes, unless it has all those magical values for when it finds the broken eeprom
Oct 07 11:10:21 <ivd> yes but even then we use the defaults given by the legacy drivers
Oct 07 11:10:39 <lfcorreia> yep, tricky indeed
Oct 07 11:11:23 <ivd> so we must follow the legacy drivers quite strictly. Which is the reason I am so keen on requesting code and register initialization validation
Oct 07 11:11:28 <sum> what about some kind of rescue-procedure... there won't be many places around where absolutley no wlan-packets are flying through the air...
Oct 07 11:11:35 * lfcorreia has changed the topic to: rt2x00 developers meeting + hack-a-ton comming up in 15 minutes (give or take)
Oct 07 11:12:06 <ivd> sum: What do you mean?
Oct 07 11:12:33 <sum> well, if eeprom settings are broken, we could just do scan's with different antenna/diversity/etc. settings and check which one works best.
Oct 07 11:12:49 <sum> this could done by some user-space tool, indeed
Oct 07 11:13:21 <ivd> Well we currently grab the defaults from the legacy drivers. rt61 and rt73 grab the diversity as default. And that means it will switch between antennas to search for the best setup
Oct 07 11:13:35 <sum> ah, ok
Oct 07 11:13:44 <sum> so "diversity" is the switching?
Oct 07 11:14:34 <ivd> yeah, there is software diversity and hardware diversity. With software diversity we keep track of the measured RSSI for a specific antenna. And when the RSSI is fluxing too much we switch to the other antenna
Oct 07 11:14:54 <sum> ah, ok. i dind't get that correct, then
Oct 07 11:14:58 <lfcorreia> the diversity theory states that due to the short wavelenght of wireless signals, we can switch to the other antenna and still receive the signal
Oct 07 11:15:14 <lfcorreia> ans RSSI regulates this switching method
Oct 07 11:16:16 <sum> brb
Oct 07 11:16:31 <AdamBaker> The intention is to cope with receive nulls - if you get the antenna in the wrong position it will receive a weak signal from the wanted AP even if it gets a good signal from other APs
Oct 07 11:17:14 <AdamBaker> Unfortunately it seems some manufacturers have used it to solve other problems like switching between internal and external antennas if the external antenna is fitted
Oct 07 11:18:58 <AdamBaker> I don't think we yet know why there are both SW and HW diversity options and in some cases the latter doesn't work
Oct 07 11:19:07 <ivd> true, but we shouldn't be bothered with that. Basically we need to do what the legacy driver is doing untill some nice userspace tool is created which can handle software diversity
Oct 07 11:20:56 <AdamBaker> agreed I was just pointing out the reasons we need to implement everything legacy does
Oct 07 11:21:07 <ivd> ok :)
Oct 07 11:24:17 * saittam (n=saittam@pD956653A.dip.t-dialin.net) has joined #rt2x00
Oct 07 11:24:49 <lfcorreia> saittam: Welcome!
Oct 07 11:24:58 <saittam> hi all :-)
Oct 07 11:25:04 <Spy84464> hi
Oct 07 11:27:23 <blathijs> oeh, it's that hack-a-ton today :-)
Oct 07 11:27:49 <blathijs> Too bad I have other things to do, but if this WLAN connection lasts far enough I might lurk around
Oct 07 11:29:20 <lfcorreia> blathijs: hang around, you might see something funny comming up
Oct 07 11:31:47 <lfcorreia> Gentleman, we're about to start our developers meeting
Oct 07 11:31:58 <lfcorreia> here's the proposed agenda for today:
Oct 07 11:32:15 <lfcorreia> Agenda
Oct 07 11:32:15 <lfcorreia> 1) legacy support
Oct 07 11:32:15 <lfcorreia> 2) current issues with rt2x00:
Oct 07 11:32:15 <lfcorreia> 3) upcoming chipset support in rt2x00 (802.11n)
Oct 07 11:32:42 <lfcorreia> anyone suggests other topics worth mentioning?
Oct 07 11:33:14 * lfcorreia waits some time before proceeding
Oct 07 11:34:14 <ivd> I guess not. :)
Oct 07 11:34:34 <lfcorreia> ok then
Oct 07 11:35:06 * lfcorreia has changed the topic to: rt2x00 developers meeting has started
Oct 07 11:35:22 <lfcorreia> first topic, legacy support:
Oct 07 11:35:28 <lfcorreia> 1) legacy support
Oct 07 11:35:28 <lfcorreia> there is way too much effort being placed on
Oct 07 11:35:28 <lfcorreia> legacy drivers. rt2x00 needs our full attention
Oct 07 11:35:28 <lfcorreia> and legacy should be only used to figure out the
Oct 07 11:35:28 <lfcorreia> differences needed to make rt2x00 work
Oct 07 11:35:35 <lfcorreia> .
Oct 07 11:36:24 <ivd> well this has always been a hot topic.
Oct 07 11:36:54 <lfcorreia> everyday I keep seeing lot's of topics from users asking for help on legacy (and even ralink's) code
Oct 07 11:37:07 <Spy84464> Agreed, but legacy are also needed for people running 2.4 and early 2.6
Oct 07 11:37:20 <saittam> also rt2x00 doesn't work for some people
Oct 07 11:37:34 <Spy84464> for the time being only ;)
Oct 07 11:37:34 <lfcorreia> and, even now as I keep seeing more and more rt2x00 related ones, that is not enough
Oct 07 11:37:39 <saittam> those who cannot or don't want to compile a git kernel.
Oct 07 11:37:53 <ivd> True, but with legacy drivers as comparison material we can improve rt2x00 to get rt2x00 working correctly
Oct 07 11:38:08 <lfcorreia> well, Ivo tries to get CVS code compilable on older kernels
Oct 07 11:38:24 <ivd> rt2x00 is scheduled for 2.6.24 that means that if rt2x00 is stable by then, then people don t have to use git
Oct 07 11:38:35 <sum> re
Oct 07 11:38:36 <ivd> lfcorreia: No I don't
Oct 07 11:38:44 <lfcorreia> I can't and won't help a guy that uses a *ubunto live cd
Oct 07 11:38:44 <Spy84464> yes, and distribution have already started to ship it
Oct 07 11:39:00 <Spy84464> fedora and ubuntu I think
Oct 07 11:39:09 <ivd> Fedora, Ubuntu, SuSE
Oct 07 11:39:14 <saittam> and suse. remember that guy on the ml?
Oct 07 11:39:15 <lfcorreia> ivd: i know, but CVS code is being somewhat maintained
Oct 07 11:39:18 <ivd> Fedora seems to be most up to date
Oct 07 11:39:45 <ivd> lfcorria: rt2x00 CVS is the exact copy of rt2x00.git
Oct 07 11:39:56 <lfcorreia> yes, fedora has one of the most up-to-date versions of our rt2x00 code
Oct 07 11:40:01 <ivd> lfcorreia: I have a script that copies and commits
Oct 07 11:40:07 <ivd> from git to cvs
Oct 07 11:40:24 <lfcorreia> ivd: oh, then it was me who was making the wrong assumptions
Oct 07 11:40:26 <saittam> well, who's actually spending much time on legacy? I only check it when rt2x00 is broken...
Oct 07 11:40:42 <lfcorreia> all: could we focus on trying to push our users to git?
Oct 07 11:40:59 <ivd> Bryan & Ibrahim are doing legacy
Oct 07 11:41:01 <sum> when will 2.6.24 be released?
Oct 07 11:41:10 <ivd> Robin & GertJan are looking at both
Oct 07 11:41:14 <ivd> sum: In a few months
Oct 07 11:41:31 <saittam> I don't think we can push users to git. Sometimes it's fine, sometimes it's plain broken.
Oct 07 11:41:32 <ivd> 2.6.23 has just been released and the merge window for 2.6.24 will close in a week or 2
Oct 07 11:41:42 <saittam> so you'd have to provide something more stable and known to work.
Oct 07 11:41:49 <saittam> maybe a stable branch?
Oct 07 11:42:12 <ivd> Well the stable branch should be in the wireless-2.6 tree.
Oct 07 11:42:18 <lfcorreia> saittam: John has pushed rt2x00 to 2.6.24 as it is currently
Oct 07 11:42:37 <ivd> I try to push patches to that reposity when most people are satisfied.
Oct 07 11:42:46 <lfcorreia> and he says it's best to push it up then to have it wait indefinetely somewhere off mainline
Oct 07 11:42:52 <sum> hm. what if we ship a package of ieee80211 and mac80211 modules together with rt2x00, so that could compile on older kernels?
Oct 07 11:42:56 <ivd> Sometimes however reports about breakage come after the push to wireless-2.6
Oct 07 11:43:14 <saittam> that's because we're busy with all sorts of other stuff :-)
Oct 07 11:43:25 <lfcorreia> sum: what do you mean about ieee80211?
Oct 07 11:43:31 <sum> ivd: sorry for that, but it worked with the rt2x00-tree
Oct 07 11:43:39 <ivd> sum: That has been discussed on the ML, if you are volunteering to that job, that that is fine.
Oct 07 11:44:01 <sum> lfcorreia: well, if the only reason, rt2x00 can't build on 2.6.22 is that the other 80211-modules changed, we could package them up as wll...
Oct 07 11:44:08 <ivd> sum: But basically keeping rt2x00 to compile on olders kernels, is too much work for me, and it slows rt2x00 progress
Oct 07 11:44:44 <sum> make a package that contains rt2x00 and all needed 80211-modules inthe correct version...
Oct 07 11:45:03 <lfcorreia> sum: intel was making some backport on the mac80211 API to make it compilable on older kernels, but i'm not sure wheteer that is useable anymore
Oct 07 11:45:08 <Spy84464> sum: that was the situation a little while ago
Oct 07 11:45:13 <ivd> sum: You mean creating a rt2x00 package for each kernel? Then how do you want to apply bugfixes/
Oct 07 11:45:32 <sum> well,, maybe i just get the problem wrong...
Oct 07 11:45:34 <saittam> sounds like a full-time job ;-)
Oct 07 11:45:49 <ivd> exactly, that was the reason why that idea was dropped.
Oct 07 11:46:09 <ivd> It isn't the best solution, I agree, but with the availble resources it is the best solution I think
Oct 07 11:46:11 <sum> so the problem is 80211-related and not rt2x00 specific?
Oct 07 11:46:21 <lfcorreia> sum: exactly
Oct 07 11:46:26 <saittam> it's just that everything involved moves too fast...
Oct 07 11:46:34 <ivd> rt2x00 depends on mac80211 and the mac80211 API changes. Which means that rt2x00 needs to follow those changes.
Oct 07 11:46:56 <ivd> I gtg for 20 minutes. l'b be back later
Oct 07 11:47:20 <sum> ivd: what about putting a working version of both (mac80211 and rt2x00) into one single tar.gz and give that one to people. so we shouldn't have too much to do with it but at least there is something...
Oct 07 11:48:05 <Spy84464> it may not be possible, mac80211 may depend on stuff from the rest of the kernel
Oct 07 11:48:12 <Spy84464> like encryption modules
Oct 07 11:48:22 <Spy84464> and their API may change as well
Oct 07 11:48:26 <lfcorreia> sum: things are not that simple
Oct 07 11:48:27 <sum> ah ...
Oct 07 11:48:34 <sum> ok, sorry for that ;-)
Oct 07 11:48:39 <lfcorreia> sum: no problem
Oct 07 11:49:03 <saittam> seems we agree again that we won't do it :-)
Oct 07 11:49:07 <lfcorreia> it is just that most people don't actually realize the effort being put on a 'simple' wlan drvier
Oct 07 11:49:15 <sum> saittam: i do, indeed.
Oct 07 11:49:18 <lfcorreia> saittam: right on!
Oct 07 11:49:53 <lfcorreia> all: do we have more volunteers to shift focus towards rt2x00?
Oct 07 11:50:21 <saittam> I've only ever done rt2x00 work, so I cannot shift ;-)
Oct 07 11:50:30 <sum> same here ;)
Oct 07 11:50:35 <Spy84464> do you mean dropping legacies?
Oct 07 11:50:49 <lfcorreia> all: or at least use legacy only for comparison features
Oct 07 11:51:16 <Spy84464> lfcorreia: so providing them "as it"?
Oct 07 11:51:19 <saittam> I think the point here is whether someone does compilation fixes for newer kernels or not?
Oct 07 11:51:20 <lfcorreia> Spy84464: well, it would be a GoodThing(TM) to do, but I won't actually do it
Oct 07 11:51:36 <lfcorreia> saittam: it's actually the opposite
Oct 07 11:51:49 <lfcorreia> saittam: making the rt2x00 following older ones :)
Oct 07 11:52:27 <lfcorreia> legacy drivers should never have got so far as they did
Oct 07 11:52:32 <sum> do i get this right: there is a hole between 2.6.22.something and 2.6.24 where neither the legacy nor the rt2x00 driver work?
Oct 07 11:52:39 <Spy84464> no
Oct 07 11:52:51 <Spy84464> legacy work everywhere
Oct 07 11:52:55 <Spy84464> as far as I know
Oct 07 11:53:17 <sum> so, then i would suggest telling people that legacy only works until 24 and after that the must use rt2x00 ;-)
Oct 07 11:53:23 <lfcorreia> we've lost now about a year and a half focusing work on legacy whereas we should have been looking up to rt2x00
Oct 07 11:53:34 <saittam> I remember trying rt73 on ppc. It was plain broken.
Oct 07 11:53:34 <lfcorreia> sum: that is the intended idea
Oct 07 11:54:09 <lfcorreia> saittam: yes, because noone tested it :) i don't and won'0t have a ppc so I can't help
Oct 07 11:54:10 * sum votes for "the idea".
Oct 07 11:55:26 <lfcorreia> we (the main developers) have internally talked about the whole legacy drop after the rt2x00 driver has entered the mainline kernel
Oct 07 11:55:45 <lfcorreia> it make absolutely no sense in keeping up effort on 'old stuff'
Oct 07 11:56:27 <Spy84464> yes, but we should keep them for a little while anyway
Oct 07 11:56:52 <Spy84464> at least until major distributions adopt the 2.6.24 kernel
Oct 07 11:57:05 <lfcorreia> sure
Oct 07 11:57:19 <lfcorreia> i know that doing a git kernel is not easy
Oct 07 11:57:25 <sum> how long do you thing will the api still be in changing?
Oct 07 11:57:32 <saittam> sum: ever!
Oct 07 11:58:25 <lfcorreia> but honestly, if people still come to the forum and ask dumb questions without even using the search buttons.... i don't know what to say
Oct 07 11:58:37 <lfcorreia> the kernel API will change a bit longer
Oct 07 11:58:49 * serialmonkey (n=serialmo@ppp121-44-67-215.lns10.syd6.internode.on.net) has joined #rt2x00
Oct 07 11:58:49 * ChanServ gives channel operator status to serialmonkey
Oct 07 11:58:57 <lfcorreia> remember that the ad-hoc and master modes are still largely undefined
Oct 07 11:59:04 <lfcorreia> serialmonkey: Welcome Mark!
Oct 07 11:59:40 <lfcorreia> serialmonkey: we've already started, I can provide you with a log of previous conversation, if you're interested
Oct 07 12:00:01 <serialmonkey> lfcorrei: already started ? I must have mixed up the time zones again - thought we had another hour.
Oct 07 12:00:10 <saittam> na, we're early :-)
Oct 07 12:00:17 <serialmonkey> Phew :-)
Oct 07 12:00:23 <lfcorreia> serialmonkey: no, we just started half an hour earlier
Oct 07 12:00:29 <lfcorreia> serialmonkey: don't worry mate
Oct 07 12:00:56 * Offering FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey
Oct 07 12:01:54 <lfcorreia> serialmonkey: topic is: 1) legacy support
Oct 07 12:01:54 <lfcorreia> there is way too much effort being placed on
Oct 07 12:01:54 <lfcorreia> legacy drivers. rt2x00 needs our full attention
Oct 07 12:01:54 <lfcorreia> and legacy should be only used to figure out the
Oct 07 12:01:54 <lfcorreia> differences needed to make rt2x00 work
Oct 07 12:03:07 * DCC SEND FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey aborted.
Oct 07 12:03:21 * Offering FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey
Oct 07 12:05:07 <lfcorreia> all: let Mark read on the previous chat session and we'll resume shorttly
Oct 07 12:05:17 <lfcorreia> all: that means 'take five :)'
Oct 07 12:06:03 <sum> can someone just tell me how to list all git-submits that modify files in a certain directory?
Oct 07 12:06:22 * DCC SEND FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey timed out - aborting.
Oct 07 12:07:12 <lfcorreia> sum: maybe going into that directory and do a 'git log', who knows :)
Oct 07 12:07:25 <sum> ah, thanks :)
Oct 07 12:07:36 <saittam> yeah, you can also do git log <path>
Oct 07 12:07:54 <lfcorreia> or you can go to the gitweb interface and look at it remotely
Oct 07 12:08:38 * lfcorreia will be back in five minutes, now behave :)
Oct 07 12:09:09 <sum> yeah, actually you need the path, else the whole git will be logged...
Oct 07 12:17:39 <sum> when i do "git revert SHA-ID_of_some_commit", will only that commit be reverted or anything else later, too?
Oct 07 12:18:21 <saittam> sum: anything.
Oct 07 12:18:22 * serialmonkey has quit ()
Oct 07 12:19:36 * serialmonkey (n=serialmo@ppp121-44-67-215.lns10.syd6.internode.on.net) has joined #rt2x00
Oct 07 12:19:36 * ChanServ gives channel operator status to serialmonkey
Oct 07 12:23:22 * lfcorreia is back
Oct 07 12:23:43 <lfcorreia> ok, we're going to proceed with this meeting
Oct 07 12:24:01 <sum> saittam: sure? this is the result: http://rafb.net/p/rDbo3l24.html
Oct 07 12:24:35 <lfcorreia> we really need your help in 'fighting' legacy :)
Oct 07 12:24:49 <lfcorreia> ok, updated agenda:
Oct 07 12:24:59 <lfcorreia> Agenda
Oct 07 12:24:59 <lfcorreia> *1) legacy support
Oct 07 12:24:59 <lfcorreia> 2) current issues with rt2x00:
Oct 07 12:24:59 <lfcorreia> 3) upcoming chipset support in rt2x00 (802.11n)
Oct 07 12:25:07 <lfcorreia> on to topic 2)
Oct 07 12:25:16 <lfcorreia> 2) current issues with rt2x00:
Oct 07 12:25:16 <lfcorreia> suspend-resume,
Oct 07 12:25:16 <lfcorreia> ad-hoc is broken,
Oct 07 12:25:16 <lfcorreia> quick disassociations
Oct 07 12:25:16 <lfcorreia> scanning inconsistancy
Oct 07 12:25:17 <lfcorreia> rt73 broken
Oct 07 12:25:41 <sum> let's start from the end of the list ;-)
Oct 07 12:26:20 <lfcorreia> i've been testing the latest code from git, after having compiled it on my devel machine
Oct 07 12:26:37 <lfcorreia> none of my 3 usb dongles are working, two rt73 and one rt2500usb
Oct 07 12:26:49 <sum> rt73usb isn't working here, too.
Oct 07 12:26:56 <lfcorreia> they just can't get any scanning results
Oct 07 12:28:13 <serialmonkey> Ivo: I take it 'issue list #6' is the most recent ?
Oct 07 12:28:30 <sum> hm. i didn't test scan. but assiciation works but traffic isn't possible: only outgoing frames are ok, incoming frames are broken (i have written that on the ML...) Now i have reverted "[PATCH] mac80211: use RX_FLAG_DECRYPTED for sw decrypted as well" and reception is ok again...
Oct 07 12:28:45 <lfcorreia> serialmonkey: no, it's #7
Oct 07 12:29:03 <serialmonkey> lfcorreia: ah yes, I see it now. Thanks.
Oct 07 12:30:14 <ivd> I'm back
Oct 07 12:30:25 <ivd> serialmonkey: #7 is indeed the latest
Oct 07 12:30:44 <lfcorreia> sum: that was the patch that Johannes made, right?
Oct 07 12:31:10 <lfcorreia> ivd: we've jumped to topic 2) on the agenda
Oct 07 12:31:18 <ivd> ok :)
Oct 07 12:33:01 <lfcorreia> Agenda summary of already discussed items:
Oct 07 12:33:01 <lfcorreia> legacy should be provided 'as-is' after rt2x00 has reached mainline kernel and at least one distro has released a version containing 2.6.24. in the meanwhile, we should keep it.
Oct 07 12:33:03 <sum> lfcorreia: lfcorreia i think so.
Oct 07 12:33:36 <serialmonkey> ok
Oct 07 12:34:07 <ivd> sounds good
Oct 07 12:34:20 <saittam> cool.
Oct 07 12:37:26 <AdamBaker> Is there any need to wait for a distro to adopt 2.6.24, if distro's are using older kernels then the existing legacy should work
Oct 07 12:37:34 <sum> really looks like this patch breaks receiving...
Oct 07 12:38:04 <lfcorreia> AdamBaker: this 'wait' is merely a suggestion, not a true requirement
Oct 07 12:39:20 <lfcorreia> AdamBaker: it's more of an 'excuse' to finally drop legacy for the 2.6 kernel series (we know it still works for 2.4)
Oct 07 12:40:03 <AdamBaker> Ultimately it is up to whoever wants to work on it - I abandoned legacy a long time ago when I realised I was never going to get it working on big endian ARM
Oct 07 12:40:19 <AdamBaker> I think rt2x00 hitting mainline is the best excuse though
Oct 07 12:40:34 <serialmonkey> Most definitely
Oct 07 12:40:53 <saittam> sum: Yeah, it's that patch. Problem is in net/mac80211/wpa.c. It checks for the FLAG and thinks it's already been decrypted, so it doesn't decrypt.
Oct 07 12:41:01 <serialmonkey> Talking about what we are going todo with legacy is all abit pointless until we are in a position to actually call rt2x00 stable.
Oct 07 12:41:26 <sum> saittam: so its not rt2x00 related :)
Oct 07 12:43:10 <lfcorreia> saittam: did you find out the reason for that patch?
Oct 07 12:43:38 <saittam> lfcorreia: no idea ;)
Oct 07 12:44:25 <saittam> we can just roll a patch that sets the flag after calling the decryption algos in ieee80211_rx_h_decrypt.
Oct 07 12:44:51 <saittam> that'll keep the old patch and get it working with minimal changes. Johannes will speak up if he doesn't like it.
Oct 07 12:44:57 <lfcorreia> saittam: if you provide a patch against most current ivd git tree, I can test it right away
Oct 07 12:45:07 <saittam> will do, just a sec.
Oct 07 12:47:27 <sum> but packages of "special" lengths are still not transmitted from rt73...
Oct 07 12:47:37 <sum> could this also be encryption-related?
Oct 07 12:47:58 <saittam> note that unencrypted frames shouldn't be affected. has anyone tested this?
Oct 07 12:47:59 <AdamBaker> I think it is bitrate related
Oct 07 12:48:12 <AdamBaker> (the special lengths)
Oct 07 12:48:46 <AdamBaker> Once I hacked 11g to work again the special lengths problem went away
Oct 07 12:49:14 <sum> AdamBaker: true, only 11m doesn't work, 2 and 5.5 works here with ping -s 68...
Oct 07 12:50:00 <sum> btw, are there any docs about the chip and firmware?
Oct 07 12:50:35 <ivd> sum: Yes. But they are restricted to only members of the rt2x00 team.
Oct 07 12:51:01 <ivd> sum: But fear not, they are hardly usefull, the legacy driver provide far more information and more accurate information then the specsheets
Oct 07 12:51:22 <saittam> ok, patch is at http://rafb.net/p/2tnAK319.html
Oct 07 12:51:29 <saittam> only compile-tested though.
Oct 07 12:51:39 <lfcorreia> sum: and there is no information about the firmware internals
Oct 07 12:51:39 <AdamBaker> just confirmed that disabling WEP makes RT73 work again for me
Oct 07 12:52:20 <saittam> There is another lenght-padding related thing I'd like to bring up:
Oct 07 12:52:44 <saittam> If we post the skb buffer in the urb and increase length (up to 7 bytes in the rt73 case).
Oct 07 12:53:08 <ivd> saittam: Should the flag RX_FLAG_DECRYPTED be set unconditionally or depending on the status of the decryption?
Oct 07 12:53:09 <saittam> How do we guard against the problem that the buffer is actually shorter?
Oct 07 12:53:50 <saittam> ivd: if decryption isn't successful, the frame is dropped immediately.
Oct 07 12:54:11 <saittam> ivd: note that result is initialized as TXRX_DROP.
Oct 07 12:54:28 <ivd> saittam: The skb buffer might indeed be shorter, but the USB layer will copy that to the allocated DMA. If the length is longer then skb->len it will probably copy some random bytes as well.
Oct 07 12:54:43 * lfcorreia announces the Metting log wiki page: http://rt2x00.serialmonkey.com/wiki/index.php?title=Meetings
Oct 07 12:54:44 <ivd> saittam: Ok
Oct 07 12:54:53 <saittam> so does the device care about these bytes?
Oct 07 12:55:14 <saittam> ivd: I mean we should make sure they are valid and zero them out if we want to be on the safe side.
Oct 07 12:56:24 <ivd> saittam: I understand, but legacy drivers doesn't seem to do that either. Neither should it be important because the device knows the correct length because of the header. This means it will probably just ignore the random bytes
Oct 07 12:57:42 <saittam> ivd: ah, ok.
Oct 07 12:58:09 <saittam> ivd: what about the possibly invalid memory references the usb layer reads from on our behalf?
Oct 07 12:59:13 <ivd> Well it should only be reading it. So as long as it doesn't write it shouldn't hurt. Since we are allowed to keep using a skb that is send to the device, the assumption the USB layer is reading it only would be safe enough
Oct 07 13:00:24 <saittam> ivd: well, ok then.
Oct 07 13:00:53 <AdamBaker> The problem that might occur is if the skb is right at the end of a memory page and the extra few bytes overflow to the next unallocated page. I think the alignment guarantees of an skb mean that can't happen
Oct 07 13:02:12 <ivd> well it is either the current approach or expensive tail reallocation for each frame we should send
Oct 07 13:02:35 <saittam> let's hope so. I'll hack a skb_tailroom() printk into the code anyway to see whether short skb buffers are related to packet loss.
Oct 07 13:02:48 <ivd> ok :)
Oct 07 13:03:08 <saittam> but not now, since I'm using the rt73 as my internet connection :-)
Oct 07 13:03:30 <ivd> hehe :)
Oct 07 13:03:32 <saittam> anyone has an idea why the driver deterministically drops packets of certain lenghts?
Oct 07 13:03:39 <saittam> or does it as of current git?
Oct 07 13:04:09 <ivd> well it depends is the packet loss caused by:
Oct 07 13:04:20 <ivd> a) packet of a certain size cannot be send
Oct 07 13:04:29 <ivd> b) packet of a certain size cannot be received
Oct 07 13:04:52 <saittam> I'm after a)
Oct 07 13:04:55 <sum> saittam: your patch doesn't apply ...
Oct 07 13:05:03 <sum> multiple Adds trailing whitespace.
Oct 07 13:05:19 <saittam> sum: I'll repost on the mailing list.
Oct 07 13:05:24 <sum> ivd: which length can't be received?
Oct 07 13:05:31 <sum> saittam: thx
Oct 07 13:06:08 <ivd> saittam: If it is (a) I am suspecting the rt2x00lib_write_tx_desc() function to be calculation the PLCP values incorrectly
Oct 07 13:06:36 * AdamBaker has quit (Read error: 104 (Connection reset by peer))
Oct 07 13:07:28 <lfcorreia> saittam: great, just had a kernel panic :9
Oct 07 13:07:39 <saittam> ivd: I'll have to retest later with current git. IIRC, I couldn't see the packets on my other machine.
Oct 07 13:07:56 <saittam> lfcorreia: sorry, I said it's only been compile-tested :-)
Oct 07 13:08:02 <lfcorreia> your patch did apply though
Oct 07 13:08:11 <lfcorreia> saittam: it's not your problem at all
Oct 07 13:08:16 <lfcorreia> rest assured
Oct 07 13:08:29 <ivd> saittaim: Well my second guess would be antenna problems
Oct 07 13:08:34 * lfcorreia has to be away from the meeting
Oct 07 13:08:41 * AdamBaker (n=aab@userch028.dsl.pipex.com) has joined #rt2x00
Oct 07 13:09:02 <lfcorreia> Friendly agenda reminder: 2) current issues with rt2x00:
Oct 07 13:09:03 <lfcorreia> suspend-resume,
Oct 07 13:09:03 <lfcorreia> ad-hoc is broken,
Oct 07 13:09:03 <lfcorreia> quick disassociations
Oct 07 13:09:03 <lfcorreia> scanning inconsistancy
Oct 07 13:09:03 <lfcorreia> rt73 broken
Oct 07 13:09:24 * lfcorreia is now known as lfcorreia_away
Oct 07 13:09:26 <saittam> ivd: ok, will have a look, but I'll be away for the first half of next week.
Oct 07 13:09:42 <AdamBaker> I recommend not testing the patch to fix s/w decrypt in mac80211 - it just kernel paniced on me
Oct 07 13:10:01 <sum> hmm. strange..
Oct 07 13:10:08 <saittam> so I guess I'd better take the patch off the web :-)
Oct 07 13:10:21 <saittam> do you have stack traces available?
Oct 07 13:10:28 <sum> the break is missing!
Oct 07 13:10:34 <saittam> uh, right :-)
Oct 07 13:10:51 <sum> but shouldn't panic, eh?
Oct 07 13:11:13 <AdamBaker> no - I didn't have a serial console plugged in and it paniced not Oopsed
Oct 07 13:11:31 <AdamBaker> it worked fine with encryption disabled
Oct 07 13:11:42 <sum> maybe the rx->u pointer is not valid after decryption any more?
Oct 07 13:14:10 * drear has quit (Read error: 148 (No route to host))
Oct 07 13:15:59 <saittam> sum: it shouldn't panic, you're right.
Oct 07 13:16:09 <saittam> I hope this one is better: http://rafb.net/p/SSGtMI20.html
Oct 07 13:17:12 <saittam> just curious: anyone of you guys interested in suspend/resume?
Oct 07 13:17:26 <AdamBaker> please excuse me if I wait till the meeting is over to test it
Oct 07 13:17:31 <sum> ok, even with the break, doesn't panic but packets of 96 bytes in total don't get send..
Oct 07 13:17:41 <sum> reception ok
Oct 07 13:17:51 <saittam> sum: was only meant to fix reception.
Oct 07 13:17:55 <sum> yep.
Oct 07 13:17:55 <AdamBaker> are you using WPA or WEP?
Oct 07 13:17:57 <ivd> saittam: Inam interested in all rt2x00 bugs. ;)
Oct 07 13:17:58 <sum> WPA2
Oct 07 13:18:05 <saittam> ivd: *gg*
Oct 07 13:18:22 <sum> but the transmission bug is definitely 11mbit related.
Oct 07 13:18:30 <saittam> AdamBaker: me too, will test tonight.
Oct 07 13:18:31 <AdamBaker> I guess the panic could be in the WEP code then
Oct 07 13:19:26 <saittam> saittam: Na, it's probably in one of the two others. WEP decrypt gets called first and the others probably received invalid state.
Oct 07 13:19:38 <sum> as i already mentioned on the ML, the transmission bug is in there since the rt2x00 code is in git...
Oct 07 13:20:17 <saittam> sum: But only 11mbit, right?
Oct 07 13:21:08 <AdamBaker> Is the length problem limited to rt73? Has anyone tested RT61 or RT2500usb?
Oct 07 13:21:28 <saittam> AdamBaker: I only have rt73 hardware...
Oct 07 13:22:14 <AdamBaker> Me too - that's why I couldn't test it myself
Oct 07 13:22:20 <saittam> I'd also be interesting to see whether legacy has frame length issues...
Oct 07 13:28:35 * saittam reboots with the patch compiled in.
Oct 07 13:28:48 * saittam has quit ("Leaving")
Oct 07 13:33:06 <sum> hm, i think there was someone who reported problems with rt2500...
Oct 07 13:35:00 <sum> hm, no
Oct 07 13:36:22 * saittam (n=saittam@pD956653A.dip.t-dialin.net) has joined #rt2x00
Oct 07 13:36:33 <sum> saittam: yes, 2 and 5.5mbit are ok
Oct 07 13:36:44 <sum> or at least with that one length i have tested...
Oct 07 13:36:53 * saittam is back with WPA2 working and packets dropped at 11mbit ;-)
Oct 07 13:37:20 <saittam> i'm now on a wired connection :)
Oct 07 13:37:56 <sum> hm. do you know a way how to force the driver to a lower bitrate?
Oct 07 13:38:00 <saittam> Adam, have you received any response to your inquiry about rate selection?
Oct 07 13:38:06 <sum> or does wpa_supplicant change the bitrate?
Oct 07 13:38:26 <saittam> sum: I don't know, but let's fix the 11mbit problem first :-)
Oct 07 13:38:52 <sum> yes, i wanted to try if the driver also fails at 5.5 mbit, maybe with different lengths...
Oct 07 13:39:15 <saittam> sum: Have you tried to change the padding, maybe even to 8 bytes or something?
Oct 07 13:39:57 <saittam> note that legacy rt73 even has different padding rules for different kinds of packets. mlme-packets are only padded to 2-byte boundaries IIRC.
Oct 07 13:40:25 <sum> no, i didn't change padding
Oct 07 13:40:47 <sum> i would like to know if nothing is sent or if wrong-length/corrupted packets are sent...
Oct 07 13:42:24 <saittam> I'll check, just switched on my monitor machine.
Oct 07 13:43:00 <ivd> I gtg now. I won't be back for a few hours. So I'll view the logfile later.
Oct 07 13:43:07 * ivd is now known as ivd_away
Oct 07 13:44:18 <saittam> sum: btw, the skb buffer seems to be ok, it's virtually anytime much larger than the padding we apply.
Oct 07 13:46:09 * lfcorreia_away is now known as lfcorreia
Oct 07 13:46:19 * lfcorreia is back into the meeting
Oct 07 13:46:49 <AdamBaker> change the bitrate with "sudo iwconfig wlan0 rate 5.5M" or whatever rate you prefer
Oct 07 13:46:55 <lfcorreia> what was the outcome of the new patch?
Oct 07 13:48:12 <sum> AdamBaker: this does not work, it just doesn't set the bitrate. i am using wpa_supplicant
Oct 07 13:48:15 * free-zombie (i=someone@tuxhacker/free-zombie) has joined #rt2x00
Oct 07 13:48:23 <saittam> lfcorreia: seems to fix decryption problems on reception for both me and sum
Oct 07 13:48:47 <lfcorreia> saittam: good, i'm updating my kernel to test it in a few minutes
Oct 07 13:49:42 <saittam> lfcorreia: I'm pretty sure it's safe now ;-)
Oct 07 13:49:46 <lfcorreia> ok
Oct 07 13:49:55 <sum> but take the newest one ;)
Oct 07 13:49:56 <saittam> sum: Seems like the packets don't go out.
Oct 07 13:50:05 <lfcorreia> gents, what about the other issues with current rt2x00?
Oct 07 13:50:16 <lfcorreia> suspend-resume,
Oct 07 13:50:17 <lfcorreia> ad-hoc is broken,
Oct 07 13:50:17 <lfcorreia> quick disassociations
Oct 07 13:50:17 <lfcorreia> scanning inconsistancy
Oct 07 13:50:41 <saittam> I can see ping packets on air for 92 and 94 byte ping packets, but 93-byte-sized packets fail and don't show up on the monitor station.
Oct 07 13:51:03 <saittam> suspend-resume produced a kernel hang in the usb layer last time I tested.
Oct 07 13:51:20 <saittam> but that was 2 weeks ago.
Oct 07 13:51:24 <saittam> need to retest.
Oct 07 13:52:51 <lfcorreia> and this hang is surely provoked by rt73?
Oct 07 13:53:02 <AdamBaker> Setting the bit rate seems to be a bit intermittent but does sometimes work. It only affects tx bit rate, the bit rate of rx data is set by the AP based on what the driver claims to support at association time
Oct 07 13:53:58 <lfcorreia> unfortunately due to an hardware problem, I can't test suspend/resume on my laptop
Oct 07 13:53:58 <AdamBaker> Is ad-hoc broken? It worked last time I tested it (when I was testing Johannes ad-hoc patch for mac80211)
Oct 07 13:54:27 <saittam> lfcorreia: well, I have posted the stack trace on the ML. I don't know whose fault it is. The stack trace indicates that it's hanging on some lock and sysrq says the kernel doesn't have any task that's ready to be executed.
Oct 07 13:54:45 <lfcorreia> AdamBaker: well, since I think we never got positive results on that one, we're assuming it is still broken :)
Oct 07 13:55:17 <lfcorreia> saittam: ah, so that is the tasklet issue i read about... hummm, must look into it a bit more
Oct 07 13:55:50 <saittam> lfcorreia: It's not our tasklet though.
Oct 07 13:56:00 <saittam> lfcorreia: Where did you read about it?
Oct 07 13:56:09 <lfcorreia> from Ivd's latest issue report: 1 - Ad-Hoc [DEBUGFS]
Oct 07 13:56:09 <lfcorreia> - rt2500usb & rt73usb don't send out beacons.
Oct 07 13:56:09 <lfcorreia> - Are the PCI drivers working?
Oct 07 13:56:09 <lfcorreia> - Is Master mode working for USB?
Oct 07 13:56:39 <AdamBaker> lfcorreia: As soon as git is stable I'll re-test ad-hoc but I think the packet size problem needs fixing first
Oct 07 13:56:41 <saittam> What's needed to test master mode? hostapd?
Oct 07 13:56:45 <lfcorreia> saittam: erm... can't recall actually... but i've got a vague recollection on that issue, maybe i'm wrong
Oct 07 13:56:53 <AdamBaker> Master mode isn't in the current mac80211
Oct 07 13:56:56 <lfcorreia> AdamBaker: sure
Oct 07 13:57:24 <lfcorreia> we need to sort out these issues to make a proper issue list :)
Oct 07 13:57:39 <saittam> Adam, what happened to the rate registration inquiry you posted on linux-wireless?
Oct 07 13:58:00 <AdamBaker> saittam: no reply yet
Oct 07 13:59:29 <lfcorreia> what about "scanning inconsistancy"
Oct 07 13:59:37 <lfcorreia> i still get that one
Oct 07 14:00:48 <saittam> I guess the scanning problem is still out there.
Oct 07 14:00:58 <AdamBaker> lfcorreia: How weak are the signals from the other APs? The only other one I can pick up is so weak it depends on antenna orientation whether I see it
Oct 07 14:01:04 <saittam> sometimes, scanning stops working and I have to reload the driver.
Oct 07 14:01:18 <saittam> Next time I see it, I'll check whether frames go out.
Oct 07 14:01:37 <saittam> But this could also be mac80211 being buggy... ;-)
Oct 07 14:01:42 <AdamBaker> saittam: Do you lose your own AP from the scan or just unassociated ones?
Oct 07 14:01:44 <lfcorreia> AdamBaker: using the same hardware with windoze, it sees a lot more AP's,but in fact all of them very weak
Oct 07 14:02:10 * freezombie has quit (Read error: 110 (Connection timed out))
Oct 07 14:02:15 <saittam> AdamBaker: Everything gone. Nothing there. Nada, niente.
Oct 07 14:02:21 <AdamBaker> lfcorreia: That could just mean we haven't got optimum sensitivity
Oct 07 14:02:42 <lfcorreia> AdamBaker: yes, we have that issue from the very beggining
Oct 07 14:02:52 <AdamBaker> Can you see the other APs with the legacy driver?
Oct 07 14:02:55 <saittam> I can also confirm my madwifi card sees much more APs than the rt73.
Oct 07 14:03:21 <lfcorreia> we made some adjustments to the link tuner and now ivd is pursuing the antenna selection to try and figure out the best way
Oct 07 14:03:58 <lfcorreia> YES!!!
Oct 07 14:04:05 <lfcorreia> rt73 is now working
Oct 07 14:04:13 <saittam> gratulations :-)
Oct 07 14:04:29 <saittam> but try some pings with 80-100 bytes packet size :-)
Oct 07 14:04:56 <sum> hm, i don't get any idea, why there are some sizes, repeating each 44 bytes...
Oct 07 14:05:15 <saittam> 44 bytes?
Oct 07 14:05:33 <sum> those sizes do not work here (padding to 8!)
Oct 07 14:05:34 <sum> 104 108 112 - 148 152 156 - 192 196 200 - 236 240 244
Oct 07 14:05:45 <sum> well the '-' only for readablilyt
Oct 07 14:05:50 <AdamBaker> My guess is it is related to the encoding used at 11M
Oct 07 14:06:23 <AdamBaker> some sizes also occasionally work
Oct 07 14:06:55 <AdamBaker> I wonder if there is some issue with padding for the encoding
Oct 07 14:07:17 <lfcorreia> funny enough, my rt73 is only using 11M, and this has to do with recent changes to the API I think
Oct 07 14:07:20 * drear (n=drear@83.145.204.27) has joined #rt2x00
Oct 07 14:07:42 <sum> AdamBaker: yes, i have also sometimes usually bad sizes that work (well, ping packets are returned in 2 or more seconds...)
Oct 07 14:07:45 <AdamBaker> Maybe it would be helpful to test with a different mac80211 supported device
Oct 07 14:08:01 <sum> i don't have any other device :((
Oct 07 14:08:11 <saittam> me neither.
Oct 07 14:08:36 <sum> i have to go now, be back later.
Oct 07 14:09:08 <lfcorreia> well, time to discuss the most unimportant topic in out agenda
Oct 07 14:09:11 <AdamBaker> I've got a laptop with bcm43xx but the OS is so out of date I need to update that before trying a new kernel
Oct 07 14:09:26 <lfcorreia> 802.11n devices
Oct 07 14:09:50 <serialmonkey> Still haven't managed to get my hands on one locally - and I need PCI or USB
Oct 07 14:09:53 <serialmonkey> (not minipci)
Oct 07 14:10:20 <lfcorreia> AFAIK, there are only minipci available
Oct 07 14:10:35 <lfcorreia> and these aren't even the final 11n specs
Oct 07 14:10:44 <saittam> can we ask some vendor to donate some?
Oct 07 14:10:57 <serialmonkey> Hence why I have actually stayed away from 802.11n all together. It's not even ratified yet
Oct 07 14:11:06 <serialmonkey> Thats why my main vendor is staying away still
Oct 07 14:11:27 <lfcorreia> saittam: ask the guy from minipci.biz
Oct 07 14:11:32 <saittam> So, do these chips also speak 11b and 11g?
Oct 07 14:11:50 <saittam> and if so, do they work with the current drivers?
Oct 07 14:12:04 <lfcorreia> saittam: yes, yes and no
Oct 07 14:12:24 <lfcorreia> it has a new driver, which is as shitty as all the others Ralink provides
Oct 07 14:12:46 <saittam> ah, thanks.
Oct 07 14:13:13 <lfcorreia> and new firmware
Oct 07 14:13:19 <saittam> lfcorreia: I don't have a minipci adapter card here.
Oct 07 14:13:38 <lfcorreia> but hte only time i tested it it did work, but as slow as all other ralink drivers
Oct 07 14:13:53 <lfcorreia> saittam: the guy can also provide a minipci to pci adapter, ask him
Oct 07 14:15:04 * freezombie (i=someone@tuxhacker/free-zombie) has joined #rt2x00
Oct 07 14:15:18 <saittam> lfcorreia: Do you have a contact address? But I don't have lots of spare time, maybe it gets better by the end of october.
Oct 07 14:16:28 <lfcorreia> saittam: sure, martin dot hoehne at minipci dot biz
Oct 07 14:16:43 <lfcorreia> or just go to minipci.biz and search for the proper contact :)
Oct 07 14:17:20 <lfcorreia> anyway, what we were planning to do about the 11n driver is the following
Oct 07 14:17:53 <saittam> lfcorreia: Thanks. Will contact him later this month.
Oct 07 14:18:42 <lfcorreia> anyway, what we were planning to do about the 11n driver is the following, we need a volunteer to cleanup ralink's code and add our fixes to it
Oct 07 14:18:57 <lfcorreia> do that we then can compare rt2x00 with legacy
Oct 07 14:19:18 <lfcorreia> but, and this is the most important issue, we don't want to support it for users
Oct 07 14:19:31 <saittam> *gg*
Oct 07 14:19:33 <lfcorreia> what is your opinion about it?
Oct 07 14:20:33 <Spy84464> You mean not supporting a legacy rt2800?
Oct 07 14:21:33 * saittam doesn't do no legacy
Oct 07 14:23:27 <lfcorreia> Spy84464: exactly
Oct 07 14:24:04 <Spy84464> this is coherent with our current approach : getting rid of legacy drivers
Oct 07 14:24:18 <Spy84464> so it makes sense
Oct 07 14:24:26 <lfcorreia> what I actually mean, if we provide our version of their legacy driver, and as 802.11n is a hype product, we would get tons of help requests about fixing it
Oct 07 14:24:42 <Spy84464> yes
Oct 07 14:24:48 <lfcorreia> so, we *may* have it, but we don't actually support it for users
Oct 07 14:25:05 <lfcorreia> nor we would have a section for it on the forum
Oct 07 14:25:06 <Spy84464> the only interest is to have something to help developing rt2x00
Oct 07 14:25:11 <lfcorreia> exactly
Oct 07 14:25:53 <Spy84464> that's fine for me
Oct 07 14:25:56 <lfcorreia> I would even start to advertise legacy support EOL :)
Oct 07 14:26:04 <lfcorreia> but that we had already discussed
Oct 07 14:26:17 <saittam> sounds good.
Oct 07 14:26:18 <lfcorreia> it's a long standing issue, legacy
Oct 07 14:26:25 <lfcorreia> ok
Oct 07 14:28:32 <lfcorreia> Agenda summary of discussed items:
Oct 07 14:28:32 <lfcorreia> legacy should be provided 'as-is' after rt2x00 has reached mainline kernel and at least one distro has released a version containing 2.6.24. in the meanwhile, we should keep it.
Oct 07 14:28:32 <lfcorreia> mac80211 API is causing some breakage to our driver.
Oct 07 14:28:32 <lfcorreia> 802.11n drivers: legacy driver should exist but not for end users. this means that the driver won't have any kind of development effort besides helping rt2x00.
Oct 07 14:29:12 <lfcorreia> if you all agree with this summary we may declare the meeting closed as for the proposed agenda
Oct 07 14:29:26 <saittam> fine with me.
Oct 07 14:29:36 <lfcorreia> we can continue to discuss some other issues or even test some other code/patches
Oct 07 14:30:28 <serialmonkey> no worries, I have to run anyway - getting late here
Oct 07 14:30:52 <serialmonkey> We should try and stick our heads in here to IRC while we are working on issues
Oct 07 14:30:56 * free-zombie has quit (Read error: 110 (Connection timed out))
Oct 07 14:31:33 <serialmonkey> gotta run, bye all
Oct 07 14:31:37 * serialmonkey has quit ()
Oct 07 14:31:38 <Spy84464> see you
Oct 07 14:31:43 <Spy84464> too late :p
Oct 07 14:32:08 * free-zombie (i=someone@tuxhacker/free-zombie) has joined #rt2x00
Oct 07 14:33:48 <AdamBaker> Did we conclude that no-one has been / is able to test if the packet loss issue at 11 Mb/s applies to anything other than RT73?
Oct 07 14:35:15 <Spy84464> I have a rt2500 card at hand, but I don't have a clone of git, my hard drive died monday
Oct 07 14:35:17 <Spy84464> sorry
Oct 07 14:35:52 <saittam> I've just run into the scanning problem again.
Oct 07 14:36:35 <saittam> seems no packets get transmitted at all, cannot see any on the monitor station.
Oct 07 14:40:43 <lfcorreia> funny enough i've tested some large ping packet size and it fails with anything bigger then '-s 1669'
Oct 07 14:46:18 * freezombie has quit (Read error: 110 (Connection timed out))
Oct 07 14:52:12 <lfcorreia> ok, we declare the developers meeting officially ended
Oct 07 14:53:06 <lfcorreia> saittam: can you prepare a patch and submit it to Johannes aprooval?
Oct 07 14:53:15 <saittam> will do :-)
</pre>

Rt2x00 GIT instructions

Serialmonkey — Tue, 17 Apr 2007 10:49:34 GMT

Summary: /* STEP 0 - Check your distro for specific details on: */

==INITIAL SETUP==

===STEP 0 - Check your distro for specific details on:===
1. installing development tools and libraries

2. examples for some distros:

'''Fedora Core 10''':
go to "System, Administration, Add/Remove Software"
click on "Package collections"
select "Development Libraries" and "Development Tools"
click "Apply"
The package manager would then download and install all relevant packages needed for software development.

'''Gentoo''':
Gentoo users should already have a working development setup
to install git, all you need is to "emerge git"

'''Ubuntu 9.04 Jaunty''':
Ubuntu has a working development setup
to install git, all you need is to "sudo apt-get install git-core"

===STEP 1 - Install GIT===
1. Make sure you have curl installed
2. Check that your distro doesn't have a package that you can just install
3. If it doesn't, grab http://www.kernel.org/pub/software/scm/git/git-1.5.0.5.tar.gz
4. Extract then 'make; make prefix=/usr/local install'

===STEP 2 - Clone a copy of our master repository for your local use===

1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git rt2x00
2. wait, may take ages, have a snack.
3. cd rt2x00

===STEP 3 - Configure GIT settings===

1. git-config remote.upload.url git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git/
2. git-config user.name "My name goes here"
3. git-config user.email "My email goes here"

==DAILY DEVELOPMENT COMMANDS==

To get your local copy in sync with the latest from the master branch on the server

1. git fetch git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git
2. git merge master

'''The following instructions are not complete, we're changing this page.
Sorry for the inconvenience.
'''

To commit a change in your local branch and push it to your branch on the server (i.e. cvs commit)
1. cg commit -e
2. An editor will fire up and you can enter in your commit description which should appear as per below

rt2x00: subject of the patch

Description of the patch you are commiting. Make sure you include the blank line below.

Signed-off-by: Random J Developer <random at developer.example.org>

To make a patch from your branch to send to rt2x00-users

1. Make sure you first have an up-to-date branch from master (as per above)
2. git-format-patch master
3. git-send-email patchfilename (replace with the filename of the patch(s) given by the command above)
4. Fill in your from address and put "users" at "rt2x00.serialmonkey.com" as the TO address

==ACCESS THE WEB INTERFACE==

Goto http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=summary

Slackware9 rt61 Howto

Zvickery — Sun, 04 Feb 2007 04:30:16 GMT

Summary: /* Configuring the Wireless Card */ fix wiki tag

== RT61PCI Install on Slackware 9 ==
By Zach Vickery, 2007

Yes, yes, I know it's an old distribution. But the details here should apply pretty well to newer Slackware versions and possibly other distributions too. So in a way this is a guide to installing a wireless card in an older distribution, or perhaps Slackware in general. At the least, I think my experiences documented below will be helpful to others..

== Kernel Configuration ==
Your kernel will need to support wireless networking and all
subsystems appropriate for your card. For the RT61PCI, this included
<code>CONFIG_NET_WIRELESS</code>, <code>CONFIG_NET_RADIO</code>, and <code>CONFIG_PCI</code>. The default
Slackware kernel should have all of this but if you build your own
kernels you may want to double check that nothing has been disabled.

== PCI Configuration ==
Obviously, you will want to install the card in the box before diving
in. Another key point is to have an updated PCI database (located in
<code>/usr/share/pci.ids</code>). With older distributions, an outdated <code>pci.ids</code>
database can cause the PCI subsystem to detect an "unknown network
controller" rather than the specific model that is installed. If in
doubt, grab the latest version from
[http://pciids.sourceforge.net/pci.ids]. With that said, after booting
up, run the command <code>lspci</code>. You should see something similar to the
below output:

01:0a.0 Network controller: RaLink RT2561/RT61 802.11g PCI

If you don't see this, it means the kernel is not seeing your hardware
and it will be impossible to load the driver. If you do see this,
you're ready to go. This output also has the side effect of
confirming which driver will be needed (in this case, the RT61). I
happened to have a Linksys WMP54G card but didn't know which driver I
needed until the above line from <code>lspci</code> told me.

== Helper Packages ==
The <code>wireless-tools</code> package must be installed. This is included with Slackware and probably most any other distribution. It includes
commands like <code>iwconfig</code> and <code>iwlist</code> which are essential to using your wireless network card.

A recent version of the DHCP tools must also be installed (3.0.4 or later will
surely work with a wireless card, I'm not sure about earlier
versions). For my Slackware 9 system, this was a manual build and
update. This meant getting the source from
[http://www.isc.org/sw/dhcp/], building and installing. It should be an
easy update, should it be necessary. To determine which version you have, running the command <code>dhclient -v</code> will work.

You will also need kernel source installed in <code>/usr/src/linux</code> in order to build the module. Of course, the source must match the kernel you
are running. The Slackware stock kernel has corresponding source
packages that can be installed if you didn't install them on setup.

== Building the Driver ==
With everything above in place, building and installing the driver
should be easy. Unpack the source in your favorite location and build
and install per the included directions. The end result is that a kernel module <code>rt61.o</code> will be installed in your kernel modules area. Typically this is the directory <code>/lib/modules/<kernel version>/extra</code>.

== Loading the Driver ==
Once the driver is installed, the command <code>/sbin/modprobe rt61</code> will
load the driver into your running kernel. If you would like the
module to automatically be loaded on boot, add the above modprobe
command to the end of <code>/etc/rc.d/rc.modules</code>.

== Configuring the Wireless Card ==
With the driver loaded, the command <code>/usr/sbin/iwconfig</code> should reveal an interface <code>ra0</code> representing your RT61 card. If <code>ra0</code> exists, the command <code>/sbin/ifconfig ra0 up</code> will activate the wireless interface.

To verify that you can see wireless networks, the command <code>iwlist ra0
scan</code> will display all wireless networks in range that are
broadcasting their ESSIDs.

Once you know which network to which you would like to connect, use
the following commands to do just that:

/usr/sbin/iwconfig ra0 essid "My Network"
/usr/sbin/iwconfig ra0 channel 9
/usr/sbin/iwconfig ra0 key s:pword (for WEP networks)
/sbin/dhclient ra0

Basically, this is setting the network name, channel, and WEP key for
your chosen network and then running <code>dhclient</code> to obtain a DHCP lease and perform the actual connection. The network name and channel can
be obtained from the <code>iwlist ra0 scan</code> output. Note that the network
does not have to be broadcasting its ESSID in order to connect in this
manner.

The final dhclient command will result in an IP address assigned to
<code>ra0</code>, routing tables configured, and DNS set up. After dhclient
finishes, the command <code>/sbin/ifconfig ra0</code> should reveal that <code>ra0</code> has an IP address associated with it. At this point everything should be working!

If you would like your system to associate with the network on boot,
you must be put the below commands in one of your system's startup
scripts (I used <code>/etc/rc.d/rc.local</code> but <code>/etc/rc.d/rc.inet1</code> is also a good candidate):

/sbin/ifconfig ra0 up
/usr/sbin/iwconfig ra0 essid "My Network"
/usr/sbin/iwconfig ra0 channel 9
/usr/sbin/iwconfig ra0 key s:pword (for WEP networks)
/sbin/dhclient ra0

== Other Configuration ==
To get the wireless card to send a host name to the access point, the below line must be added to <code>/etc/dhclient.conf</code>:
send host-name "HOSTNAME";

<code>dhclient.conf</code> accepts many other parameters; for full details check out the man page (<code>man dhclient.conf</code>).

== Conclusion ==

Hopefully this was helpful - it includes a few things I had to learn
the hard way. Thank you also to the rt2x00 team for providing such an
excellent driver collection and website to help people like myself get
their cards running on Linux!

Slackware Howto

Sxiang — Mon, 08 Jan 2007 14:39:55 GMT

Summary: /* Network startup the graphical (X) way */

== '''Slackware RT2500 HOWTO''' ==

Copyleft 2007 Alex

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

==Introduction==

This is a HOWTO document for getting rt2500 based wireless NIC cards working on Slackware Linux. It has been tested and found to work on Cisco's WRT45G wireless'' adapter working under Slackware 10 and 11.

==Compilation and device driver installation==

Follow the instructions provided in the README/INSTALL files found in the rt2500 tarball for compiling the device driver modules and installing them into the system. If rc.hotplug is disabled on your system. Then you need to type

----
modprobe rt2500
----

to insert the driver module into the kernel upon system startup.

==Network startup the graphical (X) way==

In this section I will describe a method that makes use of the RaConfig2500 graphical utility supplied with the rt2500 tarball.

After your Slackware has fully booted. You may execute the following two lines without going into X Windows (normal Slackware installations do not automatically boot into X, unlike Fedora ;-)

----
<pre>
modprobe rt2500 #necessary if rc.hotplug is disabled
ifconfig ra0 up
</pre>
----

Then, launch X with the startx command and run the following commands

----
<pre>
cd rt2500* #assuming that you've untargzed rt2500 tarball
#into the current directory
cd Utilitys
RaConfig2500 &
</pre>
----

The dialog box shown below will pop up.

http://images4.wikia.nocookie.net/ascm/images/e/ea/Wlan0.png

In my case the wireless NIC connected with the WAP named "WLAN" automatically because WLAN does not use any passwords. However, the signal strength of WLAN is too weak (10%) to be of any use. Therefore I need to switch to my home WAP named "havenview", which uses the WEP encryption algorithm. I clicked on the "havenview" entry and then pressed the "Connect" button (right next to the "Rescan" button). A dialog box then popped up asking me to enter the encryption key. After everything is entered and confirmed, the green handshake icon migrates from WLAN to havenview.

The final step consists of obtaining a DHCP address (assuming that the wireless router is configured to perform DHCP, which applies to most routers used nowadays). The version of DHCP supplied with Slackware 10 is too low to work with wireless network interfaces. Therefore when one attempts to execute

----
dhclient ra0
----

the DHCP program will come back with an error message complaining about the non-existence of ra0 and a link to redirect the users to the latest version of the dhclient program. Take note of the link, go there and download the latest version of the DHCP daemon program and compile it. Then run the following commands.

----
<pre>
cd dhcp* #assuming that you've untargzed dhcpx.y.z tarball
#into the current directory
cd work*
cd client
./dhclient ra0
</pre>
----

It is <strong>absolutely</strong> imperative to use ./ infront of dhclient, or else the default version of dhclient gets executed and nothing happens.

I think that the dhcp package that comes with Slackware versions 11 and later natively supports listening for DHCP servers on wireless networks. So it is no longer necessary to download newest version of dhclient and using ./ to run it from a specific directory.

The 2 screenshots below demonstrate how to properly use newest version of dhclient (version 3.0.4 for me) and what ifconfig should display for ra0 if everything has been set up properly.

http://images2.wikia.nocookie.net/ascm/images/0/07/Wlan1.png

http://images4.wikia.nocookie.net/ascm/images/c/c6/Wlan2.png

Finally, thou shalt be awarded with Internet access, as shown in figure below:

http://images2.wikia.nocookie.net/ascm/images/e/ef/Wlan3.png

As for Slackware 11, the default version of DHCP is good enough to handle ra0, therefore after ifconfig one could directly type "dhclient ra0" to grab an IP for the wireless NIC and start working.

==Network Startup the Shell-based way==

For you hard-core shell-aficionados (of which I'm a member), there is a way of starting up ra0 without ever going into X. I shall finish writing this section when I have more time.

And here it is:

Enter the following sequence of commands in a root shell:

<pre>
modprobe rt2500
iwconfig ra0 essid "<essid of your wireless network>"
iwconfig ra0 mode Managed
iwconfig ra0 channel <channel # of your wireless network>
<enc lines>
ifconfig ra0 up
dhcpcd ra0
</pre>

For <enc lines>, if you don't have any encryption set for your wireless network then there are no lines for you to enter and <enc lines> equate to nothing.

If you use WEP, then substitute the following lines for <enc lines>:

<pre>
iwconfig ra0 enc <your hex WEP key>
</pre>

If you use more advanced form of encryption than WEP then you need to use ''iwpriv'' to set the parameters required for your rt2500 to communicate properly with the WAP. Refer to the Ubuntu howto for more details.

Note that all quotation marks in the command lines must be entered as is. But the stuff in angled brackets must be replaced by the unique names and numbers you use for your own wireless network.

'''Note''': I just realized that as of Slackware 11 "dhclient ra0" still does not work. Instead you need to enter "dhcpcd ra0" for your rt2500 to get its own IP address. Other than the names used the two commands are otherwise completely equivalent.

==Acknowledgements==

Thanks to Mark Wallis for setting me up an account, and the crew of Rt2x00 for everything. Now only if my accursed USRobotics 56K Winmodem would also work in Slackware (teeth gritting), life would be so much better!

Rt2x00 FAQ

Ivo — Thu, 26 Oct 2006 18:06:05 GMT

Summary: /* Network startup the graphical (X) way */

ClarkConnect 3.2 rt2500 Howto

Jrogers — Sat, 15 Jul 2006 22:54:13 GMT

Summary: /* '''CLARKCONNECT RT2500 HOWTO''' */

== '''CLARKCONNECT RT2500 HOWTO''' ==

Copyright © 2006 Jeremy Rogers

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

'''Introduction'''
This is a HOWTO document for getting an 802.11g wireless NIC card based on the RT2500 chipset to work under the CENTOS-based Clarkconnect releases 3.2 thru 4.3 (www.clarkconnect.com), in a configuration where the RT2500 NIC is installed as a second NIC in addition to a fixed wire NIC behind the firewall. As a Linux newbie, Aaron Howard’s excellent CENTOS HOWTO pointed me in the right direction and this HOWTO borrows from some of his.

''Disclaimer'': as a linux newbie I don’t guarantee that all the steps set out here are actually necessary or sufficient. They do, however, appear to work: I originally worked out how to get the card working on an experimental clean CC3.2 installation on a spare box before then repeating the process on the live working server.

== '''Installing the cc developer tools and kernel sources/developer kit''' ==

(from clarkconnect newbie portal: http://newbie.valar.co.uk/)

'''Installing the developer tools:'''
You may need to install the developer tools – if you’ve got loads of disc space then it can’t do any harm. If for some reason disk space is short (e.g. like me you installed the basic CC system on a 2Gb disk) then you might be able to proceed without this step.
----
apt-get update
apt-get install cc-devel
apt-get install make
----

'''Installing the kernel sources'''<br>
''(NB requires ~250Mb free disk space for kernel source install)''

Compiling the RT2500 module from its sources requires some of the sources for your linux kernel to also be available. You can either install the full kernel sources, or only the (much smaller) kernel developer package from Clarkconnect. Whichever option you choose, you first need to know which version of the kernel you’re running:
----
uname –r
----
You also need to know which CPU type your kernel is compiled for.
----
modinfo libcrc32c.ko
----
…returns information about the existing kernel module libcrc32c.ko ( concerning some aspects of the software and hardware environment it expects to run under, including an output line something like:

vermagic: 2.6.9-27.cc '''686''' REGPARM 4KSTACKS gcc-3.4

(I chose libcrc32c.ko randomly; modinfo on other kernel modules would return similar info)

This tells you which kernel version and processor type the module was compiled for, and which compiler was used (gcc-3.4 in this case). Take particular note of the bit highlighted, reading either 686 or 586 depending on which processor you’ve got (or presumably something else for dual core systems). You can't compile the rt2500 module using kernel sources for the wrong processor, and a version of the rt2500 module compiled on a 586 machine with the 586 kernel sources won't work if you copy the compiled ko file across to a 686 machine, even if the kernel version on that machine is the same.

To actually compile the RT2500 module you can either install (and compile) the entire kernel sources, or only install the kernel developer package (which is smaller and doesn’t need compiling). I originally went down the entire kernel source route, and didn’t find out about the kernel developer package until second time around. I’d suggest the kernel developer route - option 1 below – though this may also require you to upgrade your kernel. I’ve documented the kernel sources route (option 2) as well just in case it proves useful.

'''Option 1: Installing the kernel developer package'''

''(much quicker but slightly more fiddly)''

In theory, you can just type:

----
apt-get install –V kernel-devel
----
…and this will install the correct kernel developer package under /usr/src/kernels. In my experience, however, it may install a kernel-devel package for the wrong kernel version. The –V switch will tell you which version is being installed, or you simply look at what’s under /usr/src/kernels. If what gets installed matches your current running kernel, you can skip to section 2. If you don’t get the one matching your actual kernel, the more fiddly solution is as follows:

Using a web browser, examine the contents of Clarkconnect’s developer site at http://download.clarkconnect.org/3.2/developer/ to see whether there is a package listed with a name something like:

kernel-devel-x.x.x-x.cc.iyyy.rpm

…where x.x.x-x.cc should match the kernel version you’re running (as determined above using uname –r) and yyy should match your processor type, as determined by the modinfo command earlier. If such a package exists, you can type:
----
cd /usr/src
wget
http://download.clarkconnect.org/3.2/developer/kernel-devel-x.x.x-x.cc.iyyy.rpm
rpm –Uvh kernel-devel-x.x.x-x.cc.iyyy.rpm
----

If there’s no kernel-devel package that matches your running kernel, then its time to upgrade your kernel:
----
apt-get update
apt-get install kernel
(returns a list of available kernel versions)
apt-get install kernel#x.x.x-xx.cc
(where x.x.x-xx.cc matches a version with a matching kernel-devel package)
----

'''Option 2: Installing and compiling the entire kernel sources'''
''(takes ages, and needs tons of disk space)''
----
apt-get clean
apt-get update
apt-get install kernel-source
(returns a list of available sources)<br>
apt-get install kernel-source#x.x.x-xx.cc
(x.x.x-xx.cc should match the kernel version you are running)<br>
cd /usr/src/linux-2.6.9-27.cc
make oldconfig
make
(will take a LONG time – an hour or more)<br>
depmod
----
…where make oldconfig (I think) copies the default cc build config file into the right place, so that the make then builds a replica of the kernel you’ve already got. The compilation will take a LONG time, probably an hour or more. It may produce a few error messages; ignore them.

NB the final depmod step seems to be necessary if using the beta3 release of the rt2500 driver. The beta4 release compile (make) script includes a line to call depmod before the main rt2500 module build starts.

If that doesn’t work, you could always try what I originally did:

----
cd /usr/src/2.6.9-27.cc
make menuconfig
make
depmod
----

…where make menuconfig brings up a GUI for selecting which kernel options you want to install, so you can roll your own config. For me, this GUI came up with many options preselected or predeselected. I left the options unchanged, saved the file and did the make and depmod before then

== '''Obtaining and unpacking the RT2500 driver sources''' ==
(from Aaron Howard’s excellent HOWTO install on a CENTOS distro http://rt2x00.serialmonkey.com/wiki/index.php/HOWTOS)

Navigate to the /usr/src subdirectory.
----
cd /usr/src
----

'''1. Download the RT2500 driver module sources'''
for example via sourceforge:
----
wget http://voxel.dl.sourceforge.net/sourceforge/rt2400/rt2500-1.1.0-b4.tar.gz
----
This will download the beta-4 version of the rt2500 driver (released in June 2006) directly into the directory you’re currently in, ie /usr/src

You can get the driver from whatever mirror you like – you can find out where its available from the rt2500 project downloads page at :

http://rt2x00.serialmonkey.com/wiki/index.php/Downloads.

NB Make sure you're getting the rt2500 driver, not the rt2400 driver. Also, don’t try the rt2x00 driver as this only works with linux kernel versions more advanced than that used by Clarkconnect 3.2 out of the box.

'''2. Untar the driver source tarball'''
----
tar zxvf rt2500-1.1.0-b4.tar.gz
----

This creates a new directory below the current one called rt2500-1.1.0-b4 under which are all the driver source files.

== '''Compiling the RT2500 driver module''' ==

In the rt2500-1.1.0-b4 directory is another subdirectory called Module:
----
cd rt2500-1.1.0-b4/Module
----

In order for the rt2500 sources to compile, you have to have a symbolic link called build within your currently running kernel under /lib/modules/x.x.x-xx that points to the sources under /usr/src/linux-x.x.x-xx.cc, where x.x.x-xx identifies your currently running kernel.

If you installed the kernel-devel package rather than the entire kernel sources, this link should have been made for you…but I recommend checking that it exists and is pointing to the right place:
----
ls –l /lib/modules/x.x.x-xx.cc
----
..will produce a directory listing that should include a line:

lrwxrwxrwx 1 root root 26 Jul 10 21:28 build -> /usr/src/linux-x.x.x-xx.cc

If this symbolic link exists, but is for some reason not pointing to the right place, you can remove it as follows:
----
rm –f /lib/modules/x.x.x-xx.cc/build
----
To create the symbolic link (e.g. if you went for the entire kernel sources option), type the following:
----
ln -s /usr/src/linux-x.x.x-xx.cc /lib/modules/x.x.x-x.cc/build
----

In theory, after all that preparation, you can now actually compile the actual rt2500 module, and then install it. From the /usr/src/rt2500-1.1.0-b4/Module directory, issue these commands:
----
make clean
make
make install
----

This will build the rt2500.ko module, place a copy of it somewhere under /lib/modules, and make some other (possibly) not completely correct other changes that we’ll check and/or fix in the next section.
First, however, you can check that the compiled module is going to be compatible with your kernel:
----
modinfo rt2500
----
..should return output with a line like:

vermagic: 2.6.9-27.cc 686 REGPARM 4KSTACKS gcc-3.4

…where the kernel version, processor type and compiler ID should match the one you got earlier.

== '''Installing the rt2500 driver''' ==
Especially if you went for the ‘entire kernel sources’ option, the rt2500 make install may not install the module into the right place: instead of putting it under /lib/modules/x.x.x-xx, you may find it instead under something like /lib/modules/x.x.x-xx.cccustom .

Copy the rt2500.ko module into the directory where clarkconnect stores the driver modules for those wireless cards that it supports out of the box:
----
cp /usr/src/rt2500-1.1.0-b4/Module/rt2500.ko /lib/modules/x.x.x-xx.cc/kernel/drivers/net/wireless
----
NB if you get a prompt asking whether you want to overwrite the file, this means the make install got it right first time. You can type ‘y’ or ‘n’ as you choose.

'''5. Loading the module'''
Now we need to join up the dots between lower level hardware configuration of your CCbox and the driver module you just built.

First lets find out whether your wireless card, which you should have fitted onto your motherboard, is recognised as a PCI device:
----
lspci
----
Examine the output of lspci. Assuming the rt2500 card is currently fitted in a PCI slot on the motherboard of your machine, you should see a line that looks something like this:

00:08.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01)

Now examine the hardware configuration file hwconf. This tells us what interface ID kudzu (the plug-and-pray –hardware-detector-manager thang that runs every time you reboot) has assigned to your card. Type:
----
less /etc/sysconfig/hwconf
----
…and scroll down until you see a section something like this:

class: NETWORK
bus: PCI
detached: 0
device: ra0
driver: unknown
desc: "RaLink Ralink RT2500 802.11 Cardbus Reference Card"
network.hwaddr: xx:xx:xx:xx:xx:xx
vendorId: 1814
deviceId: 0201
subVendorId: 1799
subDeviceId: 700a
pciType: 1
pcidom: 0
pcibus: 0
pcidev: 8
pcifn: 0

In the example above the rt2500 card has been assigned ra0 as its device identifier. If it doesn’t show ra0, but instead shows e.g. eth2, and also if it doesn’t show the card’s MAC address, and despite following the rest of this guide the card still doesn’t work, then you should probably reboot the system a few times until kudzu kicks in during bootup and asks you to enter the card configuration information. In my experience the card first appears in hwconf assigned to eth2 but with no MAC address showing but eventually settles down to showing up with its MAC address but assigned to ra0. (I *think* this only happens successfully if you reboot after having built and installed the driver, installed it into the kernel with modprobe, and edited modprobe.conf before rebooting.)

The end result of being assigned ra0 is possibly a problem, because bits of Clarkconnect reputedly won’t necessarily work very well with active interfaces called anything other than something like ethx. If your hwconf file already says the card has been assigned an ident like ethx then you may or may not be OK. If things don't work, you’ll need to do the interface renaming steps described later.

(If you try editing hwconf by hand, for example to change ra0 to eth2, then the next time you reboot your machine kudzu will very likely pop up with an interactive interface in the middle of the reboot, and change it back. I’ve not yet worked out how kudzu works, or what determines which particular interface ident it assigns. )

Before we finally power up the rt2500.ko module, we need to tell the kernel module loader (modprobe) what to call the new interface. Type:
----
nano /etc/modprobe.conf
----
…and find the line (probably the last line) that was inserted by the rt2500 module make install routine you ran earlier, and which probably reads:

alias ra0 rt2500

If hwconf showed that the card has been assigned ra0, then you don’t need to change this: exit nano without making any changes. On the other hand, if hwconf showed a different device name (e.g. eth2) then edit this last line of modprobe.conf to read (for example):

alias eth2 rt2500

…and then save the new modprobe.conf before exiting nano.

Now you can try to actually load the module. Type:
----
modprobe rt2500
----
There should be a short pause, after which the command prompt should return. If you get any other response (including for example that modprobe can’t find the rt2500 module) re-read the instructions above. If that fails to fix the problem, you’re on your own. Sorry.

To confirm that the driver has loaded, type:
----
ifconfig ra0/eth2/whatever
----
..and you should see something like this:

eth2 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1755 errors:0 dropped:0 overruns:0 frame:0
TX packets:3102 errors:14 dropped:14 overruns:0 carrier:0
collisions:60 txqueuelen:1000
RX bytes:342526 (334.4 KiB) TX bytes:1853988 (1.7 MiB)
Interrupt:12 Base address:0x8000

Note that this report also shows the MAC address of the card (after the HWaddr tag on the first line). Make a note of the MAC address – you’ll need it in the next step.

'''Renaming the interface'''
As said earlier, if your interface is currently called ra0 there may be a problem later with some parts of the Clarkconnect suite. Rumour has it some CC components expect all interfaces to be called ethx. You’re welcome to experiment with keeping your wireless interface as ra0 or whatever; the interface renaming method described below was part of what worked for me. It may not in fact be critical or necessary.

Obviously, we want any renaming of the interface to happen every time the machine reboots, ideally during the script that brings up all the interfaces. To achieve this, type:
----
nano /etc/init.d/network
----

Immediately after the fourth pair of lines in the section towards the top of the file (reproduced below) that reads:

# Check that networking is up.
[ "${NETWORKING}" = "no" ] && exit 0

# if the ip configuration utility isn't around we can't function.
[ -x /sbin/ip ] || exit 1

# Even if IPX is configured, without the utilities we can't do much
[ ! -x /sbin/ipx_internal_net -o ! -x /sbin/ipx_configure ] && IPX=

# Even if VLAN is configured, without the utility we can't do much
[ ! -x /sbin/vconfig ] && VLAN=

..insert the following:

# Optionally remap interfaces based on MAC address.
# '/sbin/ifrename' is part of wireless-tools package.
# /etc/iftab is currently not created by default.

if [ -x /sbin/ifrename ] && [ -r /etc/iftab ]; then
echo -n "Remapping network interface name: "
ifrename -p
echo "done."
fi

This script remaps interfaces based on their MAC addresses, using information in a file called /etc/iftab, which probably doesn’t exist on your system.

To create and edit this file, type:
----
touch /etc/iftab<br>
nano /etc/iftab<br>
----
…and in the nano editor enter:

ethx mac xx:xx:xx:xx:xx:xx

…except with ethx replaced with whatever you really want to call the interface (e.g. eth2), and with the MAC address of your actual card (which you noted earlier) entered in place of the string of xx’s.

Save this new file as /etc/iftab and exit nano.

At this point it may be wise to reboot the system and, after rebooting, repeat the ifconfig step above in order to confirm (a) that the rt2500.ko module is loading automatically on boot and (b) that it is being remapped to your chosen device name.

Assuming everything is still going according to plan, if you have any problem after this, you’ll know its to do with your interface or IP routing configurations and not with the driver module itself.

== '''Configuring the interface''' ==

OK. Now you’ve told the machine what driver to use with your rt2500 card. But you haven’t told it exactly what you want to do with it.

The final two steps in bringing up the card are (1) to tell the machine a little more about what kind of wireless network and node you want to run (e.g. channel number, encryption modes, access control etc) and (2) specify how you want ra0/ethx to behave (e.g. static or dynamic IP address?).

The first of these can be done in one of two places:

The rt2500 README file says that the rt2500 module, on loading, will attempt to configure itself by reading a file called

/etc/Wireless/RT2500STA/RT2500STA.dat

…and which looks something like this:

[Default]
AdhocOfdm=0
CountryRegion=0
WirelessMode=0
TXBurst=0
TurboRate=0
BGProtection=0
ShortSlot=0
TxRate=0
PSMode=CAM
SSID=YOUR-WIFI-NAME
NetworkType=Adhoc
Channel=9
AuthMode=SHARED
EncrypType=WEP
DefaultKeyID=1
Key1=ABCDE
StaWithEtherBridge=0

Further options and valid settings are documented in the rt2500 README file.

Alternatively, you can specify some of these settings in a new file that you need to make anyway, called /etc/sysconfig/network-scripts/ifcfg-ethx (or ifcfg-ra0, or whatever suits you…). Its not clear what happens if some of the setting appear in both places.

Handily, ifcfg-ethx is also the place where you specify most of the information concerning how the interface should behave. This file probably doesn’t exist yet. Type:

----
touch /etc/sysconfig/network-scripts/ifcfg-ethx
nano /etc/sysconfig/network-scripts/ifcfg-ethx
----
..and then edit the file so that it looks something like this:

DEVICE="eth2"
HWADDR="xx:xx:xx:xx:xx:xx"
TYPE="Wireless"
ONBOOT="yes"
USERCTL="no"
ESSID="YOUR-WIFI-NAME"
MODE="ad-hoc"
CHANNEL="11"
KEY="s:ABCDE" <- five or thirteen character shared secret string
RATE="auto"
BOOTPROTO="static"
IPADDR=10.2.1.1
NETMASK=255.255.255.0

…where you should replace the entry against the HWADDR tag with the MAC address of your card.

Note that the example ifcfg above is for a network architecture for a CC box in which it has three network cards:

eth0 = internet gateway interface with a dynamically assigned IP address
eth1 = ethernet card with static IP address 10.1.1.1 and serving a a Cat5 wired intranet on subnet 10.1.1.0
eth2 = RT2500 with static IP address 10.2.1.1 and serving as the wifi access point on subnet 10.2.1.0

With this architecture, mobile wifi devices (e.g. laptops) can connect to the rest of the fixed wire or wifi intranet or internet. Note in particular that eth2 has a static IP address (in this case 10.2.1.1) on a new subnet different from the subnet of either of the other two cards in the box.

If instead you want your new wifi interface to get its IP address assigned dynamically from an external wireless router that supports DHCP, replace the last three lines of the example above with the single line:

BOOTPROTO="dhcp"

OK – nearly there. Only three more steps….
(1) telling the firewall and DNS servers about the card
(2) telling the DHCP server whether to provide DHCP over the interface
(3) telling samba about the interface
'''Firewall and DNS'''
Before you finally bring up the interface, it would be a good idea to tell cc-firewall that it exists.

Type
----
nano /etc/firewall
----
..and edit the interface roles section as appropriate. The example below is again for the case where three NICs are installed. If the rt2500 card is the external link to the internet, I assume that there would be no entry in the WIFIF slot and the EXTIF entry would point to ethx or ra0 or whatever.

# Interface roles
#----------------

EXTIF="eth0"
LANIF="eth1"
DMZIF=""
WIFIF="eth2"
<br>
'''DNS'''
Tell the DNS server to provide name resolution to your new subnet. Type:
----
nano /etc/dnsmasq.conf
----
and, in addition to any lines already reading ‘interface=xxxx’, add the new line:

interface=ethx

Save the edited file and exit nano.
<br>
'''DHCP'''
If you’re setting up the rt2500 as a wifi access point, you’ll probably want your CC box to dole out dynamic IP addresses to devices when they connect to it. Type:
----
nano /etc/dnsmasq/dhcp.conf
----
..and append the following lines:

dhcp-option=ethx,1,255.255.255.0
dhcp-option=ethx,6,10.2.1.1
dhcp-option=ethx,6,10.1.1.1
dhcp-option=ethx,3,10.2.1.1
dhcp-option=ethx,44,10.1.1.1
dhcp-option=ethx,45,10.1.1.1
dhcp-option=ethx,46,8
dhcp-option=ethx,47,
dhcp-range=ethx,10.2.1.100,10.2.1.102,12h

These lines mostly specify the information that the DHCP server will pass to clients when they connect (netmask, gateway, wins server etc). The final line in this case instructs the DHCP server to hand out dynamic IP addresses from its subnet only in the range 10.2.1.100-102 (ie no more than four connections) and that each lease lasts 12 hours.
'''SAMBA'''
If your CC box is running samba in order to make some of its disk storage space accessible under windows networking, then you need to also tell samba about your new interface and its subnet. Type:
----
nano /etc/samba/smb.conf
----
Edit the interfaces and allow hosts lines so that they read something like:

interfaces = eth1 eth2
allow hosts = 10.1.1.0/255.255.255.0,10.2.1.0/255.255.255.0

Save the edited file and exit nano. Now type:
----
smbd
nmbd
----
…to restart samba.

== '''Bringing up the interface''' ==

That’s it. If you’ve done all the above it should, in theory, work. To power up your card type:
----
ifup eth2
----
or you can reboot your machine.

Either way, it should now be broadcasting its ESSID name on your chosen channel and either obtaining a dynamic IP address from your access point (provided you set the card to broadcast and receive on the same channel as your access point), or handing them out to your laptops. In theory, if all has gone well, you can also browse both the internet and the other parts of the intranet through your new connection.

If things don't work, or work only partially (e.g. you can see the card broadcasting its ESSID but can't get a DHCP assignement) try rebooting the machine several times. Kudzu may kick in along the way, which seems to be usually part of what's necessary to get things eventually working.

== '''Routing Issues''' ==

I’m no IP routing expert. If you seem to have partial connectivity, it could be an IP routing problem. If you type:
----
route -n
----
…you’ll get the main routing table, which I never had to try and alter. When all three interfaces are up, mine looks like this, and it works:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.2.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
w.x.y.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 w.x.y.z 0.0.0.0 UG 0 0 0 eth0

…where w.x.y.z is an IP address assigned dynamically by my cable router, and the gateway to the internet.

== '''Security Issues''' ==

The above information sets your card up to operate using WEP encryption of transmitted packets, and a (short) shared secret for authentication. These aren’t necessarily maximally secure. Greater security of authentication can be achieved using the CC built in support for MAC address filtering, whereby only devices whose MAC address is on a white list can connect. Install the cc-wireless module for this, and check out the web configuration interface on https://yourbox:81.

The rt2500 itself supports stronger authentication and encryption technologies than either shared secret or WEP; I’ve not experimented with these. If you get this far, feel free to play with the relevant settings in ifcfg-ethx and the RT2500STA.dat files.

== '''Removing the developer tools and kernel sources''' ==

(from clarkconnect newbie portal: http://newbie.valar.co.uk/)
Removing the developer tools

If your ClarkConnect box is accessible via the internet (HTTP, FTP, etc), it's highly advised that you uninstall the developer tools once you're done compiling. Since the command apt-get remove cc-devel doesn't actually remove anything, use the following procedure to remove the developer tools from your system.

1) Using the editor nano, create a script file on your ClarkConnect machine and then open it for editing in the nano editor:

Code:
----
touch ~/cc-devel-remove.sh
nano ~/cc-devel-remove.sh
----

2) Copy the code below into the nano editor, save the altered file to disk (CTRL-O), and then exit nano (CTRL-X)

Code:
----
#!/bin/bash
clear
echo -n "Removing the ClarkConnect developer tools "
apt-get remove -y cc-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps autoconf > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps automake > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps binutils > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps bison > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps byacc > /dev/null 2>&1 echo -n "."
rpm -e --nodeps bzip2-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps cpp > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps gcc > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps gcc-c++ > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps gcc-java > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps gettext > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps glibc-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps glibc-kernheaders > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps gmp > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps krb5-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps libgcj > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps libgcj-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps libstdc++-devel > /dev/null 2>&1 ; echo -n ""
rpm -e --nodeps libtool > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps m4 > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps make > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps ncurses-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps openssl-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps pam-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps patch > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps python > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps rpm-build > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps zlib-devel > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps kernel-source > /dev/null 2>&1 ; echo -n "."
rpm -e --nodeps perl-CPAN > /dev/null 2>&1 ; echo -n "."
apt-get autoclean > /dev/null 2>&1 ; echo -n "."
apt-get clean > /dev/null 2>&1 ; echo -n "."
echo -e '\E[32;40m' Complete ; tput sgr0 ; echo ""
----

3) Make the script owned and executable by root, run it, and then remove it from your machine.

Code:
----
cd ~
chmod 0700 cc-devel-remove.sh
./cc-devel-remove.sh
rm -f cc-devel-remove.sh
----
Removing the kernel sources
Code:
----
apt-get clean
apt-get remove kernel-source
----
<br><br>
== '''GNU Free Documentation License''' ==

'''GNU Free Documentation License Version 1.2, November 2002'''
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

README

Pclaassen — Wed, 31 May 2006 07:50:00 GMT

Summary: /* Contact us: */

Installation and configuration instructions for the rt2x00 Modules

==This information is now obsolete==

- Kernel

* Most (if not all) major distributions have now the rt2x00 in-kernel driver available by default in their build.
* This availability means essentially that all the previous efforts to maintain a driver off kernel are no longer needed.

==Bug reporting:==

When reporting a bug or problem with the rt2x00 module,
make sure you report the following information:

# How to reproduce
# RT2x00 debug output, usually found in /var/log/messages.
# Module version.
# Wireless card chipset, model and manufacturer.
# Kernel version (i.e. 2.6.13)
# Hardware architecture (i.e. x86, AMD64, Sparc)
# Anything else you may think will help us resolve the issue.

==Bug reports:==
http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00Wiki:Bug_reports

==Contact us:==

- Website

# http://rt2x00.serialmonkey.com/
# wireless information http://linuxwireless.org

- Forums:

# http://rt2x00.serialmonkey.com/phpBB2/

- Mailing list:

# http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com

==rt2x00 FAQ:==

This guide was put together to help people who are testing the rt2x00 suite of drives during the development phase. Please note that at this moment in time, the drivers are still in development and does not conform to the normal Linux wireless configuration process (you have to do special steps to get them going) nor are the drivers particularly stable. DO NOT USE THESE DRIVERS IN A PRODUCTION ENVIRONMENT (refer to the stable branch for the rt2500 and rt2400 drivers)

===I cannot see any debug information===

Have you compiled the drivers with “make debug” and have you modprobed the driver (rt{4|5}00{pci|usb} with debug=1? e.g. “modprobe rt2500pci debug=1”

===The steps in the readme doesn't work===

Have you following the steps verbatim (obviously substituting your network vars such as AP bessid and channel for your values)? This is a requirement at the moment since some of the functions in the card need to be initialised using the steps described in the README. Note that the driver does not comform to the normal wireless configuration process in that you will not be associated with an access point unless you follow the steps in the README.

(check http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00Wiki:Bug_reports#Bug_No:_003)

===I have a wep encrypted network===

If you need to add WEP encryption add the following step after setting the essid (where AABBCCDDEE is your 48 bit encryption key in HEX)
$iwconfig wlan0 key AABBCCDDEE

===How do I know things worked?===

You should see something like the following in dmesg:
[4439180.426000] wlan0: associate with AP 00:50:18:36:b8:36
[4439180.428000] wlan0: RX ReassocResp from 00:50:18:36:b8:36 (capab=0x431 status=0 aid=2)
[4439180.428000] wlan0: associated

===dmesg shows an authentication message time out===

If you get something like below, makes sure that you have following the README verbatim and specifically that you set the channel and iwlist wlan0 scan. These steps are required to initialize the card properly.
<pre>
[4438543.721000] wlan0: Initial auth_alg=0
[4438543.721000] wlan0: authenticate with AP 00:50:18:36:b8:36
[4438543.921000] wlan0: authenticate with AP 00:50:18:36:b8:36
[4438544.121000] wlan0: authenticate with AP 00:50:18:36:b8:36
[4438544.321000] wlan0: authentication with AP 00:50:18:36:b8:36 timed out
</pre>

===I have done everything but still cannot associate with the ap?===

Try lowering your channel on your access point as this might be a regional problem.

(check http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00Wiki:Bug_reports#Bug_No:_004)

===I loose association===

Sometimes you see this in dmesg
[4439570.806000] wlan0: RX deauthentication from 00:50:18:36:b8:36 (reason=6)
[4439570.806000] wlan0: deauthenticated

I don't know what reason 6 means yet.

===I cannot associate and get timed out messages in dmesg===

[4321475.171000] wlan0: Initial auth_alg=0
[4321475.171000] wlan0: authenticate with AP 00:50:18:36:b8:36
[4321475.371000] wlan0: authenticate with AP 00:50:18:36:b8:36
[4321475.571000] wlan0: authenticate with AP 00:50:18:36:b8:36
[4321475.771000] wlan0: authentication with AP 00:50:18:36:b8:36 timed out

You are either out of range of the AP or you have the same problem as me at the moment (will update this guide as soon as I figure out what it is)

===I have a debian based system. What about moving the modules?===

The issue here is that once you compile your new modules, they are installed in the root of your module tree (normally /lib/modules/2.6.xx-xx/rt2x00/). However, your old modules are still around in the tree and you have one of two options:

# Move the old modules out of the tree and leave your newly compiled modules where they are.
# Copy your new modules over your old ones.

'''BEWARE''' if you delete or overwrite the old modules and your new driver doesn't work the way you thought it would, then you will have to reinstall the kernel package (or boot up on an old kernel with the modules still intact) to get your old modules back. If you require a network connection in order to do this, then you might have a problem, so best strategy is to copy these items away.

===make in the folder root fails===

Makefile:52: /lib/modules/2.6.15-23-686/build/.config: No such file or directory

make: *** No rule to make target `/lib/modules/2.6.15-23-686/build/.config'. Stop.

The message is not always exactly the same since it is dependent on your kernel version. You need to install the development headers that will supply the file in question (/lib/modules/2.6.xxxxxx/build/.config).

If you have a debian based system, install the linux-headers-2.6.xxxxx package that conforms to your installed kernel

To find out your kernel version

$ uname -r

to install the headers

$ sudo apt-get install linux-headers-`uname -r`

===Statistics don't work===

Statistics have not received a high priority yet and many tools don't work correctly. We are looking for debugging information to help us identify the problem. See the debug howto on how to produce this information.

There is also currently a bug in the dscape stack and the wireless interface is not reported correctly in proc with the result that many tools does not detect the interface correctly.

This has consequences for report generation and configuration by many existing tools.

(check http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00Wiki:Bug_reports#Bug_No:001)

Documentation

Pclaassen — Wed, 31 May 2006 07:37:07 GMT

Summary:

==rt2x00 Documentation (DRAFT)==

*[[rt2x00 README]]
*[[rt2x00 Technical architecture overview]]
*[[rt2x00 Feature listing]]
*[[rt2x00 User Guide]] (covering device-specific configurations, things outside the standard config that should be covered in the DeviceScape stack)
*[[rt2x00 Ubuntu Howto]]
*[[rt2x00 Fedora Howto]]
*[[rt2x00 Gentoo Howto]]
*[[rt2x00 Project Roadmap]]
*[[rt2x00 Debugging and Testing Guide]]

Rt2570 GIT kernel integration, complete version

Hlovdal — Mon, 03 Apr 2006 20:17:57 GMT

Summary: Initial version, empty place holder

Unfortunately I am quite busy for the time being, so it will take some time
before I have the guide transformed into wiki format.

However I initially made the guide as a standalone html file (with pictures), so as a temporarily solution you can download a copy here [http://hlovdal.dyndns.org:8080/2006/rt2570/git-out-of-tree-driver-maintenance_2006-03-12.zip].

Rt2570 GIT kernel integration, simple version

Hlovdal — Mon, 03 Apr 2006 19:43:44 GMT

Summary: Initial version, dummy place holder

Not done yet, see [[Rt2570_GIT_kernel_integration%2C_complete_version|here]] until then.

Rt2570 GIT kernel integration Guide

Hlovdal — Mon, 03 Apr 2006 19:35:03 GMT

Summary: rewording

<h2>Welcome!</h2>
The contents of this guide should provide you with knowledge of

# How to integrate an out-of-kernel driver into the kernel
# How to keep your integrated driver in sync with the kernel as new kernel versions are coming.

So no more clumsy additional driver module compilation, just the normal
<tt>make modules</tt>. And if the driver was released several months ago against
an older kernel version, you can still pull the latest and greatest version from
Linus' git repository and use that. The latter might require some effort
on your part, but the good news is that the tools are there to support
you 100% and the guide will explain how.

<h2>Guides</h2>

Initially I wrote one one rather large guide but I have decided to
fork it into two versions:

* One [[Rt2570_GIT_kernel_integration,_simple_version|simple version]] which tries to respond to the following desire "OK, so I just want the rt2570 driver integrated into the latest version of the kernel tree. What are the minimum steps I have to make?"
* One [[Rt2570_GIT_kernel_integration,_complete_version|complete version]] which deals updating the source code, both for the kernel and for the driver.

<h2>Git</h2>

The creation of git[http://en.wikipedia.org/wiki/Git_%28software%29]
was the single most important event in 2005 for linux kernel development.
Nothing else compares. With git almost a new world of source control
possibilities with branching and merging opens up for the free/OSS
community. So if you have not already installed and started
to get familiar with git yet you should do so right away.

''Although this guide is written using the rt2570 driver, it should be applicable for any other driver, patch or set of patches that are not integrated into the standard kernel.''

Donations

Luis — Mon, 20 Feb 2006 09:51:04 GMT

Summary:

Eric Spakman from [http://leaf.sf.net/bering-uclibc Bering uClibc Project], has donated a Linksys WAP11.<br><br>

It's Broke

Serialmonkey — Tue, 23 Aug 2005 21:38:46 GMT

Summary:

=Troubleshooting Tips for rt2500=

# If you have SMP enabled, turn it off
# Read Module\TESTING and see how to post a DEBUG trace.
# If you have run RaConfig and/or have a /etc/Wireless/Ralink/..... directory structure then delete it, don't use RaConfig, and try to configure using the command line utilities (iwconfig, ifconfig)

=Troubleshooting Tips for rt2570=

# Stability issues can be addressed by disabling USB2.0 (ehci) and dropping back to USB1.1 (ohci). You can do this by blacklisting the ehci module
# If you have SMP enabled, turn it off
# If you have PREEMPT enabled, turn it off

=Common Troubleshooting Tips=

# If you are getting a hard panic (system freeze) then you should recompile your kernel with SYSRQ enabled, exit of out X11, enable SYSRQ (cat 1 > /proc/sys/kernel/sysrq) and then reproduce the issue from the command line and post a SYSRQ+ALT+P trace.

Mandrake 10 rt2570 Howto

Serialmonkey — Mon, 08 Aug 2005 00:19:59 GMT

Summary:

Mandrake 10 (2005 Limited) HowTo for RT2750 USB stick

by John Halfpenny

Firstly I'd like to give credit to Phillipe's Mandrake guide which got me
started on this, and a few of the bits near the beginning are the same as his
HowTo. Unfortunately that guide wouldn't get the usb stick working for me
(probably as it's for a different driver entirely, and I suspect a different
release of MDK), so here's a quick guide to how I got the usb wireless going
on my vaio.

I don't use any other packages here, this will just launch the wireless on
boot and have you up and running by the time KDE (or Gnome if you must - ;-))
comes on.

Open a terminal and log in as root

# su - root password

Download the nightly tarball and extract to /usr/src

# cd /usr/src
# wget http://rt2x00.serialmonkey.com/rt2570-cvs-daily.tar.gz
# tar zvxf rtxxxxx.tar.gz

Make sure you have the kernel source in /usr/src

# rpm -qa | grep kernel
kernel-2.6.11.6mdk-1-1mdk
kernel-source-2.6-2.6.11-6mdk

If you don't then you can install it with all necessary links from System /
Configuration / Packaging / Install software on KDE. Do a filter on 'kernel'
and it should pop up- I'd also advise installing this from the CD you used to
install Mandrake, just to make sure the versions don't get jumbled up.

Compile the module

# cd /usr/src/rtxxxxx/Module
# make
...
# make install
...

Now the module will have probably been placed in /lib/modules/(kernelversion)
custom/extra, this is wrong and you can't modprobe if you leave it there, so
we need to move it to /lib/modules/(kernelversion)/kernel/drivers/net/wireless/

# cp /lib/modules/(kernelversion)custom/extra/rt2570.ko /lib/modules/(kernelversion)/kernel/drivers/net/wireless/
# insmod /lib/modules/2.6.11-6mdk/kernel/drivers/net/wireless/rt2570.ko
# depmod -a

Now I've got a habit of rebooting machines when I do things like this, so
whether or not you choose to is up to you- but this guide presumes you have.
Open up another root terminal when the PC comes back up. Type this to make
sure the module is loaded ok, if no error is returned then it looks like we're
ok.

# modprobe rt2570

You can then configure your wireless card by writing a script for the device

# vi /etc/sysconfig/network-scripts/ifcfg-rausb0

Mine looks like this

DEVICE=rausb0
BOOTPROTO=static
IPADDR=10.4.0.6
BROADCAST=10.255.255.255
NETMASK=255.0.0.0
NETWORK=10.0.0.0
GATEWAY=10.4.0.1
WIRELESS=yes
ONBOOT=yes

This will keep the settings for the device for when you use the ifup-rausb0
statement. It will activate the device on boot, you can set this to no if you
move about with your laptop- I would advise not running the USB stick with
another activated network card though, so whenever you use the USB wireless,
try to remember to do a ifdown-eth0 or similar.

That's it if you don't use authentication!

If you use PSK, then you will need a further script to set the parameters for
that. My experiences of the PSK haven't been *excellent* but it does work, it
can be a bit fiddly though (at time of writing driver version 1.0.0), the
sleep statements in the script certainly help things along a bit.

# vi /etc/init.d/wireless-script

iwpriv rausb0 enc 3
iwpriv rausb0 auth 3
iwconfig rausb0 essid "your wireless network name"
sleep 1
iwpriv rausb0 wpapsk "your top secret password"
sleep 1
iwconfig rausb0 essid "your wireless network name"

For a full list of the config options for the card, you may need to download
the driver from ralink and look through the readme. This example only covers
PSK as it's what I use to stop my neighbours freeloading off my broadband
connection ;-).

OK, let's get the script to load automatically when we reboot

# chmod +x /etc/init.d/wireless-script
# vi /etc/rc.local

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

/etc/init.d/wireless-script

There you go! If you go to a root terminal you can check your interface is up
and running, it should also appear in the connection watcher on KDE (though
obviously this doesn't show anything about the PSK working or not).

John

Roadmap

Serialmonkey — Sat, 23 Jul 2005 05:04:44 GMT

Summary: /* Legacy Drivers */

Below is a rough outline of our current project roadmap. It covers the area's where we are currently focusing our development efforts.

==Legacy Drivers==

Support for the legacy drivers will end in April 24th 2009.

==rt2x00 Redevelopment Project==

We currently are also working on a complete driver rewrite - dubbed the rt2x00 project. This driver has been designed and written from the ground up, based on the mac80211-stack (new wireless stack).
This driver supports all current Ralink chipsets except for the 11n capable devices.
This driver is included in mainline linux and is the future of this project. If you are interested in the status of it you can [[Rt2x00_GIT_instructions|grab it using git]], read the [[Help:Contents|documentation]]. The most up to date list of issues and work in progress can probably be found on the [[Todo]] page.