What I do:
Use scapy to send/receive a UDP-Datagram from a server
(192.168.1.2)
The server replies with a UDP-Datagram to the source port of the received UDP-Datagram
This works fine, however, the client always sends a ICMP "Destination unreachable (Port unreachable))" after the datagram was successfully received.
Scapy command run on the client:
pkt = IP(dst='192.168.1.2')/UDP(sport=49000, dport=50991)/Raw(udp_command_bytes)
rec = sr1(pkt)
I have a POXIS based application using sockets that does the same thing and there is no ICMP response sent. What is the problem with the above scapy command? Shouldn't it listen on port 49000 for the response?
Scapy is not meant to 'listen' on the UDP port but rather 'sniff/spy' on it (cf. https://scapy.readthedocs.io/en/latest/introduction.html#scapy-decodes-it-does-not-interpret)
This means that the running TCP/IP stack is not aware that scapy is also receiving the packets, therefore, if it does not see a consumer, depending on your stack configuration (cf. https://serverfault.com/questions/522709/disable-icmp-unreachable-replies), it can decide to send an indication that the UDP packet did not reach a consumer (your extra ICMP message containing the UDP port unreachable indication).
As a workaround, you can simply open a shell and do:
netcat -lkfu 49000
This will ensure that your system has a consumer for this port and you can still use scapy to handle all the incoming traffic.
Related
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.
My friend told me that TCP doesn't need port forward.
What exactly he said is if the server is port forwarded the client can request something and the server will respond without port forward.
And I agreed with that even though I'm not sure it is true.
Later he said it is the same with UDP which I do not believe.
MAINLY THE QUESTION IS
If a client requests something on a server with TCP, does it need to be port forwarded to receive the response?
Also is it the same for UDP?
If the request from the client is a SYN for connect call then only a SYN-ACK response will be allowed through NAT. If the NAT supports simultaneous open connection then a SYN response from server will also be allowed through NAT. After the connection is established then client and server can communicate freely without any restriction. Port forwarding is not needed.
For UDP after a packet from client to server is sent then anything from server can be received through exact same public port of the NAT from which the first packet was sent. No port forwarding needed.
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.
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.
Some things look strange to me:
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
How should each part of the foreign address be read (part1:part2)?
What does a state Time_Wait, Close_Wait mean?
etc.
Could someone give a quick overview of how to interpret these results?
0.0.0.0 usually refers to stuff listening on all interfaces.
127.0.0.1 = localhost (only your local interface)
I'm not sure about [::]
TIME_WAIT means both sides have agreed to close and TCP
must now wait a prescribed time before taking the connection
down.
CLOSE_WAIT means the remote system has finished sending
and your system has yet to say it's finished.
I understand the answer has been accepted but here is some additional information:
If it says 0.0.0.0 on the Local Address column, it means that port is listening on all 'network interfaces' (i.e. your computer, your modem(s) and your network card(s)).
If it says 127.0.0.1 on the Local Address column, it means that port is ONLY listening for connections from your PC itself, not from the Internet or network. No danger there.
If it displays your online IP on the Local Address column, it means that port is ONLY listening for connections from the Internet.
If it displays your local network IP on the Local Address column, it means that port is ONLY listening for connections from the local network.
Foreign Address - The IP address and port number of the remote computer to which the socket is connected. The names that corresponds to the IP address and the port are shown unless the -n parameter is specified. If the port is not yet established, the port number is shown as an asterisk (*). (from wikipedia)
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
0.0.0.0 indicates something that is listening on all interfaces on the machine.
127.0.0.1 indicates your own machine.
[::] is the IPv6 version of 0.0.0.0
My machine also shows *:\* for UDP which shows that UDP connections don't really have a foreign address - they receive packets from any where. That is the nature of UDP.
How should each part of the foreign address be read (part1:part2)?
part1 is the hostname or IP addresspart2 is the port
127.0.0.1 is your loopback address also known as 'localhost' if set in your HOSTS file. See here for more info: http://en.wikipedia.org/wiki/Localhost
0.0.0.0 means that an app has bound to all ip addresses using a specific port. MS info here: http://support.microsoft.com/default.aspx?scid=kb;en-us;175952
'::' is ipv6 shorthand for ipv4 0.0.0.0.
Send-Q is the amount of data sent by the application, but not yet acknowledged by the other side of the socket.
Recv-Q is the amount of data received from the NIC, but not yet consumed by the application.
Both of these queues reside in kernel memory.
There are guides to help you tweak these kernel buffers, if you are so inclined. Although, you may find the default params do quite well.
This link has helped me a lot to interpret netstat -a
A copy from there -
TCP Connection States
Following is a brief explanation of this handshake. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. Note that this notation does not reflect Client/Server relationships as an architectural principal.
Connection Establishment
The client sends a SYN message which contains the server's port and the client's Initial Sequence Number (ISN) to the server (active open).
The server sends back its own SYN and ACK (which consists of the client's ISN + 1).
The Client sends an ACK (which consists of the server's ISN + 1).
Connection Tear-down (modified three way handshake).
The client sends a FIN (active close). This is a now a half-closed connection. The client no longer sends data, but is still able to receive data from the server. Upon receiving this FIN, the server enters a passive close state.
The server sends an ACK (which is the clients FIN sequence + 1)
The server sends its own FIN.
The client sends an ACK (which is server's FIN sequence + 1). Upon receiving this ACK, the server closes the connection.
A half-closed connection can be used to terminate sending data while sill receiving data. Socket applications can call shutdown with the second argument set to 1 to enter this state.
State explanations as shown in Netstat:
State Explanation
SYN_SEND Indicates active open.
SYN_RECEIVED Server just received SYN from the client.
ESTABLISHED Client received server's SYN and session is established.
LISTEN Server is ready to accept connection.
NOTE: See documentation for listen() socket call. TCP sockets in listening state are not shown - this is a limitation of NETSTAT. For additional information, please see the following article in the Microsoft Knowledge Base:
134404 NETSTAT.EXE Does Not Show TCP Listen Sockets
FIN_WAIT_1 Indicates active close.
TIMED_WAIT Client enters this state after active close.
CLOSE_WAIT Indicates passive close. Server just received first FIN from a client.
FIN_WAIT_2 Client just received acknowledgment of its first FIN from the server.
LAST_ACK Server is in this state when it sends its own FIN.
CLOSED Server received ACK from client and connection is closed.
For those seeing [::] in their netstat output, I'm betting your machine is running IPv6; that would be equivalent to 0.0.0.0, i.e. listen on any IPv6 address.