netdev - Re: [PATCH] af_packet: add interframe drop cmsg (v6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 02 Oct 2009 20:10:50 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Neil Horman <nhorman@...driver.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] af_packet: add interframe drop cmsg (v6)

Neil Horman a écrit :

> Add Ancilliary data to better represent loss information
> 
> I've had a few requests recently to provide more detail regarding frame loss
> during an AF_PACKET packet capture session.  Specifically the requestors want to
> see where in a packet sequence frames were lost, i.e. they want to see that 40
> frames were lost between frames 302 and 303 in a packet capture file.  In order
> to do this we need:
> 
> 1) The kernel to export this data to user space
> 2) The applications to make use of it
> 
> This patch addresses item (1).  It does this by doing the following:
> 
> A) Anytime we drop a frame for which we would increment po->stats.tp_drops, we
> also no increment a stats called po->stats.tp_gap.
> 
> B) Every time we successfully enqueue a frame to sk_receive_queue, we record the
> value of po->stats.tp_gap in skb->mark.  skb->cb would nominally be the place to
> record this, but since all the space there is used up, we're overloading
> skb->mark.  Its safe to do since any enqueued packet is guaranteed to be
> unshared at this point, and skb->mark isn't used for anything else in the rx
> path to the application.  After we record tp_gap in the skb, we zero
> po->stats.tp_gap.  This allows us to keep a counter of the number of frames lost
> between any two enqueued packets
> 
> C) When the application goes to dequeue a frame from the packet socket, we look
> at skb->mark for that frame.  If it is non-zero, we add a cmsg chunk to the
> msghdr of level SOL_PACKET and type PACKET_GAPDATA.  Its a 32 bit integer that
> represents the number of frames lost between this packet and the last previous
> frame received.
> 
> Note there is a chance that if there is frame loss after a receive, and then the
> socket is closed, some gap data might be lost.  This is covered by the use of
> the PACKET_AUXDATA socket option, which gives total loss data.  With a bit of
> math, the final gap can be determined that way.
> 
> 
> I've tested this patch myself, and it works well.
> 
> Signed-off-by: Neil Horman <nhorman@...driver.com>

Very well :)

Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>

Thanks
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html