Possible bug: Ipv4RawSocket No ICMPV4_TIME_EXCEEDED response.

[Jack Higgins]

Dear all,

I'm trying to implement an  ipV4 traceroute application (using ns-3  v3.28). 

This can be easily achieved by some modifications to the v4ping application.

In previous ns-3 versions changing the socket IpTttl did not have any effect but this bug have 

been addressed and discussed here for the same traceroute application:

Using Ipv4RawSocket to change IpTtl doesn't work?

Now, sending a  ICMPV4_ECHO with an ipTTl to 1 does send an ip header with TTL =1 but the receiving node does not reply with an  ICMPV4_TIME_EXCEEDED

 ( or ICMPV4_DEST_UNREACH in some cases). I don't know if this is because the receiving node drops the packet without replying, or because  the source node filters the

 ICMPV4_TIME_EXCEEDED type packets when receiving a reply.

Is there any filter on that I am not aware of , or the  ICMPV4_TIME_EXCEEDED packet reply are not handled correctly?

This can be easily tested by modifying  /internet-apps/model/v4ping.cc

in the V4Ping::StartApplication (void) adding the line:

m_socket->SetIpTttl(1);

By setting this, the receive function (V4Ping::Receive (Ptr<Socket> socket))

should only receive packets with the header ICMPV4_TIME_EXCEEDED, but no packets are received (icmp->getType == ICMPV4_TIME_EXCEEDED).

I used model/aodv/examples/aodv.cc  as the scenario file to test the modified ping application

Any guidance would be much appreciated.

Sincerely,

Alberto  G.

[Jack Higgins]

This is definitely a bug, or should I say an ignored feature?

ICMP_ECHO messages with TTL = 1 are not handle correctly in ipv4-l3-protocol.cc. According to the standard the ICMP_ECHO messages with TTL = 1

should be forward back to the source message with a header ICMPV4_TIME_EXCEEDED.

The current ns-3 implementation just drops them as soon as they are received.

In Ipv4L3Protocol::IpForward :

 if (ipHeader.GetTtl () == 0)

    {

      // Do not reply to ICMP or to multicast/broadcast IP address   // WHY???!

      if (ipHeader.GetProtocol () != Icmpv4L4Protocol::PROT_NUMBER &&

          ipHeader.GetDestination ().IsBroadcast () == false &&

          ipHeader.GetDestination ().IsMulticast () == false)

        {

          Ptr<Icmpv4L4Protocol> icmp = GetIcmp ();

          icmp->SendTimeExceededTtl (ipHeader, packet, false);

        }

      NS_LOG_WARN ("TTL exceeded.  Drop.");

      m_dropTrace (header, packet, DROP_TTL_EXPIRED, m_node->GetObject<Ipv4> (), interface);

      return;

    }

Blocking or allowing ICMP response traffic should be an option in the ICMP protocol not just plain dropped.

Additionally to receive ICMP_TIME_EXCEEDED  response in, ipv4-raw-socket-impl.cc , the following condition in Ipv4RawSocketImpl::ForwardUp  blocks the reception of 

TTL_TIME_EXCEEDED response packets.

  if ((m_src == Ipv4Address::GetAny () || ipHeader.GetDestination () == m_src) &&

      (m_dst == Ipv4Address::GetAny () || ipHeader.GetSource () == m_dst) && 

      ipHeader.GetProtocol () == m_protocol)

This is because the  ICMP_TIME_EXCEEED IP header source is not the same as the m_dst  (m_dst doesn't have the correct value.

I haven't figure out exactly why, or what is the best approach to patch for this.

I hope some maintainers out there have some mercy and respond to this message or make a fix of this. 

(still waiting on the bugzilla account response to report this....)

Some feedback or comments please.