Enable IPv6 in pping

Registered by Morten Brekkevold

NAV supports collecting information about IPv6 addresses and prefixes, but does not yet support communication over IPv6. A first step to make NAV more IPv6-compatible would be to enable ICMPv6 ECHO requests in the pping daemon.

Blueprint information

Morten Brekkevold
Morten Brekkevold
Christian Strand Young
Series goal:
Accepted for 3.10
Milestone target:
milestone icon 3.10.0
Started by
Christian Strand Young
Completed by
Morten Brekkevold

Related branches



Update upon release: http://metanav.uninett.no/backendprocesses?s[]=pping#pping

Algorithm is the only thing that needs updating, and maybe a notice of the ipv6 support in some way :)


pping has three threads:
  1. Thread 1 generates and sends out the icmp packets.
  2. Thread 2 receives echo replies, checks the signature and stores the result to RRD.
  3. The main thread does the main scheduling and reports to the event queue.

Thread 1 works this way:
  FOR every host DO:
    1. Check if the host address is v6 or v4, assign correct socket in scope
    2. Generate an icmp echo packet with: (destination IP, timestamp, signature).
    3. Send the icmp echo.
    4. Add host to the "Waiting for response" queue.
    5. Sleep in the configured ''delay'' ms (default 2 ms). This delay will spread out the response times, which in
       turn reduces the receive thread queue and will in effect make the measured response time more accurate.

Thread 2 works this way:
  As long as thread 1 is operating and as long as we have hosts in the "Waiting for response" queue, with a
  timout of 5 seconds (configurable):
    1. Check if we have received packets
    2. Find out what socket has received packet
    2. Get the data (the icmp reply packet)
    3. Verify that the packet is to our pid. If not, discard.
    4. Extract the unique identity from the payload of the packet.
    5. If the identity matches a key in "Waiting for response" queue, update response time for the host and
       remove the host from the "Waiting for response" queue.

When thread 2 finishes the sweep is over. If hosts are remaining on the "Waiting for response" queue, we set
response time to "None" and increments the "number of consecute no-reply" counter for the host.

When thread 3 detects that a host has to many no-replies a down event is posted on the event queue.


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.