In an application (voip rtp media server), netstat -na on the server (172.16.226.3 bound to udp port 1286) gives the following line :
udp 0 0 172.16.226.3:1286 172.25.14.11:10000 ESTABLISHED
As an udp connection can not be really "established", it strikes me to see such a line. netstat documentation says that this field is used for tcp connection states, but I am sure that this really is an udp network flow. So : what does it means ? I know (wireshark dump) that my server sends back udp packets from 173.16.226.3:1286 to 172.25.14.11:10000, but I don't see why it should matter...
Os is debian 6.
A UDP socket can be connected via the connect(2) system call, so that the socket will only accept packets from the named peer.
I expect this is the source of the ESTABLISHED column.
Related
Iperf3 uses two channels to communicate, one via TCP and the other via UDP.
When its going to communicate to another host, it uses the same port for both channels.
For example: If I tell it to connect to port 3000 on the host, the TCP channel will connect on the host's port 3000
and the UDP channel too.
I need to encapsulate the TCP communication into UDP datagrams, send over UDP to the host on port 3000 and then de-encapsulate
the TCP and demultiplex it so it gets delivered correctly at port 3000.
To achieve this, Im using socat to create a TCP-UDP tunnel like this (this tunnel is working!):
On the sender end:
socat -d tcp-listen:2000,reuseaddr,fork udp:54.226.25.18:3000
On the receiving end:
socat -d udp-listen:3000,reuseaddr,fork tcp:localhost:1080.
OK, now why I'm converting TCP to UDP and then from UDP to TCP again? I'm doing that because I was trying to use socks4, and it works
only with TCP. I was using it to encapsulate the TCP and UDP traffic into TCP, then I convert this TCP stream into UDP and send over
to the host with socat, like this:
On the sender end (tunnel+socks):
socat tcp-listen:2000 socks4a:localhost:54.226.25.18:3000 & socat tcp-listen:1080,reuseaddr,fork udp:54.226.25.18:3000 & nc localhost 2000
On the receiving end (tunnel):
socat udp-listen:3000,reuseaddr,fork tcp:localhost:1080 & nc -l 1080
This solution kinda works, this is what the receiving end receives:
�senderPcName54.226.25.18
But it only receives something the first time, when I send more data with netcat, nothing shows up on the receiving end.
Maybe this is happening because the way Im doing it theres nothing on the other side to open what is encapsulated into TCP and demultiplex it. This is my hunch, I might be wrong.
I tried to think on a solution using socks5 but I dont know how to send things through it (didn't find materials on how to do it) like I do with socks4 in this line:
socat tcp-listen:2000 socks4a:localhost:54.226.25.18:3000
I tried without success to install socat with socks5 support because it lacks files.
You can read about Iperf3's relevant behavior here:
https://github.com/esnet/iperf/issues/1019
Obs: I NEED to tunnel over UDP. And I can only use ONE UDP port.
Any pointers on how to solve this with socks or with something new altogether is greatly appreciated.
Summary of my problem: Iperf3 uses TCP and UDP to work. I can only use UDP. How to tunnel the TCP connection alongside UDP so it works without setting a real TCP connection?
You will need some kind of multiplexer solution to drive both UDP and TCP through the UDP channel.
When you have root privilege on both computers, you can establish a Socat tunnel:
On sending side:
sudo socat -d -d -d -d TUN:192.168.255.1/24,up UDP:54.226.25.18:2000,bind=:2000
On receiving side:
sudo socat -d -d -d -d TUN:192.168.255.2/24,up UDP-LISTEN:2000
You should now be able to ping 192.168.255.2 from sender and 192.168.255.1 from receiver.
For testing UDP, enter on receiver:
socat UDP-LISTEN:3000 -
On sender:
socat - UDP:192.168.255.2:3000
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.
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.
I found netcat is very useful for listening TCP connection by using -l port-number, but I'm wondering if there is a more powerful tool available to analysis all incoming protocol, like RADIUS client request, so I can check out what the request are made of and if server get the request
netstat maybe the way to go with the -c flag, but it doesn't show even tcp connection with custom port number
any idea?
Wireshark offers a command line tool as well as a GUI (http://www.wireshark.org/)
Why don't you use netstat and grep the output to filter only the ports that you need?
The output is similar to this:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 192.168.1.7.63364 64.34.119.101.80 ESTABLISHED
tcp4 0 0 192.168.1.7.63357 64.34.119.13.80 ESTABLISHED
and it is very simple to grep results by protocol, port, address and state.
Bro is a (command-line) tool that extracts a wide range of information from network traffic. It is port agnostic, e.g., can detect HTTP on non-standard ports and features a application parsers for a variety of protocols. The connection log provides a lot of useful information at flow granularity, including:
Timestamp
Connection 5-tuple (source host, source port, destination host, destination port, transport protocol)
Application-layer protocol
Duration
Transport-layer bytes sent (source and destination)
Connection status
Number of packets (source and destination)
See this answer for example output.
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.