GSOC2025IcmpSocket: Difference between revisions

From Nsnam
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 9: Line 9:
* '''Mentors:''' Tommaso Pecorella and Alberto Gallegos Ramonet
* '''Mentors:''' Tommaso Pecorella and Alberto Gallegos Ramonet
* '''Google page:'''  
* '''Google page:'''  
* '''Project Goals: Develop an ICMP socket according to LINUX implementation of ICMP SOCK_DGRAM and SOCK_RAW'''  
* '''Project Goals: Develop an ICMP socket according to LINUX implementation of ICMP SOCK_DGRAM. Currently, for sending ICMP packets, the application has to use a Raw socket. This results in having the user write all the code for adding the headers, the filtering, etc. The proposed ICMP socket aims to offload all this functionality from the user and provide the user with API's required for sending and receiving packets, filtering etc.'''  
* '''Repository:'''  
* '''Repo:''' https://gitlab.com/ADI-ROXX/ns-3-dev
* '''About Me:'''


* '''Design Document:'''
= Milestones =
Some highlights about the SOCK_DGRAM socket:
'''Phase 1: Fix the fragmentation issue in Raw sockets'''
 
[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2486 Merge Request] 
1. This is an L3 socket because ICMP is an L3 aspect, unlike UDP, TCP because it neither does it have any role in Transport functionality, nor does it do port-to-port mapping like previously mentioned L4 protocols.
* '''Changes made:''' 
 
** '''Forward assembled packets:''' In case of '''raw sockets''', forward the packet up to the '''application''' after the '''re-assembly''', not before that (existing implementation)
2. The user can only send ECHO_REQUEST. The other types of packets cannot be sent.
** '''Test cases:''' Wrote the test case for '''IPv4''' and '''IPv6 Raw sockets''' that ensure that only a single assembled packet is received. Also, included the test cases for '''Ping application''' with fragmentation.
 
3. The user may be notified only about ECHO_REPLY and ERRORS. For that, the user has to setRecvCallback and setErrorCallback (new).
 
setErrorCallback is a new function that is introduced for this specific socket. This will correctly mimic the error queue icmp socket. If wanted, setErrorCallback can be removed and we can have a single setRecvCallback and the user will have to check the packet received whether is it an error or not.
 
Let's see the ICMP v4 socket:
 
'''Now, let's go over the functions:'''
 
1. '''bind():''' Sets the local address of the socket. Just like other sockets.
 
2. '''connect()''': Sets the destination address for the packet. Again, just like other sockets.
 
3. '''close()''': Free up the socket. Just like other sockets.


'''Phase 2: Implementation of the ICMP socket''' 
[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2527 Merge Request] 
* '''Changes''' 
** '''ICMP error messages:''' Integrated support for sending '''ICMP Destination Unreachable''' messages from the '''IP layer''' upon packet drop. 
** '''ICMP socket:''' Implemented a dedicated '''ICMP socket''', the '''LLD''' of which is similar to that of the '''UDP socket'''. 
** '''Features:''' 
*** '''ICMP handling:''' The responsibility for processing '''ICMP headers''' is completely offloaded from the application. The new socket no longer sends the '''ICMP header''' to the application (unlike raw sockets). Rather, it uses '''IcmpPacketInfoTag''' for the same. 
*** '''New Packet Tag implemented:''' Introduced a new '''IcmpPacketInfoTag''' that stores '''metadata''' about the '''ICMP packet''' received to be sent up to the application. 


** '''Tests:''' Added '''unit tests''' for validating ICMP functionality covering almost all of the '''ICMP types''' for received packet ('''echo reply, destination unreachable, time exceeded, etc.''') 
** '''Ping application:''' Integrated the novel '''ICMP socket''' in the '''Ping application'''. Allowed for the user to choose whether to send packets via '''ICMP socket''' or via '''Raw Sockets'''. 


4. '''send()''': The application will call this function to send packet. This is the function responsible for adding the icmp and then passing it to the ip protocol.
* '''Limitations and proposed solutions'''
 
** '''SO_REUSEADDR:''' The novel '''ICMP socket''' does not allow for two sockets on the same node to be bound to the same '''identifier''' even if they are bound to different '''IP addresses'''. This can be solved by using a '''map(identifier -> List of ICMP sockets)''' instead of the current implementation '''map(identifier -> ICMP socket)'''. 
5. '''receive()''': It receives a packet. It then gets the type of packet: req, reply, ttl exceeded or dest unreach. It then calls the specific handler.
** '''Identifier map in Protocol layer:''' The current '''LLD''' of the socket states to store the '''map of used identifiers''' in the '''protocol layer'''. This kind-of pollutes the '''ICMP protocol'''. To solve this, an '''unordered set''' can be stored in the '''IcmpSocketFactory''' object to store all the '''identifiers''' already used for a particular '''node'''.
 
6. '''handle_echo_request()''': It creates an icmp echo reply with the same payload and sends it back to the sender. THIS PACKET IS NOT SENT UP TO THE APPLICATION.
 
7. '''handle_echo_reply()''': It sends the echo_reply up to the application. It calls the m_receivedCallback function, if set by the application using setRecvCallback.
 
8. '''handle_ttl_exceeded()''': It sends the ttl error up to the application. It calls the m_ErrorCallback function, if set by the user using setErrorCallback.
 
9. '''handle_dest_unreach()''': Just like handle_ttl_exceeded but for dest_unreach packet.
 
10. '''setRecvCallback, setErrorCallback''' will be used to set the m_receivedCallback and m_ErrorCallback respectively.
 
= Milestones =

Latest revision as of 05:28, 31 August 2025

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Back to GSoC 2025 projects

Project Overview

  • Project Name: ICMP socket and generate/handle ICMP messages (host/net unreachable)
  • Student: Aditya Ruhela
  • Mentors: Tommaso Pecorella and Alberto Gallegos Ramonet
  • Google page:
  • Project Goals: Develop an ICMP socket according to LINUX implementation of ICMP SOCK_DGRAM. Currently, for sending ICMP packets, the application has to use a Raw socket. This results in having the user write all the code for adding the headers, the filtering, etc. The proposed ICMP socket aims to offload all this functionality from the user and provide the user with API's required for sending and receiving packets, filtering etc.
  • Repo: https://gitlab.com/ADI-ROXX/ns-3-dev

Milestones

Phase 1: Fix the fragmentation issue in Raw sockets Merge Request

  • Changes made:
    • Forward assembled packets: In case of raw sockets, forward the packet up to the application after the re-assembly, not before that (existing implementation)
    • Test cases: Wrote the test case for IPv4 and IPv6 Raw sockets that ensure that only a single assembled packet is received. Also, included the test cases for Ping application with fragmentation.

Phase 2: Implementation of the ICMP socket Merge Request

  • Changes
    • ICMP error messages: Integrated support for sending ICMP Destination Unreachable messages from the IP layer upon packet drop.
    • ICMP socket: Implemented a dedicated ICMP socket, the LLD of which is similar to that of the UDP socket.
    • Features:
      • ICMP handling: The responsibility for processing ICMP headers is completely offloaded from the application. The new socket no longer sends the ICMP header to the application (unlike raw sockets). Rather, it uses IcmpPacketInfoTag for the same.
      • New Packet Tag implemented: Introduced a new IcmpPacketInfoTag that stores metadata about the ICMP packet received to be sent up to the application.
    • Tests: Added unit tests for validating ICMP functionality covering almost all of the ICMP types for received packet (echo reply, destination unreachable, time exceeded, etc.)
    • Ping application: Integrated the novel ICMP socket in the Ping application. Allowed for the user to choose whether to send packets via ICMP socket or via Raw Sockets.
  • Limitations and proposed solutions
    • SO_REUSEADDR: The novel ICMP socket does not allow for two sockets on the same node to be bound to the same identifier even if they are bound to different IP addresses. This can be solved by using a map(identifier -> List of ICMP sockets) instead of the current implementation map(identifier -> ICMP socket).
    • Identifier map in Protocol layer: The current LLD of the socket states to store the map of used identifiers in the protocol layer. This kind-of pollutes the ICMP protocol. To solve this, an unordered set can be stored in the IcmpSocketFactory object to store all the identifiers already used for a particular node.
Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=GSOC2025IcmpSocket&oldid=13687"