I'm running an ubuntu 14.04 instance on amazon ec2- I can't seem to send any udp packets from my instance to my local machine.
Running the followings commands:
On amazon ec2 instance:
echo "test" | netcat -vu m.y.i.p 5500
Connection to m.y.i.p 5500 port [udp/*] succeeded!
On my local machine:
netcat -luv 5500
Listening on [0.0.0.0] (family 0, port 5500)
So we successfully make a connection, but I never receive the test packet on my local machine.
Is there anything else I might need to configure with my instance for this to work?
A UDP transmission does not have a connection (as does TCP) so the message "Connection to m.y.i.p 5500 port [udp/*] succeeded!" doesn't really tell you much about the true success of the transmission of a packet from A to B. It might have never even left the originating machine (due to some firewall rule).
In my experience most common UDP problems are firewall blocks at the incoming machine so you certainly need to check on any firewall rules that might be blocking UDP incoming on port 5500.
If that looks ok, then the easiest way to debug is to use a packet sniffer (tcpdump, wireshark or similar). First confirm that a UDP packet is leaving your source machine, then try to see it incoming on the target machine.
tcpdump host m.y.i.p
Related
I am trying to send UDP datagrams from an Azure VM which has a public IP and a security group that has Outbound connections setup for UDP (actually for Any protocol) but I do not get the datagrams on the remote computer.
I can receive UDP datagrams on the VM with no issue.
Priority Name Port Protocol Source Destination Action
100 Any 1-65000 Any Any Any Allow
To test I am using UDP Sender/Receiver.
How can I make this work?
You could check if the remote computer is listening on the same UDP port and binds with IP address 0.0.0.0. Also, the UDP and port should be allowed in the inbound rule in the firewall of remote computer. Please note that Azure supports the UDP networking protocol but does not support UDP broadcasting. You could get more explanation in this blog. You could also get more references in this answer.
Hope this information could help you.
This is what I am trying to do:
I have a windows computer and a Linux computer (ubuntu 16.10) connected to the same wireless router. The router is not connected to the Internet, as this might raise some security concerns (and we don't want the windows computer to talk to the net).
The windows computer is running a program that is supposed to stream data to an UPD port (say port 1234). Using the Microsoft TCPView utility I can see that the windows machine opens the port. In fact, it should allow connections from any IP address and any port (that's what the *'s mean in TCPView).
View of the TCPView Utility
When I try to find the open port on the windows machine from the Linux computer using nmap this is what happens:
Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-30 16:50 EST
Nmap scan report for 192.168.0.164
Host is up (0.051s latency).
PORT STATE SERVICE
1510/udp open|filtered mvx-lm
MAC Address: 74:DE:2B:D8:26:24 (Liteon Technology)
At the very least, this tells me that the linux machine can see the windows machine (I can also ping it). However, I am not sure about the open|filtered state of the port. According to the Nmap manual:
Nmap places ports in this state when it is unable to determine whether
a port is open or filtered. This occurs for scan types in which open
ports give no response. The lack of response could also mean that a
packet filter dropped the probe or any response it elicited. So Nmap
does not know for sure whether the port is open or being filtered. The
UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.
When I try to connect to the port using Python, an error occurs. This code
import socket
UDP_IP = "192.168.0.164"
UDP_PORT = 1234
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
results in an error 'connection refused'. A little C++ client program that is supposed to read out the streamed data also fails to connect to the port. I am using Python now to test the accessibility of the port more quickly.
In contrast, connecting to TCP port 8080 works fine. Also, I have been sending data back and forth over TCP through the same router between other machines and using a range of ports.
Other important info:
The same errors occur if I switch off the firewall and virus scanner on the windows machine
I have added UDP port 1234 as an allowed connection in the advanced firewall settings of windows.
So, my questions are:
Does anybody have any suggestions about how to debug/solve this situation?
What's different between UDP and TCP that would cause TCP to work without a hiccup (in my past projects) and causes UDP to give me nightmares?
You are forgetting that UDP is not a connection-based protocol. It is a datagram protocol.
There is no way to distinguish between a server that is receiving UDP packets but not responding to them, from a server which is behind a firewall which drops those packets. This is why nmap is describing a port as open|filtered -- there is no way for it to tell the difference.
Your call to sock.bind is failing because you are trying to bind (that is, to start listening for packets!) to a port on a remote IP. This is impossible in general.
It turns out that my problems were two-fold
1) I did have a bad understanding of the UDP protocol. That's been rectified by the answers in the forum. For anyone interested in how to use UDP and Python to communicate between two computers, see this recipe: http://code.activestate.com/recipes/578802-send-messages-between-computers/
2) The windows program that I was trying to communicate with can not be used to to send data over UDP through wifi. Why? I don't know. I called the developer and that's what he told me.
Current status: the problem is not solved but is diagnosed as a combination of my lack of knowledge and an ideosyncratic windows program (see my original post above)
You are trying to bind to a non-local IP address. Use 0.0.0.0 instead of the target address you're using, and connect() or sendto() the target address.
I am running a simple UDP server using Nodejs's dgram module.
Relevant code is simply:
server = dgram.createSocket('udp4');
server.bind(10022,'127.0.0.1');
When I netstat on the local machine, using this:
sudo netstat -l
I see this entry:
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 localhost:10022 *:*
When I do a nmap from a remote machine using the IP address of the interface:
sudo nmap -sU -p 10022 192.168.7.171
I see this:
Nmap scan report for 192.168.7.171
Host is up (0.00032s latency).
PORT STATE SERVICE
10022/udp closed unknown
I have UDP client code running on the same machine which works fine when I use server.bind(10022,'127.0.0.1'), as done above. It does not when I use the real IP address assigned to the interface.
I also want to use the client code from a remote machine. So, when I use server.bind(10022, '192.168.7.171') in place of server.bind(10022,'127.0.0.1'), I would have expected to be able to send messages to the UDP process from a remote machine. I cannot. Interestingly the send function's callback, in the remote machine, does not return an error either.
How do I get the client code on the remote machine send message to the UDP server. All firewalls were shutdown for testing because I initially suspected it to be a firewall issue. In any event, both the machines are on a local intranet during testing.
The address parameter of bind() is optional, you can try to listen to all local addresses (0.0.0.0) by omitting it but still specify the port. Eg:
server.bind(10022);
Regarding the missing error UDP is by default a not reliable protocol, the transmission will be treated as successful when it's sent on the wire. UDP does not send back and acknowledgement packet, if you need a reliable channel you can use TCP.
My ubuntu machine's wireless interface is connecting to the wireless router. I wrote a simple web server listening on port 8888. I would like to understand how the packets are sent and receive using localhost. So I did the following experiment:
I started wireshark on the same machine listening wlan0 and on the terminal I type:
$telnet localhost 8888
Then I observe TCP SYN, SYN/ACK, ACK. In these messages, the MAC src and dest addresses are all 00:00:00:00:00:00. The src and dst IP addresses are all 127.0.0.1.
Does this mean these packet never go out from my wlan0 interface to the wireless router and directly loop back within my machine? Does it even reach my wireless card or just looping back within the ubuntu linux OS?
The packets to localhost do NOT 'go out on wire'; i.e. the packets are send to receive buffers locally by the network driver.
IF you telnet to local server IP, then the packets do go out on wire. e.g. telnet 192.168.100.1 would make packets go out on wire.
I am working on a user space tcp stack (mostly just for fun) and I am having some trouble testing it against the unix tcp stack. Currently the only form of testing is done via unit tests. However, I want to test my tcp stack against a real kernel tcp stack. I tried the following setups without much success.
using raw sockets: I wrote a simple echo tcp server that accepts connection using the kernel tcp socket. The tcp server listens to port 8080 on localhost. My tcp client uses the user space tcp stack. However, the kernel sends a tcp rst whenever the client sends a syn to the server. It kind of work after I modified iptable to drop all tcp rst packets. However, even though the 3 way syn, syn+ack, ack handshake is established, the server cannot recv any packet that my client sends. I eventually gave up on raw sockets.
using tun/tap: Similarly the echo server uses kernel tcp socket and listens on localhost port 8080. The client opens a tap device. The tap device has an ip of 10.0.0.1 and my client assumes an ip of 10.0.0.2. I am able to ping 10.0.0.2 from my computer. However, when my client sends a syn to the tcp server over the tap device, the server does not respond.
Note: I am using ubuntu 12.04.
You can use the conntrack tool to try getting more information on why it's not working with using raw sockets. If for some reason the kernel gets confused about the state of the tcp connection, it may be deciding to reset it. You could try telling the kernel not to track connections to rule this out by setting a notrack rule in the raw table. Something like
iptables -t raw -A PREROUTING -p tcp --port 8080 -j NOTRACK
Try using tcpdump on the tun/tap device and iptables counts to see where the packet gets dropped. I would also try tun devices instead so you only have to worry about layer 3.