Phil
said that the problem is clear, I am wondering what is the conceptual reason
why you want to mix environments. Wouldn't you better recompile the system
using the correct platform version?
Luca
On Feb 7, 2012, at 11:49 AM, Phil Sutter wrote:
> 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
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
