Re: [ns] segmentation fault when trying to read common header of a packet

[Ariel Goldberg]

I just made some progress with this... i still have the problem, but a
better idea where it comes from.  Basically, its that i get a blank packet
of the IFQ... i don't know why?

What is happening is that node 1 is sending a packet to node 0.  Node 0
replies with an Ack to node 1.  Node 1 receives the Ack in Mac802_11::recv
which then schedules the packet to be received in Mac802_11::recv_timer.
This then calls Mac802_11::recvAck and a packet is dequeued from the IFQ...
but this packet that is being dequeued from the IFQ is blank.

So, the MAC layer receives this blank packet... and one of the first things
it checks is the direction it is supposed to be going... usually it should
be DOWN and this then goes off to the send procedure... but because it is
blank it is skipping over the send function and going to the part of the
MAC802_11::recv function that deals with packets with direction UP...
anyways... this leads to a collision and some other stuff and eventually the
pktRx is placed on the calendar and then deleted... so what happens when it
comes off the calendar is that looking at its common header

struct hdr_cmn *hdr = HDR_CMN(pktRx_);

results in a segmentation fault because pktRx is literally stored as
0x in memory.

The original cause of the problem is this blank packet that comes off the
IFQ?

On Mon, Mar 8, 2010 at 4:15 PM, Ariel Goldberg ariel.goldbe...@gmail.comwrote:

 I'm running into a segmentation fault in my simulation.  The essence of the
 problem is that i am putting a packet into the IFQ of a node, but when i
 take the packet off the queue to be processed by the MAC layer... it is
 blank.

 When the simulation tries to read the common header of the packet it
 results in a segmentation fault.

 Do you have any idea what could be happening to the packet while it is in
 the IFQ... or where this blank packet could be coming from.  I am trying to
 monitor the queue by looking at the packets inserted before and after the
 packet... but i can't really make much sense of it right now.

 By looking at the memory addresses of the packets, i thought i would be
 able to track the packets as they are added to the queue from the
 LL::sendDown method in llc.cc and then see them in that order in the queue
 by looking at the next_ variable... but what i have found is that the order
 of the packets in the queue does not correspond to the order of the packets
 that came through llc.cc?

 I don't understand this?  Surely all packets in the IFQ must be coming
 through the LL::sendDown method?

 Kind Regards

 Ariel Goldberg

 Mobile: +27 82 998 7122
 Phone: +27 21 940 9757
 Mail: ariel.goldbe...@gmail.com




-- 
Kind Regards

Ariel Goldberg

Mobile: +27 82 998 7122
Phone: +27 21 940 9757
Mail: ariel.goldbe...@gmail.com

Re: [ns] segmentation fault when trying to read common header of a packet

[Ariel Goldberg]

Hi Sireesha

I am working with MAC802.11

I am not sure about authentication packets... but my understanding is that
packets are identified by the common header.  The types of packets i know of
are defined in packet.h as below:

static const packet_t PT_TCP = 0;
static const packet_t PT_UDP = 1;
static const packet_t PT_CBR = 2;
static const packet_t PT_AUDIO = 3;
static const packet_t PT_VIDEO = 4;
static const packet_t PT_ACK = 5;
static const packet_t PT_START = 6;
static const packet_t PT_STOP = 7;
static const packet_t PT_PRUNE = 8;
static const packet_t PT_GRAFT = 9;
static const packet_t PT_GRAFTACK = 10;
static const packet_t PT_JOIN = 11;
static const packet_t PT_ASSERT = 12;
static const packet_t PT_MESSAGE = 13;
static const packet_t PT_RTCP = 14;
static const packet_t PT_RTP = 15;
static const packet_t PT_RTPROTO_DV = 16;
static const packet_t PT_CtrMcast_Encap = 17;
static const packet_t PT_CtrMcast_Decap = 18;
static const packet_t PT_SRM = 19;
/* simple signalling messages */
static const packet_t PT_REQUEST = 20;
static const packet_t PT_ACCEPT = 21;
static const packet_t PT_CONFIRM = 22;
static const packet_t PT_TEARDOWN = 23;
static const packet_t PT_LIVE = 24; // packet from live network
static const packet_t PT_REJECT = 25;

static const packet_t PT_TELNET = 26; // not needed: telnet use TCP
static const packet_t PT_FTP = 27;
static const packet_t PT_PARETO = 28;
static const packet_t PT_EXP = 29;
static const packet_t PT_INVAL = 30;
static const packet_t PT_HTTP = 31;

/* new encapsulator */
static const packet_t PT_ENCAPSULATED = 32;
static const packet_t PT_MFTP = 33;

/* CMU/Monarch's extnsions */
static const packet_t PT_ARP = 34;
static const packet_t PT_MAC = 35;
static const packet_t PT_TORA = 36;
static const packet_t PT_DSR = 37;
static const packet_t PT_AODV = 38;
static const packet_t PT_IMEP = 39;

// RAP packets
static const packet_t PT_RAP_DATA = 40;
static const packet_t PT_RAP_ACK = 41;

static const packet_t PT_TFRC = 42;
static const packet_t PT_TFRC_ACK = 43;
static const packet_t PT_PING = 44;

static const packet_t PT_PBC = 45;
// Diffusion packets - Chalermek
static const packet_t PT_DIFF = 46;

// LinkState routing update packets
static const packet_t PT_RTPROTO_LS = 47;

// MPLS LDP header
static const packet_t PT_LDP = 48;

// GAF packet
static const packet_t PT_GAF = 49;

// ReadAudio traffic
static const packet_t PT_REALAUDIO = 50;

// Pushback Messages
static const packet_t PT_PUSHBACK = 51;

#ifdef HAVE_STL
// Pragmatic General Multicast
static const packet_t PT_PGM = 52;
#endif //STL
// LMS packets
static const packet_t PT_LMS = 53;
static const packet_t PT_LMS_SETUP = 54;

static const packet_t PT_SCTP = 55;
static const packet_t PT_SCTP_APP1 = 56;

// SMAC packet
static const packet_t PT_SMAC = 57;
// XCP packet
static const packet_t PT_XCP = 58;

// HDLC packet
static const packet_t PT_HDLC = 59;

// Bell Labs Traffic Trace Type (PackMime OL)
static const packet_t PT_BLTRACE = 60;

// insert new packet types here
static packet_t PT_NTYPE = 61; // This MUST be the LAST one

From the common header the ptype variable holds a number which corresponds
to a certain type of packet.  for instance, exponential traffic that i am
using is 29... whereas DSDV routing update packets are 13.

Then, the mechanism for directing the packets through the priority queue or
the normal queue is as follows.

All packets are received by the llc.cc file.  If the packet has a direction
DOWN, then it is passed to the LL::sendDown method.  In this method, the
schedules the packet to be received by the PriQueue::recv method in the file
priqueue.cc.

Now, depending on the ptype in the common header... the packet is directed
to an IFQ.  If it is TORA or AODV it goes to the red recvHighPriority(p, h);
and get s received by the PriQueue::recvHighPriority in priqueue.cc

if it is just a normal packet... like mine are type MESSAGE... then it goes
to the blue Queue::recv(p, h); and is received by the normal IFQ Queue::recv
in file queue.cc

void
PriQueue::recv(Packet *p, Handler *h)
{
struct hdr_cmn *ch = HDR_CMN(p);

if(Prefer_Routing_Protocols) {

switch(ch-ptype()) {
case PT_DSR:
case PT_MESSAGE:
case PT_TORA:
case PT_AODV:
recvHighPriority(p, h);
break;

default:
Queue::recv(p, h);
}
}
else {
Queue::recv(p, h);
}
}

That's how i think it works... i could be completely lost... but yeah.  Hope
it helps

Kind Regards

Ariel

On Mon, Mar 8, 2010 at 6:53 PM, sireesha madabhushi siri...@gmail.comwrote:

 Hello!
 Are you working on 802.11 MAC? If yes I need some help regarding the
 interface queues. I want to differentiate the authentication packets from
 others and give priority to them. But in the case statement of priqueue.cc,
 I am not able to identify the MAC AUTH 

[ns] segmentation fault when trying to read common header of a packet

[Ariel Goldberg]

I'm running into a segmentation fault in my simulation.  The essence of the
problem is that i am putting a packet into the IFQ of a node, but when i
take the packet off the queue to be processed by the MAC layer... it is
blank.

When the simulation tries to read the common header of the packet it results
in a segmentation fault.

Do you have any idea what could be happening to the packet while it is in
the IFQ... or where this blank packet could be coming from.  I am trying to
monitor the queue by looking at the packets inserted before and after the
packet... but i can't really make much sense of it right now.

By looking at the memory addresses of the packets, i thought i would be able
to track the packets as they are added to the queue from the LL::sendDown
method in llc.cc and then see them in that order in the queue by looking at
the next_ variable... but what i have found is that the order of the packets
in the queue does not correspond to the order of the packets that came
through llc.cc?

I don't understand this?  Surely all packets in the IFQ must be coming
through the LL::sendDown method?

Kind Regards

Ariel Goldberg

Mobile: +27 82 998 7122
Phone: +27 21 940 9757
Mail: ariel.goldbe...@gmail.com