Bug 2440 - SocketIpTosTag might be added twice if a packet is sent multiple times
SocketIpTosTag might be added twice if a packet is sent multiple times
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: internet
ns-3-dev
PC Linux
: P5 minor
Assigned To: Tommaso Pecorella
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-15 07:12 UTC by Stefano Avallone
Modified: 2016-06-15 10:19 UTC (History)
1 user (show)

See Also:


Attachments
Proposed fix (3.24 KB, patch)
2016-06-15 07:12 UTC, Stefano Avallone
Details | Diff
Proposed fix v2 (581 bytes, patch)
2016-06-15 10:01 UTC, Stefano Avallone
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefano Avallone 2016-06-15 07:12:34 UTC
Created attachment 2472 [details]
Proposed fix

How to reproduce this bug:

just let UdpSocketImpl::DoSendTo always add a SocketIpToS tag by commenting out the condition if (IsManualIpTos ()) (to mimic the case in which a TOS is set). The result is that simple-point-to-point-olsr, mixed-wireless and ipv4-rip crash because we attempt to add a SocketIpTosTag twice.

I found that this issue arises when a packet is sent multiple times. For instance, OLSR sends the same OLSR packet via an UDP socket as many times as the number of interfaces. The reason is that UdpSocketImpl::DoSendTo adds the SocketIpTosTag to the packet but then sends a copy of the packet. Thus, Ipv4L3Protocol removes the tag from the copy of the packet, hence the original packet still has the tag attached. If the (original) packet is sent again (as is the case with OLSR -- and RIP I assume -- packets), an attempt is made to add another SocketIpTos tag to the packet, thus crashing the example.

I propose that the SocketIpTos tag be added to the copy of the packet, just before  passing the copy of the packet to the UdpL4Protocol. This approach is implemented by the attached patch, which makes all the tests pass again (regardless of whether the IsManualIpTos () checks are commented or not).
Comment 1 Tommaso Pecorella 2016-06-15 09:14:54 UTC
Another option is to use ReplacePacketTag. Both solutions are fine by me.
Comment 2 Stefano Avallone 2016-06-15 10:01:26 UTC
Created attachment 2473 [details]
Proposed fix v2
Comment 3 Stefano Avallone 2016-06-15 10:03:01 UTC
I think using ReplacePacketTag is a better option, as it doesn't clutter the current code (and leads to a one-line patch). I didn't think of it, thanks for suggesting.

If you prefer, I can take care of committing the proposed patch v2.
Comment 4 Tommaso Pecorella 2016-06-15 10:04:21 UTC
(In reply to Stefano Avallone from comment #3)
> I think using ReplacePacketTag is a better option, as it doesn't clutter the
> current code (and leads to a one-line patch). I didn't think of it, thanks
> for suggesting.
> 
> If you prefer, I can take care of committing the proposed patch v2.

Feel free to go ahead, thanks.
Comment 5 Stefano Avallone 2016-06-15 10:19:29 UTC
Pushed with changeset 12161:09c730bb82be, thanks!