Table of Contents

Configuring your network in Slackware

This article is intended as a reference guide to network card configuration in Slackware.
The network scripts themselves are well-documented (inside the scripts) but there is not much other written end-user documentation about what you put into the configuration files. The Network Configuration chapter in the Slackware Linux Essentials book explains in generic terms how Slackware's network configuration works, and how the use of DHCP (dynamic IP address assignment) differs from static IP's. I will try not to repeat what is written there.
There is another nice and freely available book on Slackware, called Slackware Linux Basics. This book should be considered as required follow-up reading material once you mastered the Slackware Essentials. The networking chapter is well worth reading.

In essence, my Wiki article documents the /etc/rc.d/rc.inet1.conf file. The only available documentation about the configurable network parameters used to be at the bottom of that file, and it took the shape of commented-out examples. In Slackware 12.2 two man pages were added, for rc.inet1 and rc.inet1.conf, both of which are based on this Wiki article.
The rc.inet1 script in Slackware configures all your network interfaces - including wireless interfaces. If the rc.inet1 script detects that it deals with a wireless interface, it will call the sub-script rc.wireless to configure this interface's wireless properties. Both scripts take their configuration information from the same file rc.inet1.conf.
I wrote a separate chapter about Wireless Networks because a wireless network interface has so many more configurable parameters than a “wired” interface. The configuration of WPA encryption a for wireless interface is documented in it's own chapter; the WPA parameters are taken from the file /etc/wpa_supplicant.conf instead of the rc.inet1.conf file.
The final section of this article looks at alternative network configuration managers (who usually come with a GUI based client program) that have become available for Slackware over time.

I will also try to give some historic perspective on the evolution of network support in Slackware, because I was involved in this a lot.

History

I have been dabbling with Slackware's network support for a long time now. My interest started when I became an IBM employee and was exposed to a Token Ring network (which is the type of network infrastructure that IBM was known for, as opposed to Ethernet which was what the rest of the world was using). Token Ring interfaces are called tr0, tr1, etc…
Now, you may remember if you have used Slackware long enough that the network device configuration script /etc/rc.d/rc.inet1 had the name “eth” hard-coded. Slackware supported four network interfaces out of the box: they had to be called eth0, eth1, eth2 and eth3. This meant that I had to patch the script to add support for my Token Ring cards. I had to repeat this patching procedure for every computer I installed Slackware on (even at IBM, I could use Slackware because I deployed these as local servers for groups of developers in the office). At some point this became quite tedious, so I approached Pat Volkerding and asked him if he would incorporate my patch into the Slackware scripts (at the source). Pat was very friendly (of course) but also would not use my patch for quite some time (of course :-).

It would take as long as Slackware 10.2 to support network cards out of the box whose name did not start with “eth” …
Also in Slackware 10.2, the capability was added to start/stop/restart every individual interface instead of the “all or nothing” approach of the earlier rc.inet1 script. See also the section (re)starting a network interface

These patches were fairly non-intrusive, but adding support for wireless network interfaces would be a lot more complicated.
Historically, the pcmcia subsystem already supported (wired as well as) wireless cards for some time, but these cards with a 16-bit PCMCIA interface were typically configured using the /etc/pcmcia/network.opts and /etc/pcmcia/wireless.opts files. The introduction of wireless PCCard (which is essentially 32-bit PCI with a PCMCIA interface) and PCI devices demanded a new approach. Support for these cards would have to he added to the rc.inet1 script.

The first release of Slackware to have support for PCI and PCCard wireless network cards was 10.0. The script /etc/rc.d/rc.wireless was added. It takes care of configuring the wireless parameters for a network interface. This script does not run independently (although the original version of Slackware 10.0 would not complain if you did). Instead, it is executed by the generic network configuration script /etc/rc.d/rc.inet1. Note that this happens for every network interface which is being initialized - wired as well as wireless. The rc.wireless script will return control to rc.inet1 immediately if it determines that the interface has no wireless capabilities.
If a wireless interface is detected, rc.wireless will use iwconfig, iwpriv and possibly wpa_supplicant to associate the card with an access point (in managed mode) or peer it with another computer (in ad-hoc mode). When the script completes it's work, it hands back control to the rc.inet1 script which continues with the (DHCP or static) IP address assignment.
If you remove the executable bit from this script, it will never be run. This can be beneficial if you have written your own wireless script and don't want Slackware to mess it up.

The /etc/rc.d/rc.wireless script is not meant to be run on it's own by the user!

Typically, wireless network cards are assigned a name different from ethN (wlanN, raN and athN are common names) Before the release of Slackware 10.2, these cards could not easily be configured using the standard network configuration files. Support for arbitrary network interface names (other than ethN) was added in Slackware 10.2, which made the process of configuring wireless interfaces a lot easier.

We are going to assume here that you are running Slackware 10.2 or newer.
Most people with wireless cards will be better off with a recent release
like Slackware 12.1 anyway.
For older releases, there are instructions in an other Wiki article about updating the network scripts.

The first versions of the rc.wireless script relied on a configuration file /etc/rc.d/rc.wireless.conf for all of your wireless card's configuration. Starting with Slackware 10.2, it is also possible to use the generic configuration file /etc/rc.d/rc.inet1.conf to store wireless parameters.
Support for WPA encryption (using wpa_supplicant) was also added, although it would take until Slackware 11.0 before a wpa_supplicant package was actually added to the /testing directory. In Slackware 12.0, wpa_supplicant finally became part of the 'N' package series.

Network subsystem

Slackware's network subsystem is straight-forward. A network device will be used by Slackware only if Slackware finds the minimally required configuration data. Most important: it must be known if the card will use DHCP to obtain an IP address or that a static IP address will be used. Additionally for a wireless interface it is good to have configured it's wireless parameters.
So, how does Slackware load drivers for, configure and activate a network interface?

Network configuration file rc.inet1.conf

Rule of thumb: use netconfig script only for your primary wired interface configuration. For any other (including wireless) card's configuration, use vi /etc/rc.d/rc.inet1.conf instead

Network configuration parameters

Here follows a list of network parameters you can set for any card. As an example I've taken the section that is usually taken for eth0 i.e. the array variables with index [0]:

# Config information for eth0:
IPADDR[0]=""                   # Set this value to an actual IP address if
                               # you want static IP address assignment
NETMASK[0]=""                  # With a static IP address, you are required
                               # to also set a netmask (255.255.255.0 is common)
USE_DHCP[0]="yes"              # If set to "yes", we will run a DHCP client
                               # and have the IP address dynamically assigned
DHCP_HOSTNAME[0]="mybox"       # Tell the DHCP server what hostname to register
DHCP_TIMEOUT[0]=15             # The default timeout for the DHCP client to
                               # wait for server response is 30 seconds,
                               # but you might want a shorter wait.
IFNAME[0]="eth0:1"             # Set up an IP alias.
HWADDR[0]="00:01:23:45:67:89"  # Overrule the card's hardware MAC address
MTU[0]=""                      # The default MTU is 1500, but you might need
                               # 1360 when you use NAT'ed IPSec traffic.
DHCP_KEEPRESOLV[0]="yes"       # If you dont want /etc/resolv.conf overwritten
DHCP_KEEPNTP[0]="yes"          # If you don't want ntp.conf overwritten
DHCP_KEEPGW[0]="yes"           # If you don't want the DHCP server to change
                               # your default gateway
DHCP_IPADDR[0]=""              # Request a specific IP address from the DHCP
                               # server
If you want your Slackware system to configure a network interface at boot time, you will have to supply a value for exactly one of the following two variables:
IPADDR[0]=""   # Needs an IP address like "192.168.0.12"
USE_DHCP[0]="" # Needs the value of "yes" - anything else will be ignored

If both variables are empty, the interface will not be configured and activated. If both variables have values, then the interface will be configured for DHCP

Wireless Networks

If you have a Wireless Access Point that is broadcasting its station ID (the ESSID), and is not configured for encrypted traffic, then you're ready to go with the default configuration as it comes with Slackware. This kind of open wireless network is typical when

  1. you just unpacked your Wireless Access Point, and didn't have time yet to configure it;
  2. you are at an airport/hotel/pub where they offer free wireless access.

If you need to configure specific parameters to make the wireless card talk to your Access Point - for instance, the ESSID (in case the Access Point is hiding its station ID), or the channel, or a WEP key, etc) then you will need to edit either the file

/etc/rc.d/rc.wireless.conf

or the file

/etc/rc.d/rc.inet1.conf

(one of the two will do) and add a specific configuration that matches your wireless card and Access Point.

Wireless configuration in rc.wireless.conf (deprecated)

In the previous section, I briefly mentioned the fact that you can store your wireless network parameters (excluding WPA) in both rc.wireless.conf and rc.inet1.conf. I will show you how to use rc.wireless.conf but first let me explain why I prefer to let people use rc.inet1.conf instead.

Originally, rc.wireless.conf was the file to store your wireless parameters. When support for wireless parameters was also added to rc.inet1.conf this was done with a reason.
The rc.wireless and rc.wireless.conf files were initially based on the pcmcia scripts for wireless cards. That means your card's parameters were tied to it's MAC address (with the option to use a wildcard in that MAC address to support different brands of cards). This is different from the standard way of configuring a network card in Slackware, where network configuration parameters are tied to the name of the interface. Adding the option to define your wireless configuration parameters in rc.inet1.conf allows you to keep all your network settings (apart from WPA) in one file: rc.inet1.conf. I can hear you think “what happens if I define a wireless parameter in both files?”. Good question! In fact, a parameter value which is set in rc.inet1.conf will always override the value you might have set for that same parameter in rc.wireless.conf.
I regularly hear from Slackware users that they are confused by the possibility to use two configuration files for the same settings. Well, I agree. This rc.wireless.conf is a historic left-over and ultimately I would like to see it removed from the Slackware wireless-tools package completely. I think there is no good reason to want to keep using rc.wireless.conf. In fact, you can safely delete that entire file! But for those who do not want to say goodbye to it, we will keep support for it in the network configuration scripts.

Any wireless parameter defined in rc.wireless.conf and called FOO is equivalent to the wireless parameter called WLAN_FOO[n] in rc.inet1.conf (the [n] being the index relating to your card). The WLAN_ prefix is what distinguishes the two.
Please use /etc/rc.d/rc.inet1.conf as the single configuration file for all your network parameters (wired as well as wireless)

Let us have a better look at this file anyway.

Wireless configuration in rc.inet1.conf

Keep the index value below 6 whenever possible. The rc.inet1 script will not look for indexes larger than 6

It depends on your access point and the quality of the signal (think of interference because of nearby Access Points when you live in a densely populated area) whether you have to explicitly configure parameters as the channel and the rate. Leaving these undefined will cause the driver to scan for the appropriate channel and settle for a dynamic transmission rate.

Wireless configuration parameters

A comprehensive list of supported wireless parameters follows (taken from rc.inet1.conf):

IFNAME[4]="ath0"               # Use a different interface name instead of
                               # the default 'eth4'
WLAN_ESSID[4]=DARKSTAR         # Your access point's name
WLAN_MODE[4]=Managed           # "Managed" mode for use with Access Points.
                               # "Ad-Hoc" is for peer-to-peer connections.
WLAN_RATE[4]="54M auto"        # The transmission rates you want the driver to try
                               # ("auto" means that bandwidth can be variable)
WLAN_CHANNEL[4]="auto"         # The channel to which the Access Point is tuned
                               # ("auto" to let the driver find out the correct channel) 
WLAN_KEY[4]="D5A31F54ACF0487C2D0B1C10D2"
                               # Definition of a WEP key
WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=thekey"
                               # Some drivers require a private ioctl to be
                               # set through the iwpriv command. If more than
                               # one is required, you can place them in the
                               # IWPRIV parameter (separated with the pipe (|)
                               # character, see the example).
 
WLAN_WPA[4]="wpa_supplicant"   # Run wpa_supplicant for WPA support
WLAN_WPADRIVER[4]="ndiswrapper"# Tell wpa_supplicant to specifically use the
                               # ndiswrapper driver. If you leave this empty
                               # the 'wext' driver is used by default; most
                               # modern wireless drivers use 'wext'
WLAN_WPAWAIT[4]=30             # In case it takes long for the WPA association
                               # to finish, you can increase the wait time before
                               # rc.wireless decides that association failed
                               # (defaults to 10 seconds)
Read the iwconfig man page if you want to know more about the possibilities for the various WLAN_ parameters that are available. These parameters translate directly into iwconfig commands

WPA encryption

WPA stands for Wi-Fi Protected Access. It is an encryption standard which was devised after it became clear that the older WEP (Wired Equivalent Privacy) encryption algorhitm was seriously flawed - WEP can be cracked in a matter of seconds. Note that WPA is not 100% safe either, but much harder to crack than WEP. Just make sure that you use a non-trivial WPA passphrase to create your WPA key. The WPA cracking methods that rely on dictionary attacks will eventually break through your encryption if you use common words to make up your passphrase.

OK… configuring WPA encryption seems to be quite problematic for many people. But it is not hard at all if you know where to configure! I am assuming that you already have your wireless card up and running without any encryption, or possibly with WEP encryption - the way to do that was shown in the previous section.
Do not try to add WPA support if you do not yet have a functional wireless network connection! It will make the toubleshooting a lot more difficult if it does not work right away.

Slackware will tell wpa_supplicant to use the “wext” protocol if you do not specify a driver yourself. So, basically the line
WLAN_WPADRIVER[1]="wext"

can safely be omitted.

WPA2

WPA2 is considered a safer encryption protocol than WPA. However, not all (older) wireless access points support it because of the greater processing power the WPA2 protocol demands for the packet encryption/decryption.

* The wpa_supplicant.conf example in the previous section will support WPA as well as WPA2 encrypted networks. In the following line taken from wpa_supplicant.conf

  proto=WPA RSN

the string WPA2 is an alias for RSN, so that that line can be written like this as well:

  proto=WPA WPA2

* WPA2 support for the legacy RaLink drivers by serialmonkey is configured with an “iwpriv” command like this (check the earlier section about rc.inet1.conf to see the difference with the WPA1 example given there):

WLAN_IWPRIV[?]="set AuthMode=WPA2PSK | set EncrypType=AES | set WPAPSK=the_64_character_key"

WPA debugging

If your WPA connection does not activate, there are several ways to debug the problem. For the sake of the examples I will assume that the name of your wireless interface is ath0 - substitute your own card's name if you need to apply these commands.

(Re) starting a network interface

In Slackware, the way to start your network (the configuration of your nics and bringing the interfaces up, and creating a default route if required) is by running the command

/etc/rc.d/rc.inet1

Restarting the whole network is done in a similar fashion:

/etc/rc.d/rc.inet1 restart

This is quite crude, and not adequate for the dynamic detection and configuration of network devices. Therefore, when your computer boots, and UDEV detects your network hardware, it will run the following command after loading the kernel driver and determining the name of the interface (let's assume that it is wlan0):

/etc/rc.d/rc.inet1 wlan0_start

More generically speaking, you can start/stop/restart any network interface yourself by running one of the commands

/etc/rc.d/rc.inet1 INTERFACE_start
/etc/rc.d/rc.inet1 INTERFACE_stop
/etc/rc.d/rc.inet1 INTERFACE_restart

Alternative network managers

The information presented in the article up to here is historical and provides you with in-depth information about how Slackware itself can manage your computer's network configuration.
However, with the advance of mobile computers and graphical desktops, alternative means of managing network connectivity have been developed which allow for seamless roaming, VPN support and other complex scenarios.
Several alternative network managers have been added to Slackware over time, and these come with graphical front-end programs. This section of the article on networking in Slackware deals with the alternatives.

networkmanager

The Networkmanager was added to Slackware 14.0. Originally developed by Red Hat, it is now hosted by the GNOME project and has been adopted by virtually all Linux distributions.
NetworkManager is able to switch automatically between wired and wireless networks, allows VPN connections of various types and supports modems.

Read more about NetworkManager on is homepage https://wiki.gnome.org/Projects/NetworkManager

The NetworkManager package installs a daemon which talks to your computer's dbus messagebus to detect network connects/disconnects. The daemon is started at boot by making its rc script executable:

chmod +x /etc/rc.d/rc.networkmanager

Configuration of your wireless as well as wired interfaces is done via a client program. You can either use the GTK-based graphical network-manager-applet in your X Window session (KDE, XFCE, blackbox, …), or use the text user interface program nmtui if you are not using X. If you are running KDE 4 as your Desktop Environment, then the package plasma5-nm will show a system tray widget. If you are running Plasma 5 Desktop Environment, then plasma5-nm installs a Plasma widget for the graphical management of NetworkManager. To enable that widget, right-click on the system tray and select add widgets, then search for network and drag the widget to your system tray. Once the widget is visible in your Plasma system tray you can use it to interact with the daemon.

If you want to use NetworkManager, you will have to remove any network interface configuration information from /etc/rc.d/rc.inet1.conf in order to prevent a struggle for power between NetworkManager and Slackware's rc.inet1 script.

wicd

Wicd (pronounced as wicked) aims to provide a simple interface to connect to networks with a wide variety of settings. Some of Wicd's features include:

Read more about it here: http://wicd.net/

You can find the wicd package in the /extra section of the Slackware distribution. It is not installed by default as part of a full installation.
Wicd installs a daemon which talks to your computer's dbus messagebus to detect network connects/disconnects. The daemon is started at boot by making its rc script executable:

chmod +x /etc/rc.d/rc.wicd

Configuration of your wireless as well as wired interfaces is done via a wicd client. You can either run the graphical wicd-client in your X Window session (KDE, XFCE, blackbox, …), or use the console program wicd-curses if you are not using X. If you are running KDE4 as your Desktop Environment, then the package wicd-kde installs a KDE widget for the graphical management of your wicd daemon. To enable the wicd widget, right-click on the system tray and select add widgets, then search for wicd and drag the widget to your system tray. Once the widget is visible in your KDE system tray you can use it to interact with the daemon.

If you want to use wicd, you will have to remove any network interface configuration information from /etc/rc.d/rc.inet1.conf in order to prevent a struggle for power between wicd and Slackware's rc.inet1 script.

lxnm

FIXME

wifi-radar

FIXME

knetworkmanager

Do not use this. The KDE tools are not compatible with Slackware.