I've had no problems dealing with packets arriving via the winsock control in VB6,
but now i'm using a packet monitor for my current project...
Here is an example of an incoming SID_PING
00 08 02 64 F5 CD 00 0D  88 ED 01 7E 08 00 45 00
00 30 54 DB 00 00 70 06  A1 E5 3F F1 53 07 C0 A8
00 67 17 E0 E7 44 BD 87  83 73 5C 76 E0 2C 50 18
FF C8 7D DF 00 00 FF 25  08 00 A7 30 B2 FA 10 81

My problem is this, there is 54 bytes of TCP header (correct?), making the actual data I want:
FF 25  08 00 A7 30 B2 FA 10 81
but that's 2 bytes too long!
Sometimes theres extra data after packets, sometimes there isn't.
Problem comes when I'm parsing multiple packets coming in under 1 TCP header and i try to skip ahead bytes according to the packet length as specified in the packet...

Is there something big I'm missing out on in the TCP protocol that says there is gonna be some bytes at the end of the packet?

Well, if you are finding the beginning of each packet successfully, then you should be in the clear. Just be sure that you are parsing each packet length correctly. I don't see why two extra bytes added onto the end of the packet would cause any trouble because you have the packet length handed to you.

Are you only seeing this extra data in Ethereal, or are you seeing it from your emu client as well?

Sometimes you get trailing data after the actual packet, this shouldn't make any difference for your program receiving of the data, though. Especially if you are using VB winsock control, the .GetData function will only retrieve the actual packet data, so you have nothing to worry about.

I have no problems dealing with the packet that comes in right after the TCP header, but,
I've noticed sometimes, 2 (or more) packets come under the one TCP header. I can't find an example with two smallish packets so I'll make one up (2x SID_PING)

(54 bytes of TCP header) FF 25 08 00 A7 30 B2 FA 10 81 FF 25 08 00 A7 30 B2 FA

I made my program find the actual data for the first packet by skipping 54 bytes, then I tried to make it find the next packet by skipping a further x bytes according to the packet length specified, but in the current example, that pointer is garbage. I can't seem to find any way of predicting it, sometimes there's no extra bytes and it works fine, but sometimes there is???

The winsock control does indeed give only the actual data, but I need to make use of WinPCap for what I'm working on, and the DLL I'm using to interface with WinPCap is handing me these extra bytes sometimes.

Any ideas?

Split clumped packets by 0xFF, or use an efficient debuffer.

[quote author=Ersan link=topic=16117.msg162381#msg162381 date=1165570752]
Split clumped packets by 0xFF, or use an efficient debuffer.
[/quote]

whats a debuffer?
yeh thats the method im using now... get to end of packet then look for 0xff for battle.net messages and 0xf7 for warcraft in-game messages...
theres gotta be a better way?

A debuffer is essentially a pointer that keeps track of where you're at in the data buffer, discarding used data as needed.

but is there a predictable way of discarding the bytes between packets other than searching for a 0xFF or 0xF7?

The additional bytes appear to be 0, 1, 2 or 4 bytes only...

[quote author=djuhn link=topic=16117.msg162388#msg162388 date=1165585010]
but is there a predictable way of discarding the bytes between packets other than searching for a 0xFF or 0xF7?

The additional bytes appear to be 0, 1, 2 or 4 bytes only...
[/quote]

Well, I've never experienced 'extra data', as you're describing. Although there is a way to discard that data, it might not be reliable. You know each packet begins with 0xFF, and contains the length in it. Given those two items you should be able to read only the intended data, discard whatevers left, and begin at the next 0xFF byte.

The header for Battle.net packets is this:
(BYTE) 0xFF
(BYTE) Packet ID
(WORD) Length (including the header length)
(VOID) Packet Data

then follow what warz said.

[quote author=Ersan link=topic=16117.msg162387#msg162387 date=1165578381]
A debuffer is essentially a pointer that keeps track of where you're at in the data buffer, discarding used data as needed.
[/quote]

It's not a terribly good idea to dump used data.

[quote author=topaz link=topic=16117.msg162396#msg162396 date=1165617291]It's not a terribly good idea to dump used data.
[/quote]

You like to store data that you've already processed?

[quote author=Ersan link=topic=16117.msg162381#msg162381 date=1165570752]
Split clumped packets by 0xFF, or use an efficient debuffer.
[/quote]
Splitting by 0xFF is not a good idea, you should be processing via the packet length.

[quote author=warz link=topic=16117.msg162397#msg162397 date=1165623672]
[quote author=topaz link=topic=16117.msg162396#msg162396 date=1165617291]It's not a terribly good idea to dump used data.
[/quote]

You like to store data that you've already processed?
[/quote]

Thing is, sometimes you (I) want to go back to look at the data, and often the data isn't immediately useful. There's also the fact that dumping the data you've processed is the lazy way of not tracking the position you're at in the buffer and instead starting back at the top (imo). There's really no reason to dump it.

[quote author=l)ragon link=topic=16117.msg162398#msg162398 date=1165624459]
[quote author=Ersan link=topic=16117.msg162381#msg162381 date=1165570752]
Split clumped packets by 0xFF, or use an efficient debuffer.
[/quote]
Splitting by 0xFF is not a good idea, you should be processing via the packet length.
[/quote]

i was trying to parse using packet length, but there is "rubbish" data following some but not all packets, which presents a problem when some packets are joined together with "rubbish" data in between them.

I've never experienced this, even using raw sockets with winpcap :-\

[quote author=Ersan link=topic=16117.msg162381#msg162381 date=1165570752]
Split clumped packets by 0xFF, or use an efficient debuffer.
[/quote]

Bad idea. What if the packet contains an 0xFF in it's data?

FF 25 08 00 FF FF FF FF

Although unlikely, that's a totally legit SID_PING.

[quote author=djuhn link=topic=16117.msg162405#msg162405 date=1165668095]
[quote author=l)ragon link=topic=16117.msg162398#msg162398 date=1165624459]
[quote author=Ersan link=topic=16117.msg162381#msg162381 date=1165570752]
Split clumped packets by 0xFF, or use an efficient debuffer.
[/quote]
Splitting by 0xFF is not a good idea, you should be processing via the packet length.
[/quote]

i was trying to parse using packet length, but there is "rubbish" data following some but not all packets, which presents a problem when some packets are joined together with "rubbish" data in between them.
[/quote]
"rubbish" data that you see between packets in a packet capture will not be delivered to the application using the socket; it's consumed by the TCP/IP stack.  Parse by length, it's the correct way.