Behavior, in-use/open vs unused/closed ports,

when a client tries to contact them

It is useful to understand what happens when you try to contact software you think is running behind some port number. Sometimes you're wrong and there's no such software using that port. Something happens in that case, but by contrast if the port is in use by a program something different happens. It's good to get familiar with these behaviors so as to recognize them when you see them because they are commonplace. It's also important to bear in mind that there are multiple protocols that feature port numbers, not one. Most common and well known are tcp and udp. Each has a range of port numbers from 0 to 65535 (because the port number field in the protocols' headers are 16 bits wide). At any given time a protocol has some small subset of that range in use on behalf of applications (such ports are called open). And the protocols use these port numbers independent of one another. For example a server program might be using TCP port 5555, but that says nothing about whether or not any UDP program might be using port 5555. And if so, it's not the same port 5555. Each protocol keeps its own list of in-use/active port numbers. If you and I have shopping lists and mine contains milk it says nothing about yours, including whether or not yours contains milk. The lists are independent of one another.

Consequently, there are 4 cases to examine. First, trying to contact a port number as a TCP client when there is a TCP server using that number. Second, as a TCP client when there isn't. Third, trying to contact a port number as a UDP client when there is a UDP server using that number. Finally, as a UDP client when there isn't.

The assignment for you to perform

It is assumed that a target machine is available that runs the TCP discard service on port 9, no TCP service on port 10, the UDP discard service on port 9, and no UDP service on port 10. Your instructor may identify such a machine for you to use, a fellow student may run his in that way, or you may set up your own (on a different or the same box on which your client will run). If you are using provided VirtualBox VMs, the CLIENT and SERVER from the "sniffing" exercise are a suitable pair. (To activate ports 9 on SERVER, as root you would "undisable" the discard protocol in both /etc/xinetd.d/discard-stream for tcp and /etc/xinetd.d/discard-dgram for udp, then "systemctl restart xinetd". See the general procedure.)

You will run Wireshark while performing connection attempts in these 4 situations. Run it on your client machine, from where you will make the attempt (from a separate terminal window). Save your capture file in each case, using these names:

To exclude extraneous junk, filter the capture in Wireshark each time. Limit it to the port numbers your clients will be asking for. Namely, ports 9 and 10. Use the following filter syntax.

  Wireshark/tcpdump capture filter expression:   port 9 or port 10 or icmp

Remember that Wireshark has 2 kinds of filters. This is a capture filter, not a display filter. It goes in the "Capture filter" field of the "Capture Options" dialog box, not the prominent "Filter" field of the main window.

TCP client to port used by a TCP server

Run:

sock  <serverIP>  9 ^*

Observe what has appeared in the Wireshark window so far. sock stops and waits for input. If you type some, it'll send it when you hit Enter. But give it none. Instead, terminate sock with a ctrl-D keystroke. Observe what appears additionally in Wireshark. Stop the capture in Wireshark. Save it to a file, with above nomenclature.

TCP client to port used by no TCP server

Run:

sock  <serverIP>  10

sock terminates. Stop the capture in Wireshark. Save it to a file, with above nomenclature.

UDP client to port used by a UDP server

Run:

sock  -u  <serverIP>  9

sock stops and waits for input. If you type some, it'll send it when you hit Enter. But give it none. Instead, terminate sock with a ctrl-D keystroke. Observe what has appeared in the Wireshark window. Don't bother to save it, since there's nothing there. Run again:

sock  -u  <serverIP>  9

sock stops and waits for input. This time give it something: type a single letter x then hit Enter. Then terminate sock with a ctrol-D keystroke. Stop Wireshark, save to a file with above nomenclature.

UDP client to port used by no UDP server

Run:

sock  -u  <serverIP>  10

sock stops and waits for input. Give it something: type a single letter x then hit Enter. sock terminates. Stop Wireshark, save to a file with above nomenclature.

What to turn in:

port-behavior.zip - a zip file that that contains six other files:

your 4 capture files
- tcp-something.cap
- tcp-nothing.cap
- udp-something.cap
- udp-nothing.cap

- capture-screenshot.jpg (or .png)
a screenshot file showing the capture files open in wireshark windows cascaded in the same vertical order as this screenshot file. My screenshot covers up the actual traces. But in yours don't cover them over with other windows, make sure I can see the full content of the frame panel of each wireshark window.

- written-answers.txt - a text file with your very short written answers to the following two questions.
1. What is the characteristic server behavior when a client attempts to communicate with a port using TCP when no TCP program is using that port number on the server machine?
2. What is the characteristic server behavior when a client attempts to communicate with a port using UDP when no UDP program is using that port number on the server machine?

^* you can substitute netcat for sock. Use "nc" where you see "sock" in the above prescribed commands. And use ctrl-C instead of ctrl-D to terminate/interrupt netcat.