Wireshark-bugs: [Wireshark-bugs] [Bug 5206] Wireshark incorrectly processes SMPP optional parame
Abhik Sarkar
changed
bug 5206
| What |
Removed |
Added |
| CC |
|
sarkar.abhik@gmail.com
|
Comment # 8
on bug 5206
from Abhik Sarkar
Feedback from the reporter (Petr):
On 28 November 2013 14:52, Kolar, Petr <...> wrote:
Hello Abhik Sarkar
Thank you for your effort to introduce the Wireshark's preference to allow
dissection of C-Octet string type in TLV parameters of SMPP messages based on
the length information from the TLV!
My opinion is that while it is very good to have such an option, the primary
method of determining the length of the C-Octet string value in any TLV
parameter should be the Length field of the TLV. I have the following reasons
to think so:
- The TLV Length field determines length of TLV value of any type (Octet
string, C-Octet string, Integer); using the same method for all types makes the
decoder simpler.
- Forward compatibility (mentioned in the SMPP 5.0 standard in the section
2.11.1 - Forward Compatibility); when the length of C-Octet string value in a
TLV parameter is determined by searching a null octet, the information that a
TLV parameter has value of C-Octet string type changes the way how messages are
split into parameters. If such a parameter will be introduced in future, the
forward compatibility will be broken.
For these reasons I would prefer to change the text of the warning message
Actual (14) & claimed length (13) don't match. Decoding of rest of the PDU
might fail on SMSC/ESME!
to
C-Octet string is not null-terminated!
or
Null terminator not found at the end of C-Octet string!
- the second variant is usable even in the situation when a null octet is found
in the middle of the value.
With regards
Petr Kolar, Acision
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.
