On Fri, Mar 16, 2007 at 06:00:56AM -0700, Bill Fassler wrote:
> Ah, yes. I already have that documentation and the problem is I don't see how
> those 5 bytes relate to the document description. Like I said, the 5th byte
> is apparently a sequence number and increments by one each packet. The first
> byte is always 0x30... etc... now if you can look at the 5 bytes I am seeing
> and help me map them to the protocol description then I would be very
> grateful, but I fail to see the correlation...
>
> Now you see my biggest problem. I am having trouble mapping what I see to the
> protocol description.
Well, from the ascii dump you sent and your comments I assume the
following:
The packet was sent via udp, that means the "Packet length" element is
not present (tcp only). Then we have the one byte
"Packet opcode/key_id", 0x30 = 00110 000 in binary. If we only look at
the high five bits (opcode), this is 6 aka P_DATA_V1. The next 4 bytes
(00 00 00 18) are "packet_id" in the 4-byte version.
So if you could send a complete trace (setup + some data) it shouldn't
be too hard to write a dissector for this. More sample traces (e.g. with
tcp encapsulation, encryption including the key) would allow even more.
Ciao
Joerg
--
Joerg Mayer <[EMAIL PROTECTED]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
