0

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?
user207421
  • 305,947
  • 44
  • 307
  • 483
ElenorDavey
  • 247
  • 1
  • 2
  • 7
  • Use quote formatting for text that is quoted. Don't use code formatting for text that isn't code. – user207421 Jan 31 '17 at 02:27
  • "_UDP connection refused_" UDP is a connectionless protocol, so there are no UDP connections. TCP opens connections, but UDP does not. UDP simply sends out a datagram, not even caring that it is seen on the other end. UDP is a best-effort, fire-and-forget protocol, with no guarantees of order or delivery. – Ron Maupin Jan 31 '17 at 02:49
  • @RonMaupin Nevertheless you can get 'connection refused' from UDP in some circumstances. – user207421 Jan 31 '17 at 03:24
  • @EJP, that really makes no sense for a protocol without connections. Someone who came up with the error message didn't understand. – Ron Maupin Jan 31 '17 at 03:26
  • @RonMaupin I couldn't agree more, but here we are. No point in just asserting it isn't so when it is. – user207421 Jan 31 '17 at 03:28
  • Does this answer your question? [Error receiving in UDP: Connection refused](https://stackoverflow.com/questions/2372371/error-receiving-in-udp-connection-refused) – Bora M. Alper Feb 17 '21 at 11:38

3 Answers3

1

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.

  • Thank you for your reply. I can see what you're saying with respect to the nmap result. However, I believe I should still be able to connect to the UDP port, as shown here: https://wiki.python.org/moin/UdpCommunication – ElenorDavey Jan 31 '17 at 02:07
  • 2
    @DonDavey: note that the call to `bind` in that example uses `127.0.0.1` as the IP address, i.e., localhost. Unless I'm mistaken, your code instead specifies the IP address of the remote machine, and that's why it isn't working. – Harry Johnston Jan 31 '17 at 02:22
  • You're right about the IP address. The example I linked to runs entirely on a single local machine. However, isn't the whole point about UDP to communicate between machines? So, there should be a way of getting whatever the remote application is trying to stream over UDP port 1234, no? – ElenorDavey Jan 31 '17 at 02:42
  • You also have to know how to tell the other computer(s) to start sending you packets. You don't tell us what software the remote computer is running, but if it implements a specific standard (bittorrent, for example) you'll need to look up documentation for that standard, otherwise the software's own documentation should explain how to use it. – Harry Johnston Jan 31 '17 at 03:03
  • I just had an epiphany about the UDP protocol. I've been reading this example: http://code.activestate.com/recipes/578802-send-messages-between-computers/. From this it seems that the sender must directly send the data to the receiver. The receiver opens a local port and reads in the data. That would mean that, to go back to my original problem, the windows computer that runs a program that is supposed to stream data to an UPD port should **stream this to the IP address/port of the linux computer that is supposed to receive the data**. The linux computer then connects to a local port. Right? – ElenorDavey Jan 31 '17 at 03:13
  • @duskwuff You have to bind to a port *and IP address* on your local system, and you can use INADDR_ANY for the IP address. AF_UNSPEC has nothing to do with it: indeed, it would rule out UDP. And UDP being connectionless has nothing to do with this problem. Only your final paragraph is actually relevant. – user207421 Jan 31 '17 at 03:20
  • *The linux computer then connects to a local port.* - no, it *binds* to a local port. The distinction is important. – Harry Johnston Jan 31 '17 at 03:22
  • @EJP Whoops, brain fart. You're right, of course — I meant INADDR_ANY, the _other_ wildcard socket value. –  Jan 31 '17 at 04:26
1

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)

ElenorDavey
  • 247
  • 1
  • 2
  • 7
0

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.

user207421
  • 305,947
  • 44
  • 307
  • 483