Mailing List Archive

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