Capture AODV RREQ packets

[deepankar sarma]

Hi everyone,
 Can anybody tell me how can i capture RREQ and RREP packets of AODV protocol?


Regards

Deepankar

[Konstantinos]

What do you mean capture? Do you want to count Tx/Rx of them, because they are captured by AODV internally.

There are two methods to do it (the counting). 

a) Generate trace files (ASCII or PCAP) and analyse them looking at the headers etc.

b) Create trace sources for the Tx, Rx of these packets in AODV and then with callbacks count them. 

Both methods are explained in the documentation

Regards,

K.

[deepankar sarma]

No,I don't want to count.I want to display RREQ and RREP packet.


    Regards

Deepankar

[Konstantinos]

The techniques I mentioned in my previous reply apply also if you want to 'display' the packets. 

For example, when using the tracing sources Instead of increasing a counter, you will print the packet you received.

With the ASCII/PCAP trace files, you should be able to see those packets.

On Wednesday, 20 May 2015 04:41:54 UTC+1, deepankar sarma wrote:

Hello Konstantinos, sorry for late reply.I want to capture and display those RREQ and RREP packets.

Regards

Deepankar

[deepankar sarma]

Thanks Konstantinos

Regards

Deepankar

[deepankar sarma]

Sir I can't do this as you said.Can you explain with an example.

Regards

Deepankar

[Tommaso Pecorella]

Hi,

the "examples" folder is literally filled with examples. More or less any script in that folder uses traces and/or pcap and ascii outputs.

Please be precise and explain what you are not able to do and what have you tried so far. We expect that users are well acquainted with the tutorial (at least).

T. 

[deepankar sarma]

 Sir,I take 10 nodes and i am using AODV protocol to find the path.The source node will generate and broadcast RREQ message to find the path (if path not exist in the source node) and get reply from intermediate or destination node.At that time I need to print/display those RREQ and RREP messages.So please tell me how can I do this.  

    Regards

Deepankar

[Tommaso Pecorella]

Short and simple: no, I won't tell you how to do it.

The technique to do it are explained in the tutorial and the manual, and it is our policy to not do other people's work.
If you have a specific question, feel free to ask, but we will not do you work for you.

T.

[deepankar sarma]

 Sir I can't able how to do this.please give me a hint,please.

Regards

Deepankar

[Tommaso Pecorella]

Study the manual and the tutorial. Pay attention to the logging and tracing parts.

T.

[deepankar sarma]

Sir I am using the following code to display the Tx and Rx packets,

     
     void WifiMacTxTrace (std::string context, Ptr<const Packet> p)
       {
          std::ofstream out("traces.txt", std::ios::app);
          out << context << " actual_time" << (Simulator::Now ()).GetSeconds () << "\n"
          << p->ToString() << "\n"; 
          p->Print(std::cout);
       }

     void WifiMacRxTrace (std::string context, Ptr<const Packet> p)
      {
        std::ofstream out("traces.txt", std::ios::app);
        out << context << " actual_time" << (Simulator::Now ()).GetSeconds () << "\n"
        << p->ToString() << "\n"; 
 
        p->Print(std::cout);
     }

  Config::Connect ("/NodeList/1/DeviceList/0/$ns3::WifiNetDevice/Mac/MacTx",  MakeCallback (&WifiMacTxTrace)); 
   
  Config::Connect ("/NodeList/1/DeviceList/0/$ns3::WifiNetDevice/Mac/MacRx",MakeCallback (&WifiMacRxTrace));
  
Simulator::Schedule (Seconds (30.0), &GenerateTraffic,
                         source, packetSize, numPackets, interPacketInterval,sourceNode);

Is this correct or wrong.Though I am getting RREP and RREQ packets in the console there is a problem.There are lots of RREP packets and  the RREP packet displayed earlier(at 0.86 sec) than RREQ which is displayed at 30.11 sec. If this is wrong how can I correct it.


 

Regards

Deepankar

[Masahiro Rikiso]

maybe RREP packet at 0.86s is Hello packet

2015年5月30日土曜日 18時15分29秒 UTC+9 deepankar sarma:

[Konstantinos]

Hi Masahiro,

What you have at the moment is just printing any Tx/Rx packet on the second node (NodeList/1) 

If you analyse the packet headers of those packets you can identify if they are RREQ, RREP, HELLO, DATA etc. 

Regards,

K.

[deepankar sarma]

Hi Konstntinos,
 I have analysed those packets and found those are RREP packets.But the problem is why I am getting RREP packets earlier than RREQ packets and how can I solve
 this problem.

Regards

Deepankar

[deepankar sarma]

Sir
  Please reply,how can I solve this problem.

Regards

Deepankar

[Tommaso Pecorella]

Hi,

can you post a script showing the issue ? We need to reproduce the problem to check what's wrong.

Also, please cut from the script anything that is not strictly necessary. I.e., use the least nodes as possible, just one source, etc.

Thanks,

T.

[deepankar sarma]

Sir,
  here is my script

Regards

Deepankar

[deepankar sarma]

Sir please reply what's going wrong.

Regards

Deepankar

[Tommaso Pecorella]

Hi,

yes, I see the RREP, and they seems to be sent without any RREQ. I'll have to dig a bit into this. I'll let you know if I find something.

One suggestion in the meantime: check if there are "unsolicited" RREP cases. The first thing I'd check is that HELLO aren't sent as RREP by mistake.

Cheers,

T.

[Tommaso Pecorella]

... just an update: try filtering the pcap files with "!(aodv.dest_ip == aodv.orig_ip)". THAT is the right pcap.

I think I know where the bug is. Again, I'll keep you updated.

Cheers,

T.

[Tommaso Pecorella]

Hi,

final update: it turns out that the "bug" is just the normal behaviour, and

1) I'm too tired and unfocused, and

2) you should had double checked the RFC.

https://tools.ietf.org/html/rfc3561#section-6.9

6.9. Hello Messages

   A node MAY offer connectivity information by broadcasting local Hello
   messages.  A node SHOULD only use hello messages if it is part of an
   active route.  Every HELLO_INTERVAL milliseconds, the node checks
   whether it has sent a broadcast (e.g., a RREQ or an appropriate layer
   2 message) within the last HELLO_INTERVAL.  If it has not, it MAY
   broadcast a RREP with TTL = 1, called a Hello message, with the RREP
   message fields set as follows:
      Destination IP Address         The node's IP address.
      Destination Sequence Number    The node's latest sequence number.
      Hop Count                      0
      Lifetime                       ALLOWED_HELLO_LOSS * HELLO_INTERVAL

In other words: "hello" messages are just unsolicited RREP messages with a slightly special format.

Guess what? The ones you're seeing are hello messages.

Modifying the AODV helper setup in this way:

  // Enable AODV
  AodvHelper aodv;
  aodv.Set ("EnableHello", BooleanValue (false));

completely removes these "strange" RREP messages.

Case closed, these are HELLO messages.

[deepankar sarma]

Thank you sir thank you so much for your help.
Sir I will ask you again if I face any problem.

Regards

Deepankar

[deepankar sarma]

Sir, to listen and detect a node that drop data packets what should I do? 

Regards

Deepankar

[Tommaso Pecorella]

Sorry, but this group is about ns-3, not about research topics in telecommunication.

As I said more than once, research is our (paid) work. if I do your, who's gonna do mine ? Will you add me as an author to your researches ? Will my boss be happy if I'll tell him that I spent time fixing your research ?

The answer to the above questions is: no. As a consequence, sorry, but I can't help you on this.

As a small hint, I can tell you that it will not work. I already kicked some papers based on this assumption, and I'll keep on rejecting them when needed, at least until someone can explain me HOW a node can reliably listen to these events. Since nobody gave me an answer yet, I'll keep on kicking papers.

Before asking how you can do it on ns-3, try answering this: is it PHYSICALLY possible ?

T.

[deepankar sarma]

Sir sorry for the last question.
Here I have confusion related to the above simulaton script.In the trace file(wifi-s-a-g.tr) of the script the data packet is first transmitted by node 3 at time 10.0481 sec and is received by node 2 at time 10.057.Then node 2 transmitts this at 10.0663.After this the packet is received by node 1 and 3,at time 10.0752.After this node 1 transmits the data that is received by node 0(destination) and 2,at the time 10.0865.After this from time 12.0429 RERR packets are transmits and received.
Here is my question,
Why node 3 and 2(later) receives the data packet? or Why node 2 and 1 are transmitting the data packets to all of its neighbours?
Why RERR packets are transmitted and received?

Please reply.


Regards

Deepankar

[deepankar sarma]

  Sir please reply.

Regards

Deepankar

[Tommaso Pecorella]

Please upgrade your ns-3. The very first thing one should do when something strange is found is upgrade to the latest version.

Using an outdated version and trying to figure out a strange behaviour is a waste of time, your and ours.

Attached you can find the trace file as generated by my ns-3. As you can see there's no RERR whatsoever.

As a consequence, either you are using an outdated ns-3 release or you modified the sources. In both cases we can't do much.

T.

[deepankar sarma]

Sorry for my mistake.After adding " aodv.Set ("EnableHello", BooleanValue (false));" in the script and changing the scheduling time
(i.e.,scheduled at 10.0 and stop at 13.0) i can see those behaviour.And i am using ns-3.22.I have attached the modified script here,please help why is this happening
 


Regards

Deepankar

[deepankar sarma]

Sir why I am getting this,please reply.

 

Regards

Deepankar

[deepankar sarma]

Sir since I am tracing in physical layer I am getting this.Is this true or not.

 

Regards

Deepankar

[Tommaso Pecorella]

Please, we're not paid to reply 24h/day. We have a private life and a (normal) work. We try to reply to questions when we can, but they is NOT our main job.

As a consequence, being pokes 3 times in a day is quite... annoying. Patience is a virtue, and you must learn it.

T.

PS: I honestly don't care if you're in a hurry for some reason. We're all in a hurry, but the world keep spinning no matter if we meet deadlines or not.

[Tommaso Pecorella]

Citing: "And i am using ns-3.22"

Are you aware that we're at 3.23 and we're already working on 3.24 ?

When I said "Please upgrade your ns-3", I meant upgrade to the latest version, not to a version "close enough" to the latest.

Again, running your script generates the attached trace. Again, no RERR. Again, I can't exclude bugs in AIDV (I'm sure there are9, but you have to provide a replicable report. Replicable on the latest ns-3-dev, as a bug could have been fixed already from the latest release to the development one.

T.

[deepankar sarma]

Hello Konstantinos, sorry for late reply.I want to capture and display those RREQ and RREP packets.

Regards

Deepankar