ECOM

[shyosin4]

Currently I am trying to read captured packet data of UDP. Although our current system has server Kepdirect, and can see through Hamachi as remote, I would like to show a few data as remote. I could catch UDP protocal and data packet through wireshake.But I do not know formula, offset etc to read as equivalent of phsycal value as decimal.Could you please advise how I can read hex data to convert to physical decimal value?   
Thanks

[shyosin4]

Currently I am trying to read captured packet data of UDP. Although our current system has server Kepdirect, and can see through Hamachi as remote, I would like to show a few data as remote. I could catch UDP protocal and data packet through wireshake.But I do not know formula, offset etc to read as equivalent of phsycal value as decimal.Could you please advise how I can read hex data to convert to physical decimal value?   
Thanks
I add data of packet as the followings;
Hex 48 41 50 ---- are data from 28784 to remote PC. If anybody knows how to convert to decimal number, please advise.

0000   00 22 15 b1 5c 42 00 e0 62 60 25 e7 08 00 45 00 
0010   00 65 6c ee 00 00 20 11 18 53 0a 00 00 a1 0a 00 ..
0020   00 a7 70 70 04 0f 00 51 a4 ec 48 41 50 2c 67 d4 
0030   8e 40 00 22 19 00 00 7d 00 00 00 64 00 00 00 00
0040   01 00 00 00 00 00 00 14 00 64 00 64 00 c4 09 00 
0050   00 64 00 3a 00 0f 00 32 00 00 00 3a 00 0c 00 3a
0060   00 08 00 eb 05 14 05 20 03 b3 06 1e 00 00 00 00 
0070   00 f0 05                                       

[Greg]

The data is an Ethernet II telegram (coming from an ECOM) containing IP protocol, with embedded UDP protocol, with embedded HAP protocol. So, I don't know if this will help you, but here it goes:

00 22 15 b1 5c 42 = Ethernet II: Destination MAC address
00 e0 62 60 25 e7 = Ethernet II: Source MAC address (ECOM)
08 00 = Ethernet II: IP type
45 = IP: Version 4, 20 bytes
00 = IP: Differentiated services field
00 65 = IP: Length 101 bytes
6c ee = IP: ID
00 = IP: Flags
00 = IP: Offset
20 = IP: Time to live 32
11 = IP: Protocol UDP
18 53 = IP: Checksum
0a 00 00 a1 = IP: Source address (10.0.0.161) (ECOM)
0a 00 00 a7 = IP: Destination address (10.0.0.167)
70 70 = UDP: Source port 28784
04 0f = UDP: Destination port 1039
00 51 = UDP: Length 81 bytes
a4 ec = UDP: Checksum

The data following this is, as far as UDP is concerned, just... well, data. However, since this is being sent by an ECOM, the data is actually an embedded protocol of ours called "HAP" (Host Application Protocol). So, to UDP, this is just data, but to something that speaks HAP (like KepDirect), it is encoded data. Thus, this is the interpretation:

48 41 50 = "HAP" (ASCII)
2c 67 = HAP: AppVal
d4 8e = HAP: CRC
40 00 = HAP: Length 64 bytes to follow
22 = HAP: Function 22 (RESPONSE)
19 = HAP: Response to Function 19 (CCM REQUEST)
00 00 = HAP: Error code (no error)

The remaining 60 bytes are just the data the ECOM sent:
7d 00 00 00 64 00 00 00 00 01 00 00 00 00 00 00
14 00 64 00 64 00 c4 09 00 00 64 00 3a 00 0f 00
32 00 00 00 3a 00 0c 00 3a 00 08 00 eb 05 14 05
20 03 b3 06 1e 00 00 00 00 00 f0 05

[shyosin4]

Greg

Thank you for your reply. I could identify a couple of bytes with pysical values. I have a question. Please advise how is number with decimal point described. Is it described by IEEE 754 or something else?
Please advise.

Thanks

[franji1]

IEEE 754 or something else?

yes, 32 bit IEEE 754

[shyosin4]

franji1

Thanks for your reply. However I can not find any matched data as format of IEEE 754 32 bits single.

For instance, decimal number 1.514, 1.513 are converted as 3FC1CAC1 and 3FC1A9FC. I think order should be C1CAC13F and FCA9C13F on data packet, but I do not catch even 3F in data packet area.

Am I chasing wrong Hex value? Please advise.
Thanks
Shyosin4 

[franji1]

you have the endian-ness backwards (PLC is little-endian), so swap your WORDs; if you are looking at V1400/V1401, V1400 is the LSWord, V1401 is the MSWord.

Oh, and BYTEs too (you're looking at the packet). So swap every byte, so the packet data 0x01 0x02 0x03 0x04 should be the DWORD 0x04030201

[shyosin4]

Franji1

I have one more question. The following packet was sent from 00:22:15:b1:5c:42(remote)
to 00:e0:62:60:25:e7(Host). What does 35,36,37 byte mean? After those three bytes, it looks
host 00:e0:62:60:25:e7 send sepecific packets.   
Please advise.

0000   00 e0 62 60 25 e7 00 22 15 b1 5c 42 08 00 45 00  ..b`%.."..\B..E.
0010   00 2d 32 24 00 00 80 11 f3 54 0a 00 00 a7 0a 00  .-2$.....T......
0020   00 a1 04 0f 70 70 00 19 7a 18 48 41 50 6c 1d 8b  ....pp..z.HAPl..
0030   75 08 00 19 00 01 1e 7e 81 03 31 00              u......~..1.

Thanks
Shyosin4

[franji1]

I'm guessing that's the DirectNet protocol header (application layer 7)?  The DirectNet manual is available on the ADC website. http://www.automationdirect.com/static/manuals/dadnet/dadnet.html

[Greg]

Hi shyosin4,

The HAP telegram portion has the following meaning:
48 41 50 = "HAP" (ASCII)
6c 1d = HAP: AppVal
8b 75 = HAP: CRC
08 00 = HAP: Length 8 bytes to follow
19 = HAP: Function 19 (CCM REQUEST)
00 01 = HAP: N/A
1e = HAP: Direction (Read)
7e = HAP: Number of Bytes (126)
81 03 = HAP: Address 0x0381 = Octal 1601
31 = HAP: Data type (REGISTER)
00 = Padding

Thus, this is not a response to a request, but it is the request itself. The request is to read 126 bytes (63 words) starting a V1601.