I develop a replicate application using isis2. It works by connecting two hosts running the application through a router. I tried connecting these two hosts by a ethernet cable end-to-end, but it failed. Following is error exception:
MCMD SockSetup failed: error <System.Net.Sockets.SocketException: Network subsystem is down
at System.Net.Sockets.Socket.SetSocketOption (SocketOptionLevel optionLevel, SocketOptionName optionName, System.Object optionValue) [0x00000] in <filename unknown>:0
at Isis.MCMDSocket.MCMDSockSetup (System.Net.IPAddress theIPAddr) [0x00000] in <filename unknown>:0 > MCMD Mapping:
Group [ORACLE]: rate = 0 VirtIPAddr=224.0.19.136, mapped to 224.0.19.136
Is it possible to work? Is this connection incompatible with IP multicast?
Well, as configured, your system thinks the Ethernet port is not able to support IP multicast. You have two options. One is to fix the configuration (and you would also need to make sure iptables is configured to allow the packets through, or disabled). The other option is to just use the Isis2 options for running via UDP only, or even via TCP only if you are on a platform that disallows UDP communication.
Related
I have two Azure VMs I set up to test a program I made. The program is to be run on both VMs, where synchronous operations are performed, requiring the VMs to communicate with eachother on different ports using TCP protocols. To access my Azure VMs, I SSH'd into them on port 22 using Putty on my local machine. The VMs are on the same subnet, and I am trying to get them to communicate with eachother via their public IP. I have set up both VMs inbound rules to accept messages from eachother on any port, using any protocol here is an example of this.
During the execution of my program, I encounter the following error "Unable to connect to remote host: Connection refused". After this, I did some investigating. First, I had both VMs ping eachother, which they successfully did. Then, on both VMs, I ran the command "telnet other.ip 22", where other.ip is the other VMs public IP. This seems to work, as seen in this image. When I run "telnet other.ip 6000", or any other port besides 22 for that matter, I get the same error of "Unable to connect to remote host: Connection refused". My rational is that if I can get the "telnet" command running on any port, that my program will likely work too.
I am not too sure what my issue could be at this point, and my internet searches have not helped me. I doubt there is an issue of a port being backlogged with communication requests given my current inbound rules. Also, I did try to change my inbound rules so that my VMs would receive messages on any port, using any protocol, from any source, which resulted in the same error (I then changed it back from 'any source' to only my other VMs public IP for security purposes).
According to your description, you may check two points:
If there is any firewall inside the VM that is blocking the connection from the external network with port 6000. For example, if you are using Ubuntu VM, you can refer to How to Set Up a Firewall with UFW on Ubuntu 18.04. Then disable the firewall with the command sudo ufw disable or add a firewall rule to verify this.
Run the command on Linux to see open ports. sudo netstat -tulpn | grep LISTEN. You should see port 6000 in the output. If not, it might mean that your program is not started well.
Let me know if you have any concerns.
Check your firewall rules. If your organization tent to use firewall then add port 6000 in inbound and outbound chain.
you can connect the remote host with port number only when it is in listening state.
sudo netstat -tulpn | grep LISTEN.
I am working in a Linux Debian 7 distribution.
I programmed a very simple procedure to test onc-rpc.
The 'remote' call works fine when I call it this way:
test_client localhost
However, when I invoke it by calling a remote server IP:
test_client 202.170.91.155
I get an error message:
202.170.91.155: RPC: Port mapper failure - RPC: Unable to receive
I am just learning and I know almost nothing about portmapping in Linux.
The IP I was trying to call for the service is the IP address of the same machine. I speculate the rpcbind daemon does the necessary mapping for the server when you register a new service, but I really have no clue.
Which steps should I take in order to fix this error?
In the end, the issue has nothing to do with programming.
This kind of error may appear when the rpcbind daemon (In charge on giving information about the port where the requested service is listening) does not give a response to the calling machine.
This can happen due to errors in NAT or firewalling.
So, a first attempt to diagnose the problema, as with anything regarding networking, could involve verifying the connection is fine by making ping to every interface involved, from closest to furthest, making sure each jump works fine.
For instance, in the issue decribed above: Pinging the supposed internal server ip address (it failed) helped to discover that the machine was using an IP other than the intended (the one mapped to receive request to port 111).
Stopping and restarting eth0 configuration with ifdown/ifup correctly updated ipv4 info, effectively making reachable the rpc service.
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 got a problem with Azure Endpoint using Ubuntu.
SYMPTOMS
Online port scanner reported that port 1194 is closed even though the End point was defined to be open at Azure Web Interface for that VM
SETTINGS:
UFW, aka Ubuntu Firewall is inactive.
No IP Table was defined in Ubuntu
On Azure web management interface, endpoint called VPN, port TCP 443 and UDP
1194 was set to open, bidirectional allowing direct return. Public and Private port is both 1194, and both 443
lfor and netstat on ubuntu reported thata service is listening on 1194, got NC to listen to 443
DIAGNOSIS
From Ubuntu, I can see the internet. Pinging Google, getting updates works fine.
I can remote into the machine using default port 22, which is a default open endpoint defined by Azure Ubuntu Image
Restarted Ubuntu everytime a setting change.
Tried deleting and re-creating Endpoint rule, failed
Tried shutting down the VM, and delete and recreate endpoint rule, failed
I CAN Telnet to my local host from Ubuntu via 443.
TROUBLESHOOTING STEPS DEFINED
From my local computer, unable to telnet to the Ubuntu server via 443. Ok on 22, terminated because of protocol mismatch, but that is of course fine.
Online port scanners all report that 1194 was closed and so is 443
Some help would be appreciated.
I think that you need to manually configure the endpoint.
Please check https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/?rnd=1 for more information.
I hosting a dedicated Server(win2008 Standart). IIS is installed. There are several Websites bound to different ports(eg SharepointServicesCentralAdministration to 17012).
Every website work well if is bound to port 80 but if i change the port i get timeout (connection via internet) - local it works well.
(Hardware and software firewall are down.)
For some additional test a c# TcpClient Instance is listening on port 12345. If i try connect via internet i get exception:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond xxx.xxx.xxx.xxx:12345 - seems the same issue...
Any idea what could be wrong?
You most likely have port 80 forwarded to your machine from your internet bordering router/firewall.
You would need to have the other ports forwarded as well in your router/firewall for these other ports to work.
This also assumes you already opened the local firewall ports as you mentioned above, which is also required!
Is it possible for other computers in the local subnet to connect? Probably only the local subnet is allowed. The setting needed for ip-restrictions has to be installed: http://www.hrzdata.com/node/46