If you have generated a trace file from running a ns tcl script, you should be able to analyze it without the use of any tools. This could come handy in emergencies when you don’t have any tools (Tracegraph,perl scripts etc) at hand.

The following method has been suggested at a ns mailing list.

To find the interpretation of all possible trace format when you do the wireless simulation, you’d better read the code of ns2 in file ns2home/trace/cmu-trace{.h, .cc}.

where ns2home denotes the location of ns-allinone-* installation folder.

Usually the format looks like this:

ACTION: [s|r|D|f]: s -- sent, r -- received, D -- dropped,f -- forwarded
WHEN: the time when the action happened
WHERE: the node where the action happened
LAYER: AGT -- application,
 RTR -- routing,
 LL  -- link layer (ARP is done here)
 IFQ -- outgoing packet queue (between link and mac layer)
 MAC -- mac,
 PHY -- physical
flags:
SEQNO: the sequence number of the packet
TYPE: the packet type
  cbr -- CBR data stream packet
  DSR -- DSR routing packet (control packet generated by routing)
  RTS -- RTS packet generated by MAC 802.11
  ARP -- link layer ARP packet
SIZE: the size of packet at current layer, when packet goes down,
  size increases, goes up size decreases
[a b c d]: a -- the packet duration in mac layer header
  b -- the mac address of destination
  c -- the mac address of source
  d -- the mac type of the packet body
flags:
[......]: [   ip layer
  source node ip : port_number
  destination node ip (-1 means broadcast) : port_number
  ip header ttl
  ip of next hop (0 means node 0 or broadcast)
  ]

So if you have a line like this

s 76.000000000 _98_ AGT – - – - 1812 cbr 32 [0 0 0 0] ——- [98:0 0:0 32 0]

in your trace file.

You should interpret it as

Application 0 (port number) on node 98 sent a CBR packet whose ID is 1812 and size is 32 bytes, at time 76.0 second, to application 0 on node 0 with TTL is 32 hops. The next hop is not decided yet.

Similarly, You should be able to interpret a line such as this:

r 0.010176954 _9_ RTR – - – - 1 gpsr 29 [0 ffffffff 8 800] ——- [8:255 -1:255 32 0]

as

The routing agent on node 9 received a GPSR broadcast (mac address 0xff, and ip address is -1, either of them means broadcast) routing packet whose ID is 1 and size is 29 bytes, at time 0.010176954 second, from node 8 (both mac and ip addresses are 8), port 255 (routing agent).

If you choose to play safe by making use of Tracegraph, then <this> post might help you.

Update:

Recently, I chanced to read <this manual> by Eitman Altman and manual is well organised for intermediate learners in ns2. I have extraced the ns2 trace file part from that and presented it below.

r 40.639943289 _1_ AGT —- 1569 tcp 1032 [a2 1 2 800] —-  [0:0 1:0 32 1] [35 0] 2 0

* The first field is a letter that can have the values r,s,f,D for “received”,”sent”,”forwarded” and “dropped”, respectively.It can also be < for giving a location or a movement indication.
* The second field is the time.
* The third field is the node number.
* The fourth field is MAC to indicate if the packet concerns a MAC layer, it is AGT to indicate the transport layer(e.g. tcp) packet, or RTR if it concerns the routed packet. It can also be IFQ to indicate events related to the interference priority queue(like drop of packets).
* After the dashes come the global sequence number of the packet(this is not the tcp sequence number).
* At the next field comes more information on the packet type(eg. tcp,ack or udp).
* Then comes the packet size in bytes.
* The 4 numbers in the first square brackets concern the mac layer information. The first hexadecimal number,a2(which equals 162 in decimal) specifies the expected time in seconds to send this data packet over the wireless channel. The second number,1, stands for the MAC-id of the sending node, and the third,2, is that of the receiving node. The fourth number,800, specifies that the MAC type is ETHERTYPE_IP.
* The next numbers in the second square brackets concern the IP source and destination addresses, then the ttl(Time To Live) of the packet(in our case 32),
* The third bracket concern the tcp information: its sequence number and the acknowledgment number.

This article is proudly sponsored by Evansys Technologies

====================================================

How to interprete the NS2 tracefile for wireless simulation?

To find the interpretation of all possible trace format when you do the wireless simulation, you'd better read the code of ns2 in file ns2home/trace/cmu-trace{.h, .cc} Mostly, the format would be as

ACTION:	[s|r|D]: s -- sent, r -- received, D -- dropped
WHEN:	the time when the action happened
WHERE:	the node where the action happened
LAYER:	AGT -- application, 
	RTR -- routing, 
	LL  -- link layer (ARP is done here)
	IFQ -- outgoing packet queue (between link and mac layer)
	MAC -- mac, 
	PHY -- physical
flags:
SEQNO:	the sequence number of the packet
TYPE:	the packet type
		cbr -- CBR data stream packet
		DSR -- DSR routing packet (control packet generated by routing)
		RTS -- RTS packet generated by MAC 802.11
		ARP -- link layer ARP packet
SIZE:	the size of packet at current layer, when packet goes down, size increases, goes up size decreases
[a b c d]:	a -- the packet duration in mac layer header
		b -- the mac address of destination
		c -- the mac address of source
		d -- the mac type of the packet body
flags:
[......]:	[
		source node ip : port_number
		destination node ip (-1 means broadcast) : port_number
		ip header ttl 
		ip of next hop (0 means node 0 or broadcast)
		]

So we can interpret the below trace

s 76.000000000 _98_ AGT  --- 1812 cbr 32 [0 0 0 0] ------- [98:0 0:0 32 0]

as Application 0 (port number) on node 98 sent a CBR packet whose ID is 1812 and size is 32 bytes, at time 76.0 second, to application 0 on node 0 with TTL is 32 hops. The next hop is not decided yet.

And we can also interpret the below trace

r 0.010176954 _9_ RTR  --- 1 gpsr 29 [0 ffffffff 8 800] ------- [8:255 -1:255 32 0]

in the same way, as The routing agent on node 9 received a GPSR broadcast (mac address 0xff, and ip address is -1, either of them means broadcast) routing packet whose ID is 1 and size is 19 bytes, at time 0.010176954 second, from node 8 (both mac and ip addresses are 8), port 255 (routing agent).  

void
CMUTrace::format_mac(Packet *p, int offset)
{
    struct hdr_mac802_11 *mh = HDR_MAC802_11(p);
    struct hdr_cmn *ch = HDR_CMN(p);
    // This function assumes in some places that mh->dh_body points
    // to an ethertype, which may not be true and causes some portability
    // problems, so we zero the printing of this field in some cases
    bool print_ether_type = true;
    if ( (ch->ptype() == PT_MAC) && 
         ( (mh->dh_fc.fc_type == MAC_Type_Control) ||
           (mh->dh_fc.fc_type == MAC_Type_Management))) {
        print_ether_type = false;
    } 
    
    if (pt_->tagged()) {
        sprintf(pt_->buffer() + offset,
            "-M:dur %x -M:s %x -M:d %x -M:t %x ",  //<<<<<<<<<<<<<<<<====================================
            mh->dh_duration,        // MAC: duration
            
            // change wrt Mike's code
            //ETHER_ADDR(mh->dh_da),        // MAC: source
            //ETHER_ADDR(mh->dh_sa),        // MAC: destination
            ETHER_ADDR(mh->dh_ra),          // MAC: source
                       ETHER_ADDR(mh->dh_ta),          // MAC: destination
            print_ether_type ? GET_ETHER_TYPE(mh->dh_body) : 0);    // MAC: type   
    } 
}
               ETHER_ADDR(mh->dh_ra),
                       ETHER_ADDR(mh->dh_ta),

            print_ether_type ? GET_ETHER_TYPE(mh->dh_body) : 0);
    } else {
        sprintf(pt_->buffer() + offset,
            " [%x %x %x %x] ",
            //*((u_int16_t*) &mh->dh_fc),
            mh->dh_duration,
            
            // change wrt Mike's code
            //ETHER_ADDR(mh->dh_da),
            //ETHER_ADDR(mh->dh_sa),
            ETHER_ADDR(mh->dh_ra),
                        ETHER_ADDR(mh->dh_ta),
            print_ether_type ? GET_ETHER_TYPE(mh->dh_body) : 0);
    }
}







  
void
CMUTrace::format_ip(Packet *p, int offset)
{
        struct hdr_cmn *ch = HDR_CMN(p);
    struct hdr_ip *ih = HDR_IP(p);
    
    // hack the IP address to convert pkt format to hostid format
    // for now until port ids are removed from IP address. -Padma.
    int src = Address::instance().get_nodeaddr(ih->saddr());
    int dst = Address::instance().get_nodeaddr(ih->daddr());


  if (pt_->tagged()) {
        sprintf(pt_->buffer() + offset,
            "-IP:s %d -IP:sp %d -IP:d %d -IP:dp %d -p %s -e %d "
            "-c %d -i %d -IP:ttl %d ",
            src,                           // packet src
            ih->sport(),                   // src port
            dst,                           // packet dest
            ih->dport(),                   // dst port
            packet_info.name(ch->ptype()), // packet type
            ch->size(),                    // packet size
            ih->flowid(),                  // flow id
            ch->uid(),                     // unique id
            ih->ttl_                       // ttl
            );
    } else if (newtrace_) {
        sprintf(pt_->buffer() + offset,
            "-Is %d.%d -Id %d.%d -It %s -Il %d -If %d -Ii %d -Iv %d ",  //<<<<<<<<<<<<<<<============================
            src,                           // packet src
            ih->sport(),                   // src port
            dst,                           // packet dest
            ih->dport(),                   // dst port
            packet_info.name(ch->ptype()),  // packet type
            ch->size(),                     // packet size
            ih->flowid(),                   // flow id
            ch->uid(),                      // unique id
            ih->ttl_);                      // ttl
    } else {
        sprintf(pt_->buffer() + offset, "------- [%d:%d %d:%d %d %d] ",
        src, ih->sport(),
        dst, ih->dport(),
        ih->ttl_, (ch->next_hop_ < 0) ? 0 : ch->next_hop_);
    }
}