Wireshark-bugs: [Wireshark-bugs] [Bug 8505] openSAFETY: New reassemble functionality, as well as
Comment # 15
on bug 8505
from Roland Knall
(In reply to comment #14)
> I think either I am confused about what your code is doing, or you are
> confused about how the tvb functions work.
I certainly can learn a thing or two about the tvb functions, but in this case,
I think, I may be on the right side of the argument.
If you take a look at dissect_opensafety_message, you see a code for
unxorFrame. openSAFETY has 3 different message types, and only 2 of them use
the SCM UDID XOR code I mentioned earlier. In that case, I use the bytes array,
to "unxor" the code from the frame, so that the functions doing the further
dissection of the frames do not need to know about xor or the SCM UDID.
> Right now, you do:
> ssdoIndex = ((guint16)(bytes[1] << 8) + bytes[0]);
> where 'bytes' is copied from the start of the tvb. Would you not get exactly
> the same result by doing
> ssdoIndex = tvb_get_ntohs(tvb, 0);
In some cases, bytes[1] is not the start of the tvb, but in the middle. Namely
in such cases, where sub-frame 1 is transmitted after sub-frame 2, which is the
case with nearly every UDP only based implementation for openSAFETY. So I would
have to replace every code for tvb_get_ntohs with macros, which will take that
into consideration, including performing a byte-position dependant XOR
operation for the information from the second frame (see the lines for "ct = ")
in such cases where information which only resides in sub-frame 2 is needed.
> I don't see the need for fancy macros or offset calculations beyond the ones
> you've already got. If I understand correctly, every call to
> read_lowhigh_order can be replaced as-is with a call to tvb_get_ntohl simply
> by replacing 'bytes' with 'tvb'.
Normally I'd agree. Also, I did not want to present the unxor'd code in a
separate tvb section. The reason behind it is, that someone might look at the
bytes as they have been transmitted in other parts of the fieldbus system. Our
company uses some inner-machine protocols on a pci-bus implementation, and
there we see the same bytes in the same order.
You are receiving this mail because:
- You are watching all bug changes.
