Wireshark · Ethereal-users: RE: [Ethereal-users] Skinny Capture!

["Sarbeswsar Mohapatra" <smohapatra@xxxxxxxxxxxxxxx>]

Hi Martin,
Thaks a lot for your help. Yes I took the correct message as you had
mentioned and I was able to capture in ethereal. But I am still confused
about the fundamental theory,

The SKINNY-3.0 spec says

"NOTE: All SCCP messages are designed to carry c language data
structures. As such, they are
subject to the underlying machine architecture for content. Almost all
SCCP messages assume
a "little-endian" or Intel Architecture machine base where, within a
given 16- or 32-bit word,
bytes at lower addresses have lower significance (the word is stored
`little-end-first'). One of the
exceptions to this is IP addressing information, which will be stored in
Network Byte Order."

What I understand from the above excerpt, the SKINNY message has to be
encoded as little endian i.e. the LSB will be transmitted first except
the IPAddress which will be encoded in opposite order. Now say for
example if the length is 10 octets, then it should be encoded as 

MSB         LSB
00  00  00  0A


I tried to compare with the H.225, where TPKT header is added for
version and length information and there we do not need to flip the byte
order. 

So Why the byte order has to be flipped here in case of SKINNY to make
it work.

Regards
Sarbeswar

-----Original Message-----
From: Martin Regner [mailto:martin.regner@xxxxxxxxx] 
Sent: Saturday, May 03, 2003 2:13 AM
To: Sarbeswsar Mohapatra
Subject: Re: [Ethereal-users] Skinny Capture!


Hi,

I don't know so much about Skinny Protocol but I have looked a bit on
some captures before.

In the capture you sent a TCP connection is setup to port 2000 in the
normal three-way handshake and then some data is sent to the server and
then the TCP connection is Reset by the server.

The message data doesn't look the same as a RegistryAck in the capture
you'll find on 
http://ipphone.patser.net/skinny.html
and it doesn't look similar to the Skinny messages I have looked on.

In your capture the data looks as 

00 00 00 10 00 00 00 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00


but I think that the message would be more correct if it was sent as:

10 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


However I don't know if that is a correctly coded RegistryAck message
anyway, since a 
Registry Ack message probably needs to contain certain data
(KeepAliveInterval, DateTemplate and SecondaryKeepAliveInterval) and
maybe has to have a certain length.

The following message should be a valid RegsitryAck message, I think. 
14 00 00 00 00 00 00 00 81 00 00 00 0a 00 00 00 44 2f 4d 2f 59 00 00 00
0a 00 00 00                                             
It comes from the capture on http://ipphone.patser.net/skinny.html


The first four octets should be the length of the message (the length is
calculated as the length of the message after the 8 byte header
containing length and the 4 reserved bytes - at least it seems so). 
In the captures I have seen the least significant digit is sent first so
I think it should be sent that way.

Then there should be four octets that are set to 00 00 00 00 (Reserved).

Then there should be four octets indiacting what message: 81 00 00 00
for a RegistryAck message

There is another Skinny capture, phone.dump.gz, http://vomit.xtdnet.nl/
(but there is no RegistryAck message i that one).

There are som Skinny call flow scenarios available here.
http://www.cisco.com/univercd/cc/td/doc/product/voice/ata/ataadmn/sccp/s
ccpaaph.pdf

http://www.cisco.com/univercd/cc/td/doc/product/voice/ata/ataadmn/sccp/s
ccpaaph.htm



Frame 21 (82 bytes on wire, 82 bytes captured)
    Arrival Time: Aug 10, 2002 10:53:03.255925000
    Time delta from previous packet: 0.221573000 seconds
    Time relative to first packet: 13.251282000 seconds
    Frame Number: 21
    Packet Length: 82 bytes
    Capture Length: 82 bytes
Ethernet II, Src: 00:60:08:56:9b:4b, Dst: 00:30:80:62:bb:32
    Destination: 00:30:80:62:bb:32 (Cisco_62:bb:32)
    Source: 00:60:08:56:9b:4b (3Com_56:9b:4b)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.1.1 (192.168.1.1), Dst Addr:
192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 68
    Identification: 0x523d
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x64c0 (correct)
    Source: 192.168.1.1 (192.168.1.1)
    Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: 2000 (2000), Dst Port: 53002
(53002), Seq: 2635393218, Ack: 3442857, Len: 28
    Source port: 2000 (2000)
    Destination port: 53002 (53002)
    Sequence number: 2635393218
    Next sequence number: 2635393246
    Acknowledgement number: 3442857
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 32000
    Checksum: 0x360a
Skinny Client Control Protocol
    Data Length: 20
    Reserved: 0x00000000
    Message ID: RegisterAckMessage (0x00000081)
    KeepAliveInterval: 10
    DateTemplate: D/M/Y
    SecondaryKeepAliveInterval: 10

0000  00 30 80 62 bb 32 00 60 08 56 9b 4b 08 00 45 00   .0.b.2.`.V.K..E.
0010  00 44 52 3d 40 00 40 06 64 c0 c0 a8 01 01 c0 a8   .DR=@.@.d.......
0020  01 65 07 d0 cf 0a 9d 14 e8 c2 00 34 88 a9 50 18   .e.........4..P.
0030  7d 00 36 0a 00 00 14 00 00 00 00 00 00 00 81 00   }.6.............
0040  00 00 0a 00 00 00 44 2f 4d 2f 59 00 00 00 0a 00   ......D/M/Y.....
0050  00 00                                             ..



-----Original Message-----
From: Sarbeswsar Mohapatra <smohapatra@xxxxxxxxxxxxxxx>
To: ethereal-users@xxxxxxxxxxxx <ethereal-users@xxxxxxxxxxxx>
Date: Saturday, May 03, 2003 4:31 AM
Subject: [Ethereal-users] Skinny Capture!


>Greetings,
>I am new to SKINNY protocol, I have created a simple message 
>"StationRegisterAckMessage" with following data,
> 
>  0: 00 00 00 10 00 00 00 00      00 81 00 00 00 00 00 00
>................
> 16: 00 00 00 00 00 00 00 00          ........
> 
>I established a client-server connection between two machines and sent 
>the above message from server and client in two different instances. 
>Ran the ethereal in both the machines and captured all TCP packet. When

>I filtered SKINNY protocol it does not filter anything, where as I see 
>the packet in the TCP filter. I have attached the ethereal capture for 
>reference. Can anybody tell me , if I am making any mistake.
> 
>Ethereal - 0.9.4
>OS - Windows XP, NT.
> 
>Thanks in advance.
> 
>Regards
>Sarbeswar
>