I think the question explains it fully.
Another way to say it: Are the packets read via a raw socket removed from the communication channel completely, so that they are not even delivered to the TCP socket that they were intended for in the first place. For e.g., if there is a web server running on my host, listening on port 80, and I open a raw socket listening for all TCP protocol packets, will the web server never receive those packets being sent to port 80?
Thanks.
From my experience packets read on the raw socket are not removed from the communication. You could even have multiple raw sockets at the same time and all get the same packages. But to cite from Linux: man raw:
Raw sockets may tap all IP protocols in Linux, even protocols like ICMP or TCP which have a protocol module in the kernel. In this case, the packets are passed to both the kernel module and the raw socket(s). This should not be relied upon in portable programs, many other BSD socket implementation have limitations here.
Related
Why was UDP used as the standard protocol in NFS systems up to version 3 and TCP in version 4? Unfortunately, I have not yet found anything about the motives that led to this.
The Red Hat NFS documentation provides some insight about why UDP was preferred:
When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks.
...and why the move to allow and eventually require TCP was made:
However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFS server.
The current RFC also notes that TCP facilitates transport security without needing to tunnel:
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The registered port 2049 [RFC3232] for the NFS protocol SHOULD be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as described in [RFC1833]; this will allow NFS to transit firewalls.
Why TCP specifically? Actually, the RFC says SCTP is also acceptable (though TCP support is mandatory):
Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP). To enhance the possibilities for interoperability, an NFSv4 implementation MUST support operation over the TCP transport protocol.
Finally, addressing performance, the original reason UDP was chosen, the RFC says:
If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short-lived connections and will improve performance for the Wide Area Network (WAN) environment by eliminating the need for SYN handshakes.
Ultimately, only the engineers at Sun Microsystems (as the creators of NFS) know the exact reasons UDP was chosen and only the IETF working group for NFS (as the maintainers) know why the switch to TCP was made.
I'm trying to send a SYN packet that has been received in one network interface into another one on the same host (while changing the IP addresses), using a raw socket.
I'm on Windows Server 2008 R2, and while sending and receiving UDP packets is going very well, when I'm trying to send a TCP packet, the other side just not receiving it (although it shown correctly in Wireshark). The other side normally listens to SOCK_STREAM data.
I've just read in this site that:
Even though you can send TCP packets with a raw socket, the operating system's TCP/IP stack will process incoming TCP and UDP packets. When you send a TCP SYN packet with a raw socket, the destination's response will be rejected by the operating system because it is unaware of the SYN you sent. Therefore, you cannot complete a three-way handshake.
However, Microsoft noted that:
These above restrictions do not apply to Windows Server 2008 R2, Windows Server 2008 , Windows Server 2003, or to versions of the operating system earlier than Windows XP with SP2.
Is it that TCP data cannot be sent over raw sockets? However, if yes, is there a way to establish the TCP connection anyway? Maybe some WinAPI to add the stream identifier?
I'd love to hear any solution for establishing TCP connections with a raw socket. Thanks!
I started to learn Linux Networking and packets filtering. In the iptables documentation it is stated that:
If a packet is destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.
So, suppose there're 3 server apps on a host. Servers A and B are TCP servers, and C is UDP server.
Is it true, that if we receive an UDP packet, at IP level this packet is to be delivered for apps A, B, C? Or sockets of apps A & B wouldn't receive this packet at all?
TCP servers and UDP servers operate in very different ways.
At most one TCP server will listen on a given TCP port (corner cases ignored for the sake of simplicity). Connection requests (encapsulated in IP packets) destined for that port are "accepted" by exactly one process (more accurately, accepted by a process that has a file descriptor corresponding to exactly one listening endpoint). The combination of [remote_address,remote_port] and [local_address,local_port] is unique. A TCP server doesn't really receive "packets", it receives a stream of data that doesn't have any specific relationship to the underlying packets that carry the data (packet "boundaries" are not directly visible to the receiving process). And a TCP packet that is neither a connection request nor associated with any existing connection would simply be discarded.
With UDP, each UDP datagram is logically independent and may be received by multiple listening processes. That is, more than one process can bind to the same UDP endpoint and receive datagrams sent to it. Typically, each datagram corresponds to a single IP packet though it is possible for a datagram to be broken into multiple packets for transmission.
So, in your example: no, a server that is listening for TCP requests (a "TCP server") will never receive a UDP packet. The port namespaces for TCP and UDP are completely separate.
The delivery of the packet will depend on its destination port.
Lets assume that the servers A, B and C are listening on port 1111, 2222 and 3333 respectively, so when a packet with destination port 2222 is arrived, it will be delivered to server B.
My question wasn't well formulated, unfortunatelly. I understood it when I had seen the answers. Here is an explanation which I was looking for, it's from http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html#tth_chAp6: > When the process scheduler sees that there are networking tasks to do it runs the network bottom-half. This function pops packets off of the backlog queue, matches them to a known protocol (typically IP), and passes them to that protocol's receive function. The IP layer examines the packet for errors and routes it; the packet will go into an outgoing queue (if it is for another host) or up to the transport layer (such as TCP or UDP). This layer again checks for errors, looks up the socket associated with the port specified in the packet, and puts the packet at the end of that socket's receive queue.
Can I disable the ACK mechanism for TCP connections. In my country the DPI is activated for VoIP which blocks the remote end IP. (weather used with openvpn or IPsec or etc). However they are not monitoring TCP. the VoIP operates at TCP but the quality is very bad due to ACK function. I did try some DELACK but did not paid me off much. Could it be possible that I can disable the ACK in TCP protocol using some patch or some thing so I can operate VoIP with it. My servers are Linux CentOS based.
No.
TCP without ACK isn't TCP.
If you were to hack the TCP stack somehow and prevent ACKs being sent then all kinds of things would stop working. You would need to adjust your version of TCP to the point where it simply wasn't TCP anymore. You would then need it running at both ends of the connection.
I use raw socket to build a tcp client program and run it on machine A
and I run a regular tcp server program on machine B
the raw socket-based client program first send a SYN packet
and then it receives a SYN/ACK packet from the remote tcp server
then the kernel of machine A sends a RST to the remote tcp server
the sequence number and ack-sequence number is fine
what are potential reasons?
and how to deal with it? thanks!
BTW: I used tcpdump to capture packets on the remote machine B
and it shows "TCP port numbers reused" for the SYN packet from client,
actually before the client send the SYN, I used
netstat -tnp
to check on-going tcp sessions, and it shows nothing
This is perfectly normal. If a machine receives a SYN/ACK packet it doesn't expect, it should respond with a RST to let the other side know that it has no knowledge of or interest in that connection. The kernel sent a RST because that's what it's supposed to do -- it has no idea what your program is doing.
If you're trying to run your own TCP stack on a machine that already has a TCP stack, you'll have to prevent the regular TCP stack from responding to machines your stack is trying to talk to -- otherwise, they'll be talking to two TCP stacks which can't possibly work.