Created attachment 1548 [details]
The output with HelloInterval as 10

Overview: 

In adjusting the HelloInterval Attribute for OLSR protocol in NS-3 3.16 and a dev release (http://code.nsnam.org/ns-3-dev/rev/1e5921e6507d), the result is that the OLSR nodes can no longer form symmetric links due to the validity time not adjusting according to the hello emission interval.


Steps to Reproduce:

We will compare the PCAPs of one node from simple-point-to-point-olsr.cc with default HelloInterval and HelloInterval 10.

From: ~/repos/ns-3-allinone/ns-3-dev$
Do:
cp src/olsr/examples/simple-point-to-point-olsr.cc scratch/
./waf --run "scratch/simple-point-to-point-olsr --ns3::olsr::RoutingProtocol::HelloInterval=2"
cp simple-point-to-point-olsr-0-1.pcap simple-point-to-point-olsr-0-1-default.pcap 
./waf --run "scratch/simple-point-to-point-olsr --ns3::olsr::RoutingProtocol::HelloInterval=20"
cp simple-point-to-point-olsr-0-1.pcap simple-point-to-point-olsr-0-1-HelloInterval-10.pcap 


Actual Results: 

We can see in simple-point-to-point-olsr-0-1-HelloInterval-10.pcap that the validity timer is not updated, but the hello timer is.

Validity Time: 6.000 (in seconds)
Hello Emission Interval: 20.000 (in seconds)

Comparing the two PCAPs we can see that no links form since the validity timer is lower than the hello emission interval...


Expected Results: 

The validity timer needs to be updated so that it is higher than the hello emission interval if the attribute system is only allowing us to modify the HelloInterval.  Otherwise, no links will form when a 3x higher hello interval is chosen.  This makes adjusting the HelloInterval timer of little use...

RFC 3626 tells us that HELLO_INTERVAL period <= REFRESH_INTERVAL

   A HELLO message can be partial (e.g., due to message size
   limitations, imposed by the network), the rule being the following,
   on each interface: each link and each neighbor node MUST be cited at
   least once within a predetermined refreshing period,
   REFRESH_INTERVAL.  To keep track of fast connectivity changes, a
   HELLO message must be sent at least every HELLO_INTERVAL period,
   smaller than or equal to REFRESH_INTERVAL.

It would be good to at least update the refresh interval to be the same as hello interval that is set.


Build Date & Platform:

Build: http://code.nsnam.org/ns-3-dev/rev/1e5921e6507d
author	Vedran Miletić <rivanvx@gmail.com>
Fri, 21 Sep 2012 13:47:41 +0200 (6 months ago)
changeset 9079	1e5921e6507d
parent 9078	11ac313c0610
child 9080	f4cff46aab91
child 9082	0eda8dc57eff

OS: Ubuntu 10.04


Additional Builds and Platforms:

Also reproduced in ns-3.16.


Additional Information:

Bugzilla Search:
Closest thing about Hello interval was bug 739.  I don't see any bugs for this already.
https://www.nsnam.org/bugzilla/﷒0﷓

Google Search:
In one NS-3-user thread, a suggestion was made to adjust hello, but I don't think the user tried that and or this bug was not noticed.
https://groups.google.com/forum/#!msg/ns-3-users/-5StoPQZ1pU/aZ_9Xna7NvsJ

Attempted Fix:
I attempted to fix the problem by changing the macro for OLSR_REFRESH_INTERVAL from the "hard-coded" 2 value to be the same as m_helloInterval.  However, this produced various other program failures in SecondsToEmf and in int64x64-cairo.

andrew@ubuntu:~/repos/ns-3-allinone/ns-3-dev$ hg diff src/olsr/model/olsr-routing-protocol.cc 
diff -r 1e5921e6507d src/olsr/model/olsr-routing-protocol.cc
--- a/src/olsr/model/olsr-routing-protocol.cc	Fri Sep 21 13:47:41 2012 +0200
+++ b/src/olsr/model/olsr-routing-protocol.cc	Fri Mar 29 08:10:14 2013 -0700
@@ -66,7 +66,7 @@
 ///
 /// We only use this value in order to define OLSR_NEIGHB_HOLD_TIME.
 ///
-#define OLSR_REFRESH_INTERVAL   Seconds (2)
+#define OLSR_REFRESH_INTERVAL   Seconds (m_helloInterval)
 


I have detailed outputs of the exceptions/program crashes/steps, if you want me to add them.

Attached is my PCAPs of failure case.