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