|
Bugzilla – Full Text Bug Listing |
| Summary: | IPv6 fragmentation not handled correctly | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tommaso Pecorella <tommaso.pecorella> |
| Component: | internet | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
Fixes to IPv6 fragmentation are available at; http://codereview.appspot.com/4440051/ The patch does contain also the fixes for IPv4 fragmentation. Fixed with revision 7367 |
Two separate issues, but close enough to need one single handler. Both are related to this function: uint8_t Ipv6ExtensionFragment::Process (Ptr<Packet>& packet, uint8_t offset, Ipv6Header const& ipv6Header, Ipv6Address dst, uint8_t *nextHeader, bool& isDropped) found in ipv6-extension.cc 1st one: when a fragment is received but it's not the last fragment (as is, more are expected), it's called: NS_LOG_LOGIC ("Fragment. Drop!"); m_dropTrace (packet); This doesn't seems the correct behaviour, as the fragment is not really dropped. This might lead to completely wrong statistics. 2nd one: I have not found any method to "clean" the fragment buffer when a fragment is lost in space/time. If this is true, a long simulation might have memory issues (i.e., the buffer will keep increasing). I know that fragmentation should not really happen in IPv6, but still...