Make sure you have your client for program 7 (the one with the UDP broadcast to locate the server) done and runnable.
This lab will be split into two parts: one is to run your program 7 client and get it communicating with a version of the server that Anthony will provide, and the second is to work in the security lab and experiment with ethereal, one of the packet sniffers. People can work in the security lab in shifts, so it isn't such a madhouse in there.
For the first part, there will be two or three card dealers running on the machines in EPS 254. You should run your program, demonstrate that when you send out the request to locate a server, you get responses back from more than one server, then connect to one of them and deal four cards. Note that the server is going to be picky about what it expects, so if you didn't follow the specifications quite right, you may have to tweak the client a little to get it talking to the server. For instance, if you send a location request that contains the string "Dealer" with no null terminator, it will be ignored.
For the second part, you need to boot one of the machines in the security lab using Knoppix, open a window, and start experimenting with ethereal and tcpdump. Both of these programs allow you to examine packets off the network. Ethereal has a graphical interface and makes life easy for you, while tcpdump is the old text-based utility for command line Luddites like me. Here's an example of the output from tcpdump:
[root@malt ~]# tcpdump -w tcp.dmp -c 20 tcp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20 packets captured
21 packets received by filter
0 packets dropped by kernel
[root@malt ~]# tcpdump -x -r tcp.dmp
reading from file tcp.dmp, link-type EN10MB (Ethernet)
17:13:03.769502 IP power.coe.montana.edu.netbios-ssn > cjenkinsxp.coe.montana.edu.1210:
P 4011284757:4011284810(53) ack 3293976806 win 65005 NBT Packet
0x0000: 4500 005d 94e6 4000 8006 ad32 995a c202 E..]..@....2.Z..
0x0010: 995a c3ca 008b 04ba ef17 5915 c456 18e6 .Z........Y..V..
0x0020: 5018 fded f076 0000 0000 0031 ff53 4d42 P....v.....1.SMB
0x0030: 2b00 0000 0098 43c0 0000 0000 0000 0000 +.....C.........
0x0040: 0000 0000 ffff fffe 0000 feff 0101 000c ................
0x0050: 004a .J
The first command ran tcpdump to write 20 TCP messages to the file tcp.dmp, then ran it again to process that file and dump each of the packets out in hex/ASCII format. Note by default tcpdump does not include the link level (i.e. Ethernet) header in the dump, so what you are looking at is the raw IP packet. Note the first nibble is a 4 - this is an IPv4 packet. Recall that the normal IP header is 20 bytes - that means the TCP header starts with the third pair of bytes on the second line, 008b. The TCP header is another 20 bytes, if there are no extensions, so that takes you half way through the third line, where the actual packet data starts at the second pair of 0000. This packet happens to be an SMB packet (the Simple Message Block protocol, which is used by Windows machines to share files).
You need to get familiar with the UDP, TCP, and IP headers, and know how to find the various fields in the hex dump from tcpdump. The following Web site include nice diagrams of the TCP, UDP, and IP header formats. Using these formats, we can see that for the dump above, the IP header says it is version 4, has a header length of 5 words (20 bytes), type of 0x00, has a total length of 0x005d (93), ident of 0x94e6, has the "do not fragment" flag set, offset of 0, TTL of 0x80 (128), protocol of 0x06 (TCP), checksum of 0xad32, source IP of 0x995ac202 (153.90.194.2), and destination IP of 0x995ac3ca (153.90.195.202). That's it for the IP header; the next 20 bytes are TCP header. These indicate that the source port is 0x008b (139), the destination port is 0x04ba (1210), the sequence number is 0xef175915 (4011284757), the acknowledgement is 0xc45618e6 (3293976806), the data offset is 5 (20 bytes in header), the ECN bits are 0, the control bits are 0x18 (ACK and PUSH set), window of 0xfded (65005), checksum of 0xf076, and urgent pointer of 0. Note that some of this information matches up with the cursory output from tcpdump.
Quick tip: if you don't have a calculator and want to convert hex to decimal or vice versa, you can use bc, the Unix calculator utility. Just start bc, then select either the input or output base to convert between base 16 and base 10. See the following example:
bwall@esus:~/www/cs440$ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. ibase=16 5D 93 ibase=0A obase=16 93 5D
ibase sets the input base - to 16, for this example. By default, the output base, obase is 10, so when you type in 5D, it converts it to decimal, or 93. Setting the ibase to 0A (10 in hex, since you have changed the input base to 16) and setting the obase to 16 will let you convert decimal to hex.
The following are a couple of screen dumps from Ethereal, looking at a UDP packet and a TCP packet. Note how much easier it is to use; you can click on a field in the middle frame and it will highlight where it is in the bottom hex dump, and vice versa.
So you should make sure you look at a TCP message dump and a UDP message dump using the machines in the security lab. There are several ways to generate TCP traffic - point your browser at the HTTP server on the firewall (http://192.168.0.1), ssh to another machine, ftp to another machine, etc. Coming up with a UDP source might be a little trickier, but Anthony will be able to help you with that. Once you've got it figured out, you can check out NAT (Network Address Translation) in action. You'll need to connect from a computer inside one of the firewalls to a computer outside the firewall - make sure that the firewalls still have port forwarding set up, and ssh from your machine to the SSH server inside the other firewall. Use Ethereal to capture the TCP message going out of your machine and check out the port number. Now go over to the other network and use Ethereal to capture the incoming message there. (It will be easiest if you work in pairs so one person can capture the message going out on one side and the other can capture it coming in on the other side). Take a look at the port numbers and IP addresses in the packets. You should see that the original source IP address and port when the packet left your machine have been replaced by the firewall with its own outside IP address and a different port number. If you had a sniffer outside the two firewalls (on a computer attached directly to the hub), you would see that the destination IP address was the second firewall's outside address, but that it got changed to the SSH server computer's IP address by the second firewall (this is part of the port forwarding process).
Your lab report should include the following information; it can all just be in the body of the email.
0x0000: 4500 00e5 7e13 0000 8011 feee 995a c251 E...~........Z.Q
0x0010: 995a c7ff 008a 008a 00d1 f197 110e 8154 .Z.............T
0x0020: 995a c251 008a 00bb 0000 2046 4345 5045 .Z.Q.......FCEPE
0x0030: 5043 4143 4143 4143 4143 4143 4143 4143 PCACACACACACACAC
0x0040: 4143 4143 4143 4143 4143 4100 2046 4145 ACACACACACA..FAE
0x0050: ...
Make sure that you are following Anthony's submission guidelines.
The lab write-up is due by the end of the day Wednesday (i.e. 11:59 PM) for the Tuesday lab section and by the end of the day Friday for the Thursday lab section.