0

I recently encountered a scenario where in I find that ICMP network unreachable [type-1, code-3- meaning destination unreachable, which is correct w.r.t trace route working, refer rfc link below] packet is getting dropped only when bytes sent exceeds 'X' [certain] bytes.

** Check this RFC, section 3.1 - https://www.rfc-editor.org/rfc/rfc4443#section-3.1 **

For example [source: FreeBSD based trace route code],

i = sendto(sndsock, (char *)outpacket,outpacketlength, 0,
           (struct sockaddr *)&Dst, Dst.sin6_len); // to send packet of length "outpacketlength", from source buffer "outpacket" and to destination "Dst".
...
retval = recvmsg(rcvsock, mhdr, 0); // use recvmsg for receiving reply.

Question

  • When I malloc and send 'X' bytes of data, I get reply received in receive buffer.But, not greater than that limit. i.e, retval is always 0 when "outpacketlen" is greater 'X' bytes, even though you malloc and reset the buffer for 'X' bytes. But, with packet capture I see packet received in my host. Meaning, I receive packet but not in receive buffer. How/When is this possible [Any malformed packet info?]?

  • How can I go about debugging this issue?

  • Is there a tool that can use to debug such a scenario? I used "truss" utility in BSD. Are there better way of handling this?

  • How should I go about investigating the packets lost between interface and application? What tools/utilities/technique would be efficient choice based on your experience?

Am I missing something? Thanks for your time and inputs. I appreciate it.

Community
  • 1
  • 1
smaven
  • 21
  • 3

2 Answers2

1

You need to work with Wireshark and investigate if you are sending your packets correctly. Put a breakpoint just before the sendto and see what happens.

HAL9000
  • 3,562
  • 3
  • 25
  • 47
  • thanks HAL9000, for your suggestion. I did packet capture via tcpdump and investigated captured packets via "Wireshark", it looks like send/receive packets from packet capture looks fine. In fact, I do receive packets from the wire. But, somewhere between the interface and application packet is getting dropped I guess. So, I'm not really sure on my next step here. What would be your best advice here? – smaven Dec 13 '13 at 22:46
0

Is the packet you are referring to as "being dropped between interface and application" the ICMP error message for destination unreachable? ICMP errors are usually not delivered to the application that sent the packet triggering the error. I guess the logic there is, that "regular" applications using UDP or TCP cant be assumed to prepare for receiving every kind of ICMP error out of the blue inside their application protocol stream.

You dont mention your specific platform, but I am assuming (out of my hat) FreeBSD. On that platform I think you have to use raw IP sockets, if you want to receive ICMP errors. I could be wrong, or you might be on another BSD variant, so check your IP protocol man-pages for suitable socket options.

In Linux you could receive this packet by setting the IP_RECVERR socket option and then calling recvmsg()with the flag MSG_ERRQUEUE. See e.g. Read ICMP payload from a recvmsg with MSG_ERRQUEUE flag

Community
  • 1
  • 1
thuovila
  • 1,960
  • 13
  • 21
  • Thanks @thuovila. Let me give a try with this flag set.Added flavor of BSD I'm using to original post. One question I'm not sure is, how come I could see/get response for packet of size lesser than 'X' bytes but not this, knowing the fact that other reply messages are also same ICMP messages? Just that I'm not clear, may be I'm missing something.. – smaven Dec 14 '13 at 19:45
  • It was not obvious to me from you post, that you are already using raw sockets to send ICMP. I suggest you make your question more detailed, i.e. include a small working piece of code that trigegrs the behaviour you describe. I doubt the Linux flag will work on *BSD. – thuovila Dec 14 '13 at 20:25