The practical assignment must be developed in C programming language over
Linux OS and your implementation must work on the Telemática lab computers, where the assessment will take place. Please, refer to details below on machines available and how to connect remotely.
It is mandatory the use of the gcc parameter -Wall in every compilation. The code must compile without warnings or errors.
Also, the code must not have memory leaks (valgrind will be used to check this).
The submission instructions will be published during the course. Basically, the source code (.c and .h files), a Makefile file to compile it, and a README file with some data (name, email address and group) have to be submitted. Practical assignments which do no meet these requirements will not be assessed, i.e., implementations containing memory leaks, compilation warnings or compilation errors, will not be assessed.
The practical assignment consists of a simplified version of the RFC. Simplifications are listed below. The complete RFC specification can be found in the following link: RFC 2131.
The RFC 2131 standard defines both the client and the server requirements for obtaining bootstrap and configuration parameters. However, in this practical assignment only the client implementation is required.
Due to the fact that it is neccesary to be root in order to carry out the developement, a test environment will be provided, with all the software installed, including a basic DHCP server.
- Basic operation:
Next, the operation of the DHCP protocol will be briefly explained. A deeper explanation of the protocol is out of the scope of this document; it is the student, who should read the complete RFC and understand all the details required for a correct implementation.
DHCP protocol deals with different kinds of packets DHCP, of which is mandatory to implement/recognize the following:
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNACK, DHCPRELEASE and DHCPDECLINE.
DHCP works only with UDP, and it is one of the few protocols that use static port numbers not only for servers (port 67), but also for clients (port 68).
DHCP allows to obtain different parameters, such us IP address, subnetwork mask, boot file, DNS, printer server, etc...
As an example, in order to obtain those parameters, the client and server mush exchange the following packets (see figure):
- DHCPDISCOVER, sent by the client. It is an UDP multicast message which is received by DHCP servers.
- DHCPOFFER, where IP addresses are offered by one or several servers. Client should choose one.
- DHCPREQUEST, sent by the client. It is an UDP message (unicast or multicast) to request an specific address.
- DHCPACK, sent by the server to confirm an IP.
There are some messages, like DHCPNACK, DHCPRELEASE and DHCPDECLINE, which are not shown in the previous image but whose implementation/support is mandatory.
DHCPDECLINE is sent by the client to reject an offered IP address from the server (for example, if it is already in use).
So, it is mandatory to implement a DHCP client taking the considerations of the following paragraphs into account:
- Executable and parameters: refer to the dhcpcl man page for details.
- Examples and input/output format: refer to the dhcpcl man page for details.
- Traces: refer to the dhcpcl man page for details.
- Notes:
- Every message must be shown by the standard output, except error messages, which must be shown
by the error standard output.
- Once the parameters from the server are received, the client, after checking the IP address is not in use by any other machine, will only have to configure
the IP address, the subnetwork mask and the gateway (router) address. Remaining data coming from the DHCP server can be ignored by the client.
- Mandatory changes for September:
-
It is mandatory to implement both REBINDING and RENEWING states. Therefore,
the use of the T1 and T2 timers (see RFC's Figure 5) is mandatory. According to the RFC, once the client is in BOUND state,
there are three timers (T1 < T2 < leasetime) that start and lead to the transition to other states and the sending
of some messages.
- If T1 expires, the client enters in RENEWING state and sends unicast DHCPREQUEST asking for an extension of the leasetime.
- If T2 expires without receiving DHCPACK, the client enters in REBINDING state and sends broadcast DHCPREQUEST.
-
When in BOUND, REBINDING or RENEWING states, the program will finish once SIGUSR2 signal is received.
-
It is mandatory that the client checks whether the obtained IP address is available by means of ARP.
-
No scripts of any type will be allowed during the assessment.
- It is mandatory a compilation without warnings or errors, including the usage of -Wall with gcc
- Valgrind will be used to detect memory leaks on a basic execution with a server and by ending the execution with SIGUSR2
or with SIGINT (Ctrl+C). It is mandatory to use -q and
--leak-check=full options.
- Simplifications to the RFC:
- It is not necessary to implement DHCPINFORM messages.
- It is not necessary any implementation related to multi-homed hosts.
- The only mandatory link level is Ethernet.
- If the client receives more than one answer from the present servers, it has to choose one of them.
How it is selected, is left to the implementors decision.
- Everything that appears in the RFC as MAY or SHOULD is optional.
Everything that appears as MUST is mandatory for the assignment.
- Considerations about timers and timeouts: the values will always be those marked as
RECOMMENDED in the RFC.
- Considerations about sockets: it is mandatory to use UDP sockets whenever is possible (e.g.
DHCPRELEASE, DHCPDECLINE). When not possible (DHCPDISCOVER, DHCPREQUEST, ARP) raw or packet sockets will be used.
In short, the client implementation must make use of both socket types.
- How to access remotely to the lab machines:
- From home, you need to connect to any of the machines at labs 7.0.J02, 7.0.J03, 4.1B01, 1.1A16, whose FQDN are the following:
- jbit101.lab.it.uc3m.es - jbit156.lab.it.uc3m.es
- it001.lab.it.uc3m.es - it020.lab.it.uc3m.es
- lm001.lab.it.uc3m.es - lm010.lab.it.uc3m.es
- ctel001.lab.it.uc3m.es - ctel018.lab.it.uc3m.es
- Those machines are only available during working days (no weekends) and are switched off every day at 23:00.
- You need to use ssh (with -X option). Since access outside the university is filtered, you need to connect first to one of the foolowing machines below, and then
open another connection to the lab machines above:
- monitor01.lab.it.uc3m.es
- monitor02.lab.it.uc3m.es
- monitor03.lab.it.uc3m.es
- RSA fingerprint for many of the lab machines is:
dc:a9:3e:f6:51:98:54:dc:56:61:0e:96:c6:7a:70:a5
(if not, please check with the lab technicians).
-
Please, note that it is not recommended to use monitor0x for testing, since some of them still run a preemptive kernel.
To check if a kernel is preemptive, you can use uname -a:
Linux monitor02 2.6.26 #3 SMP PREEMPT Fri Jul 18 12:07:07 CEST 2008
i686 GNU/Linux
A manual page has been created for the proposed implementation of dhcpcl, that resumes the information
about input, output and traces formats. It can also be downloaded
in HTML format,
PDF format,
or TXT format,.
|
