| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| slackware:network [2008/09/11 13:56] – Move all historical info to a single chapter. alien | slackware:network [2017/08/08 20:12] (current) – Two small fixes. alien |
|---|
| ====== Configuring your network in Slackware ====== | ====== Configuring your network in Slackware ====== |
| |
| FIXME //This page is under construction, pieces of text will move and information needs to be added still// FIXME | //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 [[http://slackbook.org/html/network-configuration-tcpip.html|Network Configuration]] chapter in the //[[http://slackbook.org/html/|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 //[[http://slackbasics.org/html/|Slackware Linux Basics]]//. This book should be considered as required follow-up reading material once you mastered the Slackware Essentials. The [[http://slackbasics.org/html/netconfig.html|networking chapter]] is well worth reading. |
| |
| This article will is intended to be a thorough look into the way network cards are configured in Slackware. The network scripts themselves are well-documented but there is not much other written documentation about what you put into the configuration files. The [[http://slackbook.org/html/network-configuration-tcpip.html|Network Configuration]] chapter in the //[[http://slackbook.org/html/|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 //[[http://slackbasics.org/html/|Slackware Linux Basics]]//. This book should be considered as required follow-up reading material once you mastered the Slackware Essentials. The [[http://slackbasics.org/html/netconfig.html|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 [[http://slackware.osuosl.org/slackware-12.2/source/n/network-scripts/manpages/rc.inet1.8|rc.inet1]] and [[http://slackware.osuosl.org/slackware-12.2/source/n/network-scripts/manpages/rc.inet1.conf.5|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|Wireless Networks]] because a wireless network interface has so many more configurable parameters than a "wired" interface. The configuration of [[#wpa_encryption|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. |
| | |
| My Wiki article essentially documents the ''/etc/rc.d/rc.inet1.conf'' file. The special case of the network device is the //wireless interface//. I dedicated a separate chapter to [[#wireless_networks|Wireless Networks]] which we also configure using ''rc.inet1.conf'': I follow up on that with a chapter on [[#wpa_encryption|WPA encryption]] which has it's own configuration in ''/etc/wpa_supplicant.conf''. The tail of this article looks at alternative (mainly GUI based) network configuration managers and the extent to which these may be useful in Slackware. | |
| |
| 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. | 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. |
| <note important>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: <code> | <note important>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: <code> |
| IPADDR[0]="" # Needs an IP address like "192.168.0.12" | IPADDR[0]="" # Needs an IP address like "192.168.0.12" |
| USE_DHCP[0]="" # Needs the value of "yes" | USE_DHCP[0]="" # Needs the value of "yes" - anything else will be ignored |
| </code> If both variables are empty, the interface will not be configured and activated.</note> | </code> 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 </note> |
| |
| |
| |
| * Note that I deliberately used an ESSID (the access point's Station Set Identifier) which has spaces in it. This requires that you use quotes around the name: //"my access point"//. When your access point has a name without spaces, you do not need these quotes - in fact it is better to leave those out: //WLAN_ESSID[1]=Darkstar//. | * Note that I deliberately used an ESSID (the access point's Station Set Identifier) which has spaces in it. This requires that you use quotes around the name: //"my access point"//. When your access point has a name without spaces, you do not need these quotes - in fact it is better to leave those out: //WLAN_ESSID[1]=Darkstar//. |
| * You may have defined your WEP key as a string of ascii characters (i.e. a readable passphrase like "Hogwarts") instead of a string of hexadecimal characters (like "6CC07C36169B8E7524886F9A19"). If you want to use this readable string instead of typing a series of HEX characters, you can use the following key format in ''rc.inet1.conf'' <code> | * ** NOTE about WEP encryption:**\\ You may have defined your WEP key as a string of ascii characters (i.e. a readable passphrase like "Hogwarts") instead of a string of hexadecimal characters (like "6CC07C36169B8E7524886F9A19"). If you want to use this readable string instead of typing a series of HEX characters, you can use the following key format in ''rc.inet1.conf'' <code> |
| WLAN_KEY[1]="s:Hogwarts" | WLAN_KEY[1]="s:Hogwarts" |
| </code> This is for a 128-bit (aka 104-bit) WEP key. The even weaker 64-bit (aka 40-bit) WEP keys are still being used - in this case you would need to provide one of 4 keys (or all four with one of them defined as active), this key would have to be the one that the access point considers active as well. Suppose we want to set key [2] to the ascii value "Hogwarts" and then make this the active key, this will take two ''iwconfig'' commands: "''iwconfig key [2] s:Hogwarts''" and "''iwconfig key [2]''". These commands can be combined into one: "''iwconfig key [2] s:Hogwarts key [2]''" and the corresponding entry in ''rc.inet1.conf'' would become (the first "key" word removed): <code> | </code> This is for a 128-bit (aka 104-bit) WEP key. The even weaker 64-bit (aka 40-bit) WEP keys are still being used - in this case you would need to provide one of 4 keys (or all four with one of them defined as active), this key would have to be the one that the access point considers active as well. Suppose we want to set key [2] to the ascii value "Hogwarts" and then make this the active key, this will take two ''iwconfig'' commands: "''iwconfig key [2] s:Hogwarts''" and "''iwconfig key [2]''". These commands can be combined into one: "''iwconfig key [2] s:Hogwarts key [2]''" and the corresponding entry in ''rc.inet1.conf'' would become (the first "key" word removed): <code> |
| WLAN_KEY[1]="[2] s:Hogwarts key [2]" | WLAN_KEY[1]="[2] s:Hogwarts key [2]" |
| </code> | </code> WEP key generators can be found all over the internet. A nice one is [[http://www.powerdog.com/wepkey.cgi|PowerDog's cgi script]]. Using WPA encryption is recommended, see the section that comes next if you need to know how to configure WPA encryption. |
| WEP key generators can be found all over the internet. A nice one is [[http://www.powerdog.com/wepkey.cgi|PowerDog's cgi script]]. Using WPA encryption is recommended, see the section that comes next if you need to know how to configure WPA encryption.\\ \\ 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. | |
| | 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. |
| |
| |
| ssid="your_essid" | ssid="your_essid" |
| proto=WPA RSN | proto=WPA RSN |
| key_mgmt=WPA-PSK | key_mgmt=WPA-PSK WPA-EAP |
| pairwise=CCMP TKIP | pairwise=CCMP TKIP |
| group=CCMP TKIP | group=CCMP TKIP |
| * There is a way to generate the hexadecimal value for the PSK if you have an access point which uses a passphrase. As root, run: <code> | * There is a way to generate the hexadecimal value for the PSK if you have an access point which uses a passphrase. As root, run: <code> |
| wpa_passphrase YOURSSID passphrase | wpa_passphrase YOURSSID passphrase |
| </code> with the //YOURSSID// being the ESSID of your Access Point and //passphrase// is the ascii string you entered in the ccess Point's //WPA-PSK// configuration section. You'll receive an output, which looks like this: <code> | </code> with the //YOURSSID// being the ESSID of your Access Point and //passphrase// is the ascii string you entered in the Access Point's //WPA-PSK// configuration section. You'll receive an output, which looks like this: <code> |
| network={ | network={ |
| ssid="YOURSSID" | ssid="YOURSSID" |
| WLAN_WPA[1]="wpa_supplicant" | WLAN_WPA[1]="wpa_supplicant" |
| WLAN_WPADRIVER[1]="wext" | WLAN_WPADRIVER[1]="wext" |
| </code> The value "//wext//" for the variable //WLAN_WPADRIVER// stands for "//Wireless Extensions//". It is the protocol with which wpa_supplicant and the wireless driver communicate. //Wireless Extensions// allow for a simple framework that connects arbitrary (and well-written) wireless kernel drivers and the userland program wpa_supplicant together. Not too long ago, neither wpa_supplicant nor wireless drivers used //Wireless Extensions// by definition, so it is likely that for older releases of these sotwares, wpa_supplicant needs to talk to the driver using it's own protocol. You can easily find out what "drivers" are supported by wpa_supplicant by just running it and inspecting the output: <code bash> | </code> The value "//''wext''//" for the variable //WLAN_WPADRIVER// stands for "//Wireless Extensions//". It is the protocol with which wpa_supplicant and the wireless driver communicate. //Wireless Extensions// allow for a simple framework that connects arbitrary (and well-written) wireless kernel drivers and the userland program wpa_supplicant together. Not too long ago, neither wpa_supplicant nor wireless drivers used //Wireless Extensions// by definition, so it is likely that for older releases of these sotwares, wpa_supplicant needs to talk to the driver using it's own protocol. You can easily find out what "drivers" (cards) are supported by wpa_supplicant by just running it and inspecting the output: <code bash> |
| wpa_supplicant | wpa_supplicant |
| wpa_supplicant v0.5.10 | wpa_supplicant v0.5.10 |
| |
| ... | ... |
| </code> If you use an older version of ndiswrapper you may have to use "ndiswrapper" instead of "wext" as the driver (note that current releases of ndiswrapper require "wext") <code> | </code> //For instance:// If you use an older version of ndiswrapper you may have to use "ndiswrapper" instead of "''wext''" as the driver (note that current releases of ndiswrapper require "''wext''") <code> |
| WLAN_WPADRIVER[1]="ndiswrapper" | WLAN_WPADRIVER[1]="ndiswrapper" |
| </code> | </code> |
| |
| </code> | </code> |
| |
| | <note tip>Slackware will tell //wpa_supplicant// to use the "''wext''" protocol if you do not specify a driver yourself. So, basically the line <code> |
| | WLAN_WPADRIVER[1]="wext" |
| | </code> can safely be omitted.</note> |
| |
| | === 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 [[#wpa_encryption|the previous section]] will support WPA as well as **WPA2** encrypted networks. In the following line taken from ''wpa_supplicant.conf'' <code> |
| | proto=WPA RSN |
| | </code> the string //WPA2// is an alias for //RSN//, so that that line can be written like this as well: <code> |
| | proto=WPA WPA2 |
| | </code> |
| | |
| | * WPA2 support for the legacy RaLink drivers by serialmonkey is configured with an "''iwpriv''" command like this (check the [[#wireless_configuration_in_rc.inet1.conf|earlier section about rc.inet1.conf]] to see the difference with the WPA1 example given there): <code> |
| | WLAN_IWPRIV[?]="set AuthMode=WPA2PSK | set EncrypType=AES | set WPAPSK=the_64_character_key" |
| | </code> |
| | |
| === WPA debugging === | === WPA debugging === |
| |
| If your WPA connection does not activate, there are several ways to debug the problem. | 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. |
| |
| * Debug the WPA authentication process.\\ Make sure the network interface is down (run <code> | * Debug the WPA authentication process.\\ Make sure the network interface is down (run <code> |
| </code> | </code> |
| |
| * Debug Slackwares network intitialization.\\ Change <code>DEBUG_ETH_UP="no"</code> to <code> | * Debug Slackwares network initialization.\\ Change <code>DEBUG_ETH_UP="no"</code> to <code> |
| DEBUG_ETH_UP="yes" | DEBUG_ETH_UP="yes" |
| </code> in the file ''/etc/rc.d/rc.inet1.conf'' and look for //logger// messages that are being written to ''/var/log/messages'' while the interfaces are configured. Maybe those messages will help you trace your problem.\\ NOTE: with debugging enabled, Slackware will write your WEP/WPA keys to the message log as well, in clear text! | </code> in the file ''/etc/rc.d/rc.inet1.conf'' and look for //logger// messages that are being written to ''/var/log/messages'' while the interfaces are configured. Maybe those messages will help you trace your problem.\\ NOTE: with debugging enabled, Slackware will write your WEP/WPA keys to the message log as well, in clear text! |
| </code> or any other larger value that helps your particular setup.\\ __NOTE__: in the last line make sure that you replace the questionmark in **[?]** with the array value that matches your wireless card configuration In the [[#wireless_configuration_in_rc.inet1.conf|above example]] this array index would be [**1**] and the actual line in ''rc.inet1.conf'' would look like <code> | </code> or any other larger value that helps your particular setup.\\ __NOTE__: in the last line make sure that you replace the questionmark in **[?]** with the array value that matches your wireless card configuration In the [[#wireless_configuration_in_rc.inet1.conf|above example]] this array index would be [**1**] and the actual line in ''rc.inet1.conf'' would look like <code> |
| WLAN_WPAWAIT[1]=30 | WLAN_WPAWAIT[1]=30 |
| </code> | </code> If you set **DEBUG_ETH_UP="yes"** then you will notice messages in your "''/var/log/messages''" file like this: <code> |
| | WPA authentication did not complete, try running '/etc/rc.d/rc.inet1 ath0_start' in a few seconds.</code> |
| |
| * The Access Point is not broadcasting the SSID.\\ Some succeed, some fail in getting WPA to work when the Access Point has a //hidden SSID//. Check if your AP is broadcasting the SSID and if not, enable it. There is little point in hiding the SSID anyway, because even with network encryption there will always be packets that need to be transfered in the clear. One of the things that can not be encrypted is the ESSID! How else can a wireless card find out that it talks to the right Access Point if it cannot read the ESSID. Anyway, with WPA as a protection layer you should not be afraid of break-ins (as long as you do not use easy-to-guess passphrases!!! | * The Access Point is not broadcasting the SSID.\\ Some succeed, some fail in getting WPA to work when the Access Point has a //hidden SSID//. Check if your AP is broadcasting the SSID and if not, enable it. There is little point in hiding the SSID anyway, because even with network encryption there will always be packets that need to be transfered in the clear. One of the things that can not be encrypted is the ESSID! How else can a wireless card find out that it talks to the right Access Point if it cannot read the ESSID. Anyway, with WPA as a protection layer you should not be afraid of break-ins (as long as you do not use easy-to-guess passphrases!!! |
| |
| 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 <code> | 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 <code> |
| /etc/rc.d.rc.inet1 | /etc/rc.d/rc.inet1 |
| </code> Restarting the whole network is done in a similar fashion: <code> | </code> Restarting the whole network is done in a similar fashion: <code> |
| /etc/rc.d.rc.inet1 restart | /etc/rc.d/rc.inet1 restart |
| </code> 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//): <code> | </code> 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//): <code> |
| /etc/rc.d.rc.inet1 wlan0_start | /etc/rc.d/rc.inet1 wlan0_start |
| </code> More generically speaking, you can start/stop/restart any network interface yourself by running one of the commands <code> | </code> More generically speaking, you can start/stop/restart any network interface yourself by running one of the commands <code> |
| /etc/rc.d.rc.inet1 INTERFACE_start | /etc/rc.d/rc.inet1 INTERFACE_start |
| /etc/rc.d.rc.inet1 INTERFACE_stop | /etc/rc.d/rc.inet1 INTERFACE_stop |
| /etc/rc.d.rc.inet1 INTERFACE_restart | /etc/rc.d/rc.inet1 INTERFACE_restart |
| </code> | </code> |
| |
| |
| ==== Alternative network managers ==== | ==== 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: <code> |
| | chmod +x /etc/rc.d/rc.networkmanager |
| | </code> |
| | |
| | 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. |
| | |
| | |
| | <note warn>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.</note> |
| |
| === wicd === | === wicd === |
| |
| FIXME provide some information - this one is worthwhile FIXME | 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: |
| | |
| | * Ability to connect to wired and wireless networks |
| | * Profiles for each wireless network and wired network |
| | * Many encryption schemes, some of which include WEP/WPA/WPA2 |
| | * Remains compatible with wireless-tools |
| | * Tray icon showing network activity and signal strength |
| | |
| | Read more about it here: [[http://wicd.net/|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: <code> |
| | chmod +x /etc/rc.d/rc.wicd |
| | </code> |
| | |
| | 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. |
| | |
| | <note warn>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.</note> |
| |
| === lxnm === | === lxnm === |
| === knetworkmanager === | === knetworkmanager === |
| |
| FIXME | Do not use this. The KDE tools are not compatible with Slackware. |
| |
