Bug 1843 - IPv6 extensions dropped packets do not fire L3 drop trace
IPv6 extensions dropped packets do not fire L3 drop trace
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: ipv6
ns-3-dev
All All
: P5 enhancement
Assigned To: Tommaso Pecorella
:
Depends on:
Blocks: 1818
  Show dependency treegraph
 
Reported: 2014-01-24 03:27 EST by Tommaso Pecorella
Modified: 2014-03-17 14:57 EDT (History)
2 users (show)

See Also:


Attachments
Patch (option 1) (26.97 KB, application/octet-stream)
2014-01-24 03:27 EST, Tommaso Pecorella
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tommaso Pecorella 2014-01-24 03:27:05 EST
Created attachment 1768 [details]
Patch (option 1)

Currently we have a glitch in IPv6 dropped packets handling.

If the packet is dropped "normally", then the Ipv6L3Protocol::m_dropTrace is called.
If the packet is dropped because an extension is "bad", then Ipv6Extension::m_dropTrace is called.

Now the problem is twofold.
1) it is not obvious that both traces should be hooked, and
2) Ipv6Extension::m_dropTrace does not have the same parameters as the other one.
In particular, the drop cause is missing, plus a lot of other things.

In order to fix it, two things might be done:
1) kill Ipv6Extension::m_dropTrace and have Ipv6L3Protocol::m_dropTrace called instead.
2) leave Ipv6Extension::m_dropTrace but call Ipv6L3Protocol::m_dropTrace as well.
3) modify Ipv6Extension::m_dropTrace to have the same info as Ipv6L3Protocol::m_dropTrace.

Cons:
1) might break existing simulations.
2) might produce funny results (i.e., drops counted twice)
3) is still not obvious. People might forget about drops in extensions.

Of the three options I prefer the first. It's intrusive, but at least people will be forced to use the right things.
Comment 1 Tom Henderson 2014-03-17 09:01:44 EDT
Looks good.
Comment 2 Tommaso Pecorella 2014-03-17 14:57:17 EDT
changeset 10669	46c9391bc38b