Realtek rtl8180 in Fedora Core 4

  • Posted on: 29 August 2005
  • By: agittins

Before I upgraded to FC4 I was using the ndiswrapper drivers for my el'cheapo Netcomm NP7032 802.11b WiFi PCMCIA card - and I felt dirty because of it.
Come FC4 I found that my ndiswrapper config got blown away by the upgrade, so I embraced the change and went hunting again for suitable, Open Source drivers.

It turns out that the folks at have tackled the task and done admirably. I built the modules with some assistance from the forums - there were one or two patches to make to the sources before they compiled cleanly with gcc4 on a 2.6.12 system. Unfortunately I haven't found a source of rpms for the drivers and lack the time to package it myself so a src build was the best route, although I prefer to build packages where possible. All looked good, the modules loaded, and a one-off manual config worked fine.

Ahh, well... there's the rub. Manually setting up the nic using "ifconfig wlan0 up" then "iwconfig wlan0 essid myesssid", followed by "dhclient wlan0" all worked ok, bringing it up and onto my home network. The problem was that the system's ifup scripts just wouldn't play ball. Every time I tried to bring the interface up it failed with "Determining IP information for wlan0... failed; no link present. Check cable?" *sigh*.

Working out why took a bit of work. At first I thought I had driver problems, as I was getting these in my dmesg:

"rtl8180: EE: TX buffer error, cannot TX frames"

But after those messages it goes on to find and associate with the accesspoint. Googling the message indicated that if this was the problem, I was the only sucker on earth to have it. Based on that I figured it was not the problem, we continue...

I found that the ifup scripts were using mii-tool and ethtool to try and see if the link was up, via a function in network-functions called "check_link_down".

Well of course, I have religious issues with plugging a cable into a wireless card, so I wanted to teach the system that wifi cards don't do "link stuff" as far as mii-tool and ethtool are concerned.

The options were:

  • Educate ethtool or mii-tool about wifi "links"
  • Educate check_link_down in network-functions about wifi
  • Educate ifup-eth about the folly of running check_link_down on wifi links
  • Cheat

No prizes for guessing the route I took :-)
My primary goal (after getting the thing working at all) was that any modification should preferably reside in a configuration file or a script in /usr/local (did you know there can be an ifup-pre-local?), so that I didn't have to worry about my fix being blatted by the next update. There was an easy cheat to hand, one that I have since seen around the place used with other cards that don't support link-reporting very well.

Crack open /etc/sysconfig/ifcfg-wlan0 and add this to it somewhere:

check_link_down() {
return 1;

Effectively this replaces the check_link_down function defined in /etc/sysconfig/network-scripts/network-functions with one that just says "oh yeah, we do that". This only applies to that interface though, so my link-checking on eth0 and the like still works properly, and the hack lives in a local config file, so it shouldn't get blatted away by future updates. It's a clean(ish) hack that leaves your system in a "distro-compliant" state, which is pretty important generally as far as being able to do clean updates and avoiding dependency issues goes.

The "Real" fix would be along the lines of altering ifup-eth to not run the link-check if it's a wireless device, but I don't know if that applies equally to all wireless nics, as I didn't have this problem with the ndiswrapper driver, and I suspect that many others haven't had this problem with other drivers, so maybe it's the r8180 driver itself that is a little different. Just happy to have it working.

Now that I am fully untethered, I can walk around the house with my M300 notebook, typing at 3% efficiency and getting cramped legs juggling the thing on the lounge, yay.


I've been trying compile the same driver described in the blog but keep getting the compilation errors when I run Make. Inoticed that the author of the post said that they had made a couple of mods to the sources. What do the source mods consist of? I'm really new to linux and any help with this would be greatly appreciated thanks in advance.

Yes, sorry I guess I was being lazy in not saying exactly which patches :-)
There are two.
The first is a fix to make it compile with gcc4 which is newly shipped with fedora core 4. The details are in this bug report. I assume this will only apply to the 0.21 release of April 14, 2005 - since I expect the patch will be committed to CVS. Basically there is a missing "=" sign that borks under gcc4.

Get into r8180_wx.c and add an equals sign in the line
standard r8180_wx_handlers,
so that it looks like
standard = r8180_wx_handlers,

Kernel 2.6.12 (and later)
This one is because of some kernel changes made at or around 2.6.12 of the linux kernel. See the patch entry for details. It seems that this patch has been incorporated into CVS so I'd suggest following the Anonymous CVS steps to checkout the latest code and try building from there - you will want to check if the gcc4 patch has already been applied too.

I've posted this on the "bugs section", but I'm getting a invalid module error when I attempt to insmod their modules.

Also, Did you roll your own kernel to add the cryto stuff?

Hi Jonathan, it's hard to tell from your description, but if insmod complained that the module was an incorrect version then that will be because the kernel version doesn't match the kernel that the module was compiled for.

You will probably have better luck if you compile the module specifically for the kernel you are running, or find a pre-built module that exactly matches the kernel version you are using.

I didn't recompile my kernel to include the crypto support, I just used the stock FC4 kernel.



I have downloaded and compiled the drivers from sourceforge. I run the module_load script, switch to managed mode, scan and join no problem (Link light now on) but i still can't use the connection if i try to ping anything i get a network unreachable error. I have been told to lookup pump but have had no luck.

Thanks In Advance


Hi Dave,

Sounds like you have the 8180 driver working just fine then - if you get it to join the network then the driver is working well, and it's just down to your network configuration.

The advice to look up pump is good - you need to assign an IP address to your wlan0 interface, whether you do that by using DCHP (using pump or dhclient) or by assigning it manually.

If you are on a manually configured wireless network (relatively rare) you can issue a command as simple as "ifconfig wlan0" (substitute for an IP address you have been allocated - don't make one up here).

If you are on an automatically configured network (the more likely option) then you need to set up your system to get it's configuration details from the network. On FC4 this is handled by the dhclient program, but it is better to set things up via the normal fedora config files so that things get managed automatically for you.

Open up /etc/sysconfig/network-scripts/ifcfg-wlan0 and get it looking something like this:

# Avoid bug in check_link_down
check_link_down() {
  return 1;
# Normal wifi settings:
# Or replace with your essid

That should hopefully get things working when you do an "ifup wlan0", and should work automagically on each reboot too.

Note that if you are on a manually configured network, you should still set it up using the same file as above, but you change "dhcp" in bootproto to "static", define a new setting "" and "NETMASK=" or suitable.

cheers ash.

One more question: =
When i reboot i cant connect untill i run the module_load script as root is it possible to set this to be executed before it tries to enable the card?

Hi Dave,
I have a feeling what you are after is a line in your /etc/modprobe.conf that says "alias wlan0 r8180" - that should do it. The result should be that when the system tries to bring up wlan0 it will insert the r8180 module - which should load the other modules as dependencies. If that doesn't quite work for you then you will need to add more lines to that file to get it to load the other modules too - if that's the case have a look at the "install" section of the modprobe.conf manpage (run "man modprobe.conf") - essentially you can add the steps that the module_load script does directly into modprobe.conf via an install line to get everything loaded up.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
I love robots, but not robots that create spam. Thus, I humbly request evidence of your sentience...