- How do I get help from the TA?
- You can stop by during the TA's office hours (T,Th 1:30-2:30) or
send e-mail. I'll often be in the lab working on my own research.
While I'm happy to help answer your questions I'd like to avoid being
"interrupt-driven" when I'm working in the lab. I'd appreciate
receiving your questions by e-mail (even when I'm in the lab if it's
not my office hours) so that I can answer when I take a break. Also,
be sure to check the FAQ and Tips pages first. I'll post most of the
questions I receive and their answers there.
- How do I change my shell?
- Use chpass to change your info. This would change your shell to bash:
chpass -s bash userid
Or just use chpass and fill in all of your information.
- How do I switch kernels?
- First use "w" to make sure no one else is logged on to the
machine. Once other users have logged off, use the shutdown command to shutdown the machine:
shutdown -r now
You will need to monitor the machine as it reboots when it prints the
line "boot:" you should be ready to type in the name of your
kernel. (Note: this prompt will time out quickly and proceed to boot
with /kernel if you do not type something when it appears.) For instance, to boot with /kernel.1000:
boot: /kernel.1000
You can test to see if you are using the kernel you want by using the 'uname -a' command.
- How do I put up an xterm from bennett under XWin32?
- First, note that Xwin32 is the X-windows package for Win95 or
WinNT. If you are on a UNIX machine things should work the same for
bennett as for any other machine. There are just a few differences if
you are using XWin32 to connect to a FreeBSD machine so I wanted to
document it here.
I'm assuming you already know how to set up a connection for a
departmental machine. Use X-util to add a new session. For connect
mode, specify "rsh"; for hostname, specify "bennett"; specify your
login; and the login command is "/usr/X11/bin/xterm -ls". Be sure to
add the display option in whatever format you usually use. I usually
just hardcode the machine that I'm working from. You'll also need to
have a .rhosts file in your home directory on bennett with the machine
name and then your id for the machine you want to connect from. And,
if you have any xhost entries in your X-Win32 you will need to add one
for bennett. Good luck.
- How do I set up my environment under FreeBSD?
- Now that you have your account you should do several things.
- Change your passwd on all the machines - sorry you have to do this on each machine.
- Set your shell. See the note above.
- Set up your shell environment. My environment dates from 1990 so you probably don't want it. Be sure to keep the path, etc. that are set up in your initial environment, especially /usr/home/bin. That's where I'll install some of the tools you'll use.
- You'll probably want an X environment for when you're working in
lab. I encourage you to consider starting with the default
environment and just making minor changes; you won't use it often.
- Where can I find man pages on the commands used in the homework?
- The man pages you need should all be on bennett. If not, mail
parris@cs.unc.edu.
- Which compilers are supported in the colab machines?
- cc, c++, gcc, and g++ are all available. The expectation is that
coding for assignments will be done in C. Perl5 is also available in
/usr/local/bin in addition to many other standard UNIX packages
(e.g. awk) if you want to use them for quick data processing. Don't
spend too much time on data parsing, etc. though.
- Where should I store and process data?
- The comp290 network now has 2 file-servers/compute-servers.
bennett remains your connection to the experimental network and
the location of your home directories (which are mounted on all
machines). In addition, a new machine, granny is available as
a file and compute-server. It has connections to both the department
network (as granny) and to the experimental network (as grannyP137).
Granny's /playpen is mounted on bennett (but not the other machines)
and has 8GB of available space. You should create a directory
(e.g. /playpen/parris) to use when working with data. Do not
consider this infinite space! We will be placing traces of the
campus up-link to the internet there that may be 1GB each and you will
generate your own files as you extract data from these traces. Use
tar and gzip often when you need to retain data but won't be working
with it for a while. TIP: While you can access /playpen on bennnett,
you will probably get noticably better performance if you are logged
into granny when you are working with large datasets in /playpen since
you will avoid network overhead on NFS.
- How can I share files with my partner
- To aid you in working together on your assignments we have set up the
following unix groups on the comp290 machines. If you want to share
files in a directory you should be able to use the commands "chgrp"
and "chmod" to set permissions to share the files with your partner as
you wish.
The groups:
group0 - ott,harjono
group1 - sellappa,paramesw
group2 - dwyer,sain
group3 - weissd,xiao
group4 - clark,mattes
group5 - sunku,mundhra
- How can I access class file-systems from UNIX?
- We have mounted granny:/playpen and bennett:/usr as read-only
file-systems on buzzard. They are available as '/net/bennett/usr' and
'/net/granny/playpen'. This was mainly done for one group that needs
to use a tool that isn't available on FreeBSD to process their data.
- How is the lab configured?
- The network reconfiguration is complete (I think). I have posted
diagrams of the new network configuration above the whiteboard in the
lab. Quite a lot has changed. Please let me know if you discover any
problems. It is entirely likely I missed something in the
reconfiguration.
There are pdf
and Word
versions of the lab diagram available.
There are now 4 logical networks: P134, P136, P137, and P138.
P134 and P138 are the "end-system networks". Each of these networks
has 4 "traffic generator" machines attached. They are bollellaP138,
gomerP138, stoneP138, and poirierP138 on the P138 network and
otisP134, beckerP134, earnesttP134, and neeP134 on the 134 network.
Each of these machines has a 10Mb uplink to a 100Mb switch. Each of
the 100Mb switches are connected via an uplink to a 100Mb Hub. The
hubs are used to connect the router (chenP138 and borgP134) and a
monitor machine (talleyP134 and talleyP138). This allows talley to
monitor all traffic that will be passing through the routers. Talley
is also attached to the P136 network.
P136 and P137 are 10Mb hubs used to provide a full-duplex connection
between the two routers (borg and chen). The connection is 10Mb to
create a bottleneck. All data passing through chen destined for the
134 network goes to borg over the 137 network while all data passing
through borg destined for the 138 network goes to chen over the 136
network. Keep this in mind when analyzing data collected from the
P136 or P137 networks. We encourage you to configure your experiment
so the data flow is from P134 to P138 so you can capture packets on
the P136 network with talley.
P137 is also the connection to bennettP137 and grannyP137. Both of
these machines also have their usual connections to the department as
"bennett" and "granny".
Finally, there is an additional machine, "krishnan" with appearances
on the P134 and P138 networks. This machine will be used exclusively
by Greg Mattes and Michele Clark for their project as they will be
rebooting the machine often as they recompile and test changes to the
kernel. Michele and Greg: there is more configuration that needs to
be done for this machine. See me so we can set it up.
talley and krishan use borgP134 as their default router so while they
do have P138 addresses, you will not be able to contact them when borg
is down.
Let me know of any problems. Remember the network is a shared
resource; check to see if others are logged on (they have to come
through bennett or granny) before starting experiments.
- How do I set the delays for different flows?
- There are two programs you can use to do this. But for either one:
First verify you are running a kernel with delaybox. Use uname -a
to verify the kernel is from /usr/src/sys-altq-delay (in the path). A
1000 HZ kernel is preferred as well. Next determine the device name
for the ethernet device you want to create delays on. Use ifconfig -a
for this.
One program is "set_flows". Finally use the program "set_flows" in
/usr/local/bin to set the delays. Specify the interface name without
the interface number (e.g. ep, not ep0) for the first response, then
the number in response to the next query. Then you can specify up to
5 (0-4) source IP addresses and different delay times for each.
Simply enter the ip address and then enter the delay (in milliseconds)
for each. Flow 5 is the "default" flow which represents all other
flows. Setting a delay for flow 5 will add a delay to all packets
that don't match flow 0-4. You will need to run set_flows again and
reconfigure to set the delays back to 0 when you are done.
The other program is "setdelay" in /usr/local/bin. It is an
argument driven version of set_flows. It is an interface to the same
set of queues, etc. as set_flows but may be easier to use from inside
of scripts. Type setdelay with no arguments to see the arguments.
This program was written by Mikkel Christiansen.
Turning off delays:If setdelay is called only with a -q
option, then the delaybox for this host is deactivated. NOTE:
This does not set the delay values to zero. It turns off the delaybox
entirely. However, the settings remain in place and will be used when
delaybox is reactivated. You should always set the values for ALL the
queues to avoid accidentally using delays you did not intend to use.
These programs are NOT on bennett or granny as they are not to be
used for experiments. Should be on all others though.
- How do I use tcpdump?
- For the most part, just read the man page. But here are a few
tips for this and any other data collection you do.
- Always dump data to a local disk and copy it to your NFS space
later. You can make a directory in /usr/tmp/. Use your login as
the name. I'll leave it to you to consider why you would
always want to dump to the local disk. Note: You should NOT
store data for more than a few hours on the local disks. We may
periodically wipe any old files from the local disks to maintain free
space for others to work. Always move your data to your NFS space
after you collect it.
- Dump the data to a file in binary format (the -w option).
- Use reasonable filtering when monitoring the network to limit the
amount of data you collect.
- Use more filtering when you examine the binary file to find the
flows, etc. you are interested in.
- Where is the tcpdump source?
-
You should be able to find the source and makefile for tcpdump in:
/usr/src/usr.bin/tcpdump/tcpdump
and
/usr/src/contrib/tcpdump
The makefile structure and separate locations for the *.[ch] vs. *.o
files is a bit odd but you should be able to figure it out.
- How can I get check to see if a machine is up?
- Since the machines aren't connected to the department we use a If
you ever have what you believe might be network connectivity problems
in the lab, you can check things out with the script
"/usr/home/bin/check".
It simply does 1 ping to all of the
machines at their current locations (I will do my best to keep it
updated as I reconfigure the network). So, it may also be a useful
tool to discover the current network configuration as well.
- How can I change the TCP window size on a machine?
- '/usr/local/bin/setwindow' should do the trick. Arguments are
"-R recv_window" and/or "-S send_window". NOTE:
The machine must be running an ALTQ kernel (as that includes a bug fix
for window sizes). This program is NOT on bennett or granny as they
are not to be used for experiments. Should be on all others though.
- How can I synchronize clocks on the experimental machines?
- How can I synchronize clocks on the experimental machines?
- On bennett run /usr/home/bin/rrdate. This program will set
the clocks on all of the machines. Warning: this is not the
same as synchronized clocks. It just brings clocks closer to
being in sync.
- How can I find documentation on ttcp?
- The man page for ttcp is available on bennett in /usr/local/man.
'man ttcp' should work. I don't know why the page is so poorly
formatted but at least the information is there. Most of what you
need can probably be found in the "usage" message by typing ttcp
without any arguments.
- How can I find local documentation on AltQ?
- AltQ documentation exists in /usr/src/altq-1.1.1/docs. The
*.ps and *.txt files should be obvious. However the *.8 files are
nroff files ready for the "man" command. I have copied those files to
/usr/local/man on bennett so you should be able to simply type, for
example, 'man cbqd' and see the appropriate man page. However, you
can also type this command: 'nroff -man cbqd.8 | more' to view the
page if you are on some other machine. You can print to hplj156 from
granny and bennett.
- How can I find out about libpcap?
- Man pcap.
- Where are some sample tcpdumps to work with?
- /usr/home/dumps has one with more to come. These are binary
tcpdump files with the name indicating the date and approximate time
they were collected. Note: the bigger files represent longer traces.
I encourage you to start out by debugging your programs with smaller
traces. Possibly consider using the -r and -w options and tcpdump
filtering to generate very small trace files that include only a few
packets that you are interested in to ease debugging/verification.
- How can I plot tcpdump info graphically?
- 'tcptrace' is a great tool. The main
web page has a lot of info. We also have our own version in
/usr/home/bin/tcptrace-dirt which includes a few bug fixes Michele
Clark added. You probably won't even notice them. Just use
tcptrace-dirt. To view the resulting files you should use xplot. We
have a modified version in /usr/home/bin/xplot-dirt. There is
documentation for xplot, including the additions, on a web
page. (Michele wrote the web page, not me.)
NOTE:
Michele provides these notes on the new version of tcptrace. You may
find them extrememely useful in doing your traffic analysis.
- Where are the plots from class on 10/20/98? (TCP traffic to Orange High School)
- In /usr/home/dumps/class_samples you can find the orange high
school plots. They are named: tcpx1t1a_seg.xpl, tcpx3t1-a_seg.xpl,
tcpx3t1-b_seg.xpl, tcpx3t1-c_seg.xpl. "tcpx1t1a_seg.xpl" is a plot of
one flow to Orange High school. The bottleneck link is 1.55Mbps. The
other three plots are three flows sharing the link.
- Where are the plots from class on
10/22/98? (TCP traffic in the lab exploring window-size & delay)
- In /usr/home/dumps/class_samples/window-size you can find the
window-size & delay data. You can find a NOTES file in that directory
and a README file in each subdirectory (comp290-dump[456]) that
outline the set-up, the issue being considered, and which files are
the interesting ones. The "tcp" and "tsg" scripts in each directory
will display the plots of interest. You may want to change the geom
though as it is set for the lower resolution used by the projectors in
class.
- How can I parse tcpdump output?
- There are a few sample programs available.
See the sample program in /usr/home/src/tcpdump_samples/udp
for a sample program that reads in a tcpdump binary file. Make a copy
of the code, compile and run without arguments to get usage
information.
The sample program (ifmon) illustrates how to modify tcpdump so
that it invokes a user-supplied function for each packet found in a
live trace or when reading a file with the [-r filename] option. It
is in /usr/home/src/tcpdump_samples/ifmon . Note: this program
is slightly different than, but based on the ifmon provided in
/usr/home/bin.
- ifmon and thruput - more tools for processing dumps.
- In '/usr/home/bin', the program 'ifmon' takes a binary tcpdump
file as input (the -r argument), examines the packets matching the
filter specifications (same as tcpdump filtering), and calculates the
average load over N ms intervals (the -I argument). 'thruput' takes
the output of ifmon and outputs an xplot file with the specified title
(the -t argument). The following would sample the tcp packets in
tcpdump.out over 100ms intervals and pass the results to thruput which
would generate an xplot file with the title "tcp" in ifmon.xpl.
ifmon -I 100 -r tcpdump.out tcp | thruput -t "tcp" > ifmon.xpl
- What is OC3MON anyway?
- In a nutshell, OC3MON is a PC with two ATM interface cards that have the
ability to monitor Internet-1 traffic as it flows across OC3 optical fiber
pair to the ATM switch connecting the UNC campus to the internet.
An optical splitter carries a fraction of the light from from each fiber
to the receive port of the ATM NICs. One of the OC3MON NICs is able to
see all inbound traffic received by the switch and the other NIC all
outbound traffic.
Customized firmware is used with each ATM NIC. Software distributed
with the package includes tools for monitoring traffic in "flow
analysis" and "trace" modes. Our traces are taken using the latter
and converted to tcpdump format using another tool called "mon2dump".
For more information see:
as well as the paper given out in class
K. Thompson, G. Miller, and R. Wilder. "Wide-Area Internet
Traffic Patterns and Characteristics". IEEE Network. November
December 1997.
-
How do I interpret the timestamp format for OC3MON traces that I look at
using tcpdump?
-
Timestamps for OC3MON traces tell you when a given IP packet arrives at
the ATM interface it was received on. This value is relative to the time
when the trace began and not the time of day. An example timestamp is
given below:
00:00:02.000728
The first two fields (00:00:) are unused and have simply been initialized
to zero. The field (02.000728) gives the number of seconds since the
trace began, or to be even more specific the number of seconds (02) and
the number of microseconds (000728).
-
Why do timestamps for some adjacent packets entries have the same
value when looking at OC3MON traces using tcpdump?
-
The clock used in OC3MON trace dumps has a 25MHz precision which is finer
in granularity than the microseconds unit used in tcpdump. Hence, while
you can be sure the ordering of packet entries is correct, packet
timestamps will sometimes appear the same when the interval between them
is less than a microsecond. You may simply consider the interval between
them to be zero if that becomes an issue in your project.
-
How do I interpret OC3MON trace filenames?
-
An example is given below:
981031_1400_1800.<interface>.udp
The first field (981031) gives you the date of the trace using
the format YYMMDD (this allows you to sort by date of file
generation). The second field (1400) gives you the approximate time
the trace was started using a 24-hour clock. The third field (1800)
gives you the number of seconds that the trace ran for (1800 sec = 30
min in our example.) The interface, 'if1' or 'if2' indicates which
atm interface the trace was taken from. This means that trace files
always come in pairs--the oc3mon tracing mechanism captures packet
headers from both atm interfaces simultaneously. Afterward, we
separate them and perform format conversions and filtering. The .udp
suffix indicates this data has already been filtered for udp data
only.
-
Why is tcpdump running so slow when viewing OC3MON traces?
-
The tcpdump binary format stores source and destination fields in IP
address format (ex. 152.2.137.49). When running tcpdump, however, it does
a lookup on each address to obtain host and port names which are easier
for people to recognize. Running tcpdump with the -n option will prevent
this conversion and thus make things run a lot (!) faster. Considering the
size of the traces we will be using in this class, this is definitely the
recommended mode of operation for all parts of your projects.
-
What should I do about tcpdump entries which include hex dumps?
-
If you find that a few IP packet entries in your tcpdump trace contain a
lot of unintelligible gobbly-gook after the timestamp like the following
00:00:00.178225 82 00 10 30-82-00 0030: 30:30:30:30:30:30 sap 02 >
30:30:30:30:30:30 sap 15 I (s=0,r=0,C) len=19517
0201 0030 8200 1030 8200 0c06 082b 0601
0201 0103 0005 000c
chances are you're either seeing something that is not an IP packet or is
an IP packet corrupted such that tcpdump can no longer recognize its
format. Since this will likely cause problems for programs parsing
tcpdump format files, the recommended course of action is to filter the
unwanted entries out by running tcpdump as follows:
tcpdump -r filename -w newfilename ip
As you will find on the tcpdump man page, ip is short for the "ether proto
ip" option which simply filters out anything that is not an ip packet. In
general, we will attempt to do this for you before making traces available
to the class.
- Gethostbyname and nslookup don't work. What should I do?
- Since the machines aren't connected to the department we use a
non-standard name resolution configuration. For some reason
gethostbyname and nslookup don't seem to work. However, some programs
(e.g. ping) can resolve names from /etc/hosts as they are supposed to.
In the meantime, simply user ip address numbers without name
resoultion in your programs. You can resolve the names using nslookup
on bennett to get the ip addresses to use.
