Reading TCP Sequence Number Before Sending a Packet - c

I'm writing a C/C++ client-server program under Linux. Assume a message m is to be sent from the client to the server.
Is it possible for the client to read the TCP sequence number of the packet which will carry m, before sending m?
In fact, I'd like to append this sequence number to m, and send the resulting packet. (Well, things are more complicated, but let's keep it that simple. In fact, I'd like to apply authentication info to this sequence number, and then append it to m.)
Moreover,
is it possible for the server to read the TCP sequence number of the packet carrying m?

You can do something very nearly equivalent to this. You can count all the bytes you send and put a count of all the bytes sent before the message at the end of your message.
I get really nervous anytime anybody talks about 'packets' with TCP. Because if you talk about packets and TCP at the same time you are mixing protocol levels that shouldn't be mixed. There is no meaningful correspondence between data you send in TCP and the packets that are sent via IP.
Yes, there are sequence numbers in IP packets used to send TCP information. These sequence numbers are a count of the number of bytes (aka octets) sent so far. They identify where in the stream the bytes in the packet belong, but they are otherwise unrelated to the packet.
If a resend happens, or if you're using the Nagle algorithm, or if the TCP stack feels like it that day, you may end up with two send operations ending up in the same packet. Or, you might end up with half of one send operation ending up in one packet, and half in another packet. And each of those packets will have their own sequence numbers.
As I said, there is absolutely no meaningful relationship between send operations you perform at the transport layer and the packets sent at the network layer. I'm not talking theoretically either. It's not 'really all packets underneath and the send generally, barring some weird condition, puts all the bytes in a single packet'. No, the scenarios I outlined above where the bytes from a single send operation are spread to multiple packets happen frequently and under unpredictable conditions.
So, I don't know why you want to know anything about the sequence numbers in packets. But if you were using the sequence number as a proxy for number of bytes sent, you can keep that count yourself and just stuff it into the stream yourself. And remember to count those bytes too.

no, you can't do that -- at least not with expected result
This is because:
TCP is stream based, not packet based.
TCP sequence number is in byte, not packet.
Underlying TCP layer do the segmentation for you.
TCP window size / packet size are dynamic
These means you might send a "packet" with the sequence number at the end of "packet". It turns out, the underlying magics re-segment your packet.
What you want:
1 2 3 4
+---+---+---+---+
| A | B | C |"1"| packet 1, seq=1, len=4
+---+---+---+---+
5 6 7 8
+---+---+---+---+
| A | B | C |"5"| packet 2, seq=5, len=4
+---+---+---+---+
What you might get:
1 2 3 4
+---+---+---+---+
| A | B | C |"1"| packet 1 (seq=1, len=4)
+---+---+---+---+
(packet 1 got lost)
1 2 3 4 5 6
+---+---+---+---+---+---+
| A | B | C |"1"| A | B | packet 1, resent, seq=1, len=6
+---+---+---+---+---+---+
7 8
+---+---+
| C |"5"| packet 2, seq=7, len=2
+---+---+

TCP/IP stack does all the things for you. You receive only payload. Stack removes all the headers and provides payload at user space.
If you really want to add or modify at packet header level, try out RAW sockets. RAW sockets receives/sends packet directly from Network card irrespective of transport type (TCP or UDP). In this case you have to strip/add all the headers (TCP/UDP Header, IP Header and Ethernet Header) with your payload.
Checkout a very good video tutorial on RAW Sockets

Related

Sending multiple Package very fast in C

I'm trying to do a multiplayer game in c, but when I send multiple package like "ARV 2\n\0" and "POS 2 0 0\n\0" from the server to the client (with send()), when I try to read them with recv(), he only found 1 package that appear to be the 2 package in 1..
So I'm asking, is that normal ? And if yes, how could I force my client to read 1 by 1 the packages ? (or my server to send them 1 by 1 if the problem come from the call send)
Thanks !
Short answer: Yes, this is normal. You are using TCP/IP, I assume. It is a byte stream protocol, there are no "packets". Network and OS on either end may combine and split the data you send in any way that fits in some buffers, or parts of network. Only thing guaranteed is, that you get the same bytes in same order.
You need to use your own packet framing. For text protocol, separate packets with, for example, '\0' bytes or newlines. Also note that network or OS may give you partial packets per single "read", so you need to handle that in your code as well. This is easiest if packet separator is single byte.
Especially for a binary protocol where there are no "unused" byte values to mark packet boundaries, you could write length of packet as binary data, then that many data bytes, then again length, data, and so on. Note that the data stream may get split to different "read" calls even in the middle of the length info as well (unless length is single byte), so you may need a few lines more of code to handle receiving split packets.
Another option would be to use UDP protocol, which indeed sends packets. But UDP packets may get lost or delivered in wrong order (and have a few other problems), so you need to handle that somehow, and this often results in you re-inventing TCP, poorly. So unless you notice TCP/IP just won't cut it, stick with that.

Getting signal strength of received packet in wireless OCB mode

I am using OCB mode based on ath9k driver for my wireless connections between different nodes. I need to know the signal strength of received packets in my user-space application to do some calculation based on that. In order to communicate I am using socket APIs and udp packets.
So, here is the question: Is there any function or API in C to get signal strength of a received packet in a user-space application?
I don't know if the signal strengh "of a received packet" really makes sense, but you can get some information on the wifi signal where you are connected by reading /proc/net/wireless
$ cat /proc/net/wireless
Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 69. -41. -256 0 0 0 1 274 0
Generally speaking, /proc provides runtime information about your system. Technically speaking, if you wish to read this from a C program you should probably try to find if there is an API for this, otherwise read/open/close the file and parse its content. See this thread for details about reading the /proc filesystem.
You should use cfg80211, see http://www.linuxwireless.org/en/developers/Documentation/cfg80211/

Can LoadRunner Receive Data By UDP Packets?

We want to receive packets from udp sockets, the udp packets have variable length and we don't know how long they really are until we receive them (parts of them exactly, length were written in the sixth byte).
We tried the function lrs_set_receive_option with MarkerEnd only to find it has no help on this issue. The reason why we want to receive by packets is that we need to respond some packet by sending back user-defined udp packets.
Is there anybody knows how achieve that?
UPDATE
The LR version seems to be v10 or v11.
We need respond an incoming udp packet by sending back a udp packet immediately.
The udp packet may be like this
| orc code | packet length | Real DATA |
Issue is we can't let loadrunner return data for each packets, sometimes it returns many packets in a buffer, sometimes it waits until timeout though when there has been an incoming packet in the socket buffer. While in the c programming language world, when calling recvfrom(udp socket) we are returned only one udp packet per time (per call) which is want we really want.
If you need raw socket support to intercept at the packet level then you are likely going to have to jump to a DLL virtual user in Visual Studio with the raw socket support.
As to your question on UDP support: Yes, a Winsock user supports both core transport types, UDP and TCP. TCP being the more common variant as connection oriented. However, packet examination is at layer 3 of the OSI model for the carrier protocol IP. The ACK should come before you receive the dataflow for your use in the script. You are looking at assembled data flows in the data.ws when you jump to the TCP and UDP level.
Now, you are likely receiving a warning on receive buffer size mismatch which is taking you down this path with a mismatch to the recording size. There is an easy way to address this. If you take your send buffer and construct it using the lrs_set_send_buffer() function, then anything that returns will be taken as correct, ignoring the previously recorded buffer size and not having to wait for a match or timeout before continuing.

C: recv() -- distinguish packets

I have a threaded server, usually one thread per client, so whatever packets I receive will be from the same source.
I am designing a protocol based on
struct Packet
{
int Data;
char Data2 [size];
} Packet;
and any other permutations I may need.
The only way I can distinguish between packets so far is based on their size. Since both the server and the client have a the same struct declarations, sizeof(Packet) on the server will be the same as sizeof(Packet) (assuming identical hardware) on the client, and when I call
int bytesReceived = recv(...);
switch (bytesReceived) { (...) }
I can pass on the buffer to a packet-specific function to handle it.
This is imperfect at best, because
Datatype sizes may differ per platform --> a mismatch can occur between server and client
I may have two different packets of identical size.
What is a good workaround this problem? How can I design a protocol in a better way?
Datatype sizes may differ per platform --> a mismatch can occur between server and client
Use types from <stdint.h>, e.g. uint32_t. Also, make sure your maintain your protocol byte-order (little or big endian), so that if platform's byte order is different, you reverse the integers before sending and after receiving.
I may have two different packets of identical size.
Send packet length along with the packet type in your packet header. Something like:
+----------------+--------------+----------------------------+
| message-length | message-type | message-payload |
| 4 bytes | 2 bytes | (message-length - 6) bytes |
+----------------+--------------+----------------------------+

UDP in C: Send 1 million bytes from A to B

I must send 1 million bytes from A to B through UDP protocol.
These 1 million bytes can be an array of random characters. I understood that it's not possible to send packets larger than 65507 bytes, and UDP, as you all know, does not guarantee the arrival of messages.
I thought about sending several characters from A to B, unless B will not reach 1 million. Next, B must send a flag to A as a confirmation. But also here, there aren't any guarantees that the "ack" has reached the A end-system.
There is also an additional end-system C, where I could implement some additional code, if I need to.
I thought to create 2 processes for each end-system, one to send and receive the million bytes, and the second to send and receive the flags.
I have tried to implement it, but I am not very convinced. An important requisite is to avoid busy waiting.
I need a little help to move forward.

Resources