OpenWrt Forum Archive

Topic: Howto: Wifi wifh current kamikaze checkout (kernel 2.6) on WL500 GP V1

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi there,

I want to share what I needed to do to get WIFI working on WL500 GP V1 with a recent checkout of kamikaze:
(in my case r18759 - which is Kernel 2.6.30-10)

I have built my kamikaze image without a wifi driver, because I want to be more flexible.
-> However I only use the kernel-modules which get compiled with the firmware. - No kernel modules from a repository.


Broadcom (B43) -> Broadcom Chipsets

As mentioned on the WL500 GP V1 hardware page - The origial "ASUS WL-120G Wifi" which has a Broadcom chipset does not work with Kernel 2.6. Wrong! It works in the meantime. The hardware wiki page just hasn't been updated.

You need the following kernel modules:
* wireless-tools
* kmod-b43
* kmod-b43legacy
(And a few dependencies - opkg will tell you which ones)

now read on at the "COMMON" section below


Madwifi -> Atheros chipsets

If your have already installed a Wifi Card with an atheros chipset and successfully use MADWIFI ("kmod-madwifi") with the current kamikaze trunk, you are a lucky person, because on some wifi setups, the infamous "stuck beacon" problem has returned.

How the problem shows? Simple: Your WIFI connection is stable, however when you use a channel with many disturbances and push a lot of data through your wifi-connection, after a few seconds your data-rate suddenly drops and sometimes completely stalls. And it never recovers to normal until you reboot or restart wifi.
When you do "dmesg" on your router, you will find many "stuck beacon" messages. Believe me, using options in /etc/config/wireless help a little bit, but do not eliminate the problem. And you will only sleep well if those messages don't appear anymore.

The problem is known for years and has never been fully sorted out. Since madwifi contains proprietary closed code, and the new open source drivers ATH5K / ATH9K are getting stable, it is likely that this problem will never be sorted out.

Some say that reverting to an old version of madwifi helps, but I cannot confirm this.
The main problem with reverting to an older madwifi version is that it needs to be patched to compile with a new kernel.

To sum up: If you encounter the "stuck beacon" problem, you should consider turning your back on madwifi, (And try using ATH5K / ATK9K instead) or switch back to the original broadcom card, or use white russian or kernel 2.4.

If you want to try nevertheless, install the module
* kmod-madwifi

now read on at the "COMMON" section below


ATH5K -> Atheros chipsets

You need the following kernel modules
* kmod-ath
* kmod-ath5k
(And a few dependencies - opkg will tell you which ones)
now read on at the "COMMON" section below

(Does not work with my TP-Link TL-WN861N)


ATH9K -> Atheros chipsets

You need the following kernel modules
* kmod-ath
* kmod-ath9k
(And a few dependencies - opkg will tell you which ones)
now read on at the "COMMON" section below

(Works with my TP-Link TL-WN861N)



You also need the following to have WPA-encryption:
* wpa-supplicant
* hostapd-mini

Copy the modules from your kamikaze/bin/brcm47xx/packages directory to your box with "scp" and install them using "opkg install foo.ipkg"

Remove the "other" wifi kernel modules which you don't need with "opkg remove foo"

now reboot your box.
Most likely openwrt will have automatically updated your /etc/config/wireless file. However sometimes this doesn't work. So you might want to do the following:

wifi down
rm /etc/config/wireless
wifi detect

You will see the default-configuration which most likely works with your driver. Should look somehow like this:

config wifi-device  radio0
        option type     mac80211
        option channel  5
        option macaddr  00:1b:fc:91:8f:eb
        option hwmode   11g
        option disabled 1

config wifi-iface
        option device   radio0
        option network  lan
        option mode     ap
        option ssid     red
        option encryption       none

If nothing is displayed, the driver probably does not support the card. -> try a diffent driver or card.
Oterwise do

wifi detect > /etc/config/wireless

and edit the file with "vi".

1) Delete the "option disabled 1" line
2) Set "option ssid" to your wlan name.
3) If you have installed wpa-supplicant, you can change "option encryption none" to "option encryption psk" or "option encryption psk2" for WPA or WPA2 and add an additional line: "option key mysecretkey"
4) Important Note: When using ATH9K, the script will suggest "option hwmode 11ng". That didn't work with my "TP-Link TL-WN861N" card. I had to change it to "option hwmode 11g".

Now do:

wifi up

and wifi should be working. Then you can start fiddling with the other options in there and do "wifi up" to reinitialize wifi.

If if does not work, you might want to do "dmesg" to view the most recent kernel messages.


Oh, another thing: Your clients will not always get their IP addresses via dhcp from your router. DHCP only works on your wifi interface, if wifi was brought up on boot. So reboot instead of doing "wifi up" after fiddling with your config or assign an IP address manually on your wifi clients (for testing).


I currently use the "old" broadcom "ASUS WL-120G" wifi card, because transfers are faster when using ssh. Maybe the b43 does encryption in hardware while the ath9k does not? Maybe, don't know. Might be a different problem...

lg, Mr.M

Thank you!
This is the post i was looking for for month.
But, one question is still not answered:
is the wifi connection with the original wlan card from asus stable?

Hi there frosch6669,

Concerning the stability of the b43 driver with the original "ASUS WL-120G Wifi" card:

Well, I haven't done any long-term test, however I tried the following.
1) Permanently ping the router.
2) Unscrew the antenna(!) of the router and walk away 10 meters.
3) scp a file to the router

Iwconfig on the notebook then shows me
          Link Quality=42/100  Signal level:-84 dBm  Noise level=-86 dBm
Ifconfig gives me:
          RX packets:16702 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29122 errors:0 dropped:0 overruns:0 carrier:0

No dmesg-entries
No lost pings.
SCP drops to half the usual transfer rate.

So I guess it is stable.
I did use WPA(1).

However I can't test if it works well it in a high density wifi site, because there is not that much traffic in the air around me.
Seems to work with windows too. (but please don't ask me with which card / driver / tool /... )

lg, Mr.M

I have a WL-500W (which is almost the same as WL-500GPv1) and have tried running kernel 2.6 from latest trunk. Results are rather poor.
The systems boots up, Ethernet is working fine but wireless connection is terrible. Honestly I haven't tried using original Broadcom wireless, because everywhere it is written that it does not work under 2.6 kernel. So I bought a Atheros based card - TP-Link TL-WN961N.
The card is discovered correctly by the system and I can even start up it in an AP mode. Even more I can see it supports N-speeds so look wonderful wink. But stability is horrible sad. Although it says AP can support N speed I couldn't get more then 18Mbps of real transfer which is actually what G standard can achieve. Additionally device was getting a 100% load at the time of speed test.
One more thing is that clients with Intel based wireless cards (non N-speed) where getting huge packet loss and/or delay. After investigating I found out that the problem was a 802.11G standard, when switched to 802.11B the connection was quite stable.
I was also getting system hangs from time to time.

So, after about a month of adventure with 2.6 kernel and Atheros wireless card I switched back to Broadcom card and 2.4 kernel where everything works perfectly (almost wink )

Hope the topic will be updated from time to time by others with their comments

christmas is coming, snow outside -> best time to do some hacking!
So, first thanks for the answers.
I will try it the next week, with the original card, at the moment i am running a trunk version from before 8.09->
wifi is not stable an i got a lot of dmesg spam from the b43 module.
i bought 2 ram chips fpr upgrading the wl500gp to 128mb ram, but befor doing that i realized the following tickets/changes: which says it shoud work


which i do not understand.

What do you think about that? I do not want to kill my asus.

Greetings from hamburg/germany-> with snow ;-)


Soldering memory chips? Hmm, nice wintertime party. Just be carefull! This is not as easy as it looks first.

Btw... I have an ASUS WL500-GP v1.

Latest trunk works fine, but I don't know what am I forgot from it, cos the hide SSID option in Luci is totally disappeared. Any info about it?

Thanks wink

I also played with the idea of fitting 64MB RAM chips. Actually I have already unsoldered four of them.

If my routers were no WL500GP V1 ones, I would give it a try, however those two are just to valuable to me, so I won't risk it.
Maybe you want to buy a 4Gig usb-stick and put a 128MB swap partition on it. I am pretty sure that you will get bored with using openwrt before the first stick is worn out. smile

SMD soldering is pretty nasty, because it is very easy to ruin something:
A) When unsoldering the chips from the module: The chip with too much heat.
B) When unsoldering the chips from the router: The pads with too much heat or too much force
C) When soldering the new RAM in: The chip and the pads with too much heat.
And even if you managed not to ruin everything -> did you work clean enough to have no capacitance problems?

However if you really want to do it... (don't blame me)

I really urge you to use a good soldering iron with heat calibration and leaded(!) Solder. Find out the exact temperature at which the used solder on the PCB melts. When you can't get some solder on the PCB to melt (at that temperature), use a tiny amout of your own leaded solder to transfer the heat to the PCB-solder faster.

Try the copper wire trick when unsoldering the chips from the ram-module:
  1) Buy a very thin wire which is used for creating coils. (or disassemble a mechanic relay)
  2) Fiddle the copper wire from one side of the chip underneath one of the pin-rows to the other side of the chip. (and fixate one end of the wire eg. by soldering the end to something unimportant)
  3) Heat the first pin (on the loose side) with your soldering iron and pull the copper wire gently so that it "slips through" between the pad and the pin.
  4) Goto step 3 for next pin.
  5) Goto step 2 for the other pin-row.
  6) Do the same for the second chip.
This way the chips will hardly get warm.
Then clean the chips by putting leaded solder on the pins and remove it with the vaccum-tool. (Don't heat the pins too long - Do this for just a few pins at a time)

To unsolder the chips from the router you can do the same as above, however the problem is that if you pull the copper wire too hard, you might rip a pad off the PCB -> R.I.P.

... or you can try doing it the "rude" way:
Take one of those dremel-like tools (sorry, don't know how to describe differently) and cut all pins off the chips. (try to cut near the chip)
You should use extreme caution here of course, or you will cut through the signal lines below. -> R.I.P.
The chips will be destroyed of course, however the pads will still be intact.
Now only the pins of the chip remain on the board.
Put leaded solder on the pins and use the vaccum-tool to remove the pins with the solder. (Do not overheat the pads or heat the pads too long, or you will vacuum them too. -> just a few pins at a time)
When you are done, there will be enough leaded solder left on the pads. Just place the cleaned chip on the pads and solder them on pin by pin (do not use extra solder!) The second pin you solder should be the one on the opposite side of the chip.

Use a lot of this special PCB-Cleaner to get rid of the flux to minimize capacitance problems.

I still wouldn't do it, if I were you smile

lg, Mr.M

(Last edited by mr.m on 20 Dec 2009, 03:01)

got this from the release notes of the latest 8.09.2 Note: The brcm47xx still won't work for those of you needing broadcom wifi, stick to brcm-2.4.
We will tell you when it does work.

that actually matches my experiences :-( there is faith in "trying before reading".


Thank's for your guide Mr.M, I used parts of it successfully to update my STA-Bridge/Route to Backfire 10.03.1-RC3 on my WL500GP v1 with a Toshiba WLL4071-D4 AR5006G replacement-card. I am now posting this connected to the lan-port of my OpenWRT Box using Ath5k drivers, which in turn is a client of a WPA2 PSK remote-router!

This configuration uses a virtual interface to separate the wireless-master-connection (e.g. uplink to internet through other router) from the local network (I usually have another router connected to my OpenWRT box, which I then use to create my own network at home) with a different subnet. When this virtual interface is set up to use dhcp, it is possible to transparently jump between available access-points without changing anything on my home-network. Might be useful together with AAP or something the-like.

|ISP| = |Remote Router| - |OpenWRT| - |Other Wi-Fi Router|
               |                               |
        LAN (subnet #1)                LAN (subnet #2)

Steps taken:
Update to usual 2.6 backfire release for Broadcom (openwrt-brcm47xx-squashfs.trx), using "mtd -r write <firmware.trx> linux" from a CIFS-share on my Mac.
telnet into the box; passwd; vi /etc/opkg.conf (set to my local mirror);

opkg remove kmod-b43 kmod-b43legacy wpad-mini

opkg install kmod-ath kmod-ath5k wpa-supplicant

wifi down
rm /etc/config/wireless
wifi detect > /etc/config/wireless

Create a virtual interface by adding this to /etc/config/network

/etc/config/network wrote:

#### AIRWIRE config
config interface        airwire
        option ifname   radio0
        option proto    dhcp

I also changed the IP Address of lan to my personal subnet (different from the wireless: i.e. 192.168.100.x) and turned off WAN (proto none)

My /etc/config/wireless looks like this:

/etc/config/wireless wrote:

config wifi-device  radio0
        option type     mac80211
        option channel  1
        option macaddr  00:11:xx:xx:xx:xx
        option hwmode   11g

#       option disabled 1

config wifi-iface
        option device   radio0
        option network  airwire
        option mode     sta
        option ssid     ChooseYourPoison
        option encryption psk2
        option key      XXXXXXXXXX

Note that the network is set to airwire (the virtual interface that we added to /etc/config/network). Don't ask me about radio0, that's just the default output from wifi detect.

my /etc/config/firewall looks like this (it's propably [s]more[/s] less than sub-optimal, but it does work; please provide a meaningful fix if you have the time!):

/etc/config/firewall wrote:

config defaults
        option syn_flood        1
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT
        option drop_invalid     0

config zone
        option name             lan
        option network  lan
        option input    ACCEPT
        option output   ACCEPT
        option forward  ACCEPT
        option masq     1

config zone
        option name             airwire
        option network  airwire
        option input    ACCEPT
        option output   ACCEPT
        option forward  ACCEPT
        option masq             1

config zone
        option name             wan
        option input    REJECT
        option output   ACCEPT
        option forward  REJECT
        option masq             1
        option mtu_fix  1

config forwarding
        option src      lan
        option dest     airwire

Do all this and then
/etc/init.d/network restart and watch your OpenWRT box get an IP address from the other AP.
Hope this helps, enjoy!

Edit: I just realized that the thread was for Kamikaze, I will allow myself the liberty to double-post this reply as a new how-to for backfire.

(Last edited by ==qp== on 16 Sep 2010, 20:28)

mr.m wrote:

Hi there,


ATH9K -> Atheros chipsets

You need the following kernel modules
* kmod-ath
* kmod-ath9k
(And a few dependencies - opkg will tell you which ones)
now read on at the "COMMON" section below

(Works with my TP-Link TL-WN861N)


lg, Mr.M

Hi, I am encouraged by your post that ath9k driver supports TL-WN861N.
Could you please provide other brands and model lnumber of cards that
are fully supported by ath9k?



The discussion might have continued from here.