FreeBSD Basics

Networking with TCP/IP


When you install FreeBSD, you are plunged into the wonderful world of TCP/IP. You may have heard about DNS, ports, RFCs, private ranges, and subnet masks but may be foggy on what these are and why you should care. This article will be a primer on the TCP/IP protocol for the novice and a refresher with some interesting links for those more seasoned FreeBSD users.

First off, let's make sure you are clear on what a protocol is. By definition, a protocol is the rules of communication. If you are travelling in a foreign country, you need to be aware of the customs of that country. A gesture that may seem friendly or insignificant to you may actually be considered an insult in other parts of the world. Awareness of protocol can save you the embarassment of miscommunication.

Protocols are even more important if two computers wish to exchange information. Amazingly, computers communicate by subtly changing millions of electrical pulses, light pulses, or radio waves per second. Both computers need to be using the same protocol, or set of rules, to correctly interpret which of these pulses represent the address of the computer to receive the data, the address of the computer that sent the data, the data itself, and confirmation that the data received was the same data that was sent.

TCP/IP is more than a protocol; it is a protocol suite, or collection of protocols. TCP/IP was designed to allow any operating system on any type of hardware to talk to any other computer in the world. This is something we take for granted in the age of the Internet, but before TCP/IP changed all of the rules, operating systems, hardware, and protocols were proprietary. Proprietary means that in order to exchange information with another computer, it has to be running the same hardware and the same version of the same operating system, which was provided by the vendor of the hardware.

Because TCP/IP is a collection of protocols, new protocols can be added as the capabilities of networking evolve. The designers of TCP/IP left room for the creation of up to 65,535 application protocols. To keep track of all of these application protocols (or rules for how an application expects to receive data), each is assigned a number known as a port number. For example, the port number for Telnet is 23 and the port number for http is 80. If I wish to Telnet into a computer, TCP/IP will send out packets that contain (among other information we'll ignore for the moment) the port number 23. The other computer will realize that I wish to use the rules for Telnet, which are very different than, say, the rules for surfing or checking my e-mail.

Since TCP/IP is non-proprietary, anyone can add new functionality to TCP/IP, pending a review process of their peers known as the RFC or Request For Comments. RFCs were started before the actual development of TCP/IP and have become a fascinating record of each step in the evolution of TCP/IP and the Internet. Ever wonder about who invented DNS and why and all the nitty-gritty details of how DNS actually works? The answer lies in the associated RFCs, which are available for anyone to read via the Internet.

There are many good sites on the Internet where you can search for and read RFCs. Two of these are:

Perhaps you've been told that reading RFCs is as much fun as reading manpages. Admittedly, RFCs can be written by anyone, so writing styles will differ. Some good RFCs to start with are:

Anyway, back to ports. Your FreeBSD system contains a database file of port numbers and associated TCP/IP applications in /etc/services. If you need to know the port number for an application or vice-versa, a quick grep of this file will reveal the information:

grep ssh /etc/services
ssh		 22/tcp    #Secure Shell Login
ssh		 22/udp    #Secure Shell Login
grep -w 69 /etc/services
tftp		 69/tcp	   #Trivial File Transfer
tftp		 69/udp	   #Trivial File Transfer

With these two commands, I've determined that the port number used by ssh is 22 and that port 69 is used by the tftp application. Note that I used -w for the second grep; if you try the same command without the switch, grep will return all port numbers with a 69 in them.

Also note that each application has two port numbers: one for TCP and one for UDP. TCP and UDP are known as transport protocols. While there are thousands of TCP/IP applications, there are only two ways of "transporting" an application's data between computers. UDP is the connectionless transport, meaning that it just sends out data without double-checking that the other computer is ready to receive the data. This is similar to you just showing up at a friend's house in the hope that he may be home. TCP is the connection-oriented transport; it will not send out any data until it has contacted the other computer to ensure that it is ready to receive data. This would be similar to you phoning your friend first to see if he is home and willing to have you come over for a visit.

Once TCP/IP has determined which application you wish to use and how that application wishes to transport its data, it needs a mechanism to make sure the data makes it to the right computer. In other words, it needs an addressing scheme. The only type of address TCP/IP understands is an IP address; if your computer does not have an IP address, you can't use TCP/IP. Most operating systems use IPv4 (IP version 4) IP addresses, but this will be changing within the next few years as the Internet is slowly transitioned over to IPv6. If you are running FreeBSD 4.0 and above, your system understands both versions of IP addresses.

In IPv4, an IP address is divided into two parts: one part indicates the address of the network and the second part indicates the address of the host. (In TCP/IP, anything with an IP address is called a host, or sometimes a node.) All IPv4 addresses contain four numbers ranging from 0-255 separated by three periods; this is called dotted decimal notation. Each number is the decimal equivalent of eight binary bits, so it really represents an octet, or eight numbers. Which octets represent the network and the host addresses depends upon the class of IP address, as seen in the following table:


Network ID

Host ID



first octet

last three octets



first two octets

last two octets



first three octets

last octet


To determine the class of an IP address, compare the number in the first octet to the Range column of the table. For example, is a Class B address, since the 163 in the first octet falls within the range of 128-191. Because it is a Class B address, the first two octets, 163.48, represent the network address, and the last two octets, 92.47, represent the host address.

TCP/IP was designed to use a globally unique addressing scheme. This means you can't just make up an IP address for your computer, because it may conflict with an IP address that someone paid money to use. Network portions of an IP address are purchased to guarantee they are unique; once you have a network address, you can do whatever you want with the host addresses as long as no two computers in your network have the same host address.

Fortunately, each class of IP address also has a reserved private range. Anyone can use a private range network address for their own network; the only caveat is that you'll need a real (or purchased) IP address if you want to leave your network: for example, if you want to access the Internet. The following table shows the private ranges:


Private Range




172.16.x.x to 172.31.x.x



It is a good thing to use one of the private ranges on your network; which class you use is up to you. Most networks use a combination of private range IP addresses and NAT, or Network Address Translation. NAT is a software mechanism that allows a network of private addresses (which can't go on the Internet) to share a real IP address (which can go on the Internet).

Every IPv4 address must also have a subnet mask. I won't get into subnet masking in this article as that topic alone would fill a whole other article. If you're curious about subnet masking, 3Com's article on Everything You Ever Wanted to Know about IP addressing is a must-read.

However, you do need to be aware of the default subnet masks so you can use the correct subnet mask for your IP address. The default subnet masks are different for each class:


Default Subnet Mask




In my test network, I have three computers. I've decided to use the private Class A network range, the default subnet mask, and to use host addressess of 1, 2, and 3. This translates into the following addresses:


IP address

Subnet mask




On the computer named alpha, I used the ifconfig utility to "bind" an IP address to its NIC. In order to do this, I first had to determine the device name of the NIC using the following command:

dmesg | grep Ethernet
rl0: Ethernet address: 00:00:b4:94:9d:3f

which shows that the device name of alpha's NIC is rl0. To see if there is an IP address bound to your NIC, use the following command if you're running FreeBSD 4.0 and above (but substitute your NIC's device name for rl0):

ifconfig rl0 inet
ifconfig: rl0 has no inet interface address!

If you're running FreeBSD version 3.x or below, you do not use the inet argument as these versions only support IPv4 addresses.

This NIC does not have an IPv4 address; I'll use the ifconfig command like so to assign one:

ifconfig rl0 netmask
ifconfig: ioctl (SIOCAIFADDR): permission denied

Note that regular users have sufficient permission to view, but not to change, the IP address assigned to a NIC. Let's become the superuser and try again:

ifconfig rl0 netmask
ifconfig rl0 inet
	inet netmask 0xff000000 broadcast

Once you've bound an IP address to a NIC, you'll want to use the ping utility to ensure that the NIC can send and receive TCP/IP packets.


is called pinging your loopback address. This will check that TCP/IP has been initialized on your system. If this test does not work, you can't use TCP/IP.


will check that your IP address is valid. If this test does not work, check that you have a valid IP address and subnet mask and that no other host is using the same IP address.


If you have another host on your network, ping its IP address. If this last test works, you're in business. If not, double-check your network cabling and ensure that the other computer is turned on and that you are pinging the correct address.

Related Reading:

DNS and Bind

DNS and Bind, 4th Edition
By Paul Albitz & Cricket Liu
4th Edition April 2001
0-596-00158-4, Order Number: 1584
622 pages, $44.95

TCP/IP uses IP addresses, but humans like to use hostnames. Quick, what's the IP address of Don't feel bad if you don't know, as you don't need to in order to access Yahoo's webpage. Hostname resolution was designed to map hostnames to the IP addresses that TCP/IP understands. If you have a small network, you can use the /etc/hosts file to provide hostname resolution. DNS databases provide the same function in larger networks and on the Internet. DNS is far beyond the scope of this article; if you need to setup a DNS server, I highly recommend that you first read DNS and BIND by Cricket Liu and Paul Albitz. The DNS Resources Directory site also contains many useful documents on DNS.

However, editing the /etc/hosts file is an easy matter. First, you need to know, and possibly set, your hostname using the hostname utility. Anyone can view the computer's hostname by typing hostname. Only root can change the computer's hostname. One way to change a computer's hostname is like so:

hostname alpha

This will set the computer's hostname to alpha.

Once the computers in your network have hostnames, you should edit the /etc/hosts file so you can access resources by hostname instead of IP address. Again, only root can modify this file. Each of the computers in my network has an /etc/hosts file that looks like this:

more /etc/hosts	localhost	alpha	beta	gamma

After you edit the /etc/hosts file, always try pinging the hostnames that you've added. For example:

ping alpha
ping beta
ping gamma

If any of the pings fail, you either have a typo in your etc/hosts file or the hostname has not been set on that computer.

Well, that's probably enough about TCP/IP for one day. We'll be revisiting TCP/IP in future articles and will add more details to these basic concepts as we go along. Next week, we'll explore the world of e-mail and how your FreeBSD system uses two TCP/IP ports to allow you to exchange e-mail messages with the world.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Discuss this article in the Operating Systems Forum.

Return to the BSD DevCenter.


Copyright © 2017 O'Reilly Media, Inc.