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 <http://www.gelato.unsw.edu.au/lxr/source/>/drivers<http://www.gelato.unsw.edu.au/lxr/source/drivers/> /net <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/>/e100.c<http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c> skb_reserve() in line 1772 did the same thing. <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c> 1765 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1765> static int e100_rx_alloc_skb <http://www.gelato.unsw.edu.au/lxr/ident?i=e100_rx_alloc_skb>(struct nic <http://www.gelato.unsw.edu.au/lxr/ident?i=nic> *nic <http://www.gelato.unsw.edu.au/lxr/ident?i=nic>, struct rx <http://www.gelato.unsw.edu.au/lxr/ident?i=rx> *rx <http://www.gelato.unsw.edu.au/lxr/ident?i=rx>) 1766 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1766> { 1767 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1767> if(!(rx <http://www.gelato.unsw.edu.au/lxr/ident?i=rx>->skb <http://www.gelato.unsw.edu.au/lxr/ident?i=skb> = dev_alloc_skb <http://www.gelato.unsw.edu.au/lxr/ident?i=dev_alloc_skb>(RFD_BUF_LEN <http://www.gelato.unsw.edu.au/lxr/ident?i=RFD_BUF_LEN> + NET_IP_ALIGN <http://www.gelato.unsw.edu.au/lxr/ident?i=NET_IP_ALIGN>))) 1768 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1768> return -ENOMEM <http://www.gelato.unsw.edu.au/lxr/ident?i=ENOMEM>; 1769 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1769> 1770 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1770> */* Align, init, and map the RFD. */* 1771 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1771> rx <http://www.gelato.unsw.edu.au/lxr/ident?i=rx>->skb <http://www.gelato.unsw.edu.au/lxr/ident?i=skb>->dev <http://www.gelato.unsw.edu.au/lxr/ident?i=dev> = nic <http://www.gelato.unsw.edu.au/lxr/ident?i=nic>->netdev; 1772 <http://www.gelato.unsw.edu.au/lxr/source/drivers/net/e100.c#L1772> skb_reserve <http://www.gelato.unsw.edu.au/lxr/ident?i=skb_reserve>(rx <http://www.gelato.unsw.edu.au/lxr/ident?i=rx>->skb <http://www.gelato.unsw.edu.au/lxr/ident?i=skb>, NET_IP_ALIGN <http://www.gelato.unsw.edu.au/lxr/ident?i=NET_IP_ALIGN>); On Sun, May 18, 2008 at 11:21 AM, Richard Andrews <[EMAIL PROTECTED]> wrote: > > Sorry - I don't like it. > Can you explain why compiler alignment flags do not work. > > > --- Hai <[EMAIL PROTECTED]> wrote: > > > Below is the patch that make addresses of particular struct members align > at > > 32-bits memory boundry. > > > > Tested on my ixp4xx system: > > [EMAIL PROTECTED]:~# uname -a > > Linux IXDP425 2.4.21-rmk1-ds1-Xteam #36 Tue Mar 11 13:20:47 CST 2008 > armv5b > > unknown unknown GNU/Linux > > > > > > --- edge.c (revision 3484) > > +++ edge.c (working copy) > > @@ -747,12 +747,14 @@ > > static void readFromTAPSocket() > > { > > /* tun -> remote */ > > - u_char decrypted_msg[2048]; > > + u_char decrypted_msg2[2048]; > > +#define ALIGN_PADDING 2 > > + u_char *decrypted_msg = decrypted_msg2 + ALIGN_PADDING; > > size_t len; > > > > - len = tuntap_read(&device, decrypted_msg, sizeof(decrypted_msg)); > > + len = tuntap_read(&device, decrypted_msg, sizeof(decrypted_msg2) - > > ALIGN_PADDING); > > > > - if((len <= 0) || (len > sizeof(decrypted_msg))) > > + if((len <= 0) || (len > sizeof(decrypted_msg2) - ALIGN_PADDING)) > > traceEvent(TRACE_WARNING, "read()=%d [%d/%s]\n", > > len, errno, strerror(errno)); > > else { > > > _______________________________________________ > > Ntop-dev mailing list > > [email protected] > > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > > > > > > 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 >
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
