Excellent!
Thanks,
Amir
On Tue, Aug 16, 2016 at 11:00 AM, Alfredo Cardigliano <cardigli...@ntop.org>
wrote:
> Hi Amir
> fixed in latest code on github, thank you for reporting.
>
> Best Regards
> Alfredo
>
> On 15 Aug 2016, at 13:20, Amir Kaduri <akadur...@gmail.com> wrote:
>
> I found a bug in my code, that reveals a potential bug in pf_ring code:
>
> In user-mode, I’m reading ring statistics by parsing files under
> /proc/net/pf_ring/ in the format <pid>-<dev>.<ring_id>.
>
> For example, /proc/5998/net/pf_ring/2851-eth8.251768
>
> The problem is that the ring_id in these files is generated in 32 bit,
> while the API that returns them uses 16 bit type.
>
> This causes the ring_id to wraparound 2^16, thus not to find the ring file
> in user-mode.
>
> See for example function void ring_proc_add(struct pf_ring_socket *pfr),
> that pointer pfr of type struct pf_ring_socket
>
> owns member ring_id of type u_int32_t, while API function
> pfring_get_ring_id(pfring *ring), that I use in user-mode
>
> to access the same file, returns type u_int16_t.
>
> It also seen very clearly in function pfring_mod_get_ring_id(), that
> declares u_int32_t id and returns u_int16_t:
>
> u_int16_t pfring_mod_get_ring_id(pfring *ring) {
>
> u_int32_t id;
>
> socklen_t len = sizeof(id);
>
> int rc = getsockopt(ring->fd, 0, SO_GET_RING_ID, &id, &len);
>
> return((rc == 0) ? id : -1);
>
> }
>
>
> The above code is similar to latest pf_ring code in github.
>
>
> Please confirm that this is indeed not the intention (i.e. bug).
>
>
> Thanks,
>
> Amir
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
_______________________________________________
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
