Skip navigation
This discussion is archived

Internet Stops Working ALOT on Macbook Pro ONLY

7075 Views 33 Replies Latest reply: Dec 3, 2007 2:28 PM by oliverp RSS
  • mreckhof Level 2 Level 2 (405 points)
    Currently Being Moderated
    Nov 24, 2007 8:41 PM (in response to mreckhof)
    Ok - this is REALLY weird. I'm tempted to say this is the local router, but I'll need to do more tests on diff systems at the same time to verify. The really really odd part is that the router seems to be dropping the mac out of its arp table. It therefore won't talk to me until it decides to re-arp for my mac address.

    Things to note in this trace:

    - An ICMP ping is going to the local router (192.168.15.1) and replies are NOT coming back.
    - Packets keep coming in and going out on the local network so the local host networking is working just fine.
    - Packets destined off-network are not making it out either. See socket 60125 - it's trying to shutdown a previously opened socket and keeps having to retransmit since it's not getting a FIN-ACK back from its FIN.

    * The router sends out an ARP request asking for my mac address. So somehow, it has lost it even though I've been sending data for quite a while.
    - My box replies.

    - The ICMP pings will suddenly start going through.
    - The FIN finally gets a FIN-ACK
    - Everything is back to normal.

    Err:~ eb$ sudo tcpdump -ni en1
    Password:
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes
    22:23:17.616886 IP 192.168.15.108.1026 > 255.255.255.255.1900: UDP, length 148
    22:23:19.784710 IP 192.168.15.110.60133 > 66.135.48.253.80: S 281377011:281377011(0) win 65535 <mss 1460,sackOK,eol>
    22:23:23.153365 IP 192.168.15.104.137 > 192.168.15.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:23:24.547784 IP 192.168.15.108.4905 > 255.255.255.255.4905: UDP, length 5
    22:23:25.153257 IP 192.168.15.104.137 > 192.168.15.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:23:25.572028 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 0, length 64
    22:23:26.395649 IP 192.168.15.110.59928 > 63.246.25.157.80: . 1040691985:1040693425(1440) ack 672412312 win 65535 <nop,nop,timestamp 306542761 10941830>
    22:23:26.572250 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 1, length 64
    22:23:27.153290 IP 192.168.15.104.137 > 192.168.15.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:23:27.572506 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 2, length 64
    22:23:28.572794 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 3, length 64
    22:23:29.573086 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 4, length 64
    22:23:29.720933 IP 192.168.15.108.1026 > 255.255.255.255.1900: UDP, length 148
    22:23:30.573288 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 5, length 64
    22:23:30.814409 IP 192.168.15.110.60125 > 72.246.200.199.80: F 3333245440:3333245440(0) ack 1902839257 win 65535 <nop,nop,timestamp 306542806 1047960670>
    22:23:30.814712 IP 192.168.15.110.60065 > 63.246.25.157.80: F 2585024105:2585024105(0) ack 1117153205 win 65535 <nop,nop,timestamp 306542806 11362654>
    22:23:30.815129 IP 192.168.15.110.60120 > 209.8.114.14.80: F 1100588448:1100588448(0) ack 2720518985 win 65535 <nop,nop,timestamp 306542806 206144478>
    22:23:30.815262 IP 192.168.15.110.60119 > 209.8.114.14.80: F 762700974:762700974(0) ack 2716418281 win 65535 <nop,nop,timestamp 306542806 206144475>
    22:23:30.815409 IP 192.168.15.110.60121 > 209.8.114.14.80: F 1764537627:1764537627(0) ack 2715530987 win 65535 <nop,nop,timestamp 306542806 206144478>
    22:23:31.573572 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 6, length 64
    22:23:31.805563 IP 192.168.15.110.60125 > 72.246.200.199.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542815 1047960670>
    22:23:31.805621 IP 192.168.15.110.60121 > 209.8.114.14.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542815 206144478>
    22:23:31.805656 IP 192.168.15.110.60120 > 209.8.114.14.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542815 206144478>
    22:23:31.805682 IP 192.168.15.110.60119 > 209.8.114.14.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542815 206144475>
    22:23:32.390161 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 253
    22:23:32.393245 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 271
    22:23:32.396701 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 325
    22:23:32.403033 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 247
    22:23:32.409240 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 289
    22:23:32.412613 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 321
    22:23:32.422982 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 313
    22:23:32.432941 IP 192.168.15.1.1900 > 239.255.255.250.1900: UDP, length 318
    22:23:32.573843 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 7, length 64
    22:23:33.574092 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 8, length 64
    22:23:33.578009 arp who-has 192.168.15.110 (c0:a8:c0:a8:c0:a8) tell 192.168.15.1
    22:23:33.578094 arp reply 192.168.15.110 is-at 00:1c:b3:7c:a3:18
    22:23:33.579890 IP 192.168.15.1 > 192.168.15.110: ICMP echo reply, id 57604, seq 8, length 64
    22:23:33.809450 IP 192.168.15.110.60125 > 72.246.200.199.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542835 1047960670>
    22:23:33.809515 IP 192.168.15.110.60121 > 209.8.114.14.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542835 206144478>
    22:23:33.809543 IP 192.168.15.110.60120 > 209.8.114.14.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542835 206144478>
    22:23:33.809568 IP 192.168.15.110.60119 > 209.8.114.14.80: F 0:0(0) ack 1 win 65535 <nop,nop,timestamp 306542835 206144475>
    22:23:33.817953 IP 209.8.114.14.80 > 192.168.15.110.60121: R 2715530987:2715530987(0) win 0
    22:23:33.817963 IP 209.8.114.14.80 > 192.168.15.110.60120: R 2720518985:2720518985(0) win 0
    22:23:33.818455 IP 209.8.114.14.80 > 192.168.15.110.60119: R 2716418281:2716418281(0) win 0
    22:23:33.818629 IP 72.246.200.199.80 > 192.168.15.110.60125: . ack 1 win 6795 <nop,nop,timestamp 1048021650 306542835,nop,nop,sack 1 {0:1}>
    22:23:34.574380 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 9, length 64
    22:23:34.580694 IP 192.168.15.1 > 192.168.15.110: ICMP echo reply, id 57604, seq 9, length 64
    22:23:34.797482 IP 72.246.200.199.80 > 192.168.15.110.60125: F 1:1(0) ack 1 win 6795 <nop,nop,timestamp 1048022630 306542835>
    22:23:34.797591 IP 192.168.15.110.60125 > 72.246.200.199.80: . ack 2 win 65535 <nop,nop,timestamp 306542845 1048022630>
    22:23:35.574637 IP 192.168.15.110 > 192.168.15.1: ICMP echo request, id 57604, seq 10, length 64
    22:23:35.578570 IP 192.168.15.1 > 192.168.15.110: ICMP echo reply, id 57604, seq 10, length 64
    Mac OS X (10.5.1)
  • Hedi ® Level 1 Level 1 (20 points)
    Currently Being Moderated
    Nov 24, 2007 8:45 PM (in response to OS Lucinity)
    Wow the discussion became soo complicated, will follow until someone finds out a remedy.. Or Apple released 10.5.2
    iMac G5 20", Mac OS X (10.5), 2 GHz G5 - iPod 5th G 30 Gig - LaCie D2 DVD/DL
  • oliverp Calculating status...
    Hi All,

    Since leopard both my macbook pro and macbook have troubles to keep a stable wireless internet connection. Via cable it is a bit faster, but still slower than under Tiger.

    A major bummer - how can such an issue not show up in beta-testing, I wonder. It's quite a mistery, how there can be known issues with internet connectivity and take weeks to find a fix (is everybody busy with the iphone or planning another generation of the ipod?).

    My company is switching its Macs back to Tiger this week and has stopped an order for a new server altogether (was planned to work with leopard - since we have a mixed network the whole PC-Mac disussion is a neverending story, anyway). I guess next time we will be much more slow on purchasing updates, too. So it's fair to say that Leopard made us a little smarter. Thanks for small blessings.
    MacBookPro 2GHz 15", Mac OS X (10.5.1), Model 1.1 (exchanged mainboard)
  • PaulSahner Calculating status...
    I don't think it's just Airport...or even just DNS. I'm having nearly the same problems on a wired connection without a router of any kind.
    MacPro, Mac OS X (10.5), Quad 2.66/ 1TB/ 3GB/
  • mreckhof Level 2 Level 2 (405 points)
    I'm still up in the air on this one and somewhat confused (which is why I have not posted any more traces).

    When the mac is hanging, the windows PC on the same network (wired) seems to work fine.

    Also, when the mac is hanging, I can ping other wireless devices from the mac by IP, but I can't ping the routers IP address from the mac.

    This all does add up to what I noted earlier that the Layer 3 of the router appears to be dropping the MacBook's MAC address from its arp table. After a couple of minutes, it'll re-arp, pick it up, and everything is fine again.

    This wouldn't impact Layer 2 (the Wireless to Wireless pings) since the Layer 2 CAM table of the switch (built into the home router) is keeping the MAC in its table just fine.

    The problem is - I'm having a hard time thinking of how this could possibly be an OS issue since if the OS is sending traffic (as in my case, I can prove it is), then the router should be keeping the arp info up to date. That's not really something the OS has any control over.

    That said, folks with multiple router types (I'm using a DLink DI-604 right now, have seen others mention airport) are all reporting the same issue.

    I think I'm going to switch out my WAN router with a different brand/model and see if anything magic happens.

    If others can try to ping their default router by IP in a second terminal window while they are hanging on trying to get a DNS resolution (confirm in the first terminal window, not just safari), we can see if this is exactly the same issue elsewhere. Also try to ping things on the wireless network as well.

    It may take a few tries to ensure that it wasn't a timing issues and working pings aren't a coincidence and DNS has started working already.
    Mac OS X (10.5.1)
  • mreckhof Level 2 Level 2 (405 points)
    Very interesting. I've had zero unexplained issues since replacing the Dlink DL-604 with a Belkin F5D7230-4.

    Even more interesting is that I have always been going through the Belkin - just not as the Internet gateway - Wireless AP only. So that rules out the wireless part of my case at least and points squarely at some difference in how the Dlink and Belkin are handling packets.

    This also would match up with the sniffer traces and L3 ARP entry being lost in that both of the items can be explained by a faulty L3 router.
    Mac OS X (10.5.1)
  • mreckhof Level 2 Level 2 (405 points)
    Currently Being Moderated
    Nov 27, 2007 5:05 PM (in response to mreckhof)
    Take that back - just had a hang - check out this little bit of crazy. There is an 8 second gap of no traffic after the crazy destination on the first SYN and the correct one on the second when things start flowing again.

    18:38:49.771595 IP 192.168.15.110.62163 > 0.0.254.19.80: S 1974853609:1974853609(0) win 65535 <mss 1460,sackOK,eol>
    18:38:57.311525 IP 192.168.15.110.62164 > 209.85.159.165.80: S 941715933:941715933(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 520154049 0,sackOK,eol>

    Note the destination address: 0.0.254.19 ??? It's valid and all, but not for this. And especially not over the Internet (that I'm aware of).

    That address is also in DNS cache (showing a few other goofy entries):

    Category Best Before Last Access Hits Refs TTL Neg DS Node
    ---------- ------------------ ------------------ -------- ------ -------- ----- ---------
    Host 11/27/07 19:37:43 11/27/07 18:37:43 0 2 3600 YES
    Key: hipv4_addrlist:0.0.254.19
    Host 11/27/07 19:30:13 11/27/07 18:30:13 0 2 3600 YES
    Key: hipv4_addrlist:0.80.222.24
    Host 11/27/07 19:30:40 11/27/07 18:30:40 0 2 3600 YES
    Key: hipv4_addrlist:0.144.229.24

    ... time to keep searching I guess ...
    Mac OS X (10.5.1)
  • mrledzep Calculating status...
    Currently Being Moderated
    Nov 29, 2007 2:04 PM (in response to OS Lucinity)
    Yet another person with the same problem. I have tried all of the suggestions on this post and others but it is still dropping all the time. It is usually inconsistent unless I open mail. For some reason it kills my connection every single time I try to check for new mail. Never had a single problem until Leopard.

    APPLE HELP!!!!!!
    MBP 2.2, C2D, Mac OS X (10.5.1)
  • mreckhof Level 2 Level 2 (405 points)
    No airport here. Various different types of hardware.

    I've figured out all of my issues so far (except keyboard hang which is an open bug).

    I posted everything with solutions here: http://discussions.apple.com/message.jspa?messageID=5985103#5985103
    Mac OS X (10.5.1)

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.