UNIX Networking

Dr. T V Gopal
Professor
Department of Computer Science and Engineering
Anna University
Chennai – 600 025, INDIA

e-mail : gopal@annauniv.edu
Home Page : http://www.annauniv.edu/staff/gopal
Kernel Structure (Traditional)
UNIX Shell
 Since the kernel is responsible for so many
complex tasks (translation, memory and file system
management, etc), it typically cannot spend too
much time making life too easy for the person
using it. Its user interface, though much better than
that of the hardware, still slows down for the
average user.
 Fortunately, UNIX implements another layer of
abstraction that envelops the kernel. This next layer
is called a shell.
 The benefit of a shell, of course, is that it is built
primarily for people. Time and energy have been
taken to develop a user-friendly interface with a
language more intelligible than either the language
of the hardware or that of the kernel.
Shell and Users
Shell and User Isolation

This is similar to the IBM Virtual Machine Model.

UNIX Layers

This is similar to the Java Virtual Machine Model.

UNIX File System

The Disk Arrangement :

The boot block contains the code to bootstrap the OS.

The super block contains information about the entire
disk.
The I-node list a list of inodes, and the data blocks
contains the actual data in the form of directories and
files.
UNIX Files
Hierarchical Directory Structure in UNIX
File Permissions
 The UNIX file-system can prevent unauthorized users from
reading or altering files or directories. Every file or
directory has specific permissions associated with it, giving
different categories of user certain permissions. - just
the owner "login User"
- a group of userids "Group“(except user)
- all the other users "Others"(except user and group)
 The following permissions/rights of access are available:
- read 4 "(r)ead"
- write 2 "(w)rite"
- execute 1 "e(x)ecute"
(to enter/search in a directory)
- nothing 0
 The first character specifies the file type. This is normally :
- indicates a file
d indicates a directory
Example – File Permissions
files
directory
---------- (no permissions)
d---------
-rwx------ (high security!)
drwx------
-rwx--x--- (various perm. )
drwxr-x---
-rw-r--r--
UNIX - Process Hierarchy
* Th e UNIX d aem ons ar e als o ind icate d
UNIX Inter Process
Communications (IPC)
devices and streams
signals
pipes and FIFOs (named Pipes)
message queues
semaphores
shared memory
sockets
UNIX Signals
 There is a very easy, simple, and sometimes useful
method for one process to bug another: signals.
 Basically, one process can "raise" a signal and have it
delivered to another process. The destination process'
signal handler (just a function) is invoked and the
process can handle it.
 Many signals are predefined and the process has a
default signal handler to deal with it.
 A default handler? Yes. Take SIGINT for example. This
is the interrupt signal that a process receives when the
user hits ^C. The default signal handler for SIGINT
causes the process to exit! You can override the
SIGINT to do whatever you want (or nothing at all!)
Example 5 - Signals
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>
int main(void) {
void sigint_handler(int sig); /* prototype */
char s[200]; /* set up the handler */
if (signal(SIGINT, sigint_handler) == SIG_ERR)
{ perror("signal"); exit(1); }
printf("Enter a string:\n");
if (gets(s) == NULL) perror("gets");
else printf("You entered: \"%s\"\n", s); return 0;
}
void sigint_handler(int sig) { printf("Not this
time!\n"); }
Example 5 - Discussion

What happens when you run it?

 If you are in the midst of entering a string and you hit ^C,
the call to gets() fails and sets the global variable errno to
EINTR. Additionally, sigint_handler() is called and does its
routine, so you actually see:
 Enter a string:
 the quick brown fox jum^CNot this time!
 gets: Interrupted system call
 When the signal handler is called, the signal handler for
that particular signal is reset to the default handler! The
practical upshot of this is that our sigint_handler() would
trap ^C the first time we hit it, but not after that.
Catching Signals Many Times
The quick and dirty solution is to reset the signal
handler within itself like so:
void sigint_handler(int sig)
{
signal(SIGINT, sigint_handler); /* reset it to this
function */ printf("Not this time!\n");
}
The problem with this setup is that it introduces a
race condition. If an interrupt occurs and the
handler is called, but then a second interrupts
occurs before the first is able to reset the interrupt
handler, the default handler will be called. Signals
are thus not well structured.
Semaphores
 Semaphores can be thought of as really generic
advisory locking mechanisms.
 You can use them to control access to files,
shared memory, and, well, just about anything
you want.
 The basic functionality of a semaphore is that
you can either set it, check it, or wait until it
clears then set it ("test-n-set").
 No matter how complex the stuff that follows
gets, remember those three operations.
Semaphore is a simple synchronization
mechanism.
Semaphores at Work - 1
There are 3 semaphores
(shown in Fig A):
 S1 has a value of zero and
process P1 is blocked on
S1;
 S2 has a value of three,
meaning process(es) may
execute –ve operation on
S2 without being put to
sleep. Resources are held
with no users.
 S3 has a value of zero,
and has two sleeping
processes, P4 and P5,
blocked on it.
Semaphores at Work - 2
 What happens when a
process executes an
+ve on S1?
 In figure B, process P1
is activated by the +ve
operation. It executes a
–ve on S1 and enters its
critical section.
 Semaphore is a simple
synchronization
mechanism.
Messages and Mailboxes
UNIX Message Queues
 A message queue is a queue onto which messages
can be placed.
 A message is composed of a message type (which is
a number), and message data.
 A message queue can be either private, or public.
 If it is private, it can be accessed only by its creating
process or child processes of that creator.
 If it's public, it can be accessed by any process that
knows the queue's key.
 Several processes may write messages onto a
message queue, or read messages from the queue.
 Messages may be read by type, and thus not have to
be read in a FIFO order as is the case with pipes.
Messages and Synchronization
UNIX Shared Memory
 A segment of memory that is shared between
processes is called a shared memory.
 You just connect to the shared memory
segment, and get a pointer to the memory. You
can read and write to this pointer and all
changes you make will be visible to everyone
else connected to the segment.
What is Socket ?
 The socket is the BSD
method for accomplishing
interprocess communication
(IPC).
 What this means is a socket
is used to allow one process
to speak to another, very
much like the telephone is
used to allow one person to
speak to another.
Socket Programming Simplified

xinetd (inetd) is a daemon that has a bulk of server

code required already built-in. We need to invoke this
daemon on the server side and write the client code.
 Introduction to Unix Network
Programming
Reference: Stevens Unix
Network Programming

28 8/29/07 UIUC - CS/ECE 438, Fall 2007

 How do we Communicate?
 Send a mail from Alice to Bob Bob
 Alice in Champaign, Bob in Hollywood
 Example:
 US Postal Service

Alice

Hollywood, California

Champaign, Illinois

29 8/29/07 UIUC - CS/ECE 438, Fall 2007

 What does Alice do?
Alice
200 Cornfield Rd.
Champaign, IL 61820

Bob
100 Santa Monica Blvd.
Hollywood, CA 90028

 Bob’s address (to a mailbox)

 Bob’s name – in case people share mailbox
 Postage – have to pay!
 Alice’s own name and address – in case Bob wants to return a
message

30 8/29/07 UIUC - CS/ECE 438, Fall 2007

 What does Bob do?
Alice
200 Cornfield Rd.
Champaign, IL 61820

Bob
100 Santa Monica Blvd.
Hollywood, CA 90028

 Install a mailbox
 Receive the mail
 Get rid of envelope
 Read the message

31 8/29/07 UIUC - CS/ECE 438, Fall 2007

 What about sending a TCP/IP
packet?
 Very similar to Alice-mailing-to-Bob
 Different terminologies – very confusing
 We have to remember
 Different technologies
 Suppose to be better (faster, more reliable,
cheaper, …)

32 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Direction and Principles

Programming

learn to use Internet for

Transport communication (with focus on
implementation of networking
Network concepts)
Data Link
learn to build network from ground
Physical
up
Principles and
Concepts

33 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Sockets
 process sends/receives
host or host or
messages to/from its server server
socket
 socket analogous to controlled by
app developer
mailbox process process
 sending process relies socket socket
on transport TCP with TCP with
Internet
infrastructure which buffers, buffers,
variables variables
brings message to
socket at receiving
process

34 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Network Programming with
Sockets
 Reading:
 Stevens 2nd or 3rd ed., Ch. 1-6 or 1st ed., Ch. 1-3, 6

 Sockets API:
 A transport layer service interface
 Introduced in 1981 by BSD 4.1
 Implemented as library and/or system calls
 Similar interfaces to TCP and UDP
 Can also serve as interface to IP (for super-user); known as
“raw sockets”

35 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Client-Server Model
 Asymmetric Communication
 Client sends requests
Client  Server sends replies
 Server/Daemon
 Well-known name (e.g., IP address + port)
Client  Waits for contact
 Processes requests, sends replies
Server  Client
Client  Initiates contact
 Waits for response

Client

36 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Client-Server Communication
Model
 Service Model
 Concurrent:
 Server processes multiple clients’ requests simultaneously
 Sequential:
 Server processes only one client’s requests at a time
 Hybrid:
 Server maintains multiple connections, but processes
responses sequentially
 Client and server categories are not disjoint
 A server can be a client of another server
 A server can be a client of its own client

37 8/29/07 UIUC - CS/ECE 438, Fall 2007

 int main(int argc, char **argv) {
int sockfd = socket(PF_INET, SOCK_STREAM, 0);
struct hostent * he = gethostbyname(argv[1]);
struct sockaddr_in their_addr;
their_addr.sin_addr = *((struct in_addr *)he->h_addr);
their_addr.sin_port = htons(atoi(argv[2]));
their_addr.sin_family = AF_INET;
memset(their_addr.sin_zero, ‘\0’, sizeof their_addr.sin_zero);
connect(sockfd, (struct sockaddr *) their_addr, sizeof their_addr);
write(sockfd, “GET /\r\n”, strlen(“GET /\r\n”));
while (1) {
char buf[100];
int len = read(sockfd, buf, 100);
if (len <= 0) {
close(sockfd);
return 0;
} else {
write(1, buf, len);
}
}
}
38 8/29/07 UIUC - CS/ECE 438, Fall 2007
 Sockets
int sockfd = socket(PF_INET, SOCK_STREAM, 0);

 Creates a new socket

 SOCK_STREAM = TCP
 SOCK_DGRAM = UDP

39 8/29/07 UIUC - CS/ECE 438, Fall 2007

 TCP Connections
 Transmission Control Protocol (TCP)
Service
 OSI Transport Layer
 Service Model
 Reliable byte stream (interpreted by application)
 16-bit port space allows multiple connections on a
single host
 Connection-oriented
 Set up connection before communicating
 Tear down connection when done

40 8/29/07 UIUC - CS/ECE 438, Fall 2007

 TCP Service
 Reliable Data Transfer
 Guarantees delivery of all data
 Exactly once if no catastrophic failures
 Sequenced Data Transfer
 Guarantees in-order delivery of data
 If A sends M1 followed by M2 to B, B never receives M2 before
M1
 Regulated Data Flow
 Monitors network and adjusts transmission appropriately
 Prevents senders from wasting bandwidth
 Reduces global congestion problems
 Data Transmission
 Full-Duplex byte stream

41 8/29/07 UIUC - CS/ECE 438, Fall 2007

 UDP Services
 User Datagram Protocol Service
 OSI Transport Layer
 Provides a thin layer over IP
 16-bit port space (distinct from TCP ports)
allows multiple recipients on a single host

42 8/29/07 UIUC - CS/ECE 438, Fall 2007

 UDP Services
 Unit of Transfer
 Datagram (variable length packet)
 Unreliable
 No guaranteed delivery
 Drops packets silently
 Unordered
 No guarantee of maintained order of delivery
 Unlimited Transmission
 No flow control

43 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Addresses
struct hostent * he = gethostbyname(argv[1]);
struct sockaddr_in their_addr;
their_addr.sin_addr = *((struct in_addr *)he->h_addr);

 Look up destination host name

44 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Addresses and Data
 Internet domain names
 Human readable
 Variable length
 Ex: sal.cs.uiuc.edu
 IP addresses
 Easily handled by routers/computers
 Fixed length
 Somewhat geographical
 Ex: 128.174.252.217

45 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Address Access/Conversion
Functions
 All binary values are network byte ordered

struct hostent* gethostbyname (const char*

hostname);
 Translate English host name to IP address (uses DNS)

struct hostent* gethostbyaddr (const char*

addr, size_t len, int family);
 Translate IP address to English host name (not secure)

char* inet_ntoa (struct in_addr inaddr);

 Translate IP address to ASCII dotted-decimal notation (e.g.,
“128.32.36.37”)
46 8/29/07 UIUC - CS/ECE 438, Fall 2007
 Structure: hostent
 The hostent data structure (from
/usr/include/netdb.h)
 canonical domain name and aliases
 list of addresses associated with machine
 also address type and length information
struct hostent {
char* h_name; /* official name of host */
char** h_aliases; /* NULL-terminated alias list */
int h_addrtype /* address type (AF_INET) */
int h_length; /* length of addresses (4B) */
char** h_addr_list; /* NULL-terminated address list */
#define h_addr h_addr_list[0];/* backward-compatibility */
};

47 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Choose port
their_addr.sin_port = htons(atoi(argv[2]));

 Select a destination port

 Convert byte order

48 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Byte Ordering
 Big Endian vs. Little Endian
 Little Endian (Intel, DEC):
 Least significant byte of word is stored in the lowest
memory address
 Big Endian (Sun, SGI, HP):
 Most significant byte of word is stored in the lowest memory
address
 Network Byte Order = Big Endian
 Allows both sides to communicate
 Must be used for some data (i.e. IP Addresses)
 Good form for all binary data

49 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Byte Ordering Functions
 16- and 32-bit conversion functions (for platform
independence)
 Examples:
int m, n;
short int s,t;

m = ntohl (n) net-to-host long (32-bit) translation

s = ntohs (t) net-to-host short (16-bit) translation
n = htonl (m) host-to-net long (32-bit) translation
t = htons (s) host-to-net short (16-bit) translation

50 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Socket address
their_addr.sin_family = AF_INET;
memset(their_addr.sin_zero, ‘\0’, sizeof their_addr.sin_zero);

 Fill in a few fields in the socket address

structure
 “Magic”

51 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Socket Address Structure
 IP address:
struct in_addr {
in_addr_t s_addr; /* 32-bit IP address */
};

 TCP or UDP address:

struct sockaddr_in {
short sin_family;
ushort sin_port;
struct in_addr;
};
/* e.g., AF_INET */
/* TCP/UDP port */
/* IP address */

 all but sin_family in network byte order

52 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Connecting the socket
connect(sockfd, (struct sockaddr *) their_addr, sizeof
their_addr);

 Actually creates a TCP connection,

contacting a server
 Afterwards, use file descriptor like a
regular file - read, write, close

53 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Server
int main(int argc, char **argv) {
int sockfd = socket(PF_INET, SOCK_STREAM, 0);
struct sockaddr_in my_addr;
my_addr.sin_addr = INADDR_ANY;
my_addr.sin_port = htons(atoi(argv[1]));
my_addr.sin_family = AF_INET;
memset(my_addr.sin_zero, ‘\0’, sizeof my_addr.sin_zero);
bind(sockfd, (struct sockaddr *) my_addr, sizeof my_addr);
listen(sockfd, 10);
while (1) {
struct sockaddr_in their_addr;
int sin_size;
int newfd = accept(sockfd, (struct sockaddr *) & their_addr,
&sin_size);
write(newfd, “Hello world!\n”, 14);
close(newfd);
} }

54 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Address specification
my_addr.sin_addr = INADDR_ANY;

 Accept connections from any address

 Can also select a specific interface here

55 8/29/07 UIUC - CS/ECE 438, Fall 2007

 bind
bind(sockfd, (struct sockaddr *) my_addr, sizeof my_addr);

 Connects a socket with a well-known

incoming port on a local system

56 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Listen
listen(sockfd, 10);

 Start accepting connections

 10 is the amount of backlog connections
 If more than 10 clients waiting, computer will
refuse new connections

57 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Accept
int newfd = accept(sockfd, (struct sockaddr *) & their_addr, &sin_size);

 Receive a new connection

 their_addr contains the address of the remote
host
 newfd is the socket descriptor for
communications
 Used like a regular socket, can read write
close

58 8/29/07 UIUC - CS/ECE 438, Fall 2007

 TCP Connection Example
client server
socket
socket bind

connect listen
accept

write
read
write
read
close read
close

59 8/29/07 UIUC - CS/ECE 438, Fall 2007

 UDP Connection Example
client server

socket
socket bind
sendto

recvfrom

sendto

recvfrom
close

60 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Functions: sendto
int sendto (int sockfd, char* buf, size_t nbytes,
int flags, struct sockaddr* destaddr, int
addrlen);
 Send a datagram to another UDP socket.
 Returns number of bytes written or -1. Also sets errno on failure.
 sockfd: socket file descriptor (returned from socket)
 buf: data buffer
 nbytes: number of bytes to try to read
 flags: see man page for details; typically use 0
 destaddr: IP address and port number of destination socket
 addrlen: length of address structure
 = sizeof (struct sockaddr_in)

61 8/29/07 UIUC - CS/ECE 438, Fall 2007

 Functions: recvfrom
int recvfrom (int sockfd, char* buf, size_t nbytes,
int flags, struct sockaddr* srcaddr, int*
addrlen);
 Read a datagram from a UDP socket.
 Returns number of bytes read (0 is valid) or -1. Also sets errno on
failure.
 sockfd: socket file descriptor (returned from socket)
 buf: data buffer
 nbytes: number of bytes to try to read
 flags: see man page for details; typically use 0
 srcaddr: IP address and port number of sending socket (returned from
call)
 addrlen: length of address structure = pointer to int set to sizeof
(struct sockaddr_in)

62 8/29/07 UIUC - CS/ECE 438, Fall 2007

 TCP and UDP Ports
 Allocated and assigned by the Internet Assigned
Numbers Authority
 see RFC 1700 or
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers

1-512  standard services (see /etc/services)

 super-user only

513-1023  registered and controlled, also used for identity

verification
 super-user only

1024-49151  registered services/ephemeral ports

49152-65535  private/ephemeral ports

63 8/29/07 UIUC - CS/ECE 438, Fall 2007

UNIX to UNIX Copy [UUCP]
 UUCP is an abbreviation for Unix-to-Unix Copy
Program. The term generally refers to a suite of
computer programs and protocols allowing remote
execution of commands and transfer of files, email and
netnews between computers.
 Specifically, uucp is one of the programs in the suite; it
provides a user interface for requesting file copy
operations.
 The UUCP suite also includes uux (user interface for
remote command execution), uucico (communication
program), uustat (reports statistics on recent activity),
uuxqt (execute commands sent from remote machines),
and uuname (reports the uucp name of the local
system).
UUCP – At a Glance
 UUCP can use several different types of
physical connections and link-layer protocols,
but was most commonly used over dial-up
connections.
 Before the widespread availability of Internet
connectivity, computers were only connected by
smaller private networks within a company or
organization.
 They were also often equipped with modems so
they could be used remotely from character-
mode terminals via dial-up lines.
Inside UUCP
 UUCP uses the computers' modems to dial out to other
computers, establishing temporary, point-to-point links
between them.
 Each system in a UUCP network has a list of neighbor
systems, with phone numbers, login names and passwords,
and so on.
 When work (file transfer or command execution requests) is
queued for a neighbor system, the uucico program typically
calls that system to process the work.
 The uucico program can also poll its neighbors periodically
to check for work queued on their side; this permits
neighbors without dial-out capability to participate.
Distributed File Systems
A distributed file system may have some or all of the
following properties.
 Network Transparency : access remote files using the
same operations that apply to local files.
 Location Transparency : The name of the file should
not reveal its location in the network.
 Location Independence : The name of the file should
not change when its physical location changes.
 User Mobility : Users should be able to access shared
files from any node in the network.
 Fault Tolerance
 Scalability
 File Mobility : Move files among the nodes in a running
system.
Design Issues
 Name Space : Some systems provide a uniform name
space to allow the users to specify the same pathname.
Some other systems mount the remote files system.
 Stateful or Stateless : The client operations between
requests is tracked by the stateful server. They are
faster as they have the track record of previous
operations. They are complex.
 Semantics of Sharing : UNIX semantics require that
changes made by one client must be visible to all the
other clients when a next read or write is issued.
 Remote Access Methods : In stateless systems the
server is passive and the client does all the required
actions. This is not so in stateful servers.
Network File System (NFS)
 This is stateless distributed file system
introduced by Sun Microsystems.
 The client uses Remote Procedure Calls to
communicate with the Server.
 A ‘virtual node’ is created when the remote file
system is mounted onto the local file system.
 A set of pre-defined operations built on RPC are
defined.
Remote File Sharing (RFS)
 AT&T introduced this Stateful distributed
file system in SVR3 UNIX.
 It is based on ‘virtual circuit’ connection
between the client-server pairs.
 A centralized ‘Name Server’ maps the
symbolic resource names to their network
location.
UNIX Process Model
 Limitations of UNIX Process
Model
 The independence of parent and child, while
providing memory protection and therefore
stability, causes problems when you want to
have multiple processes working on the same
task/problem.
 The cost of switching between multiple processes is
relatively high.
 There are often severe limits on the number of
processes the scheduler can handle efficiently.
 Synchronization variables, shared between multiple
processes, are typically slow.
Threads
 Threads or Light Weight Processes(LWP) can
be very useful.
 Threads share a common address space, and
are often scheduled internally in a process,
thereby avoiding a lot of the inefficiencies of
multiple processes.
 One very popular API for threading an
application is pthreads, also known as POSIX
threads, P1003.1c, or ISO/IEC 9945-1:1990c.
LAN Concepts and Components
 This
is the most foundational Aspect of
Networking.
 OSI Protocol Stack
7 Application

6 Presentation Understanding

5 Session

4 Transport

3 Network

Transmission

2 Data Link

1 Physical
OSI Protocol Stack (cont.)
 Layers 1-4: transmission - how data
moves through the network.
 Layers 5-7: understanding - how data
appears to applications and users
OSI Protocol Stack (cont.)
 Explanation of the layers:
 Physical: Physical cable, electrical signalling, cable
length specifications, connector size.
 Data link: Error free (not reliable) media access for
datagrams
 Network: Provides path (route) through the network
for data
 Transport: Reliable (usually) flow of datagrams
between two nodes
 Session: Synchronises dialogue between two
programs
OSI Protocol Stack (cont.)
 Explanation (cont.):
 Presentation: Converts data between formats
used by two programs
 Application: Obvious (hopefully)
Internet Protocols and Services
7 Application Berkeley/ARPA NFS

6 Presentation XDR

5 Session SSL RPC

4 Transport TCP UDP

ICMP
IP
3 Network ARP

802.2
2 Data Link Ethernet
802.3

1 Physical 10 base T/2/5 Optical fibre

Transmission Attributes
 Bandwidth
 Measure of channel throughput
 Baseband: one channel (most LAN technologies)

 Broadband: multiple channels (cable TV)

 Electrical interference
 Noise produced by other electrical devices and cables
 Shielding used to reduce

 Attenuation
 Signal decay over the length of the cable
 Reduced by amplifiers (analog), repeaters (digital)
Access Methods
 CSMA/CD (ethernet)
 Carrier sense, multiple access, collision detection
 Nodes must wait to transmit, and back off if there is a
collision
 Performs poorly under high load conditions

 Token passing (token ring)

 A token is passed around from node to node - only the
node with the token can transmit
 If a node has nothing to send, it passes the token to the
next node
 Performs well under high load

 Provides guaranteed access to every node


IEEE Standards
 IEEE defined LAN standards
 Similar to OSI stack
 Split data link layer into two levels:
 Logical link control (LLC)
 Media access control (MAC)
 Standards
 802.2: LLC
 802.3: CSMA/CD

 802.4: Token passing (bus topology)

 802.5: Token passing (ring topology)

Media Types
 Coaxial (10 base 2): “BNC”, “Thin Ethernet”
 Central conductor surrounded by a metal shield and
insulators
 Bus topology

 Pros:
 No powered components
 Cons:
 Breaking one cable breaks whole network
 Length: 180 m total
 Not common any more
Media Types (cont.)
 Twisted pair (10 base T, 100 base T): “UTP”
 Pairs of wires (2 or 4 pairs), twisted together
 Star topology

 Pros:
 Each node has a separate connection, thus easy to “plug and
play”
 Failure of one cable only affects attached node
 Hubs can provide management information
 Cons:
 Requires a hub, thus more expensive than coaxial
 Failure of hub affects all attached nodes
 Most commonly used cable in the industry
 Length: 90 m per cable run, maximum of 4 hops
Media Types (cont.)
 Optical fibre
 Glass fibres transmit light pulses
 Point-to-point connection

 Pros:
 Immune to electrical interference
 High bandwidth
 Cons:
 Installation and maintenance difficult
 Equipment often expensive
 Used for some inter-network connections and high-
bandwidth disk connectivity
Transceivers
 Convert signals from a LAN card to
specific cable types
 Several types used;
 10 base T
 10 base 2

 100 base T

 Gigabit
 Gateways
7 Application

6 Presentation

Gateway

5 Session

4 Transport Transport Relay

3 Network Router L3 Switch

2 Data Link Bridge Switch

1 Physical Repeater Hub

Gateways
 “Gateway”: Generic term for something
that passes data at any level of the OSI
stack, but generally used for level 4 or
higher.
 For the lower levels, more specific terms
are normally used.
Physical Gateways
 Repeater: Re-generates signal
 Allows extension of network beyond
standard cable length limits
 Hub: Multi-port repeater
Data Link Gateways
 Bridge: Uses link-level address to
determine passing of packets
 Will only transmit frames if the destination
address belongs to a node on the other
side (learn this automatically)
 Switch: Multi-port bridge
 Switches turn CSMA/CD into point to point,
enabling it to scale much more effectively
Network Gateways
 Router: Transmits packets based on IP
addresses
 Unix systems can be routers by turning on
packet forwarding
 Not recommended: Let routers do routing,
and Unix boxes do Unix applications
IP Family Protocols
 TCP: Transmission Control Protocol
 Layer 4 connection-oriented (stream) protocol
 Guarantees delivery order and reliability of packets

 UDP: User Datagram Protocol

 Layer 4 connectionless (datagram) protocol
 Packets could be lost, duplicated, or out of sequence

 IP(v4): Internet Protocol

 ICMP: Internet Control Message Protocol
 ARP: Address Resolution Protocol
 Unix file: /etc/protocols
 Addressing
7 Application

6 Presentation

5 Session

Host Name

4 Transport Port

3 Network IP

2 Data Link MAC

1 Physical
Link Level Addresses
 Also called:
 Ethernet address, MAC address, station address,
hardware address
 48-bits
 Top 24 bits: vendor id
 Bottom 24 bits: node id
 Looks like this:
 000502879BD1, 08:00:09:C8:2D:F0
 Unix commands:
 lanscan (HP-UX), ifconfig (Solaris, Linux)
IP Addresses
 Address notation
 32 bit number
 Expressed in “dotted-quad” notation, e.g. 164.112.128.1

 Address classes
 Allocate addresses efficiently to different sized
organisations
 Use high-order bits of address to determine class

 Class A
 For large organisations
 24 bits for host addresses

 High order bit: 0

 Network numbers: 1 - 126 (0x00 - 0x7F)

IP Addresses (cont.)
 Class B
 For medium-sized organisations
 16 bits for host addresses

 High order bits: 10

 Network numbers: 128 - 191 (0x80 - 0xBF)

 Class C
 For small organisations
 8 bits for host addresses

 High order bits: 110

 Network numbers: 192 - 223 (0xC0 - 0xDF)

IP Addresses (cont.)
 Class D (Multicast)
 Special purpose, datagram only
 Mainly targeted at multimedia broadcasts

 High order bits: 1110

 Network numbers: 224 - 239 (0xE0 - 0xEF)

 Reserved
 240-255: Reserved (undefined?)
 Private networks (RFC 1918):
 10.0.0.0
 172.16.0.0 - 172.31.0.0

 192.168.0.0 - 192.168.255.0

 NAT is used to connect private networks to the Internet

IP Addresses (cont.)
 Site notes:
 Class B: most nodes
 Class A private: 10.0.0.0 (some routers)

 Class C private: 192.168.x.x (clusters, private backup

LANs)
 Class D: 224.0.x.x (NTP, OSPF, RIP, others?)

 Unix commands:
 ifconfig: interfaces
 netstat -in: interfaces

 netstat -gn: multicast

 netstat -rn: routing

Subnets
 Subnets are a way of breaking up a larger
network into smaller chunks
 Your subnet is the group of hosts you can talk to
without going through a router
 Subnets can vary in length, up to the size of the
network
 The main reason to use different sizes of
subnets is to use address space efficiently, and
optimise performance of hosts and routers
Special IP Addresses
 Network: the address on each subnet
where the host address is all zeros
 Broadcast: the address on each subnet
where the host address is all ones. All
hosts on the local subnet should respond
to this address
 Loopback: 127.0.0.1. Only the local host
will ever respond to this.
Subnet Masks
 Subnet masks are how subnet lengths are
specified
 They consist of a bit mask, with the number of 1
bits indicating the number of bits used for the
network portion of the IP address.
 32 bit number, specified as dotted quad, e.g.:
 255.255.252.0
 255.255.255.0

 255.255.255.192

 Can also be specified after IP address as a

number of bits, e.g.: 10.20.30.0/24
Subnet Masks (cont.)
 Given any IP address and subnet mask, you can
work out which subnet it’s in by ANDing the
subnet mask with the IP address:
 IP 10.20.30.81 = 0x0A141E51
 mask 255.255.255.192 = 0xFFFFFFC0
 AND 10.20.30.64 = 0x0A141E40
 To find out the broadcast address, invert the
subnet mask and OR them:
 network 10.20.30.81 = 0x0A141E51
 ~mask 0.0.0.63 = 0x0000003F
 OR 10.20.30.127 = 0x0A141E7F
Subnet Masks (cont.)
 In the above example, everything between
10.20.30.65 and 10.20.30.126 is a useable
node address on this subnet
 Common conventions:
1:
 Low addresses are communications equipment

 High addresses are servers

2:
 Low addresses are servers

 Middle addresses are workstations

 High addresses are communications equipment

IP Addresses: Warnings
 The same IP address may not be assigned to
different hosts (under normal circumstances)
 A node can have more than one interface card
 An interface card can have more than one IP
address. This is not supported by HP until HP-
UX 11.x; Solaris (and others?) are no problem
 HP-UX, Solaris (and others?) cannot have more
than one interface card on the same LAN without
problems
TCP/UDP Addresses
 Port number
 16 bits

 Separate TCP and UDP address spaces

 Unix files:
 /etc/services - all known port assignments
 /etc/inetd.conf - active port assignments (mostly)

 Command:
 netstat -an - shows all active ports
Host Naming
 Unix host name
 hostname
 uname -n

 Network naming systems:

 NIS:
 Flat name space
 Does more than just hosts: users, groups, protocols,
home directories, etc.
 DNS:
 hierarchical
 Internet standard
 Does mainly hostnames and email routing
 NIS+: combines features of NIS and DNS, adding
secure authentication
2. Configuring Unix Networking
 This section will be a bit more practical, but
shorter
 We’ll cover:
 LAN cards
 IP addresses

 Routes

 Hosts

 Troubleshooting

 Some details are applicable to HP-UX only

LAN Cards
 General hardware information: ioscan -u
 Specific LAN card information: lanscan

 Detailed LAN card information: lanadmin

 Software: swlist -l product | grep

Networking
IP Addresses and Routes
 General information: netstat -in
 Multicast: netstat -gn

 Per-LAN card information: ifconfig <lan>

 Routing tables: netstat -rn, route

 Routing daemons: gated, rdpd

 Startup files:
/etc/rc.config.d/{netconf,netdaemons}
Host Names
 Looking up hosts
 Local: /etc/hosts
 NIS: ypcat hosts

 DNS: nslookup host

(on HP-UX, this does local and NIS also)

 Configuring hostname resolution
 Resolution order: /etc/nsswitch.conf
 NIS, DNS: /etc/rc.config.d/namesvrs

 DNS: /etc/resolv.conf
Troubleshooting Commands
 ping

 traceroute

 arp

 netstat

 linkloop

 lanadmin
3. Configuring Internet Services
 In this section:
 Internetservices overview
 Configuration and startup

 Checking connections
Internet Services
C a p a b ility G e n e r a l ( m o s t l y A RBPeAr )k e l e y ( B S D )
L o g in T e ln e t r lo g in
F ile tr a n s fe r FTP , TFTP rc p
C o m m a n d e x e c u tio n re x e c , re m sh (rsh )
E m a il s e n d m a il
N e tw o r k in fo r m a tio n r w h o , r u p tim e , fin g e r
D y n a m ic r o u tin g g a te d r o u te d
N a m e s e r vic e s B IN D , N IS
T im e s y n c h r o n iz a N
tioTnP tim e d
D y n a m ic c o n fig u rB a tio
O On T P , D H C P
S y s te m lo g g in g s y s lo g d
P r in tin g lp d
Clients and Servers
D a e m o n ( / u s r / sSbeirnv) e r ( / u s r / l bCilni e) n t ( / u s r / b i nS)e r v i c e
in e t d t e ln e t d , r lo g in dt e ln e t , r lo g in L o g in
ftp d , tftp d ftp , tftp F ile t r a n s f e r
re m s h d rc p F ile t r a n s f e r
r e x e c d , r e m s h dr e x e c , r e m s h ( r sCh o) m m a n d e x e c u t io n
s e n d m a il m a il E m a il
r w h o d , f in g e r d r w h o , r u p t im e , N f ine gt we ro r k in f o r m a t io n
b o o tp d b o o tp d b o o tp q u e ry D y n a m ic c o n f ig u r a t io n
g a te d , rd p d D y n a m ic r o u t in g
n am ed n s lo o k u p N a m e s e r v ic e s
x n tp d n t p q , n t p d a t e T im e s y n c h r o n iz a t io n
s y s lo g d s y s lo g d , lo g g e r S y s t e m lo g g in g
r lp d a e m o n lp ( r lp ) P r in t in g
How inetd Works
 Listens on ports, waiting for connections
 When connection arrives, UNIX checks against
security file /var/adm/inetd.sec to allow or deny
access
Linux uses tcpd for the same purpose:
/etc/hosts.{allow,deny}
 Sets up socket connection
 Invokes server process and transfers control to it
 Returns to listening
inetd Configuration Files
 /etc/services: Well-known ports
 /etc/inetd.conf: Active inetd services

 /var/adm/inetd.sec: Access control for

inetd
 /etc/rc.config.d/netdaemons: Command
line parameters for inetd startup
Service Startup

Service Startup Script Startup Configuration

/sbin/init.d /etc/rc.config.d
Dynamic routing gated netconf
Internet daemon inetd netdaemons
DNS named namesvrs
General networking net netconf
Tracing and logging nettl nettl
NFS nfs.client nfsconf
NFS nfs.core nfsconf
NFS nfs.server nfsconf
NIS nis.client namesvrs
NIS nis.server namesvrs
Network informationrwhod netdaemons
Email sendmail mailservs
System logging syslogd
NTP xntp netdaemons
Checking Connections
 netstat

 netstat -a
Remote Login
 rlogin configuration files:
 /etc/hosts.equiv
 System-wide
 Permissions 444
 root ignores it
 $HOME/.rhosts
 Per-user
 Permissions 600
 Can override hosts.equiv
 Can be overridden with rlogind -l
FTP
 /etc/ftpusers
 Lists users not allowed to login via ftpd
 All users without passwords are also not

allowed to login
 $HOME/.netrc
 Specifies hosts, usernames, and passwords
for ftp & rexec
 Don’t use it!
Anonymous FTP
 Uses ftp user home directory
 Does a chroot() to ~ftp so that user is
“sandboxed”
 Needs certain directories & files to work:
 ~ftp/usr/bin/ls, mode 111
 ~ftp/etc/{passwd,group,logingroup}, mode 444

 Other directories:
 ~ftp/dist: outgoing files (elsewhere ~ftp/pub)
 ~ftp/pub: incoming files (elsewhere ~ftp/incoming)

 ftpd -l logs information to syslog

Other Protocols and Services
 See the separate handout for:
 RouterDiscovery Protocol (RDP)
 Network Time Protocol (NTP)

 Network Information Service (NIS)

 Network File System (NFS)