Packet Size and Handling

I was in the assumption, that you have to write sockets that take fragmented packets and combine them into one full packet, if you don't it will be your end.

Atleast thats what korvacs and many others told me back in the days. I never questioned them because I was looking up to them.. So today at my usual research routine i came across the following:

Quote:

Fragmentation, packet loss, and retransmission is all handled inside TCP/IP. Your application doesn't need to worry about it. Your application should treat a TCP socket as a stream of bytes. The bytes you put in come out in the same order. How long it takes and how many come out at once is not guaranteed.

and

Quote:

The Sockets API won't deliver you packet fragments, only complete packets. The TCP/IP stack will buffer received fragments until it has a complete packet, and if some fragments are lost the whole packet will be discarded and have to be retransmitted in its entirety.

So basically, nobody needs a fragmentation handler / Packet splitter.

I was curious and implemented a logger on Xio to tell if there were any packets of the wrong size. Result after 24h and a few 100.000 packets

0

Okay, incomming packets get merged by the stack, fine, how about outgoing packets? A packet larger than 800ish bytes closes the client, so lets send an attack packet with the size 900 and split it in two 400's.

Result: Client closes after the 2nd packet. Now, this is my problem right here which makes me question my entire research.

WinPCAP and Wireshark locked and loaded.

Turns out any packet larger than 569 bytes gets split. The maximum packetsize i can transmit is 569 bytes. my mtu is 1500 on both OS and Router. I'm really lost at this point.

That's what the documentation says, but that's not true in practice. You will find occasionally that packets are split, not because of the stack but because you read x bytes from the stack, not x packets.

If you know the exact length of a packet, and which packet is incoming then you can read a full packet without worrying about it, of course you don't know what the client will send next so that isn't possible.

There are other ways to do it of course, you can read the header and then the packet's body in sequence, this ensures that you receive complete packets every time.

Also for sending packets, your problem isn't necessarily with understand sockets, or packet splitting but the client itself. The client may simply have been written in a way that doesn't accept packets which are deliberately split.

Don't forget that if you physically send two byte[]s as two separate sends then in TCP/IP terms they are two different packets, not one. So they won't be recombined by the stack at the other end.

The client may also be written with a specific maximum incoming packet size in mind.

So a lot of things for you to consider.

Quote:

Originally Posted by Korvacs Don't forget that if you physically send two byte[]s as two separate sends then in TCP/IP terms they are two different packets, not one. So they won't be recombined by the stack at the other end.

No, actually these "packets" can, and often will, depending on things like size and time between each send, be combined and thus the receiving end has to split the two packets apart.

On Linux:
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by Best Coder 2014 No, actually these "packets" can, and often will, depending on things like size and time between each send, be combined and thus the receiving end has to split the two packets apart.

They can be, but that's all determined at much lower levels, it's equally possible and probable that they will be sent separately. Really you should avoid deliberately splitting your packets as a proof as there's a lot of issues that could occur beyond your control. So for the purposes of this they should be considered separate.

But yeah if any TCP/IP experts want to go into detail feel free, it's not really my area.

Quote:

Originally Posted by Korvacs They can be, but that's all determined at much lower levels, it's equally possible and probable that they will be sent separately. Really you should avoid deliberately splitting your packets as a proof as there's a lot of issues that could occur beyond your control. So for the purposes of this they should be considered separate. But yeah if any TCP/IP experts want to go into detail feel free, it's not really my area.

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

What do you mean you should deliberately avoid splitting your packets?

Quote:

Originally Posted by Best Coder 2014 [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] What do you mean you should deliberately avoid splitting your packets?

As in for the sake of trying to understand how the client behaves, you shouldn't deliberately take an 800 byte packet and split it in two and send two halves. Because that's not how the server would send it typically, there's no guarantee that the client will receive it as a whole packet, and there's no guarantee how the stack will behave.

Quote:

Originally Posted by Korvacs As in for the sake of trying to understand how the client behaves, you shouldn't deliberately take an 800 byte packet and split it in two and send two halves. Because that's not how the server would send it typically, there's no guarantee that the client will receive it as a whole packet, and there's no guarantee how the stack will behave.

But we were talking about packets being "merged", not split, though.