Hello Luca,
On Fri, Feb 03, 2012 at 12:09:49PM +0100, Luca Deri wrote:
> > On Wed, Feb 01, 2012 at 10:33:25PM +0100, Luca Deri wrote:
> >> some time ago we have fixed issues like the one you pointed out. Did you
> >> use the SVN PF_RING code? Are you using DNA or standard PF_RING?
> >
> > We originally noticed the problem with 5.2.1, but it happens with trunk,
> > too. DNA is not in use.
> >
> > In pf_ring.h, there is this comment above struct pfring_pkthdr:
> > | Keep 'struct pfring_pkthdr' in sync with 'struct pcap_pkthdr'
> > which is why I mentioned pcap compatibility in my first mail. Could you
> > elaborate on this? Having to keep kernel structs in sync with ones used
>
> The PF_RING header is a subset of the pcap header. So whathever we do on the
> header must be added after the pcap header
I guess, that should read "superset" since pfring_pkthdr is actually
larger than pcap_pkthdr. But yes, they're identical in the beginning,
which is part of the problem here:
> struct pfring_pkthdr {
> /* pcap header */
> struct timeval ts; /* time stamp */
> u_int32_t caplen; /* length of portion present */
> u_int32_t len; /* length this packet (off wire) */
> struct pfring_extended_pkthdr extended_hdr; /* PF_RING extended header */
> };
It's the struct timeval, which differs in size in between 32 and 64 bit.
See linux/time.h for reference:
| struct timeval {
| __kernel_time_t tv_sec; /* seconds */
| __kernel_suseconds_t tv_usec; /* microseconds */
| };
with __kernel_time_t and __kernel_suseconds_t defined as:
| typedef long __kernel_time_t;
| typedef long __kernel_suseconds_t;
identically in both arch/x86/include/asm/posix_types_32.h and
arch/x86/include/asm/posix_types_64.h
The type 'long' is 4 bytes on x86 and 8 bytes on x86_64.
> Basically the red part must be after the blue part.
No HTML-mailviewer here, sorry. But I get your point. Isn't there any
way around this pcap-compatibility constraint? Cause that's making
things really complicated here.
> Bottom line
> - I have just committed a change that might cause issues mixing 32-64
> environments
You're talking about r5155, replacing 'int if_index' with 'int32_t
if_index', right? Well, oddly the type 'int' is the same size both on
x86 and x86_64 so that should make no difference.
> - please let me know any issues you might find and how to reproduce it
Reproducing is easy: just setup PF_RING on x86_64 with 32-bit userland
and 64-bit kernel, it simply be broken.
Best wishes, Phil
Phil Sutter
Software Engineer
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Phone/Zentrale: +49-6721-49030-0
Direct line/Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
[email protected]
http://www.viprinet.com
Registered office/Sitz der Gesellschaft: Bingen am Rhein
Commercial register/Handelsregister: Amtsgericht Mainz HRB40380
CEO/Geschäftsführer: Simon Kissel
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
