Wireshark-bugs: [Wireshark-bugs] [Bug 8505] openSAFETY: New reassemble functionality, as well as
Comment # 13
on bug 8505
from Roland Knall
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > I agree, that this seems to be a little bit too much to pass arround, but
> > > the whole memory is allocated using ep_ functions, and so will be thrown
> > > away anyway at the end of each package.
> >
> > Leaks are not the concern, I just thought the entire thing could be
> > simplified.
>
> And presumably sped up, since copying the entire payload worth of bytes on
> every dissection won't be particularly efficient.
Ok, I really need to clear my head, before answering. No, the second frame is
not coded with a CRC. But it is coded with the UDID of a master node, which
basically takes the form of a MAC ID. This UDID is XORed on the first 6 bytes
of the second frame.
So, when an openSAFETY frame with 13 bytes gets transmitted, it actually
consists of two sub-frames, with the first sub-frame having 6 bytes and the
second one 7 bytes. Both sub-frames have their own CRC code, which must be
valid and differs between each frame. The second frame consists of the same
data as the first one, with only a little bit of additional information (2
bytes differ in most cases).
So, what happens is, that we receive a frame. There will be a heuristic
determination, if it may contain an openSAFETY frame (the starting position of
the whole frame may vary depending on the underlying fieldbus implementation).
Therefore the starting position of a frame in TVB has to be calculated and
cannot be deducted from the information presented at the start of the dissector
(that is what findSafetyFrame does). After we found a possible frame, the first
CRC is calculated. Only if this CRC is correct, the frame will be dissected.
Incomplete frames do not have any value, as the nodes receiving them, MUST
throw them away. Also they do not provide any information to the person reading
the trace, as incomplete frames will be detected long before they go onto the
bus. And every node building and transmitting openSAFETY frames, must be
certified to be SIL-3 compliant by the TUEV or similar certification bodies.
So, incomplete or corrupt frames, really are not an issue. It is a
all-or-nothing approach.
As for the speed-up, I do see the argument. And I will look into it, if there
can be a reduction or removal for the byte array. As of now, I simply do not
see, how I could avoid it. I've tried with macros, but they come out to be
monstrous. What I already have is a dissected and seperate TVB entry. I will
try and use that for the dissection in a future version.
But could I please ask, that I can leave this optimisation to a future patch?
At the moment I am focusing on getting the openSAFETY dissector
feature-complete.
You are receiving this mail because:
- You are watching all bug changes.
