I'm writing a soft for a microchip that will send some data via Ethernet and I've encountered a problem. I'm sending a TCP SYN segment and I have no answer from the server.
Everything looks fine, the only one difference between packets that gain answer and my ones is that my packets have no options (the pool described as optional). Are there some options that should be defined for SYN to work properly?
(If anyone know how to copy a packet from wireshark in a nice form I'll show you my packet.)
Make sure that your tcp header padding bytes are set to all 0's or 0xff
As cxxl mentioned in a comment the problem was incorrect TCP checksum.
Related
so I'm working on a project where the program can detect when its being scanned for malicious purposes by checking how many ports are being scanned at the same time and scanning them back using the SYN method and I would like to know if the TCP or UDP protocol is better for a so called "counter-scan" to the target without getting noticed I have some ideas like:
I can send them using UDP and the attacker wouldn't notice them .
using the TCP method use the existing 3 way handshake to mask the
SYN packets with his responses
sorry I have no source code since I'm still brain storming
Yes, UDP scan can be done by looking at ICMP (NOT IMCP) port unreachables, but these are often filtered.
I guess UDP would not be less "noticed"--TCP does more harm since it needs state saved (waiting for ACKs).
(nit: please work on your English)
This question was posted on StackExchange - NetworkEngineering. People suggested me to post it here. Here is my original post.
I am trying to write a client that initiates a TCP connection and sends some data. On the server side, I am using nc that listens to a certain port. Now I am able to complete the 3-way handshaking. netstats shows that the connection is established. However, after my client starts sending data, it never gets an ACK.
The client is implemented on top of DPDK, and thus bypasses the kernel stack. The server binds to a different NIC. The two NICs are directly connected. The TCP part is handled by my own code. Due to the lack of knowledge, the implementation is greatly simplified in the sense that I set a lot of fields to some fixed numbers, such as the window size.
As a newbie in networking, I have no clue what could go wrong, and thus not sure what information I should provide to help you identify the problem. Here is a screenshot from wireshark. My client is at 192.168.0.10:12345 and my server listens at 192.168.0.42:3456. No ACK is sent from the server side after packet 6.
Also, the reason for the incorrect FCS is that I had to pad zeros to the SYN and the first ACK packets, so that they are at least 64 bytes, which is a requirement from the client NIC.
I did a comparison between packets from my client and packets from nc client. It seems that for the first data packet, the only real difference is that mine does not have any TCP options, while the nc one carries a timestamp. Could this be the problem?
Please let me know if you spot anything that may cause this no-ACK issue.
TCP is stream to communicate and it has varying length. So in the application, how I can know whether the TCP ends or not?
In the transfom layer, The TCP packet header doesn't have a length field and its length is varying, how can the TCP layer know where is the end.
You design a protocol that runs on top of TCP that includes a length field (or a message terminator). You can look at existing protocols layered on top of TCP (such as DNS, HTTP, IRC, SMTP, SMB, and so on) to see how they do this.
To avoid pain, it helps to have a thorough understanding of several different protocols layered on top of TCP before attempting to design your own. There's a lot of subtle details you can easily get wrong.
If you look at this post, it gives a good answer.
Depending on what you are communicating with, or how you are communicating there will need to be some sort of character sequence that you look for to know that an individual message or transmission is done if you plan to leave the socket open.
n the transfom layer
I assume you mean 'transport layer'?
The TCP packet header doesn't have a length field and its length is varying
The IP header has a length field. Another one in the TCP header would be redundant.
how can the TCP layer know where is the end.
From the IP header length word, less the IP and TCP header sizes.
When a party of a TCP connection receives a FIN or RST signal it knows that the other side has stopped sending. At an API level you can call shutdown to give that signal. The other side will then get a zero length read and knows that nothing more will be coming.
I'm doing a research project, which needs to split tcp connection. so I have some pecular questions, which may happen in my development. The problem is understanding of TCP SACK-permitted negotiation. I read the RFC and can't find answer there.
For 3-way tcp handshake between two tcp programs: A and B. if A send a TCP SYN to B with SACK-permitted, will B surely respond a SYN/ACK packet with SACK-permitted? if B reply with a TCP SYN/ACK without SACK-permitted, does it mean
1) SACK-permmited is enabled only on A. A can selectively acknowledge tcp packets from A, but A can't selectively acknowledge tcp packets from B.
or
2) SACK-permmited is not enabled on both A and B
if A sends a TCP SYN to B without SACK-permitted, may B respond a SYN/ACK packet with SACK-permitted?
besides, why SACK-permitted is allowed or disallowed? it depends on the Operating system or kernel setting or something else? is it possible to control it? thanks!
The following should help you: TCP Selective Acknowledgements
To answer your question though (possible to control it), it all depends on "what you have control over." E.g., For Windows you CAN control it however, you have to ENABLE it. So if you're controlling both ends of the TCP session, the answer is yes. Obviously, if you don't control the other end, nothing you can do. So imagine you enable it on your end (controllable) but the destination (let's say a website) is not honoring SACKs, it ends up being a waste of time to an extent.
Most operating systems allow you to turn if off and on. On FreeBSD (my current desktop) it is on by default, in most variants of Linux, it too is on by default.
is it possible to send multiple tcp or udp packets on a single ip packet? are there any specifications in the protocol that do not allow this.
if it is allowed by the protocol but is generally not done by tcp/udp implementations could you point me to the relevant portion in the linux source code that proves this.
are there any implementations of tcp/udp on some os that do send multiple packets on a single ip packet. (if it is allowed).
It is not possible.
The TCP seqment header does not describe its length. The length of the TCP payload is derived from the length of the IP packet(s) minus the length of the IP and TCP headers. So only one TCP segment per IP packet.
Conversely, however, a single TCP segment can be fragmented over several IP packets by IP fragmentation.
Tcp doesn't send packets: it is a continuous stream. You send messages.
Udp, being packet based, will only send one packet at a time.
The protocol itself does not allow it. It won't break, it just won't happen.
The suggestion to use tunneling is valid, but so is the warning.
You might want to try tunneling tcp over tcp, although it's generally considered a bad idea. Depending on your needs, your mileage may vary.
You may want to take a look at the Stream Control Transmission Protocol which allows multiple data streams across a single TCP connection.
EDIT - I wasn't aware that TCP doesn't have it's own header field so there would be no way of doing this without writing a custom TCP equivalent that contains this info. SCTP may still be of use though so I'll leave that link.
TCP is a public specification, why not just read it?
RFC4164 is the roadmap document, RFC793 is TCP itself, and RFC1122 contains some errata and shows how it fits together with the rest of the (IPv4) universe.
But in short, because the TCP header (RFC793 section 3.1) does not have a length field, TCP data extends from the end of the header padding to the end of the IP packet. There is nowhere to put another data segment in the packet.
You cannot pack several TCP packets into one IP packet - that is a restriction of specification as mentioned above. TCP is the closest API which is application-oriented. Or you want to program sending of raw IP messages? Just tell us, what problem do you want to solve. Think about how you organize the delivery of the messages from one application to another, or mention that you want to hook into TCP/IP stack. What I can suggest you:
Consider packing whatever you like into UDP packet. I am not sure, how easy is to initiate routing of "unpacked" TCP packages on remote side.
Consider using PPTP or similar tunnelling protocol.