m_routingAgentAddr and OLSR

[med]

Hello,

I have a problem in olsr.

normally during the the step "Starting POLSR on node X" we have to
initialize m_routingAgentAddr with the main address of this node.

This address (m_routingAgentAddr) is used in instruction

if (nb2hop_addr == m_routingAgentAddr)
{
NS_LOG_LOGIC ("Ignoring 2-hop neighbor (it is
the node itself)");
continue;
}
But when I checked the src of olsr protocole I think this address is
never initialized

you can also cheked the log for :

[node 2] Looking at 2-hop neighbor address from HELLO message:
10.1.2.2 (main address is 10.1.1.2 m_routingAgentAddr
102.102.102.102)

That's means that, the node x belongs to its two neighbors set!!!
is this a bug in olsr.

[Gustavo Carneiro]

Yes it is :P

The correct code would be "if (nb2hop_addr == m_mainAddress)".  m_routingAgentAddr simply should disappear from the code.

Because the value is not initialized, it could be zero or a strange value like 102.102.102.102.  It takes a lot of bad luck for the bug to have practical effect in the results, I think.  Anyway, I am fixing it as I write this.

Thanks!

 

--
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

[med]

Think you.

I have another question.
according to 8.1. Populating the Neighbor Set in RFC 2636.
Is what we will not need to iterate all links to this neighboring node
before changing the nb_tuple->status.

see : RoutingProtocol::LinkTupleUpdated (const LinkTuple &tuple,
uint8_t willingness)

Thanks

On 9 fév, 16:52, Gustavo Carneiro <gjcarne...@gmail.com> wrote:

> INESC Porto, UTM, WiN,http://win.inescporto.pt/gjc

[med]

the previous question is asked when we we use multi-interface " for
example different channel for each interface".

[Gustavo Carneiro]

On Wed, Feb 9, 2011 at 16:28, med <chei...@yahoo.fr> wrote:

the previous question is asked when we  we use multi-interface " for
example different channel for each interface".

On 9 fév, 17:18, med <chei_...@yahoo.fr> wrote:
> Think you.
>
> I have another question.
> according to 8.1.  Populating the Neighbor Set in RFC 2636.
> Is what we will not need to iterate all links to this neighboring node
> before changing the nb_tuple->status.
>
> see  : RoutingProtocol::LinkTupleUpdated (const LinkTuple &tuple,
> uint8_t willingness)

Sorry, your english writing is not very good and I can't understand your question.  What do you think is wrong in the olsr code exactly?  What source lines?

 

--
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, UTM, WiN, http://win.inescporto.pt/gjc

[med]

Yes,

i don't see how the correspondence between link tuples and associated
neighbor tuples is maintained.

i think, upen receiving a hello message from neighbor node x, we will
iterate all the link set to this neighbor befor changing the here
for example,status.

if (tuple.symTime >= Simulator::Now ())
{
nb_tuple->status = NeighborTuple::STATUS_SYM;
NS_LOG_DEBUG (*nb_tuple << "->status = STATUS_SYM; changed:"
<< int (statusBefore != nb_tuple->status));
}
else
{
nb_tuple->status = NeighborTuple::STATUS_NOT_SYM;
NS_LOG_DEBUG (*nb_tuple << "->status = STATUS_NOT_SYM;
changed:"
<< int (statusBefore != nb_tuple->status));
}
if we use multiple interface "multiple interface adhoc for each
node". we have several links between the receiver node and the node
X.

i think, according to 8.1. Populating the Neighbor Set in RFC 263,
we have to verifies if all the link tuple from the receivernode to
the node X are asymetric or lost.

On 9 fév, 17:45, Gustavo Carneiro <gjcarne...@gmail.com> wrote:

[med]

Yes,

i don't see how the correspondence between link tuples and associated
neighbor tuples is maintained.

i think, upen receiving a hello message from neighbor node x,  we
will
iterate all the link set to this neighbor  befor  changing  the

status.

for example, in

[med]

 Yes,

 i don't see how the correspondence between link tuples and
associated
 neighbor tuples is maintained.

 i think, upen receiving a hello message from neighbor node x,  we
will
 iterate all the link set to this neighbor  befor  changing  the
status.

 for example, in

  if (tuple.symTime >= Simulator::Now ())
         {
           nb_tuple->status = NeighborTuple::STATUS_SYM;
           NS_LOG_DEBUG (*nb_tuple << "->status = STATUS_SYM;
changed:"
                         << int (statusBefore != nb_tuple->status));
         }
       else
         {
           nb_tuple->status = NeighborTuple::STATUS_NOT_SYM;
           NS_LOG_DEBUG (*nb_tuple << "->status = STATUS_NOT_SYM;
 changed:"
                         << int (statusBefore != nb_tuple->status));
         }
 if we use multiple interface "multiple interface adhoc for each
 node".  we have several links between the receiver node and the node
 X.

 i think, according to 8.1.  Populating the Neighbor Set in RFC 263,
 we have to verifies if  all the link tuple from the receivernode to

 the node X are asymetric or lost befor doing this changement :
nb_tuple->status = NeighborTuple::STATUS_NOT_SYM;.

[Gustavo Carneiro]

Thank you, I understand now.  I agree it is a bug.  But fixing it is not trivial, I opened a bug report to fix later:  http://www.nsnam.org/bugzilla/show_bug.cgi?id=1052

Regards.

INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc

[med]

Thanks