Cannot access Mac from another local Mac or iPhone on same router

[velohomme]

I'm a developer testing a web application on my local Mac. I fired up the web server (google app engine) on port 8888. I can access web app fine at localhost:8888 but was unable to connect from another Mac and iPhone on the same wireless router. The mac firewall (ipfw) is turned off. If go to Preferences and turn on Web Sharing I can access port 80 just fine from these other devices.

I'm baffled what is blocking the traffic. Is there another place in Lion where I need to open ports?

 

[squeakr]

Try System Preferences>Security & Privacy> Firewall and see if your firewall is on and blocking the ports. Can you ping correctly from the other machines?? How are you trying to access it (i.e. IPaddress:8888)?

 

[velohomme]

The firewall is off (ipfw is the firewall). I have confirmed it via the preferences window, command line and waterroof. No need to ping: as I said I can access the Mac at port 80 without problems when I turn on Shared Web Server. I'm accessing via IP address (http://x.x.x.x:8888). BTW I've tried to same thing on both an iMac and MacBookPro with the same result. Thanks for anything you can suggest.

 

[Mac-Michael]

Is it possible that the web server is only configured to receive connections to 127.0.0.1:8888 and not x.x.x.x:8888?

 

[squeakr]

I saw the comment about port 80 being open, but thought you might want to run a ping for 8888 and see if it is responding at all. You might try a port scan on 8888 as well. I suggest these, as if the port is not returning responses correctly then you definitely have a port issue not being routed correctly (no matter what the other tools are reporting about the port being open or not).

As I have said to others, trouble shooting is a finesse, and even though may seem irrelevant, trying it can't hurt and may actually reveal the true issue that is occurring or point one in the correct area.

 

[Mac-Michael]

I found this. Under Command-Line Arguments:
--port=...
The port number to use for the server. Default is 8080.
--address=...
The host address to use for the server. You may need to set this to be able to access the development server from another computer on your network. An address of 0.0.0.0 allows both localhost access and hostname access. Default is localhost.

 

[velohomme]

@Mac-Michaeal: Bingo (to your web server config idea)! I hadn't considered that because I usually run Tomcat which is very open. In this case I was using Google App Engine's local server. It doesn't like IP addresses (other than 127.0.0.1). Easy to fix issue now.
@squeakr: Ping can't be directed at a port. It doesn't work that way. For that reason it is generally a bad tool for validating access through firewalls. Generally Telnet is used for checking port access. You can telnet to the particular port. It obviously doesn't work as a Telnet server but the web server will spit back at you enough to see that he did, in fact, listen (or not).

Thanks for the help guys!

 

[squeakr]

Ping can be directed at a specific port and will work that way. I have used it several times to resolve issues with access to ports.

I just tested/ tried it again and it is resolving correctly and working as intended. If I ping my server, I get a response from the server itself, if I ping the server with my web server port appended, then it returns the address of the web server correctly, so the ping through does work.

 

[velohomme]

@squeakr I'm not sure what you are doing but ping does not test ports.

 

[squeakr]

I am doing this:

A ping may be sent using the User Datagram Protocol (UDP) to a device located behind a network address translator (NAT) to keep the port binding on the NAT from timing out and removing the mapping.

UDP applications use datagram sockets to establish host-to-host communications. An application binds a socket to its endpoint of data transmission, which is a combination of an IP address and a service port. A port is a software structure that is identified by the port number.

 

[jasonvp]

A ping may be sent using the User Datagram Protocol (UDP) to a device located behind a network address translator (NAT) to keep the port binding on the NAT from timing out and removing the mapping.

I think there's a bit of confusion here. What velohomme is referring to is the old UNIX CLI version of ping. And that version uses ICMP ECHO_REQUEST packets. It doesn't use UDP or TCP. And it can't be set to "ping" a specific port because that's not how ICMP works.

You're not using the classic ping. You're apparently using some other tool that's calling itself 'ping'.

jas

 

[squeakr]

The ping utility within Mac allows it. The OP is on Mac and having issues with Mac hence the recommendation to use the ping utility in Mac (which it works on).

Correct in that the classic version does not, but the utility within Mac does.

 

[jasonvp]

The ping utility within Mac allows it. The OP is on Mac and having issues with Mac hence the recommendation to use the ping utility in Mac (which it works on).

What "ping utility" are you referring to?

jas

 

[squeakr]

The ping functionality within the Network utility.

 

[jasonvp]

The ping functionality within the Network utility.

...which just calls the UNIX CLI ping command. There are no options in it that I see that allow for checking specific ports or using a protocol other than ICMP. Are you possibly mistaking it with the "Port Scan" part of the Network Utility, which just uses a form of the CLI nmap command?

jas

 

[squeakr]

Nope try it yourself. I do know the difference. Enter in an address with port specified (such as your personal known web page forward, I used http://x.x.x.x:80 with my server ip in place correctly). The same thing in a traditional ping will return an error and not connect to the host, but it resolves through correctly within this ping option.

 

[jasonvp]

Nope try it yourself.

I did. I have ssh running on my system:

$ telnet 127.0.0.1 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.6

But as you can see from the attached image, the Ping Utility doesn't know about ports.

Are you using Lion?

jas

 

[squeakr]

Yes I am on Lion:
Enclosed screen shots of it working for me, as it resolving to the correct web server address

 

[jasonvp]

Yes I am on Lion:
Enclosed screen shots of it working for me, as it resolving to the correct web server address

OK, I'm not quite sure what kind of network you're sitting on right now, but it looks you have some sort of DNS poisoning/caching/altering going on there. In other words, any lookup you do, you get back the same IP address.

Is there some sort of web-based proxy or firewall (or both) that you have to pass through to get out to the intardwebz? What you're seeing is NOT normal, and is NOT the way ping works. What you're seeing is a funky resolver response that's getting, well, anything, and returning an IP address.

Is that 192.168 IP the one on your Mac right now?

What happens if you try it with the same IP, sans the port?

jas

 

[squeakr]

Sans the port everything returns the way you would expect. With the port, I get redirected to the correct IP address as would be expected for me with the site hosting. Yes these are set up accordingly in my routing table, so no poisoning taking place. Like I said, for me it is working with the UDP settings as I specified earlier. Mine work the same as if you were to ping an url and not just an ip.

 

[jasonvp]

Like I said, for me it is working with the UDP settings as I specified earlier. Mine work the same as if you were to ping an url and not just an ip.

I think you're fairly confused as to what's going on with your system. In fact I'm certain of it.

Open a Terminal window and do this:

nslookup www.google.com

What's that output look like?

nslookup www.google.com:80

Cut and paste the output.

Finally, try these:

ping -c 10 www.google.com

and

ping -c 10 www.google.com:80

jas

 

[belvdr]

Sans the port everything returns the way you would expect. With the port, I get redirected to the correct IP address as would be expected for me with the site hosting. Yes these are set up accordingly in my routing table, so no poisoning taking place. Like I said, for me it is working with the UDP settings as I specified earlier. Mine work the same as if you were to ping an url and not just an ip.

An <ip>:<port> nomenclature denotes TCP, as in your example with the http:// prefix in front of it; that's TCP 80. TCP 443 is SSL. Not sure what UDP 443 is, but it appears some have seen it with Skype.

Anyway, ping does not do TCP/UDP. My guess is the port in your example is just being removed/truncated. You can see clearly in your results by the ICMP sequence number. Even better, do a tcpdump on the host you're pinging from and check the packets. That's the only way to definitively prove it. You may think it's UDP, but it's not. I'm not sure why you'd even think so.

My guess is you're using OpenDNS or your DNS provider tries to search for your request automatically. Many ISP DNS providers do this these days, so that if you mistype something, it goes to another host to help you find what you're looking for. In this case, it's trying to lookup "192.168.1.5:443" as a hostname or FQDN, not an <ip>:<port> combo. Thus, it's redirecting you. Another indicator is the ping response time. A local network, especially a home network, wouldn't have response times in the 20-30ms range. It would be much less.

If what you're saying were accurate, you wouldn't get replies from anything but 192.168.1.5. In your case, trying pinging both 192.168.1.5 and 192.168.1.5:443. My guess is you get replies from different IPs. Another option is to disconnect your Internet line and retry the ping.

Linux had a utility to do this sort of thing and it was called hping. Not sure if it exists any more, as I don't use ping to test connectivity.

 

[squeakr]

Nope not being removed/ truncated as like I said when sans the port it returns as expected in this case the same ip address as the original ping.

 

[belvdr]

Nope not being removed/ truncated as like I said when sans the port it returns as expected in this case the same ip address as the original ping.

You keep saying that but it doesn't make sense. Why would a ping (echo request) to 192.168.1.5 receive and echo reply from another address? The only time I've seen that is when you have a routing loop, but then you get a TTL expired, not an echo reply.

Note how it resolved "192.168.1.5:443" in your output window. It resolved that to another IP, so it is going to DNS first, instead of to the IP. That means it is trying to resolve it, like it would any other hostname or FQDN.

Do the tests that jasonvp provided above, specifically the nslookup on google OR do a

man ping

and show us the relevant section on pinging UDP. Therein lies your answer.

 

[squeakr]

I could do these things all day long and if you don't like the results you will ask me to try something else. I am not the one having issues, nor did I come here seeking help. I have done everything above before and when I upgraded to Lion Server the mail stopped working for some odd reason. Spent hours on the phone with Apple 3rd level support, and nothing could be found wrong. The mail server just started working again the next day after no changes. I get all of the correct name resolutions and such, so I don't see what the big deal here is that everyone feels the need to probe my network? When I do what is asked and provide screen shots, I am told it is not working right, yet I am having no issues and have had no issues, so why the concern really?