We have two computers connected through a local network. Our IP addresses are ip1 and ip2. We are sending to port 1234. When the first computer sends to the second, we execute the command (using sendosc):
[terminal of first computer]$ sendosc ip2 1234 /test i 123
and indeed the second computer receives the message (using protokol).
When the second computer sends an osc to the first one, like so:
[terminal of second computer]$ sendosc ip1 1234 /test i 123
then the first computer fails to receive it. When the first computer sends an osc to itself like [terminal of first computer]$ sendosc ip1 1234 /test i 123, then it works.
The first computer has an xubuntu system running. The ip was retrieved from ifconfig. What could possibly be the issue? Do we need to open a port, like: sudo nc -l -4 -p 1234. But that doesn't seem to solve the issue either.
Related
I have two devices running Node-RED. I'm trying to send data from one to another using Node-RED. For that here's what I've done :
the first device:
So the first one should just send the String "Testing" to the 2nd with IP 100.
On the second here's what I've done:
The problem is I'm not receiving anything, despite port and IP address checks.
Does anybody has a hint about how to solve this ?
It looks like you have configured both TCP (in and out) nodes to "connect" to the other.
This is wrong, you want to have the TCP-in node (on 192.168.178.10) configured to "Listen on" port 80 and then have the TCP-out node (on 192.168.178.100) configured to "Connect to" port 80 on 192.168.178.100.
I have two machines:
Ubuntu 16.04 server VM (172.18.6.10)
Proxmox VE5 station (192.168.6.30)
they are communicating through a third machine that forwards packets between the two. I want to create a gre tunnel between the two machines and to do that and make it persistent I have edited the /etc/network/interfaces and added a gre interface and tunnel to be made on boot up as the following:
After they were created I have tried to ping one machine from the other to check connectivity, pinging the gre interface IP address (10.10.10.1 and 10.10.10.2). The issue is that when I ping the Proxmox machine from Ubuntu I get no feedback, but when I run tcpdump on gre1 on Porxmox I see that the packets are received and there is a ICMP reply outgoing:
When I run the ping the other way around and check it with tcpdump on the Ubuntu machine I get nothing. I understand that the issue is when packets leave Proxmox to Ubuntu via gre1 and get lost or blocked because Ubuntu can clearly send Proxmox packets but the reply never comes back. How can I fix this?
Check if you have packet forwarding enabled for the kernel of the 3rd machine that you user for the communication of the other 2 machines
Check /etc/sysctl.conf and see if you have this:
net.ipv4.ip_forward = 1
if it's commented (#) uncomment it, save the file and issue a:
sysctl -p
Then try again the pings...
Problem
I'm trying to develop a communication system where:
A, B are machines under NAT, A is the server B is the client
S is the STUN server
S is running on a machine reachable on the Internet
The flow is as follows:
A hits S with an opcode saying he's the server
S registers A as server
B hits S with an opcode saying he's the client
S sends to A B's external infos (IP, PORT)
S sends to B A's external infos (IP, PORT)
A starts sending B an opcode saying he's the server every 500ms
and meanwhile listens for packets saying he's got a client
B starts sending A an opcode saying he's the client every 500ms
and meanwhile listen for packets saying he's got the server
Trouble
Here's where the troubles start, the STUN server does its job, since both ends receive correct infos about the other.
But then I do never receive the other end's message, so both ends keep listening without receiving the handshake opcode nor anything else.
NAT's Behaviour
I did examine this NAT's behaviour and seems it does like this
A is at 192.168.X.X, on port 4444
connects to the outside exposing N.N.N.N:4444
so the port number is kept as long as it's free, gets a new (random ?) one if not available.
Tests
The tests I run have seen both ends (A, B) hosted on the same machine, both bound to the machine's internal IP, tried to bind to 127.0.0.1, 0.0.0.0, nothing changed.
If while they're listening for handshakes I echo something with nc to localhost, it is received and displayed (as an unrecognised message) without any problem. The connection routed via the NAT doesn't wotk tough, every packet is discarded.
Also tried with A hosted on the machine, B on an Android phone under mobile data, with a simple app written ad-hoc. Still locks waiting for something, like the nodejs tests.
Update:
Another thing I tried to do is to open an hole with nc
On two different machines under the same NAT I ran:
echo "GREET UNKOWN PEER" | nc -u <NAT IP> 4567 -p 4568
echo "GREET UNKOWN PEER" | nc -u <NAT IP> 4568 -p 4567
Different times for each machine. From my understanding this should punch an hole in the NAT with the first packets discarded and the subsequent forwarded. But nothing happened, no end got the message.
I've also tried:
from local machine
echo "GREET UNKOWN PEER" | nc -u <PUBLIC IP> 4567 -p 4568
from public machine
echo "GREET UNKOWN PEER" | nc -u <NAT IP> 4568 -p 4567
this one works, the local machine under NAT contacts the public one and after the first discarded packet is able to receive and send on the assigned port. I wonder why this doesn't work on two machines under the same NAT (???)
Code
I didn't show any code because I think there is some kind logic flaw in this, however here's the github project for that.
index.js contains the STUN server, the tests folder contains the test cases: test.js starts the stun server, PeerClientTest.js and PeerServerTest.js are mockups of the client and server.
Run node tests/test.js to start the server on a public machine (change IPs in config.js and tests/config.js)
then node tests/PeerServerTest.js to start the server ("A") and node tests/PeerClientTest.js to start the client ("B"). Both will recognize each other via STUN, then listen for the other end's handshake opcode while sending their own handshake opcode. This never happens so they just keep sending/listening forever.
Node is not required, so if there are better solutions in other languages just tell, will be appreciated.
B's NAT is filtering A's packets and is not letting them through. NAT filters unknown packets sent to it. Your server A is sending packet to client B. But client B previously never sent a packet through NAT to A. So to B's NAT A's packets are unknown and being discarded.
You need to punch a hole in B's NAT for the NAT to allow the incoming packets. Send a packet from B to A NAT's IP:Port. After that when you send a packet from A to B, B's NAT won't discard A's packet.
This won't work if A and B's NAT has a combination like Symmetric and Symmetric/PRC NAT. In this case you will have to use a TURN relay server.
I have implement a Client-Server application in java. The server can serve multiple clients, and I want to test that, but my knowledges on Networking is poor, and I need a way to test my application on my home.
I have a rooter, which are connected both of my computers. My "server" class in java uses as host the local host (127.0.0.1) on a given port.
How can I test my program if
The Server.java is running on the Computer A
Server.java is running on 127.0.0.1 on 3943 port
1st Client.java is running on the Computer A
1st Client.java is connected to 3943 port
2nd Client.java is running on the Computer B
2nd Client.java is connected to 3943 port
Any ideas?
Use unique ports for the clients and servers running on the same machine. In addition 127.0.0.1 is localhost (internal to that machine). Computer B cannot communicate with 127.0.0.1 on Computer A. Use 127.0.0.1 if all applications or on the same machine. Use the computers actual IP address if you want external machines to be able to communicate with the server.
When client and server, are on the same computer, what you are doing must be already working.
To connect from a different computer, you need to find the "real" ip address of your server.
If you are on Windows, open a command shell on your computer A, and run ipconfig. On unix/linux/mac, run ifconfig.
Look for a string, looking like an ip address, but not 127.0.0.1, there has to be another one if you are connected to a network, probably looks like 10.0.0. or 192.168.<0 or 1> ..
Use this address everywhere instead of 127.0.0.1
A full TCP connection consists of two different endpoints. The server side of the connection is one endpoint (it will be do a listen on that endpoint). When a client creates it's side of the connection (the client socket), it will do a connect to the server ip:port combo and get a number assigned from a range of so-called "ephemeral" ports.
The fact that both sides of the connection have the same IP address doesn't matter - the full connection is defined by two distinct elements (address:port combinations).
FirstClient's connection to the server will be ServerIP:ServerPort<->Client1_IP:Client1_Port, and SecondClient's connection will be ServerIP:ServerPort<->Client2_IP:Client2_Port. The network layer can differentiate between these (they are two different connection streams) and route traffic to the appropriate sender/receiver for that stream.
If you run the server bound to IP 127.0.0.1 you are not opening it to the network, only your own computer will be able to connect to it, acessing 127.0.0.1 (loopback IP address).
To open this server to the network, you must do one of the two things:
Bind it to the IP 0.0.0.0 so it will be acessible from all networks;
Bind it to a specific network IP address so that it will be available to that network only.
Its common practice to just bind it to 0.0.0.0, its easier.
Once its done, you will be able to connect from other computers to the server running on computer A, however, not through IP 127.0.0.1. Thats the loopback address and can only be used by a computer to connect to itself.
Computer A can use the IP 127.0.0.1 to connect to the server since the server is running on it, but other network computers will have to specify computer A's network IP address.
You can find your IP address on the network adapter details, or running the command ipconfig /all on a command prompt (Windows) or ifconfig (Linux).
I am running a Windows 8 VM inside of vmware Fusion. It runs inside a Mac running OSX 10.10 (Yosemite). The VM has a computer name of "Proud". When I ping the VM from within itself, i.e. ping -a 192.168.0.138 I get a response like:
Pinging Proud [192.168.0.138] with 32 bytes of data:
Reply from 192.168.0.138: bytes=32 time<1ms TTL=128
However whenever I ping Proud from Yosemite, i.e. ping Proud I get a response like:
PING proud (199.101.28.130): 56 data bytes
64 bytes from 199.101.28.130: icmp_seq=0 ttl=46 time=418.646 ms
The VM is using bridged networking.
Why does Proud resolve to that IP address? It is not correct and means I am unable to use the hostname (a necessity) so that I can connect to it from the Mac.
First, test and check with IP_address typed for ping from OSX 10.10 <host> terminal, so as to be independent of any DNS-service, that is responsible for a hostname translation of your <hostname> to a pre-configured IP_adress
Second, You say bridged -- thus check, that the VM has the very same network-part of the IP_address ( boundary is given by non-zero bits in subnet-mask
Check details with ifconfig resp. ipconfig
-------------------------|-----------------------------|||--------|||.|||.|||.|||
VM/w8 connected to VMnet? has IP_address := 192.168.0.??? subnet ???.???.???.???
RM/OSX connected to VMnet? has IP_address := 192.168.0.??? subnet ???.???.???.???
EDIT#12014-08-20 15:30 [UTC+0000]:
-------------------------?-----------------------------???--------255.255.255.0
-------------------------|-----------------------------|||
Best to post PrintScreens from {OSX|w8} terminals {ping|ipconfig|ifconfig} and the setup of VMnet
This seems to be a 'feature' of Mac OS. If I attempt to ping any hostname it will return the ping from this IP address - even if the hostname is fictional. I do not know why OS X does this.
This is called DNS hijacking and is done by a lot of ISPs out there to redirect you on incomplete or wrong browser address inputs and show you these custom pages with advertisment 'Hey, we couldn't find your webpage Aple.com but maybe you look for Apple.com?'
Maybe this is whats happening here. Btw, ISPs break RFCs here.
You need to check on your own /etc/host file. See if you might have done any changes to this file, to indicate the machine "Proud" comes as 192.168.0.138 or x.x.x.130? Next thing to ensure (user3666197 is actually right), you need to check on ifconfig to check if you have any connection have the IP address pointing to x.x.x.130 or x.x.x.138.
Last but not least, is there any virtual appliance or instance running of "proud" which might have caused confusion as it is possible for any virtual appliance or instance to get a IP address from the same segment as well, hence having "two" machines on the network?
Hope this helps. Check on your WINS config too...