On Tue, 7 Dec 1999, Gilbert Ramirez wrote:
> Okay, we'll go ahead and include it in the Etheral source tree.
> I would like to change the prefix you used for the protocol, though, since
> "g" is rather generic. Do you prefer "gryph" or "gryphon" as
> the prefix.
Thanks. I am willing to maintain the files as ethereal and the Gryphon
protocol evolve. Although I use ethereal myself and want to keep up to
date with it, I would rather not read this list on a regular basis. If we
could work out some mechanism for you to inform me of ethereal changes
that would require changes to the dissector I would appreciate it. For
changes that I make to support protocol evolution, I could post the
updated versions to my ftp site and inform someone of their availability.
(Would patches be preferred?)
You may as well use gryph to keep it short.
> static hf_register_info hf[] = {
> { &hf_gryph_src,
> { "Source", "g.src", FT_UINT8, BASE_DEC, NULL, 0x0,
> "" }},
> { &hf_gryph_srcchan,
> { "Source channel", "g.srcchan", FT_UINT8, BASE_DEC, NULL, 0x0,
> "" }},
>
> However...
>
> data = &pd[offset];
> if (fd)
> end_of_frame = END_OF_FRAME;
> else {
> end_of_frame = ntohs (*(unsigned short *)(data + 4)) + 8;
> end_of_frame += 3 - (end_of_frame + 3) % 4;
> }
>
> We can't just make shorts (or longs) out of arbitrary bytes in the
> packet. On RISC machines there are alignment issues... 16-byte integers
> need to be aligned on 2-byte boundaries, and 32-byte integers need to
> be aligned on 4-byte boundaries. The above code works on ix86, but
> not on other CPUs. You never know if the sum total bytes preceding
> the gryphon packet is even or odd. We have some macros in packet.h
> to help with these issues: pntohs, pntohl, pletohs, pletohs. You'll
> want to convert your uses of ntohs(x) to pntohs(&x).
The protocol was designed with alignment problems in mind. As long as
the packet is aligned on a 32 bit boundary, everything should be
fine. (AFAIK the TCP/IP header is a factor of 4 bytes long.) If you
still think this is a problem, let me know and I'll correct the calls.
The line
end_of_frame += 3 - (end_of_frame + 3) % 4;
computes the end of the frame including the padding which must be present
in all Gryphon protocol frames.
Steve
______________________ _______________________________________________
/ Steve Limkemann \/ A microsecond here and a microsecond there, \
| Westland, Michigan || and before you know it, you're talking |
| USA, North America || real-time. |
| Earth, Solar System || |
| Milky Way || Smoking: Not just an addiction, |
| MGX467 271 48185 || but a way of death. |
\ _____________________/\ ______________________________________________/
