Not sure what this issue has to do with spray specifically, but I tried to reproduce with a netty-based server, and curling the local ip seems to work fine. Does anyone know what might cause the following not to work even though it does work with a basic netty server:
$ ifconfig
eth0 Link encap:Ethernet HWaddr <my mac address>
inet addr:172.16.16.31
...
...
...
$ curl localhost:8080/myPath
myContent
$ curl 172.16.16.31:8080/myPath
curl: (7) Failed to connect to 172.16.16.31 port 8080: Connection refused
Advice on how to troubleshoot this issue is also welcome.
Found the issue. Answering here in case anyone else has the same problem. My spray server was initialized with a command like the following:
startServer(interface = "localhost", port = 8080) {
This specification of an interface appears to cause the issue. If I set it to be the Ipv4 address of the machine, then curling localhost fails and curling the ipv4 address works (still not working for ipv6 though).
I got similar issue, change your interface to ::0 which supports both ipv4 and ipv6 address.
My code looks like below
IO(Http) ? Http.Bind(service, interface = "::0", port = 8080)
More : https://groups.google.com/forum/#!topic/spray-user/0kPXN1XVe0E
Related
I got the following error while running curl:
curl: (7) Failed to connect to 127.0.0.1 port 8080: Connection
refused.
It seems that it is easy to debug, but, I didnt find how to solve it.
The adress 127.0.0.1 is mentioned in the file etc/hosts.
I am using curl version 7.47 on Ubuntu system.
Anyone has an idea about it ?
Thank you.
Make sure you have a service started and listening on the port.
netstat -ln | grep 8080
and
sudo netstat -tulpn
Try curl -v http://localhost:8080/ instead of 127.0.0.1
Listen to the port in one session and then open another session to test it with l$ curl -v http://localhost:8080/
It should work. That's how I worked although in l
Termux
You have to start the server first, before using curl. On 8/10 occasions that error message arises from not starting the server initially.
127.0.0.1 restricts access on every interface on port 8000 except development computer. change it to 0.0.0.0:8000 this will allow connection from curl.
I set my linux as an access point, and then run simple web-server that print "hello world" at port 3000.
and connect it with my smart phone successfully.
in linux terminal, http://localhost:3000 works well.
But in smart phone,
If I access to http://172.24.1.105:3000, can't connect to it. (172.24... is ap's ip)
the chrome's error message is
This site can't be reached. 172.24.1.105 refused to connect
I searched Google (https://serverfault.com/questions/725262/what-causes-the-connection-refused-message) and I suspicious linux's firewall.
pi#raspberrypi:~/prj/ap_server $ sudo tcpdump -n icmp
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
... when I access to port 3000,
15:07:13.102750 IP 192.168.0.3 > 168.126.63.2: ICMP 192.168.0.3 udp port 42531 unreachable, length 386
the log is above. so I couldn't reach ap's webserver.
so I wonder two things...
1. How can I disable to its port block?
2. in tcpdump log, I access to port 3000 actually, why the log print port 42531?
Plus)
even I type sudo service iptables stop, the problem is not solved
sudo netstat -ntlp | grep 3000 logs:
**tcp6 0 0 :::3000 :::* LISTEN 1999/nodejs**
+I followed this tutorial-> https://frillip.com/using-your-raspberry-pi-3-as-a-wifi-access-point-with-hostapd/ .
and there is ipv4 setting.
If you want to run it on your mobile it will work on Live IP (externel) address
if it is working fine on local address (localhost) and not on live IP then
enable routing from your router
and allow that specific port it will work fine.
I found the issue.
my dhcp set was
interface=wlan0 # Use interface wlan0
listen-address=172.24.1.1 # Explicitly specify the address to listen on
bind-interfaces # Bind to the interface to make sure we aren't sending things elsewhere
server=8.8.8.8 # Forward DNS requests to Google DNS
domain-needed # Don't forward short names
bogus-priv # Never forward addresses in the non-routed address spaces.
dhcp-range=172.24.1.50,172.24.1.150,12h # Assign IP addresses between 172.24.1.50 and 172.24.1.150 with a 12 hour lease time
like above.
I tried to connect the external ip(172.24.1.105) that I can see on mobile continuously but got failed. but when I tried with 172.24.1.1, then success.
I don't know why. maybe there is accurate ip address and something in mobile is temporal.
See similar topic at Node JS not listening to port 1337 on server
Your web server is not listening remote address.
I tried to connect to my wifi network but i am not able to connect through my laptop .My other device at home are able to connect to internet. I am using ubuntu 16.04 LTS . I set my browser proxy to no proxy . I have no antivirus installed .
I tried to ping -c 5 (google .com and facebook.com) in terminal its showing unknown host google.com and unknown host facebook.com and tried to install eclipse while downloading it shows error java error unknown host .
Please help me to solve this issue.
Sounds like DNS may not have been configured when you connected to the network. This should normally happen automatically, but you can check by looking at the file /etc/resolv.conf. There should be at least one line in the file containing nameserver and an IP address.
If there are no nameserver lines, or if there's only one and it says nameserver 127.0.0.1, then you can try to use Google's public DNS by adding the line nameserver 8.8.8.8 (replacing the 127.0.0.1 if that's present).
Like everyone, I had to face this issue. So what did I do to address this issue?
1) I configured my Ubuntu server to have two network interfaces (NAT and Intnet).
2) In /etc/network/interfaces , I added the following lines:
auto enp0s8
iface enp0s8 inet static
address 192.168.10.23
dns-nameservers 8.8.8.8 8.8.4.4
3) Restarted the network - /etc/init.d/networking restart
Result: ping google.com worked.
I hope this helps you in resolving this issue :)
Hi StackOverflow members,
I have an issue with ssh connection on my Debian 7 system to a remote OpenSSH server located on the same network. It looks like there is some network configuration problem but I cann't find where it lays. This two debian machines are connect with a switch that is NOT connected to a router. So the two machines have no internet connection.
A-Debian 7
IP: 192.168.1.2
MASK: 255.255.255.0
GW: 192.168.1.1
B-Debian 7
IP: 192.168.1.3
MASK: 255.255.255.0
GW: 192.168.1.1
With that configuration the ssh command prompts my for a password in less then a second. But the with the following network configuration I get the password prompt after a 10+ second delay:
A-Debian 7
IP: 10.10.1.83
MASK: 255.255.255.128
GW: 10.10.1.1
B-Debian 7
IP: 10.10.1.82
MASK: 255.255.255.128
GW: 10.10.1.1
The ssh connection from the server A -> B runs with both configs on custom 1111 port.
The B machine has also a Web server running on port 8080 that has no delays with both net configurations.
Thank you in advance for any clues or tips how to solve that problem.
SOLVED: Removing of the gateway parameter "GW: 10.10.1.1" in the network settings has solved the problem.
The usual culprits here are IPv6 and DNS lookups.
SSH might try to connect via IPv6, first, but the timeout is too low for that. You can see whether IPv6 is enabled with
cat /proc/sys/net/ipv6/conf/eth0/disable_ipv6
To disable:
echo 1 > /proc/sys/net/ipv6/conf/eth0/disable_ipv6
The second culprit is DNS; my guess is that DNS lookups don't work correctly with the second configuration. Try host www.google.com to test this theory.
If that also has a delay, you need to fix your DNS setup.
If that's not it, check the rest of your networking parameters: Gateway, cables, etc.
Start to ping the other host. Is that fast & reliable?
Next, try remote login (ssh, telnet). Note that you can give telnet a port to connect to, so if you have DB server running, you can still use telnet to connect to the server. It will print an error but it allows you to test the TCP/IP connection without any extra error sources.
I've installed CouchDB on my vagrant 0.9.0 box that is running CentOS 6.2.
In Vagrantfile I've added config.vm.forward_port 5984, 5985.
After reloading vagrant i attempt to curl the address: curl -v localhost:5985 with poor results.
* About to connect() to localhost port 5985 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5985 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: localhost:5985
> Accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
* Closing connection #0
I get the feeling that port forwarding isn't working properly - at first I thought it might have something to do with iptables so I disabled that but, alas, results did not improve.
Been beating my head against this for days now. Would greatly appreciate some assistance.
It's quite likely that your CouchDB is listening on address 127.0.0.1 of the virtual machine (not of the physical machine). This is the default for CouchDB. Do you have the following in local.ini?
[httpd]
bind_address = 0.0.0.0
After restarting CouchDB check with netstat, on the virtual machine, if the change took effect:
sudo netstat -tlnp |grep :5984
Then check that CouchDB is running fine from the virtual machine:
curl http://127.0.0.1:5984/
If you don't see {"couchdb":"Welcome","version":"1.1.1"}, check the logs for error messages. It may be some permissions problem.
How have you installed CouchDB?
in my case, the solution to a very similar problem was much more obvious: coming from ubuntu, I didn't expect a firewall to be running on the centos box
this will disable it:
sudo service iptables stop
thanks to this blog!