# [Working!] USB/wi-fi ASUS WL-167G on Acer laptop

## Sir No

Wow! It's been amazing two days, and now I have my USB wi-fi (ASUS WL-167G) working! And it was easier than I ever thought...  :Very Happy: 

Now, back to the point. I've used the following resources:

Search results for ndiswrapper - Gentoo Linux Wiki

HARDWARE Gentoo Acer Travelmate 803LCi Manual - Gentoo Linux Wiki

HOWTO Wireless Configuration and Startup - Gentoo Linux Wiki (little outdated)

HARDWARE rt2500 - Gentoo Linux Wiki

List - NdisWrapper (this one kept me believe that it's possible at all)

Gentoo Handbook x86 - Gentoo Network Configuration - Wireless Networking (rocks!)

Yesterday I emerged ndiswrapper. To my surprise the card was working after simply installing the WinXP drivers (via ndiswrapper -i <inf_file>) and loading the necessary module (via modprobe ndiswrapper). At first I've tried to add the "log2_irq_thresh=4" option for the ehci_hcd module, to get rid of USB errors (but it created some problems and was in fact unnecessary - see below). Then modules-update and finally restart - not too complicated IMHO.

Today I configured the wlan0 interface and connected it to the ad-hoc wi-fi network, hosted on my wife's WinXP box. Following the Wireless Networking Guide was also quite simple (config_wlan0=( "dhcp" ) is the best!). Then a link /etc/init.d/net.wlan0 -> net.lo, then /etc/init.d/net.wlan0 start and then... To my surprise, everything worked! So I was able to type this!  :Mr. Green: 

Great, great compliments to the Gentoo team, and especially the networking team!!!

Good Job!

EDIT:

Recently it turned out that adding the "log2_irq_thresh=4" option for the ehci_hcd module was not so good idea. After that my USB external drive started to working veeery slooowly. I removed this option, installed a newer kernel (right now it's 2.6.14-r2) and newer ndiswrapper (1.5). Now the Wi-Fi works correctly and the USB drive is as fast as it should be. So, remember to do upgrades! That's the moral of this story.

----------

## wiflye81

Hi,

I have also tried to install my wl-167g with ndiswrapper but no success, it seems to be a driver problem, can you tell me which driver and version you use ?

Thx

----------

## Sir No

 *wiflye81 wrote:*   

> Hi,
> 
> I have also tried to install my wl-167g with ndiswrapper but no success, it seems to be a driver problem, can you tell me which driver and version you use ?
> 
> Thx

 

For me it's:the rt2500usb.sys driver that came on the driver CD (08/13/2004, 1.02.01.0000 - DriverVer key from rt2500usb.inf file)

net-wireless/ndiswrapper-1.5

sys-kernel/gentoo-sources-2.6.14.5

What exactly did go wrong in your case?

----------

## SirYes

Only recently I've found a wireless misconfiguration problem. Diagnosis was simple, but it took a looong time to find the solution...

I was using a simple ad-hoc configuration to connect my laptop (Gentoo) to the family workstation (WinXP, internet connection sharing) at home. On the workstation I set up a WEP encryption with shared authentication and automatic key generation with a passphrase. All was working well (WinXP->WinXP and Gentoo->WinXP) until at some point in time it stopped - so I was unable to connect Gentoo to the network anymore.

To cut the long story short, it turned out that automatic key generation with a passphrase is no longer supported in Gentoo. After assigning the key manually on the WinXP box, all came back to normal.  :Smile: 

The funny thing is, the final configuration on the Gentoo side turned out to be exactly the same as it was before I started diagnosing this problem.  :Wink: 

So, that was NOT a driver issue, ndiswrapper issue, hardware issue, mysterious change in Windows after some update, but simply a discontinued support of the passphrase in the Gentoo networking setup. I deduced that after spotting the "Passphrase IS NOT supported" notification in /etc/conf.d/wireless.example file...

So, it's a hint for the people in a similar situation and also a reminder to always read the fine documentation!  :Very Happy: 

----------

## SirYes

@wiflye81:

Only recently I've updated the ndiswrapper along with the kernel. I unmerged ndiswrapper-1.7 first, removed its dir /etc/ndiswrapper then emerged ndiswrapper-1.8 and installed rt2500usb.[inf/sys]. After all the device was not recognized anymore!

It turned out that the new ndiswrapper is sensitive to the order of entries in the inf file. I moved the Asus entries to the front and then installation of the driver (ndiswrapper -i) proved to be successful. Here are the details:

After inserting the card, it's identified as:

```
 # lsusb

Bus 003 Device 002: ID 0b05:1706 ASUSTek Computer, Inc.

Bus 003 Device 001: ID 0000:0000

Bus 002 Device 001: ID 0000:0000

Bus 001 Device 001: ID 0000:0000
```

After installing the original rt2500usb.inf file, the /etc/ndiswrapper dir contains:

```
# ndiswrapper -i rt2500usb.inf

# ls /etc/ndiswrapper/rt2500usb

148F:2570.F.conf  rt2500usb.inf  rt2500usb.sys
```

Hmm. But '148F:2570.F.conf' is not the right one! It should be something like '0B05:1706.F.conf'...

Let's see. In the rt2500usb.inf file there's something:

```
# cat rt2500usb.inf

...

[Manufacturer]

%Ralink%        = Ralink

%Amigo%         = Amigo

%MSI%           = MSI

%SMC%           = SMC

%ASUS%          = ASUS

[Ralink]

; DisplayName               Section                 DeviceID

; -----------               -------                 --------

%Ralink.DeviceDesc%         = RALINK.ndi,           USB\VID_148F&PID_2570

...

[ASUS]

; DisplayName               Section                 DeviceID

; -----------               -------                 --------

%ASUS.DeviceDesc%           = ASUS.ndi,             USB\VID_0B05&PID_1706

%ASUSGEN.DeviceDesc%        = ASUSGEN.ndi,          USB\VID_0B05&PID_1707

```

I've tried to modify the [Manufacturer] section, namely I've moved the ASUS line to the front:

```
[Manufacturer]

%ASUS%          = ASUS

%Ralink%        = Ralink

%Amigo%         = Amigo

%MSI%           = MSI

%SMC%           = SMC
```

Then installation:

```
# ndiswrapper -i rt2500usb.inf

# ls /etc/ndiswrapper/rt2500usb

0B05:1706.F.conf  0B05:1707.F.conf  rt2500usb.inf  rt2500usb.sys
```

And that's about it. The device works again as it should.  :Smile: 

IIRC the previous ndiswrapper made a symlink like '148F:2570.F.conf' -> '0B05:1706.F.conf' so both configurations were valid. This has changed with the new ndiswrapper (or maybe I installed the driver WITHOUT the card inserted?) Anyway, the workaround is simple.

And that's all folks!  :Very Happy: 

----------

## ricei

ASUS releases the driver source code specifically for this dongle. Why are people using ndiswrapper ?

I ask because I was thinking of buying this dongle but I need to know if there is a problem with the ASUS drivers as I will not be able to use ndiswrapper.

----------

## SirYes

 *ricei wrote:*   

> ASUS releases the driver source code specifically for this dongle. Why are people using ndiswrapper ?
> 
> I ask because I was thinking of buying this dongle but I need to know if there is a problem with the ASUS drivers as I will not be able to use ndiswrapper.

 

Wow! Since when is ASUS doing that? Could you provide a link or something?

Thanks in advance.

PS.

When using ndiswrapper all works fine, really. Even if I had the ASUS Linux driver, I'm not sure if I really would use it, since I agree with the "If It Ain't Broke Don't Fix It" rule.

----------

## ricei

http://dlsvr02.asus.com/pub/ASUS/wireless/WL-167g/SourceCode-V2040.zip

I'd be interested to know how well this works.

----------

## SirYes

Only recently my wireless card started to behave oddly. To be honest, dhcpcd stopped working suddenly. Checking the wlan0 network interface by using ethereal gave me the impression that my laptop was asking for an address but never got any valid answer from the Windows machine that was supposed to provide it.  :Shocked: 

It took me a bit longer than expected, but I've finally figured out that it's one of the kernel options (!) that was responsible for this. In fact such options are specified in the /etc/sysctl.conf file. So it looks like some Gentoo folks decided that it would be safer to enable the net.ipv4.conf.all.rp_filter option. But look at the marked part from the following article:

http://www.linuxsecurity.com/content/view/111337/65/

 *David Lechnyr wrote:*   

> The rp_filter can reject incoming packets if their source address doesn't match the network interface that they're arriving on, which helps to prevent IP spoofing. Turning this on, however, has its consequences: If your host has several IP addresses on different interfaces, or if your single interface has multiple IP addresses on it, you'll find that your kernel may end up rejecting valid traffic. It's also important to note that even if you do not enable the rp_filter, protection against broadcast spoofing is always on. Also, the protection it provides is only against spoofed internal addresses; external addresses can still be spoofed.. By default, it is disabled.

 

To summarize, the rp_filter is optional and by default it's turned off. Someone decided that it should be turned on. Of course, it may quite likely provide additional security means, but if it cuts off my wireless internet - that's BAD.  :Evil or Very Mad: 

Here's the listing of available rp_filter options:

```
# grep rp_filter /etc/sysctl.conf

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.all.rp_filter = 1
```

As one can easily see, there are two said options. All that's needed is to comment out the line containing the second option, namely net.ipv4.conf.all.rp_filter, by putting a # at the beginning (like in the last line):

```
# less /etc/sysctl.conf

# /etc/sysctl.conf

#

# For more information on how this file works, please see

# the manpages sysctl(8) and sysctl.conf(5).

#

# In order for this file to work properly, you must first

# enable 'Sysctl support' in the kernel.

#

# Look in /proc/sys/ for all the things you can setup.

#

# Disables packet forwarding

#net.ipv4.ip_forward = 0

# Disables IP dynaddr

#net.ipv4.ip_dynaddr = 0

# Disable ECN

#net.ipv4.tcp_ecn = 0

# Enables source route verification

net.ipv4.conf.default.rp_filter = 1

# Enable reverse path

#net.ipv4.conf.all.rp_filter = 1

```

Maybe someone can magically make his/her dhcpcd work by using this method too?  :Very Happy: 

----------

## Quas

hi,

i am using (trying to use) tis usb wlan stick.

i am using ndiswrapper.

everything loads fine.

driver present and hardware present

i can scan fpr APs but i acant connect to them. wireless config is 100% right

has anyone an idea?

i am really freaking out on this issue now

bye

stefan

----------

## SirYes

Actually it stopped working for me too, some time ago. But as I don't have right now any time to resolve the issue, I'm just using a regular Ethernet (cable) connection...  :Sad: 

I guess this is the problem with ndiswrapper, for some reason. If only this chipset had an in-kernel driver to work over USB...  :Confused: 

----------

