I would like to establish a connection between 2 computers using socket. For this purpose one of them is a server and this is the code I've write:
sock= TCPServer.open('localhost', 6666)
sock.accept
the client try to establish the connection:
client = TCPSocket.open(ip_server, 6666)
but is not working. I've notice scanning server's ports that the server does not open the port to the network, only works in local mode.
Any suggestion, thk in advance
I've used this code successfully. Server side:
serverSocket = TCPServer.new( "", port )
serverSocket.accept
and on the client
t = TCPSocket.new(server_ip, port.to_i)
However, recently I've started using the 'EventMachine' gem, which made handling sockets 10 times easier
It's already been said that the service is running in "Local Mode" using the loopback "localhost".
sock= TCPServer.open('localhost', 6666)
sock.accept
TCPServer is a handy interface for the underlying file descriptor. Frankly, it almost makes socket programming too easy.
Like what has already been said, 'localhost' is a loopback to 127.0.0.1. Therefore, your statement is equivalent to:
sock= TCPServer.open('127.0.0.1', 6666)
sock.accept
If you will be using the network connection on a local network, assuming the server has an assigned IP of 192.168.0.1, you can assign a local IP address to listen on:
sock= TCPServer.open('192.168.0.1', 6666)
sock.accept
For an open port, conceivably open to all, use:
sock= TCPServer.open(6666)
sock.accept
Remember that everything is a file – the connection you're making is reading and writing to the same file or series of files from two (or more) locations. It's important to control who might have access to those files, and to what extent.
Yes, and it allright so, because you said it should bind the server port to the interface of 'localhost' and this is 127.0.0.1 and is bind to your loopback interface and not to any real interface connecting to the realworld.
You should try
sock = TCPServer.new(6666)
sock.accept
It works in "local mode" because it listens on localhost wich is loopback address for the computer the server is launched in. The IP address of your server should be address your computer has on local network (something like 192.168.x.x).
Related
I have a REST service running on Mac OS X, which im currently accessing using "localhost:8888" and "10.0.2.2:8888"
I want to access the same service from another computer which is in the same network.
I disabled the firewall also and I typed
nc -v 192.168.1.3 8888
and got the result as
nc: connectx to 192.168.1.3 port 8888 (tcp) failed: Connection refused
currently i use localhost (to access using java application) and 10.0.2.2 (to access using android application runs in the simulator) which both runs on the same machine which the server runs too.
I want to put the android application to my phone and give the machine ip addess ( because if i connect to internet via wifi, it'll be in the same local area network) i should be able to access my service runs on my machine.
can some one please tell me what im doing wrong here? Thank you
You can't access localhost from your front end code. It needs to refer to the server's name or address.
The localhost address should be 127.0.0.1, which is in the loopback range of addresses. Any address in the 127.0.0.0/8 block can never appear anywhere on any network, nor can any address in that block be used as a source or destination address outside a host. It is not possible for one host to access anything in that address range on another host.
The goes back at least as far as RFC 990, ASSIGNED NUMBERS:
The class A network number 127 is assigned the "loopback" function,
that is, a datagram sent by a higher level protocol to a network 127
address should loop back inside the host. No datagram "sent" to a
network 127 address should ever appear on any network anywhere.
RFC 1122, Requirements for Internet Hosts -- Communication Layers:
(g) { 127, }
Internal host loopback address. Addresses of this form MUST NOT
appear outside a host.
Also RFC 3330, Special-Use IPv4 Addresses:
127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
Why does Apache-Commons-Net's FTPClient sometimes make the wrong computation for the port number in the PORT command? This is in active mode. For example FTPClient it could send out
PORT <some>,<ip>,<address>,<here>,235,181 when in fact the port number used is 60340. What's the cause for this wrong computation?
This could happen on version 3.3.
I know ftpClient.enterLocalPassiveMode(); could solve this, but I want to know the part where the active mode doesn't work as expected.
From your comments, I assume you mistake an FTP control connection with a data connection.
I assume that the 60340 is local port of the FTP control connection. When opening data connection, 60341 is assigned (hence the PORT ...,235,181).
Reasoning: In an FTP active mode, the client opens listening port for the expected data connection, which it then reports to the server via PORT command over an existing control connection. If the server cannot connect to the port, no TCP/IP packet can ever come to that port. As you claim that the "two machines still communicate at port 60340", it must be the control connection. There cannot be any communication on port, if the connection failed ("Can't open data connection").
The actual cause of the "Can't open data connection" error is likely that you are behind a firewall, so the server cannot connect back to the client. What is a common nowadays. That's what passive mode is good for.
I had already created a qt program that listens on a specific port on my server. And it works fine. Now I want to create a simple ruby program to do the same. Right now I just have a simple test server using netcat which establishes a network socket and accepts UDP data (this is Ubuntu server by the way):
$ sudo nc -l 1720
Now I am just trying to listen on the port in Ruby:
# network.rb
require 'socket'
socket = UDPSocket.new
socket.bind('64.xxx.xx.xxx', 1720)
This right away raises this exception:
network.rb:4:in `bind': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL)
WHy is it saying the address is not available? All that is there is a netcat socket. The goal is that I will have UDP data coming in from GPRS devices to that port, and then I will have ruby sitting on my ubuntu server listening for that data, then decoding it, and storing it into a postgresql database.
You are making a server or client?
you used nc, so i guess you are making client.
server is bind
client is connect:
c = UDPSocket.new
c.connect("127.0.0.1", 1111)
"address is not available" usually as the port is used.
or you can ping the address fisrt to check if the address can be reached
I was getting the same error by running:
rails s -b 10.0.0.61
It turns out that my local IP wasn't 10.0.0.61 and this was causing the error.
I am trying to learn how to send TCP packets across the internet to another computer. So say, computer 1 sends data across the internet to computer 2 (using TCP). Assuming that both computer have port forwarding correctly set, how would I go about establishing a TCP connection between the two computers (in Ruby preferably)? I have it working on my LAN, but when I try over the internet, it doesn't seem to work.
My attempt (basically):
Computer 1:
server = TCPServer.new 32500
client = server.accept
Computer 2:
TCPSocket.new PUBLIC_IP_OF_COMPUTER_1, 32500
Problem is that TCPSocket never connects to TCPServer.
I read in the Ruby doc that TCPServer.new's syntax is
new(remote_host, remote_port, local_host=nil, local_port=nil)
What happens if I just leave local_host=nil and local_port=nil (rather than assign them the private IP and port 32500 number on Computer 1)?
If somebody could point me in the right direction, that's be great! I hope I my approach is at least somewhat correct.
You created a server which is listening only on the loopback Interface.
Try this out:
curl ifconfig.me
You will get your external IP address, how it is visible from outside, for example 123.123.123.123
server = TCPServer.new 2000
Now You have a server listening on port 2000
lsof -i :2000
for example:
ruby 37186 wopi 6u IPv4 0xcf0818acc2bdc38d 0t0 TCP *:callbook (LISTEN)
now connect from THE SAME machine to localhost
telnet localhost 2000
this works
telnet 123.123.123.123 2000 # substitute your real external IP address
this will not work
That is why You can't connect from outside.
Checkout how ngrep, netcat and tcpdump are working, invaluable tools for network debugging.
This is part programming, part sysadmin, so please excuse me if you feel that this should be over on serverfault.
I have an application that is not SOCKS aware and that we need to use through a firewall. We cannot modify the application to have SOCKS support either.
At the moment, we do this by aliasing the IPs the application talks to the loopback adapter on the host, then creating SSH tunnels out to another host. The IP's the application uses are hardcoded. Our SSH connections look like:
ssh -L 1.2.3.4:9999:1.2.3.4:9999 user#somehost
Where 1.2.3.x are aliases on the loopback.
So the application connects to the open port on the loopback, which gets sent out to the SSH host and onto the real 1.2.3.4.
It works, but the problem is that this application connects to quite a few IPs ( 50+ ), so we end up with 50 ssh connections out from the box.
We've tried to use several 'proxifying' apps, like tsocks and others but have had alot of issues with them ( the app is running on OS X and tsocks doesn't work so well, even with the patches )
Our idea was to write a daemon that listened on all interfaces on the specified port - it would then take the incoming packets from the application, scrape the packet info ( dst IP, port, payload ), recreate the packet and proxify it through a single SSH SOCKS connection ( ssh -D 1080 user#somehost ). That way, we only have 1 SSH connection that all the ports are being proxied through.
My question is - is this feasible? Is there something that I'm missing here? I've been combing through pfctl, ipfw, iptables docs, but I don't see any option to do it through those and this doesn't seem like it'd be the most difficult thing to code. It would recreate the packet based on the original destination IP and port, connect to the local SOCKs proxy and resend the packet as if it were the original application, but now with SOCKS support.
If I'm missing something that someone knows about that already does this, please let me know. I don't know socket programming or SOCKs too well, but this doesn't seem like it'd be too big of a project to tackle, but I'd like some opinions if I'm biting off way more that I should.
Thanks
If your application could add SOCKS client support, you can simply ssh -D lock_socks_port remote_machine, which will open up the local *lock_socks_port* as a SOCKS server at localhost, which can then connect to any host accesible by the remote machine.
Example: imagine you are using an untrusted wifi network without encryption. You can simply launch ssh -D 1082 home, and then configure your web browser to use localhost:1080 as SOCKS server. Of course, you need a SOCKS-enabled client. All the traffic would appear as coming from your gateway, and the connection would be opaque to those snooping the wifi.
You can also open a single ssh client with an indefinite number of LocalForward requests, which would be tunneled on top of a single ssh session.
Moreover, you can add ssh connections to an already-established ssh connection by using the ControlMaster and ControlPath options of ssh.