Hi! I am using last version of Wireshrk. So, i have a hex dump of one packet (SCCP): 09 81 03 10 1B 0D 12 06 00 72 04 73 21 85 25 03 00 79 24 0B 12 07 00 11 04 53 97 79 10 00 00 46 62 44 48 04 0E 00 03 77 6B 1E 28 1C 06 07 00 11 86 05 01 01 01 A0 11 60 0F 80 02 07 80 A1 09 06 07 04 00 00 01 00 0E 03 6C 80 A1 18 02 01 01 02 01 38 30 10 80 08 42 06 22 03 00 79 24 F5 02 01 01 83 01 00 00 00 00 00 03 65 8B 80 02 73 81 70 00 6E F9 A0 01 7B 2A F8 01 12 FA 18 02 73 81 80 01 13 07 88 04 73 21 85 25 03 00 79 02 73 82 38 00 11 04 53 97 79 10 00 00 46 62 44 48 04 0E 00 03 77 6B 1E 01 1B BE F8 00 00 00 00 01 01 01 A0 11 60 0F 80 02 73 82 20 09 06 07 04 00 00 01 00 0E 03 6C 80 A1 18 02 01 01 02 01 38 30 10 80 08 01 7A D8 80 00 79 24 F5 02 01 01 83 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 5E 76 0C 00 00 00 02 02 73 82 30 00 A4 32 5C 02 73 82 30 00 A4 2E 64 03 65 8B 80 00 81 F7 58 00 00 00 00 00 00 00 00 03 65 8B 80 00 A4 2D DC 02 73 82 38 00 A4 2E 08 02 73 82 48 00 81 F7 6C 00 00 00 00 00 00 00 02 02 73 82 58 00 81 F6 C4 00 00 90 32 00 00 00 00 02 73 82 60 00 80 5A E8 02 73 82 70 01 12 F6 C0 00 00 With Text2pcap tool i converted this dump to pcap file (text2pcap -l 142 hd.txt hd.pcap). And all seems ok... I can see SCCP part, TCAP part and GSM MAP Part. All this parts are in first 70 bytes. But how about the rest?.. That all the rest bytes mean?.. I'll be very grateful, if some one could help me to understand this message or to point me to some good direction. Thanks. asked 28 Aug '12, 06:21  SerijVeter showing 5 of 10 show 5 more comments |
2 Answers:
Hmmm, well, the SCCP, TCAP, and MAP parts all look fine to me. And you've got a total of 374 octets there which is bigger than a single SCCP message could be (well, okay, an LUDT could be that big but this is not an LUDT). I'd guess that whatever follows the end of the message isn't really part of that message but something else entirely (maybe just junk left by whatever recorded the message). It does not look to me (based on some rough scanning) that the following bytes are not another SCCP message. I'd suggest checking with whatever tool recorded the message to see what it thinks those extra octets are. answered 28 Aug '12, 08:35  JeffMorriss ♦ |
Whatever it is, it's probably a concatenation of serveral messages, as serveral byte pattern are repeated in the byte stream. How did you create the hex dump? TCAP, as displayed in Wireshark
Same byte pattern, later in the byte stream. Could be TCAP as well.
The same for parts of the SCCP message (as displayed in Wireshark)
later in the byte stream
Regards answered 28 Aug '12, 10:32  Kurt Knochner ♦ edited 28 Aug '12, 10:33 |
Hello again.
This hex dump was created from incoming message on our audiocodes. With perl help. Something like...
Step 1 - check is it sccp message or not.
my $si = uc(unpack('H*', substr($msg,$si_offset,1))); return if $si !~ /^\d3$/;
Step 2 - Cut off offset = 40
my $sccp = substr($msg,$offset); $pkt->{print} = uc(unpack('H*', $sccp)); $pkt->{print} =~ s/(\w{2})/$1 /g; $pkt->{print} =~ s/\s+$//;
This is not my solution, but it works. After this two steps we have hex dump, similar to dump example in my previous post. So, we cut offset, uses Text2pcap and after that wireshark understands first 70 bytes as sccp message. And appears a clue - that all the rest bytes means.
If you are still interested in this question, i can provide some example of the full hex dump of message on our audiocodes.
Our main problem is that we can't understand there is one packet or two and how to divide them by some sort of concatenation mark.
01 91 FD 54 FF FF 80 E0 00 00 00 01 00 00 00 02 01 0E C1 B8 02 73 80 F0 00 01 0F B8 00 00 00 69 A5 CC 3F 83 B2 D3 EB F4 09 81 03 11 1C 0E 12 06 00 71 04 73 21 85 25 03 00 48 72 01 0B 12 07 00 11 04 23 94 05 00 12 00 40 62 3E 48 04 00 1F 06 F4 6B 1A 28 18 06 07 00 11 86 05 01 01 01 A0 0D 60 0B A1 09 06 07 04 00 00 01 00 0E 03 6C 1A A1 18 02 01 22 02 01 38 30 10 80 08 42 06 22 03 00 48 72 F1 02 01 04 83 01 00 00 00 00 00 00 00 00 03 65 99 80 02 73 81 70 00 69 A5 CC 01 7B 2A F8 01 12 FA 18 02 73 81 80 01 13 07 88 04 73 21 85 25 03 00 48 02 73 82 38 07 00 11 04 23 94 05 00 12 00 40 62 3E 48 04 00 1F 06 F4 6B 01 1B BE F8 00 00 00 00 05 01 01 01 A0 0D 60 0B 02 73 82 20 04 00 00 01 00 0E 03 6C 1A A1 18 02 01 22 02 01 38 30 10 80 08 42 06 22 01 7A D8 80 F1 02 01 04 83 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 5E 68 0C 00 00 00 02 02 73 82 30 00 A4 32 5C 02 73 82 30 00 A4 2E 64 03 65 99 80 00 81 F7 58 00 00 00 00 00 00 00 00 03 65 99 80 00 A4 2D DC 02 73 82 38 00 A4 2E 08 02 73 82 48 00 81 F7 6C 00 00 00 00 00 00 00 02 02 73 82 58 00 81 F6 C4 00 00 90 32 00 00 00 00 02 73 82 60 00 80 5A E8 02 73 82 70 01
That does not explain where the data comes from ($msg in your perl script) and that's the place where the concatenation of several packets most certainly takes place. Can you please be more specific?
More specific? Ok. On one side - Huawei GGSN02 node. On other side - Mediant 3000. And all i have for now is perl script that tries to decode incoming messages. All we cant tell for sure is 5 bytes from 36 to 40 - MTP3 header. All the rest mast be the SCCP part. But for now i can't understand first 35 bytes and i can't tell for sure is thee one packet with some garbage, or there are two packets.
O.K., by "specific" I meant something different ;-). How do you get the data into the perl script? Do you read from a pipe, a log file, etc.? Maybe there is a bug in your perl script or the component that provides the data.
Sorry. Some misunderstanding :) Script listens a socket, opened to our Mediant, and waits for incoming UDP messages. So it is a pipe.
O.K. then it could be a problem with your perl script. Is it possible to capture that socket with Wireshark in parallel and then compare that with the hexdump delivered by the script?
I'll see what can be done. Also i can show your more then one dump. Maybe it generates some more ideas. As i can see that 12 byte is always 00 or 01. Our mediant has two channels. So may be 12 byte indicates channel - first or second. Also bytes 2 and 3 are some sort of counter. Don't know...
40 bytes from the beginning in four variants, one by one:
01 95 29 54 FF FF 00 00 00 00 00 01 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 6D F2 99 3F 83 B2 D3 EB 44
01 95 2A 54 FF FF 00 00 00 00 00 00 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 6D 99 F3 3F 83 AF 93 EC 84
01 A6 2B 54 FF FF 00 00 00 00 00 01 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 7E F2 9A 3F 83 B2 D3 EB F4
01 A6 2C 54 FF FF 00 00 00 00 00 00 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 7E 9A F4 3F 83 AF 93 EC 94
well, I think it will help more to comapre the wireshark data with the hex dump of the script first. Only if that comparison delivers the same result, I would suggest to digg into the script or to analyze the way data is sent to that socket.
First thing that jumped out at me is the TCAP length is 0x64 (70 bytes). Wireshark is being told to find 70 octets after that length field. Look near the beginning of that dump for the string "46 62 44 48 04 0E 00 03 77". That says "70 octets, TCAP BEGIN, 68 octets, OrigTransId, length 4 octets, TID: 0e000377". This appears to be a SendAuthInfo (opcode 0x38). With IMSI: 246022300097425.
Neither I now Wireshark have a clue how to interpret the noise that occurs after the 70 octets.