Monthly Archives: October 2007

realtek 8180 on kernel 2.6.23

To make RealTek 8180 wireless cards work in Linux you need the open source drivers from rtl8180-sa2400. Actually this driver supports more realtek cards not just 8180, you can get the list of supported devices from their homepage.

The only problem with those drivers is that they are a bit outdated. They were initially build sometime in 2005 at a time when the kernel version was 2.6.12 . Since then there were patches released to make those drivers work with newer kernels and the latest patch I found was for kernel 2.6.22.You can download the patch from sourceforge . I downloaded that and it just complied and installed without problems.

I loaded the following kernel modules in the exact order :

  1. modprobe ieee80211_crypt-rtl
  2. modprobe ieee80211_crypt_wep-rtl
  3. modprobe ieee80211_crypt_tkip-rtl
  4. modprobe ieee80211_crypt_ccmp-rtl
  5. modprobe ieee80211-rtl
  6. modprobe r8180 # or some other for other supported cards

At this point I got the card working but there was no security. I knew this card supports WEP encryption and I was trying to set up a link between the card and a linksys WRT54G router that can also do WEP. When I tried to set a key (WEP ) I the card told me setting a key was not supported by hardware and I got the following error in dmesg: rtl_ieee80211_crypt_wep: could not allocate crypto API arc4

This was very weird because I knew I already loaded the arc4 crypto module . Then why doesn't it work?
After digging a bit in the code I realize that the ecb module is also needed for kernel versions higher then 2.6.15.

After I loaded the ecb module I was able to set a key with iwconfig and the link was up.

To summarize...
in order get this driver working you have to compile your kernel with the following options:

-> Networking
-> Networking support (NET [=y])
-> Wireless
-> Improved Wireless API

for the wireless tools ( iwconfig ) to work
Device Drivers
-> Wireless LAN
I'm not sure if this one is really needed cause the rtl8180 drivers user their own 802.11 stack but it doesn't hurt to enable it as a module, and if you have other wireless devices or you want to ue your card as a host ap you may need tis anyway.

From the Cryptographic API make sure you select ARC4 and ECB

After you compile the kernel you need to load the modules like this:

  1.  
  2. modprobe ecb
  3. modprobe arc4
  4. modprobe ieee80211_crypt-rtl
  5. modprobe ieee80211_crypt_wep-rtl
  6. modprobe ieee80211_crypt_tkip-rtl
  7. modprobe ieee80211_crypt_ccmp-rtl
  8. modprobe ieee80211-rtl
  9. modprobe r8180

bring up the interface :

  1.  
  2. ifconfig wlan0 up

and set the ESSID and key with iwconfig in order to connect it with the Access point

  1.  
  2. iwconfig wlan0 essid "your_Access_poing_ESSID" key restricted the_wep_key_used_by_your_access_point

If everything went well you should see something like: wlan0 802.11b linked when typing iwconfig
Next i will try to configure this card to be used as a Host AP.
Did any of you try that ? feel free to share your experiences in the comments.

Update:

There is a new project that forked the rtl8180 driver and ported it to the new 802.11 stack in 2.6.23 kernel. This new project was already included in 2.6.23 but at the moment only support for  rtl8185 is available. The project is rtl-wifi and you might want to watch their page for when they add support for 8180

Explicitly ignorant in Unix

I'm working on a patch for antinat, to make it do some cool/weird stuff that it can't do at the moment.

In case you're wondering antinat is a great implementation of a socks server. It supports socks4, socks5 with user/password authentication, accept/reject acls based on user or ip, easy configuration in an XML file and it's also multithreaded ( ok maybe this is not so great for some but I like it ).

I'm not going to write about the patch I'm working on but maybe I'll write about that in another post.

While I was looking over it's source code I found this funny comment right before a function that was used to handle the SIGPIPE signal:

  1.  
  2. /*
  3. UNIX trivia - when is a problem a problem? When you don't ignore it.
  4. If you do nothing, well, you're not being ignorant enough. You have
  5. to be explicitly ignorant.
  6. */

This is funny but the comment has a good point. If you write an application and it tries to write to a connection that was closed, your program will receive a signal with the code SIGPIPE, which means ( according to the man page of the kill program) that if the proces does not have a default handler for SIGPIPE then it will just exit. So there you have a big problem.

The simple solution is to just set your own signal handler for SIGPIPE . So you have to set a function that will be called when the program receives a SIGPIPE and your function doesn't really have to do anything about it, so it will just ignore it and reset the handler to itself.

  1.  
  2. void
  3. ignorer (int x)
  4. {
  5. signal (x, ignorer);
  6. }
  7.  

But if you don't explicitly set this, your process will just die upon receiving a SIGPIPE and you really don't want that especially when writing server applications.