On Mon, Oct 21, 2002 at 03:24:48PM -0700, Guy Harris wrote: > > Description: > > remove buffer move in LBL_ALIGN case, which does more bad things than good things. > > (if there's unaligned access, they must be converted to EXTRACT_xx) > > Modified files: > > File: tcpdump/print-atalk.c; Revision: 1.75; > > Date: 2002/10/18 04:40:02; Author: itojun; Lines: (+1 -16) > > File: tcpdump/print-ip.c; Revision: 1.116; > > Date: 2002/10/18 04:40:03; Author: itojun; Lines: (+1 -25) > > File: tcpdump/print-ip6.c; Revision: 1.27; > > Date: 2002/10/18 04:40:03; Author: itojun; Lines: (+1 -20) > > There are plenty of unaligned accesses, e.g. every access in > "print-ip.c" and "print-udp.c" is potentially unaligned, and probably > every other access to a more-than-1-byte field in a structure unless > EXTRACT_xx is being used. > > I ran the current CVS version of tcpdump on a token-ring capture on a > SPARC/Solaris machine, and it crashed on one packet with an alignment > fault. > > "pcap_open_offline()" attempts to put the buffer into which packets are > read on a memory boundary so that the link-layer payload is aligned on a > 4-byte boundary; however: > > 1) it does so only for Ethernet and FDDI; > > 2) it's not possible to do so for Token Ring, as the link-layer > header on Token Ring is variable length, and the source > routing information is only guaranteed to be a multiple of 2 > bytes in length, not a multiple of 4 bytes, so the correct > alignment could be packet-dependent. > > Similar problems exist for live captures.
So should we undo that change, or should we go through and, at minimum, convert all 4-byte accesses to use EXTRACT_32BITS()? (Presumably little-endian fetches are already using EXTRACT_LE_32BITS().) If so, I'd say we should convert 2-byte accesses to use EXTRACT_16BITS(), just to be sure. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request@;tcpdump.org?body=unsubscribe
