Created attachment 13052
pcap file containing UCP message operation 30 with alphanumeric message "message"
Build Information:
TShark 1.10.6 (Git Rev Unknown from unknown)
Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GLib 2.36.4, with libpcap, with libz 1.2.7, with POSIX
capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.10.0, with
Lua 5.1, without Python, with GnuTLS 3.1.20, with Gcrypt 1.5.3, with MIT
Kerberos, with GeoIP.
Running on Linux 3.14.17-100.fc19.x86_64, with locale en_US.utf8, with libpcap
version 1.4.0, with libz 1.2.7.
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Built using gcc 4.8.2 20131212 (Red Hat 4.8.2-7).
Dissector does not decode data (alphanumeric message) of UCP operation 30.
(In reply to Martin Kaiser from comment #1) > does this look ok? but what's the meaning of the trailing B5 byte? > (see also https://code.wireshark.org/review/#/c/4098/ ) > > Universal Computer Protocol > Transaction Reference Number: 0 > Length: 75 > Type: Operation (79) > Operation: SMS message transfer (30) > Data > AdC: 49173789456 > OAdC: 6006 > AC: 8066 > NRq: NAdC used (49) > NAdC: 49172123456 > NPID: Mobile station (100) > AMsg: message > > [...] > 0070 33 34 35 36 2f 30 31 30 30 2f 2f 2f 2f 36 44 36 3456/0100////6D6 > 0080 35 37 33 37 33 36 31 36 37 36 35 2f 42 35 03 57373616765/B5. Sorry, by accident I added another comment (no. 2) instead of replying to this one.My reply: It does look good. The trailing B5 byte is the UCP checksum of the message.