MacOS – Trying to understand inconsistent web access

macosNetworkwifi

In a library with an iPad and a MacBook Pro (MBP) on unsecured WiFi. Websites in Safari on the iPad are showing no problems.

On the MBP, Safari says “server unexpectedly dropped connection” for every website tried.

On Firefox, it’s connection timed out.

Tor is able to connect to directory server but unable to establish connections to any of the entry nodes it offers. The log shows the connection failures are of three different types. All are on port 443, and my browsing is always https when possible. But https is working on the iPad.

Ping takes 40-100 milliseconds to echo the same domains that the web browser cannot reach.

Hard to imagine library staff having any reason for device detection, if even the ability to implement it.

Devices forty centimeters apart, so probably on the same router.

What would cause this inconsistency?

UPDATE: Both devices have behaved as expected everywhere else as long as I’ve owned them. I risked reprimand 🙂 by transferring the Cat-5 cable from their Windows box to the MBP. en0 became active, but would not connect even to their router. Prefs said that I had a self-assigned IP address, but the menu said using DHCP, and renewing the lease got a 169.x.x.x address which I would never manually assign, and is weird because their WiFi router is 172.16.110.1 according to trace route.

DNS was resolving host names on both devices.
Safari has no extensions installed, yet when I change https to http, it gets changed back. Firefox has “https everywhere” but turning it off does not fix the problem. Tried to check port 80 in shell but there is no telnet executable!

sftp times out on the command line. No ftp executable either (grr). Finder connected to the ftp port and displayed contents, but then announced connection interrupted—and about 1.5 seconds later entire screen went gray; had to reboot. Second try, Finder gets the spinning pizza, and won’t do anything else, not even shut down on the menu bar. Relaunch from the dock killed the Finder and it did not come back. That sounds like something wrong with the MBP but still, the WiFi access worked fine many other places.

In case the above is too confusing or doesn't say everything:

  • No problems noted on the iPad.
  • MBP could do ping, traceroute, DNS, and whois
  • MBP could not do http, https, smtp, imap, exchange, or sftp
  • tor could contact its directory servers via port 9001 but could not use the addresses found on port 443.
  • although the shell could not invoke ftp, Finder could, and displayed the known contents of the remote directory. However, something about doing so caused Finder to crash the O.S. and to not work properly until the fourth reboot.

Best Answer

There's a lot in this question that revolves around misconceptions and this answer is an attempt to address them to give a more holistic view of how things work.

Connectivity

On the MBP, Safari says “server unexpectedly dropped connection” for every website tried.

On Firefox, it’s connection timed out.

Your connection isn't browser dependent. If your connection doesn't work, it's not going to work for any browser.

Ping takes 40-100 milliseconds to echo the same domains that the web browser cannot reach.

This is not indicative of anything other than one device can connect (iPad) while one cannot (MBP). A ping time of 40-100ms is well within what's considered "normal."

sftp times out on the command line. No ftp executable either (grr). Finder connected to the ftp port and displayed contents, but then announced connection interrupted

Like your browser, CLI tools like sftp, scp, ssh, etc. aren't going to connect if there's no connection. The spinning "pizza" (aka spinning beach ball of death) is Finder waiting for the result of the connection - either you get a directory to display or it times out. This is entirely normal.

As for FTP and Telnet, those were removed because they are grossly insecure.

DNS Issues

DNS was resolving host names on both devices.

DNS is cached locally. This is how you can be disconnected, but when you attempt to ping an address you've already been to, it will immediately resolve but give you a host not reachable or timeout error message.

The main point here, is that this is not indicative of anything. To see if DNS is working correctly, you need to use a tool like dig or nslookup to actually query the DNS server directly.

Tor is able to connect to directory server but unable to establish connections...

Same thing. DNS is cached, but when you attempt to actually connect to a server, it can't because you're not connected.

Ancillary Assumptions

A few other minor details that need to be cleared up:

Hard to imagine library staff having any reason for device detection, if even the ability to implement it.

Yes they do and, they most certainly do; in that order. WiFi is not an unlimited resource and every organization must implement controls to ensure access for everyone. They may require registration of your device, they may have a captured portal that asks for certain info, or they may look at traffic, but they can and do detect devices and filter content.

It could be as complex as device authentication mechanisms and device detection or as simple as they ran out of IPs on that particular subnet. However, the next statement gives us a clearer picture:

I risked reprimand :-) by transferring the Cat-5 cable from their Windows box to the MBP. en0 became active, but would not connect even to their router. Prefs said that I had a self-assigned IP address, but the menu said using DHCP, and renewing the lease got a 169.x.x.x address which I would never manually assign, and is weird because their WiFi router is 172.16.110.1 according to trace route.

Not just reprimand, but depending on the organization and how their AUP (Acceptable Use Policy) is written, you could have been banned and had a police report filed for "interfering with a government owned computer/network". (I know, I write and update these things).

However, your results (getting a self assigned IP) tells us something very important - they use some sort of authentication to allow computers onto the network (probably RADIUS). If it works on their Windows machines, but not on your MBP, it's a safe bet they have something preventing foreign computers from accessing their network (so, yes, they have a reason and the ability to implement device detection).

Devices forty centimeters apart, so probably on the same router.

There's nothing other than getting a list of associated clients from each of the WAPs (Wireless Access Points; not routers) that can confirm this. WAPs are placed in physical locations for more than just signal strength, there may be high demand in particular locations so you may have more in one area than another. Just because a WAP can support up to (for example) 256 clients, doesn't mean it can do so simultaneously.

TL;DR

Your MBP is not connected to the network while your iPad does and is. If you've confirmed that your WiFi works properly everywhere else but the Library, you need to approach the Library support staff to look into it (maybe they're out of resources or you're actually blocked). Do not circumvent their systems and/or policies in order to get connected.