[jy lin]

Hi, everyone

I found different Binary headers size in p2p messages.

The original Binary headers size is 48 bytes like this

0000 00 00 00 00 cd e8 78 01 00 00 00 00 00 00 00 00 ......x.........
0010 19 02 00 00 00 00 00 00 19 02 00 00 00 00 00 00 ................
0020 da 1d 9e 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0040 78 78 78 78 78 78 40 68 6f 74 6d 61 69 6c 2e 63 xxxxxx@hotmail.c
0050 6f 6d 20 4d 53 4e 53 4c 50 2f 31 2e 30 0d 0a om MSNSLP/1.0..

But when I use WLM 2009, I got 32 bytes and even 16 bytes like this

0000 18 03 02 b4 4c e0 26 ac 01 0c 00 02 00 00 00 0e ....L.&.........
0010 76 2d 0f 01 00 00 00 00 08 01 00 00 00 00 00 00 v-..............
0020 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0030 78 78 78 78 78 40 6d 73 36 32 2e 68 69 6e 65 74 xxxxx@ms62.hinet
0040 2e 6e 65 74 3b 7b 64 31 65 34 32 33 36 34 2d 36 .net;{d1e42364-6
0050 66 64 63 2d 34 66 30 62 2d 62 62 34 61 2d 32 32 fdc-4f0b-bb4a-22
0060 34 33 64 36 30 34 66 37 32 32 7d 20 4d 53 4e 53 43d604f722} MSNS
0070 4c 50 2f 31 2e 30 0d 0a LP/1.0..

0000 08 00 03 05 4c e0 29 60 08 01 00 01 00 00 00 00 ....L.)`........
0010 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0020 78 78 78 78 73 40 6d 73 36 32 2e 68 69 6e 65 74 xxxxx@ms62.hinet
0030 2e 6e 65 74 3b 7b 64 31 65 34 32 33 36 34 2d 36 .net;{d1e42364-6
0040 66 64 63 2d 34 66 30 62 2d 62 62 34 61 2d 32 32 fdc-4f0b-bb4a-22
0050 34 33 64 36 30 34 66 37 32 32 7d 20 4d 53 4e 53 43d604f722} MSNS
0060 4c 50 2f 31 2e 30 0d 0a LP/1.0..

Could someone knows what 32 bytes or 16 bytes header means? thanks :D

[Uri]

jy lin, on Feb 3 2009, 11:23 AM, said:

Hi, everyone

I found different Binary headers size in p2p messages.

The original Binary headers size is 48 bytes like this

0000 00 00 00 00 cd e8 78 01 00 00 00 00 00 00 00 00 ......x.........
0010 19 02 00 00 00 00 00 00 19 02 00 00 00 00 00 00 ................
0020 da 1d 9e 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0040 78 78 78 78 78 78 40 68 6f 74 6d 61 69 6c 2e 63 xxxxxx@hotmail.c
0050 6f 6d 20 4d 53 4e 53 4c 50 2f 31 2e 30 0d 0a om MSNSLP/1.0..

But when I use WLM 2009, I got 32 bytes and even 16 bytes like this

0000 18 03 02 b4 4c e0 26 ac 01 0c 00 02 00 00 00 0e ....L.&.........
0010 76 2d 0f 01 00 00 00 00 08 01 00 00 00 00 00 00 v-..............
0020 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0030 78 78 78 78 78 40 6d 73 36 32 2e 68 69 6e 65 74 xxxxx@ms62.hinet
0040 2e 6e 65 74 3b 7b 64 31 65 34 32 33 36 34 2d 36 .net;{d1e42364-6
0050 66 64 63 2d 34 66 30 62 2d 62 62 34 61 2d 32 32 fdc-4f0b-bb4a-22
0060 34 33 64 36 30 34 66 37 32 32 7d 20 4d 53 4e 53 43d604f722} MSNS
0070 4c 50 2f 31 2e 30 0d 0a LP/1.0..

0000 08 00 03 05 4c e0 29 60 08 01 00 01 00 00 00 00 ....L.)`........
0010 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0020 78 78 78 78 73 40 6d 73 36 32 2e 68 69 6e 65 74 xxxxx@ms62.hinet
0030 2e 6e 65 74 3b 7b 64 31 65 34 32 33 36 34 2d 36 .net;{d1e42364-6
0040 66 64 63 2d 34 66 30 62 2d 62 62 34 61 2d 32 32 fdc-4f0b-bb4a-22
0050 34 33 64 36 30 34 66 37 32 32 7d 20 4d 53 4e 53 43d604f722} MSNS
0060 4c 50 2f 31 2e 30 0d 0a LP/1.0..

Could someone knows what 32 bytes or 16 bytes header means? thanks :D

Hi,

I have been doing some research on the new binary headers sent by the new WLM 2009.
When the client Alice logs in using MSNP18, and starts a session to another WLM 2009 client Bob (I believe Alice knows the client type of Bob by the GUID that is attached to the email in Bob's JOI command) then the file transfer session is substantially changed.
Changes are as follows:
All data is Big Endian!!!
The binary header size is dynamic - It can be 40, 28 and 16 (I haven't seen cases with 32 - Are you sure you haven't tacked on 4 bytes?)
For all of them -
Bytes 0-1 -- Flag - Unclear about the meaning but the initial application/x-msnmsgrp2p MSG of a file transfer always carries the 0x1803
Bytes 2-3 -- Payload length - Number of bytes following the header in this MSG
Bytes 4-7 -- BaseID(BlobID?) - Starts randomly, Add the payload length to get the next one.
Bytes 8-9 -- Another Flag

When transferring file data, the header size is 28 bytes (Unless it's the last chunk - then its 16 bytes):
Bytes 12-15 -- SessionID - It is specified in the MSNSLP body of the initial transaction
Bytes ?-25 -- Remaining File size (Not including current payload length)

Attached is an edited sample capture.

I haven't got the rest figured out just yet -- Any Help/Comments anybody?
I'll upload what I have to MSNPiki soon.

--Uri

Attached File(s)

•  edited_capture_msnms9.txt (2.87K)
  Number of downloads: 75

[jy lin]

Uri, on Feb 3 2009, 11:14 AM, said:

Hi,

I have been doing some research on the new binary headers sent by the new WLM 2009.
When the client Alice logs in using MSNP18, and starts a session to another WLM 2009 client Bob (I believe Alice knows the client type of Bob by the GUID that is attached to the email in Bob's JOI command) then the file transfer session is substantially changed.
Changes are as follows:
All data is Big Endian!!!
The binary header size is dynamic - It can be 40, 28 and 16 (I haven't seen cases with 32 - Are you sure you haven't tacked on 4 bytes?)
For all of them -
Bytes 0-1 -- Flag - Unclear about the meaning but the initial application/x-msnmsgrp2p MSG of a file transfer always carries the 0x1803
Bytes 2-3 -- Payload length - Number of bytes following the header in this MSG
Bytes 4-7 -- BaseID(BlobID?) - Starts randomly, Add the payload length to get the next one.
Bytes 8-9 -- Another Flag

When transferring file data, the header size is 28 bytes (Unless it's the last chunk - then its 16 bytes):
Bytes 12-15 -- SessionID - It is specified in the MSNSLP body of the initial transaction
Bytes ?-25 -- Remaining File size (Not including current payload length)

Attached is an edited sample capture.

I haven't got the rest figured out just yet -- Any Help/Comments anybody?
I'll upload what I have to MSNPiki soon.

--Uri

thanks share

If Bytes 0-1 is Flag， I think it come first is 0x1803, after that comes 0x0800.

And today I test file transfer, I got 44 bytes header ...

By the way, I got those 32 and 16 bytes headers when I invite someone to watch webcam.

[jy lin]

I just found
if flag is 0x0800 , head size always 16 bytes

[jy lin]

I think I found some thing :twisted:

the first byte may be part of head length

0000 18 03 02 b4 4c e0 26 ac 01 0c 00 02 00 00 00 0e ....L.&.........
0010 76 2d 0f 01 00 00 00 00 08 01 00 00 00 00 00 00 v-..............
0020 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0030 78 78 78 78 78 40 6d 73 36 32 2e 68 69 6e 65 74 xxxxx@ms62.hinet
0040 2e 6e 65 74 3b 7b 64 31 65 34 32 33 36 34 2d 36 .net;{d1e42364-6
0050 66 64 63 2d 34 66 30 62 2d 62 62 34 61 2d 32 32 fdc-4f0b-bb4a-22
0060 34 33 64 36 30 34 66 37 32 32 7d 20 4d 53 4e 53 43d604f722} MSNS
0070 4c 50 2f 31 2e 30 0d 0a LP/1.0..

For this case, first part of length is 0x18 (24), after 24 bytes, we got 0x08(8), after 8 bytes comes data.

00000000 18 03 04 ca 06 f4 b5 ab 01 0c 00 02 00 00 00 0e ................
00000010 76 2d 0f 01 00 00 00 00 14 01 00 00 00 00 00 00 v-..............
00000020 01 08 00 00 00 00 00 00 00 8e 00 00 49 4e 56 49 ............INVI

Here is another sample, header length 44 means 0x18+ 0x14

[Uri]

jy lin, on Feb 4 2009, 08:51 AM, said:

I think I found some thing :twisted:

the first byte may be part of head length

0000 18 03 02 b4 4c e0 26 ac 01 0c 00 02 00 00 00 0e ....L.&.........
0010 76 2d 0f 01 00 00 00 00 08 01 00 00 00 00 00 00 v-..............
0020 49 4e 56 49 54 45 20 4d 53 4e 4d 53 47 52 3a 78 INVITE MSNMSGR:x
0030 78 78 78 78 78 40 6d 73 36 32 2e 68 69 6e 65 74 xxxxx@ms62.hinet
0040 2e 6e 65 74 3b 7b 64 31 65 34 32 33 36 34 2d 36 .net;{d1e42364-6
0050 66 64 63 2d 34 66 30 62 2d 62 62 34 61 2d 32 32 fdc-4f0b-bb4a-22
0060 34 33 64 36 30 34 66 37 32 32 7d 20 4d 53 4e 53 43d604f722} MSNS
0070 4c 50 2f 31 2e 30 0d 0a LP/1.0..

For this case, first part of length is 0x18 (24), after 24 bytes, we got 0x08(8), after 8 bytes comes data.

00000000 18 03 04 ca 06 f4 b5 ab 01 0c 00 02 00 00 00 0e ................
00000010 76 2d 0f 01 00 00 00 00 14 01 00 00 00 00 00 00 v-..............
00000020 01 08 00 00 00 00 00 00 00 8e 00 00 49 4e 56 49 ............INVI

Here is another sample, header length 44 means 0x18+ 0x14

I think you are on track - the first byte tells us the initial header length. If after that length comes 0x00 then the header is finished, otherwise it is extended by that number (This happens once, the first byte after the extended amount is part of the payload).
Note that the byte after the header can be part of the footer 4 * 0x00:
MSG 150 D 230\r\n
0000 10 00 00 00 39 ad 2b 59 02 04 e8 34 f7 48 00 00 ....9.+Y ...4.H..
0010 00 00 00 00 ....

Now to figure out what the second part of the flag means :-)

--Uri

[zinid]

Hi all.

I have reversed almost the whole MSNP18 P2P protocol and have a working implementation. There is a brief description in the attached file. I'm too lazy to complete the documentation, so it would be great if someone can complete it :)

Attached File(s)

•  p2p.txt (5.55K)
  Number of downloads: 128

[不羁之心]

zinid, on Apr 6 2009, 08:17 AM, said:

Hi all.

I have reversed almost the whole MSNP18 P2P protocol and have a working implementation. There is a brief description in the attached file. I'm too lazy to complete the documentation, so it would be great if someone can complete it :)

thanks， I thank you are right.


the operation code int Transport Layer:
02 meaning need ack(i test to get friend's dispaly pictrue).

[不羁之心]

不羁之心, on Apr 7 2009, 08:17 AM, said:

thanks， I thank you are right.


the operation code int Transport Layer:
02 meaning need ack(i test to get friend's dispaly pictrue).

and in the TLVs, 02 means is a ack.


who knows other codes?

[zinid]

不羁之心, on Apr 7 2009, 08:20 AM, said:

and in the TLVs, 02 means is a ack.


who knows other codes?

03 means you need to ack with [{2, ReplySeq}, {1, Unknown}]
where ReplySeq is a Seq of the message to reply plus the size of the Payload of that message,
Unknown is unknown :) but I always send [0,2,0,0,0,14,0,0,15,1,0,0] (12 byte)

[不羁之心]

zinid, on Apr 7 2009, 10:26 AM, said:

03 means you need to ack with [{2, ReplySeq}, {1, Unknown}]
where ReplySeq is a Seq of the message to reply plus the size of the Payload of that message,
Unknown is unknown :) but I always send [0,2,0,0,0,14,0,0,15,1,0,0] (12 byte)

code == 03, is not always. sometimes is 02 or 00.

SLV tag==01 means what？ , if code ==0 , i can find SLV with tag == 01.

[kakaroto]

Good job zinid in reverse-engineering this protocol!
By the way, this is called P2PV2 officially by WLM since a contact in WLM can have the property "CapabilityP2PV2". I just thought it might be nice to know how to call this new protocol.
I think everything you gave was perfectly correct, what we are missing now is the operation codes (for data and transport layers), what the flag means, and what are the TLV types and meanings... and finally how it all fits together, what is the sequence chart for a normal P2PV2 session.
Hopefully I can help a little soon.
Keep it up!

[kreddy]

Hi guys,

I am the new member in this forum, I am glad to have such a greatly useful information.

Currently I am working on a project, where we want to support wlm2009 file transfers over the P2P, hence we need to parse the P2P binary headers properly to manage the file transfers. One thing I want to tell is P2PData packets like sessionreqbody, transreqbody, transrespbody used to come over the conversation connection for P2P handshake, now the same P2PData packets also coming over the P2P connection, do not know the exact reason.

Still I am able make P2P connection properly and data(P2PData packets sessionreqbody, transreqbody, transrespbody)exchange happening over the P2P connection, when it comes to file data packet the sender client is not pushing to P2P connection, here I stuck up. do am I missing something here?

==========The last data packet that exchanged over the P2P connection=================
00 13 20 20 f0 33 00 0c 29 fd 0f 20 08 00 45 00 .. .3..).. ..E.
02 54 a6 38 40 00 80 06 ec 1e c0 a8 72 4f c0 a8 .T.8@.......rO..
72 ac 0c 68 07 27 62 9a 21 fc e9 90 b4 66 50 18 r..h.'b.!....fP.
3f 3e 6a 17 00 00 08 00 00 31 2f d3 29 a3 08 07 ?>j......1/.)...
00 00 92 7f 03 e9 54 68 69 73 20 66 69 6c 65 20 ......This file
69 73 20 66 6f 72 20 77 6c 6d 32 30 30 39 20 66 is for wlm2009 f
69 6c 65 78 66 65 72 20 74 65 73 74 69 6e 67 ef ilexfer testing.
01 00 00 08 00 01 e7 2f d3 29 d4 08 01 00 03 00 ......./.)......
00 00 00 42 59 45 20 4d 53 4e 4d 53 47 52 3a 6d ...BYE MSNMSGR:m
66 74 69 6d 65 32 40 68 6f 74 6d 61 69 6c 2e 63 ftime2@hotmail.c
6f 6d 3b 7b 36 31 37 31 36 37 66 35 2d 66 66 38 om;{617167f5-ff8
36 2d 34 63 30 36 2d 62 35 62 37 2d 34 64 65 37 6-4c06-b5b7-4de7
61 37 32 62 35 37 39 34 7d 20 4d 53 4e 53 4c 50 a72b5794} MSNSLP
2f 31 2e 30 0d 0a 54 6f 3a 20 3c 6d 73 6e 6d 73 /1.0..To: <msnms
67 72 3a 6d 66 74 69 6d 65 32 40 68 6f 74 6d 61 gr:mftime2@hotma
69 6c 2e 63 6f 6d 3b 7b 36 31 37 31 36 37 66 35 il.com;{617167f5
2d 66 66 38 36 2d 34 63 30 36 2d 62 35 62 37 2d -ff86-4c06-b5b7-
34 64 65 37 61 37 32 62 35 37 39 34 7d 3e 0d 0a 4de7a72b5794}>..
46 72 6f 6d 3a 20 3c 6d 73 6e 6d 73 67 72 3a 6d From: <msnmsgr:m
66 74 69 6d 65 31 40 68 6f 74 6d 61 69 6c 2e 63 ftime1@hotmail.c
6f 6d 3b 7b 63 34 32 32 65 65 63 34 2d 35 32 39 om;{c422eec4-529
39 2d 34 65 38 38 2d 39 30 61 32 2d 30 63 66 64 9-4e88-90a2-0cfd
33 61 66 66 34 39 34 38 7d 3e 0d 0a 56 69 61 3a 3aff4948}>..Via:
20 4d 53 4e 53 4c 50 2f 31 2e 30 2f 54 4c 50 20 MSNSLP/1.0/TLP
3b 62 72 61 6e 63 68 3d 7b 42 43 30 34 42 31 30 ;branch={BC04B10
35 2d 32 33 45 45 2d 34 34 30 33 2d 41 35 44 30 5-23EE-4403-A5D0
2d 44 38 46 32 42 38 39 35 41 41 35 34 7d 0d 0a -D8F2B895AA54}..
43 53 65 71 3a 20 30 20 0d 0a 43 61 6c 6c 2d 49 CSeq: 0 ..Call-I
44 3a 20 7b 33 34 37 42 36 46 41 34 2d 33 37 37 D: {347B6FA4-377
33 2d 34 45 30 43 2d 38 41 42 33 2d 32 36 42 37 3-4E0C-8AB3-26B7
30 30 41 43 30 36 30 36 7d 0d 0a 4d 61 78 2d 46 00AC0606}..Max-F
6f 72 77 61 72 64 73 3a 20 30 0d 0a 43 6f 6e 74 orwards: 0..Cont
65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 ent-Type: applic
61 74 69 6f 6e 2f 78 2d 6d 73 6e 6d 73 67 72 2d ation/x-msnmsgr-
73 65 73 73 69 6f 6e 63 6c 6f 73 65 62 6f 64 79 sessionclosebody
0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 ..Content-Length
3a 20 32 36 0d 0a 0d 0a 53 65 73 73 69 6f 6e 49 : 26....SessionI
44 3a 20 32 34 35 37 37 39 37 36 30 39 0d 0a 0d D: 2457797609...
0a 00 ..

===============================================================

[不羁之心]

kreddy, on Apr 9 2009, 06:26 AM, said:

Hi guys,

I am the new member in this forum, I am glad to have such a greatly useful information.

Currently I am working on a project, where we want to support wlm2009 file transfers over the P2P, hence we need to parse the P2P binary headers properly to manage the file transfers. One thing I want to tell is P2PData packets like sessionreqbody, transreqbody, transrespbody used to come over the conversation connection for P2P handshake, now the same P2PData packets also coming over the P2P connection, do not know the exact reason.

Still I am able make P2P connection properly and data(P2PData packets sessionreqbody, transreqbody, transrespbody)exchange happening over the P2P connection, when it comes to file data packet the sender client is not pushing to P2P connection, here I stuck up. do am I missing something here?

==========The last data packet that exchanged over the P2P connection=================
00 13 20 20 f0 33 00 0c 29 fd 0f 20 08 00 45 00 .. .3..).. ..E.
02 54 a6 38 40 00 80 06 ec 1e c0 a8 72 4f c0 a8 .T.8@.......rO..
72 ac 0c 68 07 27 62 9a 21 fc e9 90 b4 66 50 18 r..h.'b.!....fP.
3f 3e 6a 17 00 00 08 00 00 31 2f d3 29 a3 08 07 ?>j......1/.)...
00 00 92 7f 03 e9 54 68 69 73 20 66 69 6c 65 20 ......This file
69 73 20 66 6f 72 20 77 6c 6d 32 30 30 39 20 66 is for wlm2009 f
69 6c 65 78 66 65 72 20 74 65 73 74 69 6e 67 ef ilexfer testing.
01 00 00 08 00 01 e7 2f d3 29 d4 08 01 00 03 00 ......./.)......
00 00 00 42 59 45 20 4d 53 4e 4d 53 47 52 3a 6d ...BYE MSNMSGR:m
66 74 69 6d 65 32 40 68 6f 74 6d 61 69 6c 2e 63 ftime2@hotmail.c
6f 6d 3b 7b 36 31 37 31 36 37 66 35 2d 66 66 38 om;{617167f5-ff8
36 2d 34 63 30 36 2d 62 35 62 37 2d 34 64 65 37 6-4c06-b5b7-4de7
61 37 32 62 35 37 39 34 7d 20 4d 53 4e 53 4c 50 a72b5794} MSNSLP
2f 31 2e 30 0d 0a 54 6f 3a 20 3c 6d 73 6e 6d 73 /1.0..To: <msnms
67 72 3a 6d 66 74 69 6d 65 32 40 68 6f 74 6d 61 gr:mftime2@hotma
69 6c 2e 63 6f 6d 3b 7b 36 31 37 31 36 37 66 35 il.com;{617167f5
2d 66 66 38 36 2d 34 63 30 36 2d 62 35 62 37 2d -ff86-4c06-b5b7-
34 64 65 37 61 37 32 62 35 37 39 34 7d 3e 0d 0a 4de7a72b5794}>..
46 72 6f 6d 3a 20 3c 6d 73 6e 6d 73 67 72 3a 6d From: <msnmsgr:m
66 74 69 6d 65 31 40 68 6f 74 6d 61 69 6c 2e 63 ftime1@hotmail.c
6f 6d 3b 7b 63 34 32 32 65 65 63 34 2d 35 32 39 om;{c422eec4-529
39 2d 34 65 38 38 2d 39 30 61 32 2d 30 63 66 64 9-4e88-90a2-0cfd
33 61 66 66 34 39 34 38 7d 3e 0d 0a 56 69 61 3a 3aff4948}>..Via:
20 4d 53 4e 53 4c 50 2f 31 2e 30 2f 54 4c 50 20 MSNSLP/1.0/TLP
3b 62 72 61 6e 63 68 3d 7b 42 43 30 34 42 31 30 ;branch={BC04B10
35 2d 32 33 45 45 2d 34 34 30 33 2d 41 35 44 30 5-23EE-4403-A5D0
2d 44 38 46 32 42 38 39 35 41 41 35 34 7d 0d 0a -D8F2B895AA54}..
43 53 65 71 3a 20 30 20 0d 0a 43 61 6c 6c 2d 49 CSeq: 0 ..Call-I
44 3a 20 7b 33 34 37 42 36 46 41 34 2d 33 37 37 D: {347B6FA4-377
33 2d 34 45 30 43 2d 38 41 42 33 2d 32 36 42 37 3-4E0C-8AB3-26B7
30 30 41 43 30 36 30 36 7d 0d 0a 4d 61 78 2d 46 00AC0606}..Max-F
6f 72 77 61 72 64 73 3a 20 30 0d 0a 43 6f 6e 74 orwards: 0..Cont
65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 ent-Type: applic
61 74 69 6f 6e 2f 78 2d 6d 73 6e 6d 73 67 72 2d ation/x-msnmsgr-
73 65 73 73 69 6f 6e 63 6c 6f 73 65 62 6f 64 79 sessionclosebody
0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 ..Content-Length
3a 20 32 36 0d 0a 0d 0a 53 65 73 73 69 6f 6e 49 : 26....SessionI
44 3a 20 32 34 35 37 37 39 37 36 30 39 0d 0a 0d D: 2457797609...
0a 00 ..

===============================================================

This bye means the work is finished.

While sending file data, the data layer has one SLV protocol------the type == 1, value has 8 bytes---- means the left file bytes.

also, if is last file data packet, i didnot find the slv protocol.

[kreddy]

不羁之心, on Apr 9 2009, 11:39 AM, said:

This bye means the work is finished.

While sending file data, the data layer has one SLV protocol------the type == 1, value has 8 bytes---- means the left file bytes.

also, if is last file data packet, i didnot find the slv protocol.

==========================

Thank you very much for your help, I am not sure what is going wrong in my case, so here with I am attaching SUCCESS PCAP and FAILURE PCAP for the sender
If possible pls have a glance and help me out for this issue.

NOTE : pls change file ext .txt to .pcap and open with whireshark/ethereal

Attached File(s)

•  SuccessSender.txt (310.13K)
  Number of downloads: 43
•  FailureSender.txt (74.8K)
  Number of downloads: 13

[kakaroto]

@kreddy:
The P2P data can be sent over any transport, it can be the direct TCP connection, or the Switchboard (conversation connection) or UDP or TURN, etc.. it can use *any* transport.. the session-req, transreqbody and all that stuff is also P2P data, if you don't have a p2p connection, it will use the switchboard to send that, and then it will switch to the best transport available (the direct connection in your case) that's why you're receiving the BYE in the direct connection.. note that if you send a second file transfer while the first one is still transfering, you will see that the INVITE, etc.. will all be sent over the direct connection too. You just have to parse them correctly from wherever the p2p data is coming.

[gauri]

Hi,
I am trying to decode the WLM 2009 binary header specially in the file transfer. So faer Ihave found out that, the binary header is 28 bytes in file data pkt except fro alst packet where it is 16 bytes.

in the 28 bytes header, there are 2 parts 8 byte and 20 bytes.
In the 20 bytes, there is 4 bytes data field that indicates the remaining data size excluding the current data in the packet.

I haven;t been able to decode other fields. I am mainly inetrested in knowing how do we know it s a file dat packet.
In earleir version there was a flag 100003 which indicated a filedata packet.

Has anyone decode this header?

Thanks
Gauri.

[joneschi]

Hi all,
I observe the packets in webcam sharing,
and I guess the code=03 of transport layer means SYN, and the TLVs code=01 means hello,
Because when I use ospy to capture the informations, it shows "add SYN and Hello to the first packet" before send the first p2p packet.

The code=01 of transport layer means the packet contain SIP message, header length is always 8 bytes of this type, and the following two bytes(2,3) after the code means it is the Nth SIP message(first is 0), and the remaining four bytes are always zero.

This post has been edited by joneschi: 22 April 2009 - 04:23 PM

[Doggie]

I'll pin this thread, it seems like its becoming useful for other users. Good work :)

[kreddy]

anybody had chance to find what these binary headers represent,
as per my understanding

first header
first byte - first header len
second byte - flag unkown
3 & 4 bytes - payload len
5,6,7&8 bytes - sequence number

Remaining bytes if any in the first header dont know.

second header
first byte - second header len
second byte - operation code ( dont know, what each bit represents)
3&4 bytes - sequence number
5,6,7&8 bytes- session ID

Remaining bytes if any in the second header dont know.

When I am parsing the P2P packet I am also modifying the P2P packet content and changed the payload length accordingly, do I need to change any other header apart from pay load length when I modify the P2P data packet content?

Please advice