Some issues with OLSR

28 views
Skip to first unread message

Lalith Suresh

unread,
Dec 24, 2009, 1:06:49 AM12/24/09
to ns-3-...@googlegroups.com
Hello all,

I'm trying to simulate a Colluding Node attack for MANETs using ns-3. Here is the simulation setup I am considering:

 n20  n21  n22  n23  n24
 n15  n16  n17  n18  n19
 n10  n11  n12  n13  n14
 n5   n6   n7   n8   n9
 n0   n1   n2   n3   n4

IP range starts with 10.1.1.1 for node 0, upto 10.1.1.25 for node 24.

Node 7 is the target, node 8 is the first colluding node and node 9 is the second colluding node.

The attack works as follows:

1) Node 8 sends a fake HELLO message indicating one-hop connectivity to _all_ of node 7's two hop neighbours.
2) Hence, node 7 chooses node 8 as its only MPR.
3) Node 8 then chooses node 9 as its only MPR.
4) Node 9 then drops any packets coming from node 7 or node 8 (note, TC packets are dropped).
5) Hence, none of the nodes out of node 8's two hop neighborhood will be able to see node 8, and hence, it's been knocked out of the network.

To achieve this, I've been fiddling with the olsr code itself. I've added some attributes that tell the colluding nodes who they're targeting, and what their role is (who should be sending the fake HELLO, who should be doing the packet dropping and so forth).

I also extended the olsr-header to include two-hop neighborhood information in its HELLO message, which is also working fine. I need this for tring out a countermeasure proposed in a paper. Node 8 sends the fake HELLO after learning about node 7's two hop neighbours. Node 8 seems to be sending the fake HELLO, and node 7 seems to be including the information in it's TwoHopNeighborSet as the following dump indicates. But the only problem is, node 7 is not computing the MPR set as expected. I've also included the debug information from node 7 calculating its MPR set (it's the same as when node 8 is not sending fake HELLOs).

I even tried hard coding it such that node 8 sends the fake HELLOs from the beginning itself, the TwoHopNeighborSet tuples that node 7 maintains gets affected early on (the entries with neighborMainAddr == 10.1.1.9 will be seen together then). But still the MPR set computed by 7 is the same. In this case, I even took off the two-hop connectivity information from the headers.

Here's the TwoHopNeighborSet dump towards the end of the simulation:

[...]
68.486s ** BEGIN dump TwoHopNeighbor Set for OLSR Node 10.1.1.8
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.8, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.9, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.18, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.7, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.12, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.14, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.19, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.13, twoHopNeighborAddr=10.1.1.17, expirationTime=74229949045ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.4, twoHopNeighborAddr=10.1.1.8, expirationTime=74477086762ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.4, twoHopNeighborAddr=10.1.1.9, expirationTime=74477086762ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.4, twoHopNeighborAddr=10.1.1.10, expirationTime=74477086762ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.4, twoHopNeighborAddr=10.1.1.5, expirationTime=74477086762ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.4, twoHopNeighborAddr=10.1.1.3, expirationTime=74477086762ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.8, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.11, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.13, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.6, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.12, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.1, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.2, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.7, twoHopNeighborAddr=10.1.1.3, expirationTime=74076004408ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.3, twoHopNeighborAddr=10.1.1.8, expirationTime=74452615468ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.3, twoHopNeighborAddr=10.1.1.9, expirationTime=74452615468ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.3, twoHopNeighborAddr=10.1.1.7, expirationTime=74452615468ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.3, twoHopNeighborAddr=10.1.1.2, expirationTime=74452615468ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.3, twoHopNeighborAddr=10.1.1.4, expirationTime=74452615468ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.2, twoHopNeighborAddr=10.1.1.8, expirationTime=74413601242ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.2, twoHopNeighborAddr=10.1.1.6, expirationTime=74413601242ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.2, twoHopNeighborAddr=10.1.1.7, expirationTime=74413601242ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.2, twoHopNeighborAddr=10.1.1.1, expirationTime=74413601242ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.2, twoHopNeighborAddr=10.1.1.3, expirationTime=74413601242ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.15, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.8, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.13, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.10, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.5, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.14, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.3, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.4, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.15, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.8, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.20, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.9, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.18, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.13, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.10, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.14, twoHopNeighborAddr=10.1.1.19, expirationTime=74296312245ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.8, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.11, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.18, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.13, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.16, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.6, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.7, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.12, twoHopNeighborAddr=10.1.1.17, expirationTime=74441013490ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.12, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.11, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.6, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.1, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.2, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.18, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.7, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.17, expirationTime=74486021504ns)
TwoHopNeighborTuple(neighborMainAddr=10.1.1.9, twoHopNeighborAddr=10.1.1.16, expirationTime=74486021504ns)
** END dump TwoHopNeighbor Set for OLSR Node 10.1.1.8

Yet, this is the MPR set that node 7 (10.1.1.8) is computing:

[...]
Computed MPR set for node 10.1.1.8: [10.1.1.2, 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
Computed MPR set for node 10.1.1.8: [10.1.1.2, 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
Computed MPR set for node 10.1.1.8: [10.1.1.2, 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
Computed MPR set for node 10.1.1.8: [10.1.1.2, 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
[...]

What am I missing over here?


--
Thanks and regards,
Lalith Suresh
Department of Computer Engineering
Malaviya National Institute of Technology, Jaipur
+91-9982190365 , lalithsuresh.wordpress.com

Tom Henderson

unread,
Dec 26, 2009, 6:40:53 PM12/26/09
to ns-3-...@googlegroups.com
> Computed MPR set for node 10.1.1.8 <http://10.1.1.8>: [10.1.1.2,

> 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
> Computed MPR set for node 10.1.1.8 <http://10.1.1.8>: [10.1.1.2,

> 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
> Computed MPR set for node 10.1.1.8 <http://10.1.1.8>: [10.1.1.2,

> 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
> Computed MPR set for node 10.1.1.8 <http://10.1.1.8>: [10.1.1.2,

> 10.1.1.4, 10.1.1.7, 10.1.1.9, 10.1.1.12, 10.1.1.13, 10.1.1.14]
> [...]
>
> What am I missing over here?

Lalith,
There was a bug fixed in OLSR this week; can you please either update
your code to the tip of ns-3-dev, or else apply this patch:
http://code.nsnam.org/ns-3-dev/raw-rev/8c65da328ae9
and see if it still produces unexpected behavior?

- Tom

Lalith Suresh

unread,
Dec 26, 2009, 11:11:50 PM12/26/09
to ns-3-...@googlegroups.com


On Sun, Dec 27, 2009 at 5:10 AM, Tom Henderson <to...@tomh.org> wrote:
Lalith,
There was a bug fixed in OLSR this week; can you please either update
your code to the tip of ns-3-dev, or else apply this patch:
http://code.nsnam.org/ns-3-dev/raw-rev/8c65da328ae9
and see if it still produces unexpected behavior?

- Tom

Thanks for the reply Tom. I'd followed that bug fix, and although I didn't apply the patch, I did make the necessary change to the source (replacing m_state.FindNeighborTuple with m_state.FindSymNeighborTuple). The results I got were obtained with the updated version. I'm on ns-3.6 by the way.

Since I'm on dial up now, I won't be able to update to ns-3-dev until next week! Any other major changes made to OLSR in between ns-3.6 and current-dev?

Gustavo Carneiro

unread,
Dec 27, 2009, 10:50:34 AM12/27/09
to ns-3-...@googlegroups.com
2009/12/27 Lalith Suresh <suresh...@gmail.com>



On Sun, Dec 27, 2009 at 5:10 AM, Tom Henderson <to...@tomh.org> wrote:
Lalith,
There was a bug fixed in OLSR this week; can you please either update
your code to the tip of ns-3-dev, or else apply this patch:
http://code.nsnam.org/ns-3-dev/raw-rev/8c65da328ae9
and see if it still produces unexpected behavior?

- Tom

Thanks for the reply Tom. I'd followed that bug fix, and although I didn't apply the patch, I did make the necessary change to the source (replacing m_state.FindNeighborTuple with m_state.FindSymNeighborTuple). The results I got were obtained with the updated version. I'm on ns-3.6 by the way.

Since I'm on dial up now, I won't be able to update to ns-3-dev until next week! Any other major changes made to OLSR in between ns-3.6 and current-dev?



--
Thanks and regards,
Lalith Suresh
Department of Computer Engineering
Malaviya National Institute of Technology, Jaipur
+91-9982190365 , lalithsuresh.wordpress.com

--

You received this message because you are subscribed to the Google Groups "ns-3-users" group.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.



--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Lalith Suresh

unread,
Jan 6, 2010, 10:40:54 AM1/6/10
to ns-3-...@googlegroups.com
Hello,

On Sun, Dec 27, 2009 at 5:10 AM, Tom Henderson <to...@tomh.org> wrote:

Lalith,
There was a bug fixed in OLSR this week; can you please either update
your code to the tip of ns-3-dev, or else apply this patch:
http://code.nsnam.org/ns-3-dev/raw-rev/8c65da328ae9
and see if it still produces unexpected behavior?


I just tried using the latest ns-3-dev. The MprSet is being computed as expected. Thanks!
Reply all
Reply to author
Forward
0 new messages