Documentation:

Background:

Data communication protocols: A protocol is a set of rules and message formats that precisely define the interactions between communicating nodes in a data communications network. If (as is commonly the case) the protocols used by a communications network have a layered structure, then corresponding layer entities in communicating nodes in the network interact with each other using their own layer-specific protocols. Thus, the TCP entities in the source and destination nodes of an Internet connection interact with each other using the Transmission Control Protocol (TCP). At the same time, the IP entities in adjacent nodes along a communication path will interact with each other using the Internetworking Protocol (IP). A protocol stack is the implementation, at one node, in software and/or hardware, of the algorithms that implement a layered protocol. Low-level protocol layers usually handle more basic functions, such as addressing and transmission control between adjacent nodes in the network. Middle-level protocol layers take care of functions, such as end-to-end reliable packet transmission, that require more knowledge of the structure (e.g. byte sequencing) of the transmitted data. At the higher layers, applications may use protocols, such as the HyperText Transfer Protocol (HTTP), that must parse the structure and meaning of the exchanged streams of bytes that are transported over an underlying TCP/IP connection.

Internetworking Protocol (IP): The Internet is actually a world-wide collection of interconnected networks that are able to interact with each other successfully because, even though they may be based on different physical layer transmission technologies, they all use the same middle-layer communication protocols. At the so-called data link layer, the Internetworking Protocol specifies how nodes in the Internet will be uniquely identified by means of numerical addresses. In the Internet domain (as opposed to within a networked Unix file system domain), each full IP address consists of the 32-bit node address (called the IP address) and a 16-bit port number. The port number is an unsigned integer that is used as a local address to identify different software services within a network node. Many of the small-valued port numbers have been assigned standard meanings. For example, port number 80 identifies the software process (the so-called web server process) that handles incoming requests to serve out HTML-encoded information that is stored on the node. Port numbers above 2000 are generally not reserved for standard services, and can thus be used for new user-defined services.

IP is used to route data packets of variable length from the source node along a path of intervening nodes to the correct destination node. At the sending node, the local IP entity prepends an IP header to each incoming data packet (typically a TCP or UDP segment) that is passed down to it by the overlying protocol layer. The IP header is a data structure that contains the IP addresses of the source and destination nodes as well as other useful information. The IP header and associated data packet are together called an IP datagram. Each IP datagram travels separately through the Internet. The contents of the IP header are consulted by the IP entities in the intervening nodes as each IP datagram arrives so that it can be decided if the datagram has reached its destination node, or that it should be passed along to the next node in its route. If the IP datagram has indeed arrived at the destination node, then the header is stripped away by the local IP entity and the remaining packet (usually a TCP or UDP segment) is passed up to the next higher layer (usually the TCP or UDP entity) in the destination node's protocol stack.

Transmission Control Protocol (TCP): IP alone does not ensure that a stream of one or more IP datagrams will arrive in the correct order and without errors at the destination node. Such problems are taken care of in the Internet by a middle-level transport layer protocol called the Transmission Control Protocol. At the sender node, the local TCP entity prepends a TCP header to the front of each packet of user application data that it is given to transport. TCP then passes the resulting TCP segment down to the local IP layer. At the receiving node, the local TCP entity strips off the TCP headers from the arriving TCP segments and processes the TCP header information. By processing the TCP headers, the local TCP entity can detect missing segments, duplicate segments, and out-of-order segments. By not acknowledging segments, the TCP entity in the destination node will cause the TCP entity in the source node to time out and then retransmit those segments.

TCP/IP over SLIP: The standard combination of TCP running over IP is called TCP/IP. Higher-level protocols may exist on top of TCP, and lower-level protocols may exist underneath IP. In this laboratory exercise, the Linux host will be interfaced to the DUART in the microcomputer using a bi-directional serial RS232 link. A simple low-level protocol is required to break up IP datagrams into bytes so that the bytes can be transmitted one-by-one over the serial link. At the receiving end, the bytes are then reconstituted back into IP datagrams. Several such protocols have been developed for running IP over a serial line: we will be using perhaps the oldest and simplest such protocols, which is called the Serial Line Interface Protocol (SLIP). The simplest version of SLIP uses the following rules: When a data packet needs to be transmitted, simply start sending the bytes in the packet. After the last packet byte has been sent, send the END character (END = octal 300 = $C0). If an END character appears in the packet data, then send ESC-334 instead (ESC-334 = octal 333, 334 = $DB, $DC). If an ESC character appears in the packet data, then send ESC-335 instead (ESC-334 = octal 333, 335 = $DB, $DD). Note that SLIP provides no addressing information nor and error detection capabilities: it merely allows the data packet boundaries to be indicated (for the benefit of the TCP/IP stack in the destination node).

Sockets: TCP/IP functions can be called directly, but this requires extensive knowledge of the many features of TCP and IP. To simplify communication over the Internet using TCP/IP, a so-called Application Program Interface (API) is usually provided. For example, within a Unix system, processes participate in TCP/IP-controlled interactions by means of software abstractions provided by the API called sockets. If a software process within a Unix host (or a task within a MicroC/OS-II host) is expecting to be contacted in the future by software running on other hosts for the purposes of setting up a TCP/IP communications channel, then that local process (or task) creates and initializes a socket using procedure calls or traps to the local operating system. Once the socket has been properly initialized, the local TCP/IP stack will know to which process (or task) the incoming data packets should be delivered. The socket API allows a process to be blocked until the time that an expected data packet is received. When such a packet is received, then the local TCP/IP stack extracts the application data from the received IP datagram and loads it into the mailbox of the receiving process (task); then the TCP/IP stack calls the operating system to unblock the process (task) so that it will be scheduled to resume running on the local CPU.

Client-server communication: Communication over the Internet typically starts when one process, called a client process, requests information or some other service from a second process, called a server process, which typically (but not necessarily) exists on another node in the Internet. A common example of this would be a web browser client process on a personal computer requesting web pages from a departmental web server. Server processes know in advance that they may be contacted in the future over the Internet by client processes. To get ready for this possibility, a server process uses calls to the local operating system to create and initialize a new socket that will then be available to terminate requested connections. In Unix nodes, the operating system calls made by a server process to create and initialize a socket are named socket, bind, listen and accept. When a client process wishes to request a connection to a server, then it creates and initializes a socket on its own local node, then connects to the client and sends data packets to it. In Unix nodes, the operating system calls made by a client process are named socket and connect. Once a connection has been established between a client and a server, the two processes can send and receive data packets using the send and receive functions.

MicroC/OS-II extended with lwIP: In the laboratory exercise you will be using the Lightweight TCP/IP (lwIP) stack within the MicroC/OS-II environment. lwIP is a compact implementation of TCP/IP that is intended for use in embedded systems with limited memory. The API to lwIP is very similar to that in Unix, as indicated in the following table:

Unix system call	lwIP function call	Purpose
socket	netconn_new	Create a socket (clients and servers)
bind	netconn_bind	Bind a socket to a port number on the local machine (servers only)
listen	netconn_listen	Listen for connections to the socket (servers only)
accept	netconn_accept	Block the process until a client connects with the server (servers only)
connect	netconn_connect	Connect to the socket of a specified server (clients only)
send	netconn_write	Send data to the remote application (clients and servers)
receive	netconn_recv	Receive data from the remote application (clients and servers)
shutdown	netconn_delete	Closes and deletes a socket (clients and servers)

The provided code includes a server task, called tcpecho, that uses the lwIP API to create and initialize a socket in the MicroC/OS-II environment. Please study it carefully. If the tcpecho task is running on the 68332 microcomputer, then client processes on the Linux host can create sockets on the PC and then initiate connections to tcpecho.

Pre-lab Work:

Produce a flowchart or snippet of pseudocode that outlines your solution to exercise 2, and exercise 3. Each flowchart or snippet of pseudocode will be worth 5 points for a total of 10 points.

Exercise #1: Verifying the Build and Connection Over SLIP

1. Before making any connections between your breadboard and the PC, you need to load the SLIP interface on the PC. From a shell prompt run
   

   sudo slipup

   You should verify that you now have an active SLIP interface by running
   

   /sbin/ifconfig

   You should see output similar to the following lines in addition to the usual interfaces in place.

   sl0       Link encap:Serial Line IP
             inet addr:10.0.0.1  P-t-P:10.0.0.2  Mask:255.255.255.0
             UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:296  Metric:1
             RX packets:1198 errors:0 dropped:0 overruns:0 frame:0
             TX packets:1523 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:10
             RX bytes:74346 (72.6 Kb)  TX bytes:103380 (100.9 Kb)
   	

2. Connect the DB9 cable to your breadboard as was done in lab 2.
3. Retrieve the lab 3 tar file and place it in your cmpe401/ directory. Untar it using
   

   tar xvf lab3.tar

4. Build the lab3.s19 file by first changing into the lab 3 directory and typing
   

   make

   Download the lab3.s19 file to the board in the normal way.
5. After typing

   go 10000

   at the CPU32Bug prompt you should see:

   	LWIP 0.7.2 Loaded
   	Loopback Interface Up 127.0.0.1
   	Nancy's Fall2004 Version
   	SLIP Interface Up 10.0.0.2
   	Network Initialized
   	TCPEcho:listening on Port 7
   	

6. From your terminal shell run
   

   ping 10.0.0.2

   The NMIX Board has been assigned IP addresss 10.0.0.2 and the Linux Host has been assigned IP address 10.0.0.1. If the pings are returned the connection has been successfully created on both the Linux side and the board side.
7. Launch a telnet session over port 7 by typing
   

   telnet 10.0.0.2 7

   at the command line in your terminal shell. This will open a connection to the TCPEcho server. When you enter some text in the terminal window, the TCPEcho server will echo the text back to you. You will also see some status messages in the minicom window indicating that the server has received a connection request. Close the telnet connection by typing
   

   cntrl ]

   (control key and square bracket ] key) and then typing

   quit

   The TCPEcho server should return to listening mode.
8. After you have terminated your client-server application please turn off SLIP by running
   

   sudo slipdown

   If you do not terminate SLIP the next student may not be able to access the ttyS1 (minicom 2) serial port they may need for lab #2. Please be courteous and turn off SLIP before you leave your station.

Exercise #2: Creating a Statistics Server on Port 8

1. Uncomment the

   statserv_init()

   call in host.c to ensure that your stats server is created.
2. Using the template in lab3/net_apps/statserv.c create a new server that listens on port 8. When a connection is made to the server via telnet, a welcome message should be sent back to the Linux box along with a set of possible commands. Display the local and remote IP addresses in the form X.X.X.X
   The commands should be:
   • time: displays the current time. Retrieve the time from the Linux box by opening a connection to the Linux box over port 13.
   • localip: displays the local (board) IP address
   • remoteip: displays the remote (linux box) IP address
   • bye: closes the connection to the client
3. Your stats server must recognize case insensitive versions of time, localip, remoteip, and bye. In addition, the lab instructor's test cases will include cases like localip1, which must be rejected as incorrect input. If the user inputs an improper command like localip1, display a short warning and write the usage string to the terminal window again.
4. Test your stats server by running
   

   telnet 10.0.0.2 8

5. Solutions to the exercises in lab 3 are mutually exclusive. Demo them individually or as a group; your choice.

Exercise #3: Packet Header Information for the IP, ICMP, and TCP Protocols

1. Set the #DEFINE software switch for exercise 3 to TRUE. This will create the task that processes packets at the SLIP level along with the supporting functions. Several queues are also created to pass buffer data back and forth. As each packet arrives, it is copied to the allocated buffers, subject to availability, and the head of the buffer is posted to another queue so that the packet may be processed. As many as 5 packets may be waiting for processing at any one time. If the number of empty buffers is reduced to zero, the incoming packets will be dropped until the number of empty buffers is at least one.
2. The EndPacketTask pends on a queue that contains a pointer to the header of the next unprocessed packet. As soon as one is available the task will process it. You are to place your packet processing code inside the EndPacketTask in the indicated spot. The information from 3 types of headers is to be displayed. Click on the links for IP header information, ICMP header information, and TCP header information to get all the field definitions that you need to complete this section. The IP header always comes first followed by the ICMP or TCP header.
   • The IP header fields should include the remote IP address, the local IP address, the protocol type, and the total length. Display the protocol type in human readable form, either ICMP or TCP.
   • If the IP protocol header = 1, the incoming packet is an ICMP packet. Display the first 8 bytes of the ICMP header in hexadecimal form. Display the type information from the ICMP header in human readable form for the case of type=0:echo reply, or type=8: echo request. Ignore all other types.
   • If the IP protocol header = 6, the incoming packet is a TCP packet. Display the source port, the destination port, the sequence number, the acknowledgement number, the window, and the first 8 bytes in hex after the urgent pointer.

1. Uncomment the call to

   httpd_init()

   in the host.c file. This will create the web server thread.
2. Use the template provided in net_apps/httpd.c to create your web server.
3. Your web server must have a home page at index.html and /, and a stats.html page to display the same stats that you displayed in exercise 2. These would include daytime, localip and remoteip. The bye command should not be included. The daytime command and the local and remote IPs should be displayed in a human readable format as they were in exercise 2. In addition, a page at personal.html will serve up a web page of your own design. If the address requested by the browser is not one of index.html or /, stats.html or personal.html you must return a 404 error response message indicating page not found.
   
   Creativity is the key here. Impress the lab instructor with your coding (HTML and client-server) prowess! Feel free to include images, text or anything else the Firefox browser can handle. Testing of your web server code will only take place with the Firefox browser. This will eliminate any problems related to different browsers.
   
   The bonus points for this section are 5 points for the demo and 10 points for the report section of the bonus. The sum of the two portions equals 10% of the total lab mark. The maximum for this lab is therefore 110%, or 5.5% of your total grade. Good Luck!

• Please include your pre-lab submission as an appendix to the lab report.
• You source code submission should include statsserv.c, EndPacketTask, and your optional solution to exercise 4 if you attempted it. Do not include the host.c file or the lab3.c file in the report unless you made changes over and above the changes you were instructed to make in the various exercises above.
• The report format is identical to the previous reports. Include an abstract, a design section, a testing section, a conclusion, and your code submission plus the pre-lab.

Marking Scheme: Lab #3 is worth 25% of the final lab mark.
Please view the Marking Sheet to ensure that you have completed all of the requirements of the lab. The Marking Sheet also contains a limited test suite in the demo section. Please make use of it.

Last modified October 31, 2004