- General technical notes - ** PC username/password: gatech/gatech and root/gatech ** Mounting file systems: Unix treats the entire file system as one hierarchical tree, and additional devices can be mounted at any directory within the tree. Essentially, you can think of this as temporarily grafting a device at an arbitrary tree location. For example, if you have disk drive device named /dev/sda1, you could mount the drive into a directory like /mnt/my_sda1. The contents of the drive would then be accessible from /mnt/my_sda1 until the device is unmounted. In the lab, you'll mostly be using floppies and USB drives. These should automatically mount somewhere in the /media directory. Your lab manual also contains specific mounting commands, and there are plenty of good man page and online resources for more information. ** Changing PC IP addresses: The Linux command to manage interfaces is ifconfig. For instance, "ifconfig eth0 10.0.0.1" will set eth0's IP address to 10.0.0.1. As always, you can man ifconfig for all the gory details. ** Implicit routing table changes: As for the IP address issue, the commands you entered were correct, but they have implicit effects on the routing table. If you use the route[1] command, you can see the current contents of the machine's routing table. When you change the address of an interface, you implicitly add a rule *at the end of the table*[2] to the system to route all traffic locally relevant to that network out of the interface. The problem here arises from the fact that both interfaces are on the same local 10.0.0.X network. The first rule that is matched gets used. Originally, the table has two rules, essentially, they are: 1) If the destination is 10.0.0.X, use eth0 2) If the destination is 10.0.0.X, use eth1 This case works because eth0 is matched first. However, when you execute those ifconfig commands, the tables are switched to be: 1) If the destination is 10.0.0.X, use eth1 2) If the destination is 10.0.0.X, use eth0 Now you have a problem because the eth1 rule is being matched, but only eth0 is plugged in to the hub. eth1 is unplugged, and thus you get the "destination host unreachable" messages from it. [1] Use "route -n". The -n argument tells route to ignore DNS names. In our environment, without any DNS at all, this is a necessity. [2] They will be added to the end, with the exception of any default/last resort rules that are in the table. ** Starting/stopping PC services: Services can be started by executing the proper init script for the service. For the FTP daemon, the command would be (as root) "/etc/init.d/vsftpd start" where vsftpd is the name of the FTP daemon installed on the lab machines. You'll also find a GUI service management tool under Applications->System Settings->Server Settings->Services. ** PCs slow to respond: See Lab 8 section. - Lab Specific notes - Lab2 - FTP daemon doesn't allow root logins: In the password sniffing section of lab 2, you're asked to login to the FTP daemon using the root account and sniff the account's password. Some students have reported problems using the root account. If you can't login to the ftpd as root, use the normal gatech account instead. The point of the exercise is to see that the passwords are being sent in plaintext. You already know the root password anyway! Lab4 - Zebra is now quagga The lab manual is a little dated here. The zebra project is no longer active, so the quagga folks forked it and took over. Quagga config files live in /etc/quagga. The username and password for quagga and friends is zebra. Lab5 - Serial links 1) Only one side of the serial link needs to have a DCE (black) connector. The other side should use one of the white ones. 2) Make sure the clock rate is set on the appropriate interface. 3) The interface names in the book are (as usual) outdated. On our routers, use the names Serial 0/0/0 and Serial 0/0/1. If you have any doubts about interfaces, use the "show interfaces" command. Lab5 - Congestion control The book assumes we have a 10Mbit link where we actually have 100Mbit, and it assumes we have a 1Mbit link where we actually have 128Kbit. My attempts to fix the first link (make the router and/or PC1 force to 10 instead of auto sensing) failed because the hubs (at least on the left rack) refuse to speak with anything that isn't 100Mbps. Our router hardware limits what we can do with the second link, and the huge speed discrepancy makes things difficult. So, given these limitations, I've tested ttcp, and while I can't quite find a combination that results in no unwanted retransmissions, the following come close enough that I think we can probably still do the lab. At the very least, the effect of unplugging and reconnecting the cable on retransmissions can still be seen. On the receiving side (PC2), ttcp -rs -l128 -n25000 -p4444 On the sending side (PC1), ttcp -ts -l56 -n25000 -p4444 -b56 10.0.2.22 The router's serial link should be set to the maximum clock rate of 128000 (128Kbit/s). This gives you approximately one minute to plug/unplug the cable and (hopefully) get some decent results. The -l56 -b56 arguments on the sender side force the size of the sender's socket buffer to 56 bytes. Essentially, this is a cheap way of reducing the size of the sender's packets and slowing down the sender's transmission rate. Lab8 - Hostname lookups When you change the /etc/hosts file for lab 8, please make sure pcX and pcX.localdomain (where X is the PC's number) have a valid address associated with them. 127.0.0.1 is fine. Also, please remove the contents of /etc/resolv.conf when you finish. The reason this caused the slowdown is because the window manager uses the local hostname to talk to the X server. With an invalid nameserver in /etc/resolv.conf and no entry in /etc/hosts, name lookups fail, and you have to wait for them to timeout.