Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [ethereal-dev] Re: Ethereal Contribution + patches

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Laurent Deniel <deniel@xxxxxxxxxxx>
Date: Mon, 31 Aug 1998 23:45:48 +0200
Gerald Combs - Unicom Communications wrote:
> 
>   [ I'm Cc'ing this message to the ethereal-dev list because I think
>     everyone might be able to benefit from the alignment issues discussed
>     below.  I hope Laurent doesn't mind.  :)  ]
> 

No problem, I only received 2 times the same message ;-)

>   Great!  The font issue doesn't suprise me.  GTK+ doesn't define a
> standard monospace font.  Lucida Typewriter was present on each of the
> platforms we run here, but I wasn't sure it would be present on all
> systems.  It would probably be a good idea to add a font test to the
> configure script, so that this could be handled at compile time.

Yes, I was thinking about it, but I'd prefer to handle it with process
arguments to allow the user to change the default fonts (a font 
available at compile time may not be available at execution time
e.g. binary distribution, run on different system installations, 
use of remote display on a heterogeneous environment (as I do ;-).

> > More will follow (such as unaligned access fixes on Digital UNIX).
> 
> 
>       e_udphdr  *uh;
>       uh = (e_udphdr *) &pd[offset];
> 
>   Where pd is a byte array containing the packet data.
> 
>   There are two things very wrong with this approach:
> 
>   - The e_udphdr struct may have holes in it.  It works fine on Intel,
>     SPARC, and PowerPC systems, but Alpha systems may have problems.

It should work if the structure is correctly written for Big & Little
Endian
architectures, and if it carefully handles common compiler padding
(structures defined in system network include files are usually correct).

>   - Arbitrarily overlaying data this way may have alignment problems.
>     For instance SPARCs require that 32-bit integers be aligned on
>     4-byte boundaries.  This is why dissect_ip() uses memcpy() to copy
>     the IP header data into the e_ip struct.

Yes, and in the exemple given, on Alpha, the &pd[offset] address shall be
also aligned on 8-byte boundaries.
 

> I have a feeling that much of the packet dissection code will have to be
> rewritten for the Alpha.  

I will check that.

> If this is the case, let me know and I'll help.

Ok

On Linux, I noted some strange results with the loopback device :-)
(no tested yet on Digital UNIX).

Laurent.

--
Laurent DENIEL            | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE             |         deniel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
                          | WWW   : http://www.worldnet.fr/~deniel
    All above opinions are personal, unless stated otherwise.