Fedora – Unable to reconnect to a WiFi network on Fedora 20

driversfedoranetworkingrealtekwifi

Problem

After leaving my Fedora 20 laptop running overnight, I open it back up and it prompts me to re-enter the password for my home WiFi network. The password is already typed in and censored, but it wants me to to confirm and hit Connect.

I have deliberately made sure the password I am typing in is correct.

Once I type the password into the prompt, I press Connect and the prompt disappears. About five to ten seconds later, without displaying an error message of any sort, it brings up the exact same prompt with the password already entered. Just to be sure, I've tried just pressing Connect without editing the password, and I have also retyped the password and tried again to no avail.

Guaranteed Fix

As of right now, the only way I know I can indefinitely fix the problem is by restarting my laptop, which leads me to believe that either my home WiFi network is misconfigured in the WiFi Settings, or there is something that Fedora isn't handling properly.

Ideally, yes, I could just restart my laptop, but for example, let's say I'm uploading a significant amount of files over FTP, and if I restart my computer, that means I have to reupload a few thousand files because I have no idea which ones have been uploaded, which is just a huge delay.

Network Setup

My network is a Westell modem connected to an Apple AirPort Extreme router. As far as I know, it's a pretty standard setup.

The router handles DHCP and NAT, which does cause a small problem with the modem (a double NAT), and AT&T told us that if we want to use the features from our AirPort Extreme, we will have to deal with it. But it hasn't affected Internet usage on any other devices for the past year and a half since we set it up.

This is the AirPort Utility's description of a Double NAT:

This AirPort base station has a private IP address on its Ethernet WAN port. It is connected to a device or network that is using Network Address Translation (NAT) to provide private IP addresses. Change your AirPort base station from using DHCP and NAT to bridge mode.

Using bridge mode disables some of the most important features of our AirPort Extreme base station, including guest networking. But as I said previously, having the Double NAT hasn't affected Internet usage on any other device for the past two years.

Best Answer

Solution

Description

After many months of having this issue with intermittent WiFi connections and sometimes losing connectivity for hours at a time, Bug 1108801 on the Red Hat / Fedora bug tracker seemed to hold the solution for me.

As described in Comment #12 on that bug, Realtek (the manufacturer of my wireless card) has updated drivers for my RTL8188EE wireless card that are NOT included in the Linux kernel / Fedora by default. So, my solution was to manually download the source code for the drivers, compile and install the code onto my computer, and then reboot. After doing this, I have not had any of the issue that I used to have with staying connected to WiFi networks!

How to fix

The commands I ran to install the drivers from Realtek's GitHub are as follows. Make sure you have already installed the git package from the Fedora software repositories!

$ git clone http://github.com/lwfinger/rtlwifi_new.git
$ cd rtlwifi_new
$ make
$ sudo modprobe -rv rtl8188ee
$ sudo make install
$ sudo modprobe -v rtl8188ee

Disclaimer

As of the time of writing this, I haven't had more than a day to ensure that this has resolved the issue entirely for me, but it resolve the issue I was having prior to installing the driver and rebooting. I can only hope this was the final solution, but if my problem continues, I will update the question.

IMPORTANT!

Every time that there is a kernel update for Fedora, you will have to download, compile, and install the drivers each time, as it only installs the drivers for whichever kernel you are currently using.

Edit, Mar. 5 2015

The RTL8188EE driver in Linux kernel 3.18.5 and up is exactly like the one in repository listed above. Depending on your specific wireless card, you may not need to use rtlwifi_new, and you can just upgrade your kernel version! For more info, read the GitHub issue.

Related Solutions

Linux – Ubuntu Linux Router: Set outbound NAT on 2 interfaces

The problem lies in getting a response from the client LAN I think, and so yes you need to use NAT to the client-LAN as well.

Let me explain:

Nodes on your LAN have your gateway as their default gateway.

Thus any traffic from them, be it to the client network (10.0.0.0/8) or the wider world (0.0.0.0/8) goes to it.

Traffic to the wider world is then NAT'd onto the Internet.

Traffic to the client's LAN is forwarded as is (I'm assuming here forwarding is working which the NAT working indicates it is).

So a packet from a node on your internal LAN, let us say it's IP is 192.168.1.200 goes to your gateway and is forward to the client LAN. However it's source address is still 192.168.1.200.

The client machine receives this and tried to reply, to 192.168.1.200.

Unless the client LAN machines have routes set for 192.168.1.0/24, or their default gateway is able to forward the packets to your gateway, they will not be able to route.

With NAT enabled then at the gateway the source address 192.168.1.200 is NAT'd to your client LAN gateway address, which client LAN nodes can respond to, where it will be re-addressed by your gateway and returned.

Linux – Arch Linux Ethernet to WiFi bridge

I'm not absolutely certain, but if you have both network connections up and running, I think all you really need is a magic iptables configuration.

This will allow NAT from anywhere, to anywhere:

iptables -t nat -A POSTROUTING -j MASQUERADE

You could add a -o flag to control which interface is routed to where, but I don't think it's necessary.

I use this for sharing my network connection with LXC guests. You'll probably also need to set up a DHCP server for the devices behind the Pi (dnsmasq will do the job -- don't forget to bind the interface or you'll end up dishing out addresses to both networks!). DHCP is not necessary if you use static IPs, so I'd do that first.

Obviously, this isn't a full bridge, but I don't know how to help with that. :)