Hello Jeff,
Thank you for your comments, I will follow your advices and request a new
DLT for MTP2 with FCS.
But before, I will, first, ask for the agreement of the board manufacturer.
I hope they will not disagree..
In the same time, if someone has samples of use for the MTP2 DLT, it could
be very helpfull.
Maybe, the right way will be to have :
- DLT_MTP2_noFCS for K12 files,
- DLT_MTP2_FCS, for this board.
- and to keep the current DLT_MTP2 for compatibility.
Best regards
Florent
Jeff Morriss
<jeff.morriss@xxxxxxxxxx To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
m> cc:
Sent by: Subject: Re: [Wireshark-dev] Add checksum validation option for MTP2
wireshark-dev-bounces@wi
reshark.org
05/02/2007 10:02
Please respond to
Developer support list
for Wireshark
Salut Florent,
Florent.Drouin@xxxxxxxxxxxxxxxxx wrote:
> In fact, the FCS checksum are not ahead the sequence numbers, but after
the
> payload.
> So the MTP2 header is not changed, we have just two additional bytes
> containing the CRC16.
> I did join somes messages (captured with libpcap) to show the impact of
the
> patch.
Yes, I re-read my email later and realized my mistake about the location
of the FCS. So it's not as bad as I initially thought.
> You can see, that the current MTP2 dissector do not take into account the
2
> last bytes of the frame.
> And the SCCP dissector reads the length in the SCCP part, so there is no
> impact for the next subdissectors, the 2 additional bytes are just
ignored.
True. However if the "validate FCS" option is turned on when dissecting
a frame without the FCS then the packets will show up as malformed.
Worse, it won't be MTP2 showing the packets as malformed but MTP3.
It's too bad the MTP2 LI isn't accurate (for bigger packets): if it
were, MTP2 could know if the FCS was there by checking if
tvb_reported_length_remaining()==LI+2.
Another way of handling it automatically would be to convert all the SS7
dissectors to be "new style" (that is, have them return the number of
bytes they dissected) so then MTP2 could check if there was an extra 2
bytes left undissected at the end of the tvb. But even then that
probably wouldn't be 100% reliable because those bytes might be padding
or other garbage (if someone decided to send MTP2 over SCTP, for
example). And of course this method would be a lot of work.
> That's why, for me, it was not necessary to request a new DLT.
> Moreover, if I add a new DLT, this will not change the MTP2 header itself
,
> but just change the way to detect if FCS are present or not.
> Instead of an option, you will have a dedicated DLT.
> This will be more confortable for the end users, but this will need
changes
> in libpcap...
Easier for users is always a good thing, I think. And the change to
libpcap is quite minimal: only a new DLT number. Wiretap would need a
little more change but not much (just a few case statements).
> Do you think I should request now a new DLT for MTP2 with FCS ?
I would still think so, yes, though if anyone else on the list has an
opinion, I'd like to hear it.
> And what about the other capture devices on PCM link ?
> As the FCS are part of the MTP2 layer (or HDLC layer), the checksums
should
> be present with other boards too, even if they use the current MTP2 DLT.
It depends on what the devices are giving to the monitoring process (it
may vary by device). It would appear the original author of the MTP2
dissector's device (also) did not supply the FCS or else he chose to not
dissect it, which I find unlikely.
> Maybe if I have a feedback from users working on PCM link, it will be
> easier to see if this patch has to be reworked ?
Agreed.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
