0

I'm creating an Android app (on the Galaxy Nexus, using Jellybean 4.2.2) that sends information to a Windows c# app (running on Windows 7) through sockets via wifi. I'm getting this error...

java.net.ConnectException: failed to connect to /169.254.245.49 (port 1234): connect failed: ECONNREFUSED (Connection refused)

...when I run this line on the Android side:

socket = new Socket("169.254.245.49", 1234);

If I change the IP address to a bogus address, I get a different error; I suspect the problem is on the Windows side with regard to the wireless point to point network, but I'm not sure what's missing. Here's what I've done so far:

1) I've added this to the Android manifest file:

<uses-permission android:name="android.permission.INTERNET"/>

2) I'm using code that's almost identical to this for both the Android and C# sides; the only differences being the IP address and port #: TCP/IP communication using Android as Client and C# as server

3) I created a point to point network on my Windows computer through the following commands:

netsh wlan set hostednetwork mode=allow ssid=tests key=tests123
netsh wlan start hostednetwork

I also went into the Wireless Network Connection for the Microsoft Virtual WiFi Miniport Adapter, and in the Networking tab, I unchecked all of the items except for "Internet Protocol Version 4 (TCP/IPv4)".

4) Just for the heck of it, I turned off Windows Firewall.

5) I ran ipconfig and confirmed that the IP address for my point to point network is 169.254.254.49.

6) I connected the Galaxy Nexus to the "tests" wireless connection.

What else should I check? I've been trying to find a solution for hours and have not made much progress. Any help would be greatly appreciated!

Community
  • 1
  • 1
Andr
  • 1,043
  • 4
  • 13
  • 15
  • `ECONNREFUSED` means that the server machine actively refused the connection. That is, the connection request actually made it to the machine, but the machine sent back "no can do". Generally, this means that there is no socket bound to that port or it's not in LISTEN state. Are you sure the server process is running and is actually listening on that port? `netstat -a` should show all the ports in a LISTEN state. – Gil Hamilton Jul 13 '16 at 11:45
  • I'm seeing this while running the c# server application and calling netstat -a: TCP 0.0.0.0:1234 computerName:0 LISTENING I assume the 0.0.0.0 means that the server application is listening to all IP addresses on port 1234. Is this what I should be seeing? – Andr Jul 13 '16 at 12:31
  • Yes. That looks right. Could run wireshark on your windows box, verify that you're seeing a `SYN` packet come from the android side, and a `RST` being sent back. That's what I would expect is happening. If you see something else though, maybe it would suggest something else. – Gil Hamilton Jul 13 '16 at 12:55
  • So, I just noticed the IP address you've referenced is 169.254.X.X. That address is in a range reserved for link-local. Why is your windows box configured with that address? It usually means that your network interface was unable to get an IP address via DHCP. – Gil Hamilton Jul 13 '16 at 13:01
  • You might also try downloading android "ping tools" (or another one of the several android IP tools apps). If you can't ping the box, chances are that you won't be able to connect either. – Gil Hamilton Jul 13 '16 at 13:02
  • That's a UDP broadcast packet (#4). You shouldn't be seeing that as part of a TCP connection request. I still think you should investigate why you're using 169.254.X.X addresses. That's not normal and could definitely be part of the problem. – Gil Hamilton Jul 13 '16 at 14:03
  • @GilHamilton -- you got me on the right track. I was able to fix things by doing the following: 1) I uninstalled and reinstalled my computer's wireless network card drivers. (I'm not sure if this helped.) 2) I used Connectify to create the wifi hot spot (http://www.connectify.me/ ), as I could never get the IPv4 internet connection to work with the netsh command above or Virtual Router. 3) I used a different port than 1234. Maybe something else was hogging that particular port up, but after I switched it to 2222 on both client and server, I got things to work. Thanks for your help! – Andr Jul 14 '16 at 15:21

0 Answers0