Hopefully this page will answer some of the most common questions I get about issues specific to our lab. You may wish to print this page for your reference; I'll try to keep a copy of it around the lab as well.
Submissions should be mailed to the TA. Submissions must be organized into two sets of files: (i) answers to short questions, and (ii) computer generated output. The tarzip of all files should be emailed to the TA. You may also submit the answers to short questions of prelabs to the main office in the CMPSCI building to Pauline, but email is preferred. If there are any doubts as to what to turn in and what not to turn in via paper, please ask the TA.
Handy tips for debugging your configuration:
- Double check your settings. It's amazing how often fixing a simple typo will get your whole setup working. Use
ifconfig,netstat -rn, andshow running-configfrequently so you can make sure you're entering the correct settings.- Use Ethereal. It's great to use Ethereal even when you don't need to capture data to put in your report. One student found out he reversed two interfaces on the router from loading Ethereal and noticing one of the routers sending ARPs destined for the wrong subnet. Ethereal's output is easy to browse through and will help you catch tons of configuration problems.
- Make sure your ethernet interface is in promiscuous mode. If you're sure data's getting sent, but you can't see anything, this is likely the problem.
ifconfig [interface] promiscwill do it.- Check the whiteboard.
The whiteboard may contain some helpful notes and hints to problems that are arising. In the past, the questions and answers on the whiteboard have eventually made it into this FAQ.- DOUBLE CHECK YOUR SETTINGS. It's impossible to emphasize this enough. In addition to checking settings that you've entered, make sure to check for parameters that someone else might have changed, particularly on the routers. Most configuration details on the PCs can be reset by rebooting, but the routers are a bit more permanent. Go through the output of
show running-configand make sure no modes you don't want are enabled. For example, someone who was previously using the router as a bridge instead of a router can really foul up your configuration.
Linux will not let you unmount a drive if an application is using a file on that drive. But you swear you aren't!
Be sure to not have a shell's working directory in the directory of the floppy disk. Just type "cd" at the shell prompt, and this should fix this Try not to use the file system manager in either KDE/gnome. This includes throwing files into the trash can, etc. Often these programs forget to close files on the floppy, and this will prevent your floppy from unmounting. As a last resort, try typing "lsof | grep /mnt/floppy" should give you an idea of what program is using a file on the floppy disk. The second column is the process ID (aka pid). You can kill processes using the command "kill pid"
WARNING! (2/18/04) Apparently you can break your USB keychain if you plug it into a linux machine. One person has reported being able to get their keychain working again after a few days. You have been warned!!!Be sure you read the warning notice in the previous paragraph. Other than that, you can mount usb flash disks in linux. All the PCs in the lab have USB ports under the front cover. The PCs have been configured to automatically detect USB flash drives. You must mount the disks manually, similar to how to mount floppy disks. Mounting a USB flash disk to /mnt/flash can be done with:
mount /dev/sda1 /mnt/flashJust like a floppy, remember to unmount the flash disk!umount /dev/sda1Please let the TAs know if you have any problems with the flash disks.
For reasons we don't really understand, sometimes when the routers are powered up they don't really start. If this happens to you, just type
resetand it'll reboot and be fixed.
No, Cisco just uses a different naming scheme for our routers than the ones the lab was written for. Instead of ethernet0, use FastEthernet0/0. Instead of ethernet1, use FastEthernet0/1.
If you're going to use KDE, please have the courtesy not to set it as the default session and to logout when you're done. Not everyone knows the systems well enough to get out of KDE and into an environment they're already familiar with. The default environment for these machines is GNOME/Sawfish. Please leave it that way.
There are absolutely no guarantees that any files you save on the lab PCs will be there when you return. This means that you should be sure to bring a floppy disk with you every time you visit the lab.Each PC in a workstation has a its own hard drive. Be sure to look for your files on the correct PC when you return!
To lessen the chance of your files being overwritten by another student, PLEASE add your name (first name, or edlab username) to your "labdata" directory name. Note that this still offers no guarantees of your data being there when you return.
Be sure that you differentiate between /labdata and /root/labdata. There really is a difference between the "root directory of the filesystem" (= /) and "root's home directory" (= /root). You can use either, but be sure to be consistent, so that you know where to find your files!
The up arrow recalls the last command entered. pressing the up arrow multiple times will scroll through the command history. This is useful if you made a typo, so that you dont have to type the entire command out again. Another good tidbit to know, is that control-a will move the cursor to the beginning of a line, and control-e will move the cursor back to the end.
To copy a directory onto a floppy, use the command "cp -r". The "-r" flag (also known as an argument) will recursively copy a directory from one place to another. For example, when a floppy is mounted, cp -r /labdata-armenb /mnt/floppy/will copy the entire directory "labdata-armenb" to the floppy disk.Do not forget to unmount the floppy disk using the "umount" command!
First, be sure to check the introduction chapter in the lab manual for a quick rundown on how to define both kinds of filters. There is more information available at:http://home.insight.rr.com/procana/index.htmltcpdump manpage - just type "man tcpdump" on any PChttp://www.firetower.com/forum/tcpdump.htmlSearching on google will probably yield better results.
arp -d [ip address].
For some odd reason, ifconfig on linux doesn't support this operation:ifconfig eth0 10.0.1.100/24Intuitively, you'd think that eth0 would be set with the netmask 255.255.255.0. However, ifconfig completely ignores the /24 you may append to the ip address.Actually, what ifconfig does is use the pre-CIDR default network sizes of automatically assigning the following netmasks to their respective network ranges (that are actually called classes):
Be sure you explicitly state the netmask of the network with the "netmask" command in ifconfig, rather than using the slash-notation.
- Class A: 1.0.0.0 to 127.255.255.255 has a default netmask of 255.0.0.0
- Class B: 128.0.0.0 to 192.255.255.255 has a default netmask of 255.255.0.0
- Class C: 193.0.0.0 to 223.255.255.255 has a default netmask of 255.255.255.0
You may see non-deterministic behavior of ARP requests in this regard because of when exactly the TCP retransmission timer on a PC attempts to send a packet. Both cases exhibit correct behavior of ARP.
There sure is. Open a new terminal window and type "kermit router". The file "/root/router" contains all the line-setting and connecting commands in it.
These messages are generated by the routers, and as far as I can tell, are completely useless and harmless. You can ignore them.
For some reason (and only on 1 PC, and not anymore) the route cache was specifically forbidden from accepting updates from ICMP redirect messages. If this happens to you, here's how to fix it:echo '1' > /proc/sys/net/ipv4/conf/all/accept-redirectsAlso, please tell the TA so they can have a look at the machine to see if any of the rest of the configuration is broken as well.
The lab manual inadvertently leaves out directions to configure PC3 to reach PC2. Be sure to add an entry to PC3's routing table, such that it knows how to reach 10.0.2.0/24 (i.e., through 10.0.3.2). You can do this by typing:route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.3.2 eth0
For currently unknown reasons, ethereal sometimes doesn't put the ethernet interface into promiscuous mode. the status of the ethernet interface can be shown by typing:
ifconfig eth0at the linux prompt. What should appear is something like:
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1If the
PROMISCflag isn't shown, put the ethernet interface into promiscuous mode manually by typing:
ifconfig eth0 promisc
as root. That should solve that problem.
Yes. At the config prompt:
(config)# no ip routing
(config)# ip routingDisabling then re-enabling ip routing flushes the routing table. Sometimes this is NOT what you want, though, so be aware of it even if you don't intend to use it this way.
Yeah, don't do that. :) Apparently some of the labs call for the routers to be attached to PCs that aren't the normal ones (in order). Ignore these directions. Be a good neighbor; if you find out that someone's scrambled things when you're doing your setup, set it right and make everyone's day a little easier.
Do a quick
show running-configand make sure the interface duplexing is set to "auto-duplex" rather than "full-duplex." We ran into that over the summer and fixed all of them; lately they've been getting set back to full-duplex, which doesn't work with our hubs. If you fix it, make a note of which router was doing it so we can keep an eye on it.
As far as we can tell, this is a bug in Cisco's IOS. For now, you will just have to wait until the entries in the router cache time out (on the order of a few minutes).
Until further notice, the count-to-infinity portion of Lab4 is optional, because of a problem in CISCO IOS. Specifically, the version of IOS loaded on the routers ignores commands to shut off triggered updates. When triggered updates are on, it is VERY difficult to exhibit the count-to-infinity problem.In lieu of carrying out the experiment, be sure to explain HOW the count-to-infinity phenomena should have exhibited itself in this portion of the lab. Be sure to mention what routers would have been involved in the count-to-infinity.
The linux computer being configured as a bridge needs to be running a kernel with bridging enabled. To use this kernel, reboot the machine, and using the arrow keys, select the kernel with bridging enabled in the GRUB menu just before the kernel gets loaded.
Make sure you have an entry for 10.0.2.0/24 in dhcpd.conf, or dhcpd will ignore that interface.
There are actually TWO iptables and dhcpd commands - one in /etc/rc.d/init.d/, and one in their respective normal locations (probably /sbin and /usr/sbin/). The /etc/rc.d/init.d/ version is actually a script that runs on bootup and on shutdown of the machine, and takes as an argument "start", "stop", "restart", and probably a couple of other commands. The iptables and dhcpd scripts that live in /etc/rc.d/init.d/ are not what you should be using; you should be using the /sbin/iptables and /usr/sbin/iptables commands.The reason you are getting the wrong result is because the /etc/rc.d/init.d/ directory is in your path variable (PATH in bash), and it is executing the scripts rather than the actual commands: as you've figured out, the iptables arguments used in the book don't work with the scripts.
A sure-fire solution to this problem is to use the full path of the command, e.g. "/sbin/iptables -L" or "/usr/sbin/dhcpd -d". If you know how to muck with the path variables, change them so they don't include /etc/rc.d/init.d.
State whether the data is in ascii or binary format in the messages.
This means someone forgot to restore the /etc/hosts files on the PCs to their original state after changing them in lab 8. Switch to a text console (control-alt-f1), log in, uncomment (or add) this line to /etc/hosts:127.0.0.1 PC2 localhost.localdomainThis example assumes PC2's hostfile is broken. Be sure to change "PC2" to the proper name of the PC. Switch to a graphical console (control-alt-f7), and log in. Let the TA know if you have any problems!
Last updated 5/11/2004.