Dynamic Source Routing (DSR)

This issue is created to review the code that adds MANETs routing protocol Dynamic Source Routing (DSR) to ns-3 based on RFC 4728. This model is built
to operate as a shim between IP and transport protocol and provide source routing functionalities. It operates based on several adjustable parameters, with a detail parameter list defined in dsr-routing.cc file. A detailed description of this implementation is shown in docs folder.

[John Abraham, 2011-08-10 15:42:13]

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.cc
File src/dsr/model/dsr-fs-header.cc (right):

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
src/dsr/model/dsr-fs-header.cc:195: uint32_t fill = CalculatePad
((DsrOptionHeader::Alignment) {4,0});
struct compound literals are C99 extensions (and are not always portable)
I would recommend using
DsrOptionHeader::Alignment align = {4,0};
CalculatePad (align);

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
src/dsr/model/dsr-fs-header.cc:212: uint8_t buf[length];
Variable length arrays are not always portable

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
src/dsr/model/dsr-fs-header.cc:294: return 8 + DsrOptionField::GetSerializedSize
();
Please comment about the reason for using a constant literal such as "8"

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
src/dsr/model/dsr-fs-header.cc:302: i.WriteU8 (GetMessageType ());
Per the header described in the "*.h" file , Message Type is followed by Payload
Length.Was there some reason, to Write GetLength at the last?

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
src/dsr/model/dsr-fs-header.cc:322: 
Is there a reason why a "Deserialize" function needs a GetSerializedSize for a
return value? (I mean at first glance Deserialize should have nothing to do with
Serialize)
Can we not obtain the correct value to return using the return of
"DsrOptionField::Deserialize" ?

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.h
File src/dsr/model/dsr-fs-header.h (right):

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.h...
src/dsr/model/dsr-fs-header.h:66: * \brief The modified version of Dsr fixed
size header Format
Can you provide the reference document for the modified version of Dsr?

http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.h...
src/dsr/model/dsr-fs-header.h:126: uint16_t GetLength () const;
To improve readability and consistency with RFC 4728, this could be
GetPayloadLength rather than GetLength

[ycheng, 2011-08-11 16:40:06]

On 2011/08/10 15:42:13, johnjoe7 wrote:
> http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.cc
> File src/dsr/model/dsr-fs-header.cc (right):
> 
>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
> src/dsr/model/dsr-fs-header.cc:195: uint32_t fill = CalculatePad
> ((DsrOptionHeader::Alignment) {4,0});
> struct compound literals are C99 extensions (and are not always portable)
> I would recommend using
> DsrOptionHeader::Alignment align = {4,0};
> CalculatePad (align);
> 
I've changed this one based on your suggestion.

>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
> src/dsr/model/dsr-fs-header.cc:212: uint8_t buf[length];
> Variable length arrays are not always portable
> 
Not sure other way to do this trick. Option headers are linked after fixed-size
header and we need to deserialize them based on the payload length from the
fixed-size header.

>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
> src/dsr/model/dsr-fs-header.cc:294: return 8 +
DsrOptionField::GetSerializedSize
> ();
> Please comment about the reason for using a constant literal such as "8"
> 
Fixed this one. It's confusing without comment.

>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
> src/dsr/model/dsr-fs-header.cc:302: i.WriteU8 (GetMessageType ());
> Per the header described in the "*.h" file , Message Type is followed by
Payload
> Length.Was there some reason, to Write GetLength at the last?
> 
Fixed.

>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.c...
> src/dsr/model/dsr-fs-header.cc:322: 
> Is there a reason why a "Deserialize" function needs a GetSerializedSize for a
> return value? (I mean at first glance Deserialize should have nothing to do
with
> Serialize)
> Can we not obtain the correct value to return using the return of
> "DsrOptionField::Deserialize" ?
> 
It is because option headers are linked to fixed-size header and it needs the
GetSerializeSize to get the size of fixed-size header and option headers
together.

> http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.h
> File src/dsr/model/dsr-fs-header.h (right):
> 
>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.h...
> src/dsr/model/dsr-fs-header.h:66: * \brief The modified version of Dsr fixed
> size header Format
> Can you provide the reference document for the modified version of Dsr?
> 
There is no reference document for this modification. In ns-3, there is not way
for us to use IP forward DSR packet, so we transmit the packet hop-by-hop based
on source route, so the source and destination address in IP header changes. We
need extra fields in dsr-fs-header to keep track of these information and trace
results.

>
http://codereview.appspot.com/4823051/diff/4001/src/dsr/model/dsr-fs-header.h...
> src/dsr/model/dsr-fs-header.h:126: uint16_t GetLength () const;
> To improve readability and consistency with RFC 4728, this could be
> GetPayloadLength rather than GetLength

Fixed.

[Alaa Alhamoud, 2011-10-14 05:18:28]

The implementation of DSR does not follow the model of other manets
implementation in which the helper class inherits Ipv4RoutingHelper. Because of
that I was not able to use wifi netdevice which uses DSR routing in combination
with pointTopoint device on the same node. Whenever I try to send via the p2p
link, it initiates a route request via DSR. Do you know how to solve this
problem?

[Tom Henderson, 2011-10-17 05:26:33]

On 2011/10/14 05:18:28, alaa.alhamoud wrote:
> The implementation of DSR does not follow the model of other manets
> implementation in which the helper class inherits Ipv4RoutingHelper. Because
of
> that I was not able to use wifi netdevice which uses DSR routing in
combination
> with pointTopoint device on the same node. Whenever I try to send via the p2p
> link, it initiates a route request via DSR. Do you know how to solve this
> problem?

It seems to me that it would be easiest on future users to align the helper with
the other helpers; is there a reason why DsrMainHelper couldn't be rewritten to
be more like DsdvHelper?

I also don't understand your comment about using this in combination with
PointToPointNetDevice in the manet-routing-compare.cc program; there are no such
devices in that program.  

Can you clarify what you mean by "Whenever I try to send via the p2p link..."? 
Does this mean that you are trying to send to an address on that link, or that
you are binding your socket to the p2p device, or something else?

[Alaa Alhamoud, 2011-10-17 17:08:00]

On 2011/10/17 05:26:33, Tom Henderson wrote:
> On 2011/10/14 05:18:28, alaa.alhamoud wrote:
> > The implementation of DSR does not follow the model of other manets
> > implementation in which the helper class inherits Ipv4RoutingHelper. Because
> of
> > that I was not able to use wifi netdevice which uses DSR routing in
> combination
> > with pointTopoint device on the same node. Whenever I try to send via the
p2p
> > link, it initiates a route request via DSR. Do you know how to solve this
> > problem?
> 
> It seems to me that it would be easiest on future users to align the helper
with
> the other helpers; is there a reason why DsrMainHelper couldn't be rewritten
to
> be more like DsdvHelper?
> 
> I also don't understand your comment about using this in combination with
> PointToPointNetDevice in the manet-routing-compare.cc program; there are no
such
> devices in that program.  
> 
> Can you clarify what you mean by "Whenever I try to send via the p2p link..."?

> Does this mean that you are trying to send to an address on that link, or that
> you are binding your socket to the p2p device, or something else?
Assume that we have a node which has two net devices: one is an adhoc netdevie
and the other is a p2p netdevice. This node is connected to adhoc network
(10.1.1.0) and is also connected to some other p2p node on network (10.1.2.0)
using p2p link. If DSR is installed on this node, then even the traffic destined
to some other p2p node will be directed to DSR. The DSR will try to find a path
to the other p2p node which is on a completely different netwrok. Say the adhoc
network is 10.1.1.0 and the p2p network is 10.1.2.0 with a subnet mask
255.255.255.0. This is because the DSR is implemented as a shim between layer 4
and layer 3 and in the file dsr-helper.cc in function Create, the downtarget of
tcp, udp and icmp is set to DSR instead of IpV4. So in order to send a packet
via the p2p link you need to change the downtarget of the layer 4 protocol "tcp
for example" and set it to IPv4 and after sending you set it back to DSR. This
was the only possible work around I found.

[tomh_tomh.org, 2011-10-18 04:38:46]

On 10/17/2011 10:08 AM, alaa.alhamoud@googlemail.com wrote:
> On 2011/10/17 05:26:33, Tom Henderson wrote:
>> On 2011/10/14 05:18:28, alaa.alhamoud wrote:
>> > The implementation of DSR does not follow the model of other manets
>> > implementation in which the helper class inherits Ipv4RoutingHelper.
> Because
>> of
>> > that I was not able to use wifi netdevice which uses DSR routing in
>> combination
>> > with pointTopoint device on the same node. Whenever I try to send
> via the p2p
>> > link, it initiates a route request via DSR. Do you know how to solve
> this
>> > problem?
>
>> It seems to me that it would be easiest on future users to align the
> helper with
>> the other helpers; is there a reason why DsrMainHelper couldn't be
> rewritten to
>> be more like DsdvHelper?
>
>> I also don't understand your comment about using this in combination
> with
>> PointToPointNetDevice in the manet-routing-compare.cc program; there
> are no such
>> devices in that program.
>
>> Can you clarify what you mean by "Whenever I try to send via the p2p
> link..."?
>> Does this mean that you are trying to send to an address on that link,
> or that
>> you are binding your socket to the p2p device, or something else?
> Assume that we have a node which has two net devices: one is an adhoc
> netdevie and the other is a p2p netdevice. This node is connected to
> adhoc network (10.1.1.0) and is also connected to some other p2p node on
> network (10.1.2.0) using p2p link. If DSR is installed on this node,
> then even the traffic destined to some other p2p node will be directed
> to DSR. The DSR will try to find a path to the other p2p node which is
> on a completely different netwrok. Say the adhoc network is 10.1.1.0 and
> the p2p network is 10.1.2.0 with a subnet mask 255.255.255.0. This is
> because the DSR is implemented as a shim between layer 4 and layer 3 and
> in the file dsr-helper.cc in function Create, the downtarget of tcp, udp
> and icmp is set to DSR instead of IpV4. So in order to send a packet via
> the p2p link you need to change the downtarget of the layer 4 protocol
> "tcp for example" and set it to IPv4 and after sending you set it back
> to DSR. This was the only possible work around I found.
>

There is a callback that hooks NotifyInterfaceUp() in the static routing 
code (actually, the Ipv4ListRouting object will hook this and then call 
NotifyInterfaceUp() in all the protocols in the list).  So, if you use 
DsrRouting with ListRouting and Ipv4StaticRouting, and you insert Dsr at 
a priority lower than Ipv4StaticRouting, what should happen is that when 
the transport protocol calls RouteOutput() for an on-link address, the 
Ipv4StaticRouting route will match first and a call to DSR can be avoided.

Are you using DSR in conjunction with Ipv4ListRouting and 
Ipv4StaticRouting, and is DSR at a lower priority than Ipv4StaticRouting?

- Tom

[Alaa Alhamoud, 2011-10-19 20:01:40]

On 2011/10/18 04:38:46, tomh_tomh.org wrote:
> On 10/17/2011 10:08 AM, mailto:alaa.alhamoud@googlemail.com wrote:
> > On 2011/10/17 05:26:33, Tom Henderson wrote:
> >> On 2011/10/14 05:18:28, alaa.alhamoud wrote:
> >> > The implementation of DSR does not follow the model of other manets
> >> > implementation in which the helper class inherits Ipv4RoutingHelper.
> > Because
> >> of
> >> > that I was not able to use wifi netdevice which uses DSR routing in
> >> combination
> >> > with pointTopoint device on the same node. Whenever I try to send
> > via the p2p
> >> > link, it initiates a route request via DSR. Do you know how to solve
> > this
> >> > problem?
> >
> >> It seems to me that it would be easiest on future users to align the
> > helper with
> >> the other helpers; is there a reason why DsrMainHelper couldn't be
> > rewritten to
> >> be more like DsdvHelper?
> >
> >> I also don't understand your comment about using this in combination
> > with
> >> PointToPointNetDevice in the manet-routing-compare.cc program; there
> > are no such
> >> devices in that program.
> >
> >> Can you clarify what you mean by "Whenever I try to send via the p2p
> > link..."?
> >> Does this mean that you are trying to send to an address on that link,
> > or that
> >> you are binding your socket to the p2p device, or something else?
> > Assume that we have a node which has two net devices: one is an adhoc
> > netdevie and the other is a p2p netdevice. This node is connected to
> > adhoc network (10.1.1.0) and is also connected to some other p2p node on
> > network (10.1.2.0) using p2p link. If DSR is installed on this node,
> > then even the traffic destined to some other p2p node will be directed
> > to DSR. The DSR will try to find a path to the other p2p node which is
> > on a completely different netwrok. Say the adhoc network is 10.1.1.0 and
> > the p2p network is 10.1.2.0 with a subnet mask 255.255.255.0. This is
> > because the DSR is implemented as a shim between layer 4 and layer 3 and
> > in the file dsr-helper.cc in function Create, the downtarget of tcp, udp
> > and icmp is set to DSR instead of IpV4. So in order to send a packet via
> > the p2p link you need to change the downtarget of the layer 4 protocol
> > "tcp for example" and set it to IPv4 and after sending you set it back
> > to DSR. This was the only possible work around I found.
> >
> 
> There is a callback that hooks NotifyInterfaceUp() in the static routing 
> code (actually, the Ipv4ListRouting object will hook this and then call 
> NotifyInterfaceUp() in all the protocols in the list).  So, if you use 
> DsrRouting with ListRouting and Ipv4StaticRouting, and you insert Dsr at 
> a priority lower than Ipv4StaticRouting, what should happen is that when 
> the transport protocol calls RouteOutput() for an on-link address, the 
> Ipv4StaticRouting route will match first and a call to DSR can be avoided.
> 
> Are you using DSR in conjunction with Ipv4ListRouting and 
> Ipv4StaticRouting, and is DSR at a lower priority than Ipv4StaticRouting?
> 
> - Tom
Actually I am a newbie in ns-3 so that I might make some silly mistakes. I tried
to use DSR in conjunction with Ipv4ListRouting and Ipv4StaticRouting but the
problem is that DsrRouting inherits Ipv4L4Protocol not Ipv4RoutingProtocol as
the other routing protocol, so that I was not able to add it to Ipv4ListRouting.
-Alaa

[Guillermo Gala, 2011-10-26 22:11:08]

I want to probe DSR routing protocol, but when i use the above code the result
is:

../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
ns3::dsr::DsrRouting::SendRerrWhenBreaksLinkToNextHop(ns3::Ipv4Address,
uint8_t)’:
../src/dsr/model/dsr-routing.cc:593:14: error: se define la variable ‘source’
pero no se usa [-Werror=unused-but-set-variable]
../src/dsr/model/dsr-routing.cc: En la función miembro ‘bool
ns3::dsr::DsrRouting::PromiscReceive(ns3::Ptr<ns3::NetDevice>, ns3::Ptr<const
ns3::Packet>, uint16_t, const ns3::Address&, const ns3::Address&,
ns3::NetDevice::PacketType)’:
../src/dsr/model/dsr-routing.cc:858:10: error: se define la variable
‘optionLength’ pero no se usa [-Werror=unused-but-set-variable]
../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
ns3::dsr::DsrRouting::PacketScheduleTimerExpire(ns3::dsr::MaintainBuffEntry&,
const ns3::dsr::PacketKey&, uint8_t, bool)’:
../src/dsr/model/dsr-routing.cc:1632:14: error: se define la variable ‘dst’ pero
no se usa [-Werror=unused-but-set-variable]
../src/dsr/model/dsr-options.cc: En la función miembro ‘virtual uint8_t
ns3::dsr::DsrOptionRreq::Process(ns3::Ptr<ns3::Packet>, ns3::Ptr<ns3::Packet>,
ns3::Ipv4Address, const ns3::Ipv4Header&, uint8_t, bool&)’:
../src/dsr/model/dsr-options.cc:456:7: error: se define la variable ‘isError’
pero no se usa [-Werror=unused-but-set-variable]
../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
ns3::dsr::DsrRouting::RouteRequestTimerExpire(ns3::Ptr<ns3::Packet>,
ns3::Ipv4Address, ns3::Ipv4Address, uint8_t)’:
../src/dsr/model/dsr-routing.cc:1963:16: error:
‘((ns3::dsr::DsrRouting*)this)->ns3::dsr::DsrRouting::EraseRreqTimer’ no tiene
un tipo de clase
../src/dsr/model/dsr-options.cc: En la función miembro ‘virtual uint8_t
ns3::dsr::DsrOptionRerr::Process(ns3::Ptr<ns3::Packet>, ns3::Ptr<ns3::Packet>,
ns3::Ipv4Address, const ns3::Ipv4Header&, uint8_t, bool&)’:
../src/dsr/model/dsr-options.cc:1259:14: error: se define la variable
‘srcAddress’ pero no se usa [-Werror=unused-but-set-variable]
../src/dsr/model/dsr-options.cc:1260:14: error: se define la variable
‘destAddress’ pero no se usa [-Werror=unused-but-set-variable]
../src/dsr/model/dsr-options.cc: En la función miembro ‘uint8_t
ns3::dsr::DsrOptionRerr::DoSendError(ns3::Ptr<ns3::Packet>,
ns3::dsr::DsrOptionRerrUnreachHeader&, uint32_t, ns3::Ipv4Address, uint8_t)’:
../src/dsr/model/dsr-options.cc:1361:14: error: se define la variable
‘rerrUnreach’ pero no se usa [-Werror=unused-but-set-variable]
cc1plus: todos los avisos se tratan como errores

cc1plus: todos los avisos se tratan como errores

Anyone has the same problem?

[Tom Henderson, 2011-11-25 15:04:40]

On 2011/10/26 22:11:08, valentinosnake wrote:
> I want to probe DSR routing protocol, but when i use the above code the result
> is:
> 
> ../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
> ns3::dsr::DsrRouting::SendRerrWhenBreaksLinkToNextHop(ns3::Ipv4Address,
> uint8_t)’:
> ../src/dsr/model/dsr-routing.cc:593:14: error: se define la variable ‘source’
> pero no se usa [-Werror=unused-but-set-variable]
> ../src/dsr/model/dsr-routing.cc: En la función miembro ‘bool
> ns3::dsr::DsrRouting::PromiscReceive(ns3::Ptr<ns3::NetDevice>, ns3::Ptr<const
> ns3::Packet>, uint16_t, const ns3::Address&, const ns3::Address&,
> ns3::NetDevice::PacketType)’:
> ../src/dsr/model/dsr-routing.cc:858:10: error: se define la variable
> ‘optionLength’ pero no se usa [-Werror=unused-but-set-variable]
> ../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
> ns3::dsr::DsrRouting::PacketScheduleTimerExpire(ns3::dsr::MaintainBuffEntry&,
> const ns3::dsr::PacketKey&, uint8_t, bool)’:
> ../src/dsr/model/dsr-routing.cc:1632:14: error: se define la variable ‘dst’
pero
> no se usa [-Werror=unused-but-set-variable]
> ../src/dsr/model/dsr-options.cc: En la función miembro ‘virtual uint8_t
> ns3::dsr::DsrOptionRreq::Process(ns3::Ptr<ns3::Packet>, ns3::Ptr<ns3::Packet>,
> ns3::Ipv4Address, const ns3::Ipv4Header&, uint8_t, bool&)’:
> ../src/dsr/model/dsr-options.cc:456:7: error: se define la variable ‘isError’
> pero no se usa [-Werror=unused-but-set-variable]
> ../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
> ns3::dsr::DsrRouting::RouteRequestTimerExpire(ns3::Ptr<ns3::Packet>,
> ns3::Ipv4Address, ns3::Ipv4Address, uint8_t)’:
> ../src/dsr/model/dsr-routing.cc:1963:16: error:
> ‘((ns3::dsr::DsrRouting*)this)->ns3::dsr::DsrRouting::EraseRreqTimer’ no tiene
> un tipo de clase
> ../src/dsr/model/dsr-options.cc: En la función miembro ‘virtual uint8_t
> ns3::dsr::DsrOptionRerr::Process(ns3::Ptr<ns3::Packet>, ns3::Ptr<ns3::Packet>,
> ns3::Ipv4Address, const ns3::Ipv4Header&, uint8_t, bool&)’:
> ../src/dsr/model/dsr-options.cc:1259:14: error: se define la variable
> ‘srcAddress’ pero no se usa [-Werror=unused-but-set-variable]
> ../src/dsr/model/dsr-options.cc:1260:14: error: se define la variable
> ‘destAddress’ pero no se usa [-Werror=unused-but-set-variable]
> ../src/dsr/model/dsr-options.cc: En la función miembro ‘uint8_t
> ns3::dsr::DsrOptionRerr::DoSendError(ns3::Ptr<ns3::Packet>,
> ns3::dsr::DsrOptionRerrUnreachHeader&, uint32_t, ns3::Ipv4Address, uint8_t)’:
> ../src/dsr/model/dsr-options.cc:1361:14: error: se define la variable
> ‘rerrUnreach’ pero no se usa [-Werror=unused-but-set-variable]
> cc1plus: todos los avisos se tratan como errores
> 
> cc1plus: todos los avisos se tratan como errores
> 
> Anyone has the same problem?

This is a gcc-4.6 issue; gcc-4.6 may never have been used on this code yet. 
Either delete these unused variables, or pass the -Wno-unused-but-set-variable
flag in waf such as is already done in the top-level wscript:

    add_gcc_flag('-Wno-error=deprecated-declarations')
+   add_gcc_flag('-Wno-unused-but-set-variable')

[Guillermo Gala, 2011-11-29 22:19:07]

On 2011/11/25 15:04:40, Tom Henderson wrote:
> On 2011/10/26 22:11:08, valentinosnake wrote:
> > I want to probe DSR routing protocol, but when i use the above code the
result
> > is:
> > 
> > ../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
> > ns3::dsr::DsrRouting::SendRerrWhenBreaksLinkToNextHop(ns3::Ipv4Address,
> > uint8_t)’:
> > ../src/dsr/model/dsr-routing.cc:593:14: error: se define la variable
‘source’
> > pero no se usa [-Werror=unused-but-set-variable]
> > ../src/dsr/model/dsr-routing.cc: En la función miembro ‘bool
> > ns3::dsr::DsrRouting::PromiscReceive(ns3::Ptr<ns3::NetDevice>,
ns3::Ptr<const
> > ns3::Packet>, uint16_t, const ns3::Address&, const ns3::Address&,
> > ns3::NetDevice::PacketType)’:
> > ../src/dsr/model/dsr-routing.cc:858:10: error: se define la variable
> > ‘optionLength’ pero no se usa [-Werror=unused-but-set-variable]
> > ../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
> >
ns3::dsr::DsrRouting::PacketScheduleTimerExpire(ns3::dsr::MaintainBuffEntry&,
> > const ns3::dsr::PacketKey&, uint8_t, bool)’:
> > ../src/dsr/model/dsr-routing.cc:1632:14: error: se define la variable ‘dst’
> pero
> > no se usa [-Werror=unused-but-set-variable]
> > ../src/dsr/model/dsr-options.cc: En la función miembro ‘virtual uint8_t
> > ns3::dsr::DsrOptionRreq::Process(ns3::Ptr<ns3::Packet>,
ns3::Ptr<ns3::Packet>,
> > ns3::Ipv4Address, const ns3::Ipv4Header&, uint8_t, bool&)’:
> > ../src/dsr/model/dsr-options.cc:456:7: error: se define la variable
‘isError’
> > pero no se usa [-Werror=unused-but-set-variable]
> > ../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
> > ns3::dsr::DsrRouting::RouteRequestTimerExpire(ns3::Ptr<ns3::Packet>,
> > ns3::Ipv4Address, ns3::Ipv4Address, uint8_t)’:
> > ../src/dsr/model/dsr-routing.cc:1963:16: error:
> > ‘((ns3::dsr::DsrRouting*)this)->ns3::dsr::DsrRouting::EraseRreqTimer’ no
tiene
> > un tipo de clase
> > ../src/dsr/model/dsr-options.cc: En la función miembro ‘virtual uint8_t
> > ns3::dsr::DsrOptionRerr::Process(ns3::Ptr<ns3::Packet>,
ns3::Ptr<ns3::Packet>,
> > ns3::Ipv4Address, const ns3::Ipv4Header&, uint8_t, bool&)’:
> > ../src/dsr/model/dsr-options.cc:1259:14: error: se define la variable
> > ‘srcAddress’ pero no se usa [-Werror=unused-but-set-variable]
> > ../src/dsr/model/dsr-options.cc:1260:14: error: se define la variable
> > ‘destAddress’ pero no se usa [-Werror=unused-but-set-variable]
> > ../src/dsr/model/dsr-options.cc: En la función miembro ‘uint8_t
> > ns3::dsr::DsrOptionRerr::DoSendError(ns3::Ptr<ns3::Packet>,
> > ns3::dsr::DsrOptionRerrUnreachHeader&, uint32_t, ns3::Ipv4Address,
uint8_t)’:
> > ../src/dsr/model/dsr-options.cc:1361:14: error: se define la variable
> > ‘rerrUnreach’ pero no se usa [-Werror=unused-but-set-variable]
> > cc1plus: todos los avisos se tratan como errores
> > 
> > cc1plus: todos los avisos se tratan como errores
> > 
> > Anyone has the same problem?
> 
> This is a gcc-4.6 issue; gcc-4.6 may never have been used on this code yet. 
> Either delete these unused variables, or pass the -Wno-unused-but-set-variable
> flag in waf such as is already done in the top-level wscript:
> 
>     add_gcc_flag('-Wno-error=deprecated-declarations')
> +   add_gcc_flag('-Wno-unused-but-set-variable')

Hi Tom,

after add the line above I get this:

../src/dsr/model/dsr-routing.cc: En la función miembro ‘void
ns3::dsr::DsrRouting::RouteRequestTimerExpire(ns3::Ptr<ns3::Packet>,
ns3::Ipv4Address, ns3::Ipv4Address, uint8_t)’:
../src/dsr/model/dsr-routing.cc:1963:16: error:
‘((ns3::dsr::DsrRouting*)this)->ns3::dsr::DsrRouting::EraseRreqTimer’ no tiene
un tipo de clase

Regards