...
Featured image of post HowTo Get or Change LAN Configuration on Linux Host
How-To

HowTo Get or Change LAN Configuration on Linux Host

This post will show to you HowTo obtain LAN configuration parameters on Linux Host or HowTo change it. You can find here base information how to obtain LAN parameters as _hostname, DNS name, IP address_, _LAN Local IP address range_, _Default Gateway IP, DNS server IP_ etc.

Values for these parameters can be useful if you are configure new computer in your LAN, or if something doesn’t go well with your networking.

The meanings of those parameters has been explained in my posts The IP Networking Fundamentals for Dummies and The DNS Fundamentals for Dummies, then in this post I’ll expect that you understand what those terms mean.

For Windows users, I have provided post HowTo Get or Change LAN Configuration on Windows Host where you can find principles how to obtain same values on computers with Windows OS.

Public IP address

Before OS dependent parts, I can briefly describe how to easily obtain a value of your public IP address. As I mentioned in my IP networking post, many providers and home networks use NAT technology to connect computers to the Internet. In this case, the computer has IP address from a private range and this IP is unavailable from the Internet. But, of course, your router or other NAT device has to have one or more public IP which is translated by NAT mechanism. Sometimes can be useful to know this IP value.

To resolve this IP, you can use your web browser and access DynDNS CheckIP service web page: checkip.dyndns.com.

This web page resolves the public IP address which generates HTTP request on the page and it is exactly your public IP address. Exception here is if you are using an public proxy server. In this case, you will see IP address of this proxy server instead of your public IP. But if you are using proxy in your LAN, then it will works clearly too.

Before we start, I can mention that all commands and procedures in the post are related to Ubuntu Linux distribution. On some other distributions procedures can be slightly different.

At first, we will take look on host name and domain name. I’ll expect that FQDN of the host is mylinux.homedomain.hd in rest of the post.

The hostname can be obtained by command line call

1
2

hostname
mylinux

As you can see, the command will return mylinux string as result.

To obtain Domain Name, you can use this call:

1
2

dnsdomainname
homedomain.hd

Result is homedomain.hd.

If you can see the FQDN of the host, then use hostname command again, but with optional parameter:

1
2

hostname -f
mylinux.homedomain.hd

The result of the call is expected value mylinux.homedomain.hd.

To modify the hostname to different value, for example newhostname you can use this call:

1

sudo hostname newhostname

But if you will provide this change and then you will try to use all previous commands again, you will got surprise result:

1
2
3
4
5
6

user@mylinux:~$ hostname
newhostname
user@mylinux:~$ dnsdomainname
dnsdomainname: Name or service not known
user@mylinux:~$ hostname -f
hostname: Name or service not known

The hostname change completely broke the other commands output.

Before I explain why and how to modify hostname and other parameters correctly, provide one additional step - reboot your host:

1

sudo reboot

After successful reboot try all previous commands again. Voila, all values are correct again! But why?

The hostname command reads the value from the kernel memory and when you use this command to change hostname, it stores the value to the kernel only. Linux host uses content of the file:

1

<em>/etc/hostname </em>

to initialize the kernel value during the host boot process. It is the reason, why the hostname change from previous example is not persistent and is lost after computer reboot. Then, if you want to make your hostname change persistent, you must change content of the_ /etc/hostname_ file and reboot workstation or provide same change manually by previous command or by script which host uses during boot process (preferred method):

1

sudo /etc/init.d/hostname restart

Ok, now we know how the Linux handle hostname value. But why change of the value completely broke the FQDN of the host and DNS domain? Answer is, because hostname is used as primary key to find those corrupted values inside other file presented on the host:

1

/etc/hosts

In my post The DNS Fundamentals for Dummies you can find information about the function and structure of the file. To resolve Domain Name and FQDN correctly, the file must contains line which specified the FQDN of the host as alias for your hostname. Here is content of the file for our mylinux.homedomain.hd FQDN:

1
2
3
4
5
6
7
8
9

127.0.0.1       localhost
127.0.1.1       mylinux.homedomain.hd mylinux
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
::1     mylinux.homedomain.hd mylinux
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

The key for correct FQDN and DNS domainname resolving is the line:

1

127.0.1.1       mylinux.homedomain.hd mylinux

The FQDN value must be first alias on the line to grant correct DNS Domain Name and FQDN resolving. If you will modify the line to this form:

1

127.0.1.1       mylinux mylinux.homedomain.hd

then you will get incorrect result from previous commands:

1
2
3
4

    user@mylinux:~$ hostname -f
    argon
    user@mylinux:~$ dnsdomainname
    (empty string)

To obtain an adapter(s) related information, the Linux OS use the _ifconfig _command line command :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

ifconfig
eth0      Link encap:Ethernet  HWaddr 00:27:0e:03:b4:a0
            inet addr:192.168.1.23  Bcast:192.168.1.255  Mask:255.255.255.0
            inet6 addr:fe80::227:eff:fe03:b4a0/64 Scope:Link
            UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
            RX packets:1195 errors:0 dropped:0 overruns:0 frame:0
            TX packets:957 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:165074 (165.0 KB)  TX bytes:114523 (114.5 KB)
            Memory:f6ae0000-f6b00000

eth1      Link encap:Ethernet  HWaddr c4:17:fe:03:b4:a0
            inet6 addr:fe80::c617:feff:fe63:181a/64 Scope:Link
            UP BROADCAST MULTICAST  MTU:1500 Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:20
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
            Interrupt:17 Base address:0xc000

lo        Link encap:Local Loopback
            inet addr:127.0.0.1  Mask:255.0.0.0
            inet6 addr: ::1/128 Scope:Host
            UP LOOPBACK RUNNING  MTU:16436  Metric:1
            RX packets:30 errors:0 dropped:0 overruns:0 frame:0
            TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:2562 (2.5 KB)  TX bytes:2562 (2.5 KB)

On previous dump, you can see two adapters named eth0 and eth1. The name is merged from device type (in our case ethernet - eth) and order number of the device. It is common naming convention for Linux devices.

Adapter eth0 is active and fully configured, adapter eth1 is active too, but not configured, because is not connected to any network (it is dump for my laptop wireless adapter).

The important line for the adapter eth0 is this:

1

inet addr:192.168.1.23  Bcast:192.168.1.255  Mask:255.255.255.0

It defines the IP address of the adapter, Network Mask and also specified Broadcast Address here.

Line marked as inet6 is related to IPv6 configuration, but both adapters are not connected by IPv6 to public Internet, they have only link-local addresses assigned. I’ll not provide more info about IPv6 here, because IPv6 is not yet widely supported and this problematic requires special post.

All other lines hold statistical information about adapter transferred traffic.

The adapter named lo is special loopback adapter and is used for internal communication between applications running on the host. It allows to those applications to send data between them even the host is connected to any network or not.

Default Gateway

The Default Gateway value must be obtained by route command on linux host.

1
2
3
4
5

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 eth0

In route result you have to find a line with UG value in Flags column. Then IP address in Gateway column on the line is the Default Gateway IP address - in our case 192.168.1.1

Configure the Adapter

In previous part we have learned how to get adapter related information. Now I’ll try to explain how to configure an adapter. By default, Ubuntu Linux is trying to configure all adapters by DHCP mechanism. It is same behavior as on Windows, and is sufficient for 99% of the Linux OS usage.

To make things more complicated, Ubuntu Linux now contains two mechanisms to manage and configure a network:

  • Command line scripts (ifup, ifdown..)
  • NetworkManager daemon

Command Line scripts are old good way how to configure networking in the Linux. In Server environment, it is still default way for network configuration.

If you are unsure, if the NetworkManager is in game on your host, use this command:

1
2

sudo ps -A | grep NetworkManager
710 ?        00:00:00 NetworkManager

If you will get result above, you have running NetworkManager on your system. If the listing is empty, you are not using this service.

The Network Manager is targeted to the desktop environment with GUI interface. It makes the networking for normal user in the GUI environment more easier, especially if you are using Wireless connections. It is default in Ubuntu Linux Desktop environment and it suppress script commands.

If you are interested in Network Manager deeper, you can find more information here: http://projects.gnome.org/NetworkManager.

Enabling the scripting approach will disable the Network Manager handling for the interface(s) but by NetworkManager ifupdown plugin we can join both worlds together. Modify the file /etc/NetworkManager/nm-system-settings.conf :

1
2
3
4
5
6

[main]
plugins=ifupdown,keyfile
    
[ifupdown]
#managed=false
managed=true

and change value managed in [ifupdown] section from false to true.

More info about the Network Manager configuration can be found on it’s wiki pages: http://live.gnome.org/NetworkManager/SystemSettings where you can find also information related to different Linux distributions then Ubuntu and Debian.

I will not provide more information about NetworkManger here, because scripting approach works well even if NetworkManager is installed or not and gives to us better control over networking. Then, all task can be done by those scripting approach, from my tests.

The network configuration for command line scripts is handled by  _/etc/network/interfaces _file content.

The default content of the file after pure desktop Ubuntu installation is this:

1
2

auto lo
iface lo inet loopback

On server, you will find this default content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

The difference between those files content is caused by NetworkManager service usage. In first case on desktop environment, scripts are not configured because NetworkManager will provide configuration of the networking itself. On Server, where Network Manager is not present, the_ /etc/network/interfaces_ file has correct content.

Notice: If the file /etc/network/interfaces has no entry for an interface then commands ifup  ifdown and others which rely on this file content will not work. If you can use those commands, you have to define correct content here even you are using NetworkManager or not.

Next lines the _/etc/network/interfaces _file explicitly define that the eth0 interface will be configured by DHCP:

1
2

auto eth0
iface eth0 inet dhcp

It is default content for the Server.

To use static IP address, we have to change the eth0 definition in the file to this:

1
2
3
4
5

auto eth0
iface eth0 inet static
    address 192.168.1.23
    netmask 255.255.255.0
    gateway 192.168.1.1

The line with auto prefix is important, because it grants that interface will be initialized during host boot process. Without this line the interface will be not configured and you will have to bring it up by explicit ifup command call. Other line parameters are self-explained, so I’ll not provide a detailed description here for them.

The file /etc/network/interfaces has more different options for special networking configurations, but this is beyond the scope of the post. You can get more information about that by use this command:

1

man interfaces

To activate your adapter configuration changes changes immediately, use those commands:

1
2

sudo ifdown eth0
sudo ifup eth0

It will restart the eth0 interface with new parameters. Of course, you can reboot the computer too to activate changes, but ifup/down commands save a time and are more elegant.

DNS Servers, DNS Suffixes

DNS servers and DNS suffixies are handled by file /etc/resolv.conf. Here is example of the file:

1
2
3
4

nameserver 192.168.1.1
nameserver 192.168.1.100
domain homedomain.hd
search homedomain.hd  example.com

As you can see the DNS servers are present on first two lines.

Parameter domain holds local domain name (if is missing, then this name is resolved form the hosts file as described above) and is recommended to have synced this value with your /etc/hosts content.

Parameter search handles DNS suffixes for DNS short queries. The priority of suffixes is same as order of the domain names on that line, then for our example and query host1, the host1.homedomain.hd is tried by resolver  first and when this query not succeeded, the host1.example.com will be tried to resolve.

If you can add or change your DNS server or you can modify the DNS suffixes list, you have to edit the file content and modify or add appropriate line here.

This approach works well if you are using Static IP configuration. But if you are using DHCP then you will discover that after renew your configuration by DHCP, all added lines to the_ /etc/resolv.conf_ disappear and content of the file is replaced by values obtained from DHCP server only.

It is caused by DHCP agent, which always regenerate content of the_ /etc/resolv.conf_ file from scratch. If you can make your changes here permanent, you have to modify the DHCP agent configuration to add required values during this regeneration process to the file.

This configuration is stored in the file /etc/dhcp3/dhclient.conf. This file is very complex and  allow lot of additional config modifications but the key to provide our DNS servers and DNS suffixes is in those lines:

1
2

#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;

The supersede domain-name line handles DNS suffixes list in final configuration. To add our previous suffixes to final config remove comment from the line with prefix supersede domain-name and add here youd domain suffix or suffixies inside quotation maarks separated by space :

1

supersede domain-name "homedomain.hd example.com";

This change grants that homedomain.hd  and example.com suffixies will be presented on your DNS suffixes list even you obtained those values from DHCP server or not.

If you can add a different DNS server to your configuration, you have to remove comment and modify the line with prefix prepend domain-name-servers and add here IP addresses of requested DNS servers:

1

prepend domain-name-servers 8.8.8.8, 8.8.4.4;

If you can add more then one DNS server, you have to separate values by comma here. This line insert your DNS servers before any other DNS server(s) IP obtained by DHCP, but final list of name servers will contain DHCP obtained values too.

Maybe you have discovered that two lines above has different behavior. One replaces DHCP obtained values completely, second one joins config values with DHCP values. This behavior is handed by the first word on the line; the supersede and prepend directives. The config file offer these modifiers to handle option behavior:

Modifier Description
default This value is used in case when no value for this option is obtained from DHCP server
supersede The agent will always use the value from this option specified in config file. Any value obtained from DHCP server is supressed by this config value
prepend The agent join values from this option and obtained from DHCP server, but values from config are used first.
append The agent join values from this option and obtained from DHCP server, but values from config are usedlast (after values from DHCP server)

Then by those modifiers you can easily influence which values will be used in final configuration and in which order they will be presented.

As I mentioned before, the possibilities to configure the DHCP agent are very complex. If you can get more information about that, use the classical man command:

1

man dhclient.conf

I have tried to present in this post all base information about Linux OS network configuration possibilities. Those principles are oriented on Ubuntu Linux distribution and can be different for other distros, as CentOS or RedHat. I believe that you will find some information from this post useful and if you will find any wrong piece of information, let me know by comment or e-mail.

© 2010 - 2023 Zdenek Polach
Built with Hugo
Theme Stack designed by Jimmy