Understood. I still don't think your patch fully solves the problem; I'l
propose a different way.

The read buffer is aligned at byte 0 and parts of the buffer will be de-aligned
for different platforms regardless of the offset. So I think your fix is good
for 32-bit but not general enough. This would be fine in a driver where you
known the architecture, but not in platform independent code.

The real problem is casting a buffer to a struct. This should not be done for
data that originated on another platform. I actually had this piece of code in
my list of things to be careful about.

The real problem is the cast to (struct ip *) in send_packet2net(). This
requires a memcpy to guarantee that the pointer is on aligned memory.

Hai - can you please create a new patch that modifies send_packet2net() such
that "the_ip" is a local variable (not a pointer) and the data is put into it
via memcpy. Something like:

    struct ip the_ip;
    memcpy( &the_ip, 
            decrypted_msg+sizeof(struct ether_header), 
            sizeof(the_ip) );

When it works on ARM and linux submit the patch and I'll be happy to include
it.

--
  Rich


--- Hai <[EMAIL PROTECTED]> wrote:

> Compiler alignment flags do not work because decrypted_msg is not a struct,
> compiler don't know how to align it.
> 
> Because ether frame header has 14 bytes, the start address of ip header will
> be 14, not at 32-bits memory boundry. In arm systems(like IXP425), this will
> cause returning unwanted data when read from the_ip->ip_src.s_addr
> 
> There is an example in kernel driver for e100 netcard. Check the file
> Linux-2.6.17

 <snip>




      Get the name you always wanted with the new y7mail email address. 
www.yahoo7.com.au/y7mail

_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to