Resolved Mysterious TCP block?

Discussion in 'Mac Basics and Help' started by Let's Sekuhara!, Nov 18, 2013.

  1. Let's Sekuhara!, Nov 18, 2013
    Last edited: Nov 19, 2013

    Let's Sekuhara! macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #1
    This is bizarre. I can't connect to the internet on my iMac because all sorts of connections are being blocked. No TCP connections are going through. I can successfully ping an IP address through Terminal because ping is ICMP, not TCP.

    The problem came up seemingly randomly today. It was working fine a couple of days ago.

    At first it seemed to be specifically a DNS problem, but now it's clear that it is something beyond that.

    UDP may also not be working because I can't ssh.

    Any ideas? Please help!

    [OS X 10.8.2]
     
  2. vmachiel macrumors 68000

    Joined:
    Feb 15, 2011
    Location:
    Holland
    #2
    Check your router settings, do they have some option for port blocking?
     
  3. Let's Sekuhara! thread starter macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #3
    Thanks but it's not a router issue. There are several other Macs connected with no problems.
     
  4. vmachiel macrumors 68000

    Joined:
    Feb 15, 2011
    Location:
    Holland
    #4
  5. Let's Sekuhara! thread starter macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #5
    Thanks, but I've tried that. No luck.
    I suspect it's not a network configuration thing,
    but rather something deeper in the system.

    I had a firewall (Little Snitch) running, although after running into this problem I turned it off, and after still not being able to connect I completely uninstalled it (using the official uninstaller). This didn't resolve the issue.

    I also tried creating a new user account and attempted to connect while signed in to this new test account. But it still won't connect to the internet. (It connects to Wi-Fi, just won't pull data through the connection)
     
  6. vmachiel macrumors 68000

    Joined:
    Feb 15, 2011
    Location:
    Holland
    #6
    Are you sure this isn't a router issue? Isn't there some setting in there that limits traffic to your local IP?
     
  7. Let's Sekuhara!, Nov 18, 2013
    Last edited: Nov 18, 2013

    Let's Sekuhara! thread starter macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #7
    The person who set up the network was confident it was nothing in the router settings or network settings.
    Let me ask you however, is there any reason a router would block a local IP suddenly?
     
  8. satcomer macrumors 603

    satcomer

    Joined:
    Feb 19, 2008
    Location:
    The Finger Lakes Region
    #8
  9. mfram macrumors 65816

    Joined:
    Jan 23, 2010
    Location:
    San Diego, CA USA
    #9
    One possibility to look into is MTU weirdness. If there are mismatched MTU values on different segments on the network, it can cause problems because larger IP packets could be dropped by the network. Apps that use TCP would lend themselves to applications that could use large IP packets.

    One place MTUs could be artificially lowered is if there's a VPN involved. Another problem I've seen is with a mis-configured DHCP server at an ISP that was sending out bogus values for MTU. I think Windows tends to ignore that information, but a Mac (or your router) may pay attention to it which would be a problem.

    Normal MTU over an ethernet segment should be 1500.

    Linux 'ping' offers the -s argument to specify a packet size. I don't have a Mac in front of me at the moment to see if that same option is available. If so, use a larger size like 1490 and see if the ping goes through.
     
  10. Let's Sekuhara! thread starter macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #10
    Thanks for the idea. We played with changing the MTU value, but to no avail.

    The conclusion we're coming to is that there's something in the software configuration of this Mac that has somehow been changed, possibly by malware or a corrupt setting file that is causing certain types of connections to be refused.

    Pinging a domain name fails. (Seems it can't resolve DNS)
    Pinging an IP address succeeds in Terminal but if that IP address is entered into a browser it fails to connect to the site. (I think because when going through an application TCP is used?)

    Connecting to another machine on the network via ssh fails (from both directions), yet via ftp succeeds! Strange.

    We get the same results whether physically connected through a LAN cable or wirelessly through Wi-Fi.

    We can view the router settings page through the browser, but all router settings appear normal and all other connected devices are functioning as normal.

    ----------

    Another reason we believe there is something blocking the connection from the Mac's software configuration locally is that when connections are "refused" or fail the error message is returned instantaneously. It's not like it's taking a moment to talk to the network and then failing. The request never makes it out in the first place.
     
  11. ElectricSheep macrumors 6502

    ElectricSheep

    Joined:
    Feb 18, 2004
    Location:
    Wilmington, DE
    #11
    Couple of things to try....

    Check the state of the ipfw and pf packet-filters:

    sudo ipfw show
    sudo pfctl -s all

    the default ipfw rule is to allow ip any from any, and the pf should be disabled (Status: Disabled; all counters should be zero).

    You can perform manual dns lookups with nslookup, optionally specifying a specific DNS server to override the system configured DNS server:

    nslookup www.google.com 208.67.222.222 (using one of OpenDNS's servers)

    Running nslookup without specifying a server address will report the configured server.

    scutil --dns will provide comprehensive information with how the resolver is configured on the Mac. There will be quite a few entries for local, multicast, and ipv6; you are interested in resolver #1. You can test reachability with scutil -r www.google.com.

    If you can on another machine, download lft (Layer Four Traceroute) and copy it to the target machine. You may have to build from source, and libpcap must also be installed. Its a much more flexible traceroute tool that allows for using protocols alternative to ICMP.
     
  12. Let's Sekuhara!, Nov 19, 2013
    Last edited: Nov 19, 2013

    Let's Sekuhara! thread starter macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #12
    IT IS FIXED! YESSSSSSSS!

    The culprit was either a Dropbox auto-update or something in /Library/Preferences/SystemConfiguration
    Since Dropbox updated itself on the 16th I believe Dropbox is most likely the cause.

    Steps to resolve:
    I quit Dropbox, deleted Dropbox.app and DropboxHelperTools
    (Steps to uninstall Dropbox here)

    I also deleted the contents of /Library/Preferences/SystemConfiguration
    (No known connection to Dropbox, but it's another step I took. Mentioning it just in case.)

    I then rebooted. And once again I can connect to the internet!

    Symptoms:
    It is interesting to note that before deleting said files scutil --dns would list only resolver #1 with if_index being 5.
    After resolving the problem scutil --dns now lists resolvers #1 through #8, and the if_index of #1 is now 6.

    Thank you ElectricSheep and everyone who contributed ideas in this thread!
    I was on the verge of wiping my drive and reinstalling OS X.
     
  13. ElectricSheep macrumors 6502

    ElectricSheep

    Joined:
    Feb 18, 2004
    Location:
    Wilmington, DE
    #13
    I'm glad you resolved your issue (no pun intended). The reason for the inconsistent behavior is that DNS resolution on MacOS X is a little bit funny depending on what is doing the lookup. For most basic posix/command-line/non-cocoa applications, the contents of /etc/resolv.conf governs what name servers will be used for DNS queries.

    However, starting with MacOS X 10.6, name resolution is handled by mDNSResponder, which consolidates lookups for multicast (Bonjour/Rendezvous) and unicast (traditional DNS lookups) requests. mDNSResponder uses the SystemConfiguration, stored in /Library/Preferences/SystemConfiguration/. This collection of property lists forms a database which can be manipulated by scutil. If something gets screwed up, it can affect DNS requests from some applications but maybe not others.

    This is also why you should not disable mDNSResponder unless you know what you are doing; its not just for Bonjour/Rendezvous anymore.
     
  14. Let's Sekuhara! thread starter macrumors 6502

    Let's Sekuhara!

    Joined:
    Jun 30, 2008
    Location:
    日本
    #14
    What's odd is that in the end I had to do a complete reinstall anyway.
    Still not sure if it was a Dropbox issue or something else.
    But the TCP problems came back after a week or so.

    Figured that the time I'd need to spend pinpointing the issue would be greater than simply reinstalling, so I chose the later.

    Oh well. In the end I have to chalk it up to being one of those inexplicable issues that you just gotta let go and start over.
     

Share This Page