VINT/SAMAN/CONSER Conventions

Mailing Lists

All mailing lists are homed at ISI and are thus available as listname@ISI.EDU. Listname may be one of:

These lists are subscribed to via their mailman information pages.

Quick Start -- All you need to do

CHANGES.html

NS and nam both have a CHANGES.html file. Please record ``medium-sized'' (or larger) changes in this file.

What is a medium-sized change? A judgement call. Simple bug fixes aren't (the Makefile had an extra .o in OBJS and was breaking, I fixed it). Larger bug fixes are (the tahoe TCP module produced wrong results in a particular case). New features certainly are (multicast code is now present). If in doubt, ask someone.

Before Committing Changes to CVS

Before commiting changes to ns, you should always run the validation test suites (run "./validate" in the top-level ns directory). Since ns is a large and complex piece of software it's critical to locate bugs early.

This applies to even "obviously correct" one-line changes. All too frequently there's a minor error that slips through and someone else has to fix it.

CVS

All of the vint-related project code is stored in a cvs repository under the sub-directories "common" and "vint". Normally, you won't need to worry about path names in the repository and instead will just refer to "module nicknames".

To access the repository, set your environment as follows:

	setenv CVSROOT username@nsnam.isi.edu:/nfs/jade/vint/CVSROOT
	setenv CVS_RSH ssh

For CVS documentation, see

You can issue normal cvs commands just as if the repository were local. Here are some hints:

Release tags, Branch tags, and working with branch tags

Periodic releases of ns-2.0 are marked as ns-2.0a###, where ``###'' is a monotonically increasing count. Each completed release will be tagged with the tag keyword ns-2_0a###. Note that we change the dot(.) to underscore(_) because tags in CVS cannot have dots in them.

An an example, the current status as of Fri Apr 4 17:14:51 PST 1997 is ns-2.0a16 (released), and ns-2.0a17 (pending); release ns-2.0a16 will be tagged as ns-2_0a16, and when the next release is completed, it will be tagged as ns-2_0a17.

The command for tagging the release is:
        cvs rtag ns-2_0a### ns-2

In order to check out an earlier version of ns-2, you can now use the tags to check out the relevant version. Assume that we have found some bugs in that were possibly present in ns-2.0a15, and wish to check out that release to verify this fact. The following command then achieves that goal:
        cvs checkout -r ns-2_0a15 ns-2

However, in order to make changes to the earlier release and commit these changes, we need a separate and new branch, with its own tag. Use a tag that identifies your branch clearly. A good example is one that uses your initials and a version number as ns-2_0a###-bXXX, where ### is the version you want to modify, and XXX is the string uniquely identifying your branch. For example,
        cvs rtag -b -r ns-2_0a15 ns-2_0a15-bKVa1 ns-2

We can now check out ns-2_0a15-bKVa1, make changes to it, and commit them back. The sequence is:
        cvs checkout -r ns-2_0a15-bKVa1 ns-2
	cd ns-2
Check to see if the file ./CVS/Tag exists and contains the tag corresponding to the branch that you just created. If NOT, do this:
	cvs update -r ns-2_0a15-bKVa1 
Do local modifications to the working sources as needed. You can use commands such as "update", "commit", "add", etc. just as before. The "sticky" tag for the branch is assumed implicitly. To commit do:
   cvs commit

At any time, you can diff the current files in you working directory with respect to those at the time the branch was created, using the following command:
	cvs diff -r ns-2_0a15 -r ns-2_0a15-bKVa1

It is also a good idea to tag our final commits in that branch, in case we need to make further modifications on that branch later on.
        cvs rtag ns-2_0a15-bKVa2 ns-2

Now, to go back to working on the main trunk, we need to do an update:
        cvs update -A ns-2

At some point, we may need to merge the change on that branch to the main trunk. The sequence is to first check out the sources from the main trunk, join the modifications on the branch into your working copy, and then commit the modified sources back to the main trunk, as
        cvs checkout ns-2
        cvs update -j ns-2_0a15-bKVa1
	cvs commit

Binary Releases

All release binaries should be put in the /nfs/web/isi.edu/htdocs/nsnam/dist/binary directory. This directory maps to http://www.isi.edu/nsnam/dist/binary on the website. After making a relase please update the ns and nam web pages to reflect the current version.

CVS Accounts

To be able to access new cvs repository, you also need to have an account created on nsnam.isi.edu, which can be accessed only via ssh.

CVS and Subdirectories

By default, CVS does not create subdirectories when you do a cvs update. If you know someone's added a new subdirectory, make sure you do cvs update -d when updating.

Hint: to make this the default behavior put one line in your ~/.cvsrc:

update -d

Accounts on nsnam.isi.edu

Everyone who wants to use CVS needs an account on nsnam.isi.edu. E-mail account requests with your ~/.ssh/identity.pub info to Kun-chan Lan ([email protected]) for an account.

Procedure to add a new account on nsnam.isi.edu

  1. add or modify /etc/passwd for the new user
  2. add new user into group "nsnam" in /etc/group
  3. add new user into /etc/sendmail.cE
  4. Get their ssh info

Big-memory Simulations

We have a large-memory machine for doing big simulations. Ask for an account on big.isi.edu. Currently this machine is on Haobo's desk and runs FreeBSD.

Additional SSH Details

The -v option is useful in helping to diagnose problems with ssh. When ssh is working properly, it should look something like this:

unix> ssh -v nsnam.isi.edu
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid 1003 geteuid 0 anon 1
debug1: Connecting to nsnam.isi.edu [128.9.160.91] port 22.
debug1: Connection established.
debug1: unknown identity file /home/username/.ssh/identity
debug1: identity file /home/username/.ssh/identity type -1
debug1: unknown identity file /home/username/.ssh/id_rsa
debug1: identity file /home/username/.ssh/id_rsa type -1
debug1: identity file /home/username/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_2.5.2p2
debug1: match: OpenSSH_2.5.2p2 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.5.2p2
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug1: got kexinit: ssh-rsa,ssh-dss
debug1: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[email protected]
debug1: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[email protected]
debug1: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug1: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug1: got kexinit: none,zlib
debug1: got kexinit: none,zlib
debug1: got kexinit: 
debug1: got kexinit: 
debug1: first kex follow: 0 
debug1: reserved: 0 
debug1: done
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: Sending SSH2_MSG_KEX_DH_GEX_REQUEST.
debug1: Wait SSH2_MSG_KEX_DH_GEX_GROUP.
debug1: Got SSH2_MSG_KEX_DH_GEX_GROUP.
debug1: dh_gen_key: priv key bits set: 119/256
debug1: bits set: 1002/2049
debug1: Sending SSH2_MSG_KEX_DH_GEX_INIT.
debug1: Wait SSH2_MSG_KEX_DH_GEX_REPLY.
debug1: Got SSH2_MSG_KEXDH_REPLY.
debug1: Host 'nsnam.isi.edu' is known and matches the RSA host key.
debug1: Found key in /home/username/.ssh/known_hosts2:2
debug1: bits set: 1025/2049
debug1: ssh_rsa_verify: signature correct
debug1: Wait SSH2_MSG_NEWKEYS.
debug1: GOT SSH2_MSG_NEWKEYS.
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: done: KEX2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/username/.ssh/identity
debug1: try privkey: /home/username/.ssh/id_rsa
debug1: try pubkey: /home/username/.ssh/id_dsa
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8088228 hint 2
debug1: read SSH2 private key done: name dsa w/o comment success 1
debug1: sig size 20 20
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: shell
debug1: channel 0: open confirm rwindow 0 rmax 16384
Last login: Mon Jun 25 16:14:09 2001 from starbucks.hell.com
DELL-installed Red Hat Linux Thu Oct 14 09:20:18 CDT 1999
[username@vir username]$

You can use these message to debug what's gong wrong if this doesn't work. The error message about X are expected.