Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I've seen lots of questions asking what to do when Ethernet works and Wi-Fi doesn't, but I seem to have the opposite problem. System details are as follows:

  • 2009 Mac Mini (Intel Core Duo)
  • OS X 10.6.8 (Snow Leopard)
  • Fairly typical home network, with Centurylink ADSL service coming through an Actiontec DSL modem into a Buffalo wireless router/firewall/base station.
  • Other computers in the house connect wirelessly to the Buffalo router which is configured to hand out IP addresses via DHCP and forward DNS requests to the DNS server (I'm using Google). One of the Ethernet ports on the router is connected to the uplink port on a Netgear minihub, and two Macs (the Mini and an old G4 tower) are connected to that minihub.

With this setup my Mini can see the router in Network Preferences, and seems to be getting the DNS server address correctly via DHCP. I can ping outside servers by IP address or by name and get response times under 100 ms. Yet WWW access is incredibly slow. Most pages that I open in Safari will take 5-10 minutes to load, if at all--usually the progress bar gets halfway through the title of the page and then just freezes. This is a recent development (but of course I can't think of anything that might have changed to trigger it).

If I activate Airport and change the order of preferred networks in the Network Preferences pane to Airport first, Ethernet second, all of a sudden everything works fine.

I realize there is room for some hardware diagnostics to be done here. I can take the minihub out of the equation by connecting the Mini directly to the Buffalo router, and I can try different Ethernet cables. Beyond that I'm not sure what to do. What can be done at the command line or via diagnostic software to see where the request packets are going and why nothing's coming back? I'm really baffled as to why ping to a server by name works fine, but Safari doesn't--my limited understanding of TCP/IP says that if the former works, the latter should too. And why does wi-fi work fine, but a hard-wired connection straight to the router doesn't?

EDIT: Here's the output of ifconfig -v with Airport active and Ethernet inactive.

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet 127.0.0.1 netmask 0xff000000 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
    ether 00:25:4b:bc:f6:48 
    media: autoselect
    status: inactive
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
    lladdr 00:25:4b:ff:fe:bc:f6:48 
    media: autoselect <full-duplex>
    status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:25:00:f9:4c:d1 
    inet6 fe80::225:ff:fef9:4cd1%en1 prefixlen 64 scopeid 0x6 
    inet 192.168.11.10 netmask 0xffffff00 broadcast 192.168.11.255
    media: autoselect
    status: active
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:50:56:c0:00:08 
    inet 192.168.186.1 netmask 0xffffff00 broadcast 192.168.186.255
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:50:56:c0:00:01 
    inet 192.168.37.1 netmask 0xffffff00 broadcast 192.168.37.255

EDIT AGAIN: Here's the en0 section from ifconfig -v with Airport inactive and Ethernet active.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:25:4b:bc:f6:48 
    inet6 fe80::225:4bff:febc:f648%en0 prefixlen 64 scopeid 0x4 
    inet 192.168.11.200 netmask 0xffffff00 broadcast 192.168.11.255
    media: autoselect (10baseT/UTP <half-duplex>)
    status: active

EDIT #3: Here's the output from netstat -i for en0 with Airport inactive and Ethernet active.

en0   1500  <Link#4>    00:25:4b:bc:f6:48   352450  1385   289436     0     0
en0   1500  alex-chambe fe80:4::225:4bff:   352450     -   289436     -     -
en0   1500  192.168.11    192.168.11.200    352450     -   289436     -     -
share|improve this question
    
Can you open Terminal, run ifconfig -v and post its output? –  jaume Jun 13 '13 at 6:50
    
@jaume: Done, see above... –  dodgethesteamroller Jun 13 '13 at 15:06
    
Thanks, I see that Ethernet is set to autonegotiate (media: autoselect). Could you add the output of ifconfig -v with Ethernet active? The en0 section will suffice. –  jaume Jun 14 '13 at 5:40
    
@jaume: Done, see above... –  dodgethesteamroller Jun 16 '13 at 16:44
    
Thanks, that <half-duplex> may be causing the problem... Could you run netstat -i and add the output to your question? Only the line for en0 is relevant. Please run netstat -i with Airport inactive and Ethernet active. –  jaume Jun 16 '13 at 18:29
show 5 more comments

1 Answer

up vote 0 down vote accepted

It could be an duplex mismatch problem: small packets, like the ones ping sends, get through while large packets (as generated when browsing the web) get delayed or lost, which leads to poor performance.

This problem may arise either when the autonegotiation process between your Mac Mini and the Netgear minihub fails or when speed/duplex mode are set manually and don't match at both ends.

To solve the problem you first need to check the Ethernet settings:

  • Open System Preferences>Network, select Ethernet from the list on the left and click Advanced....
  • Select the Hardware tab.

Then:

  1. If configure is set to "Automatically":

    enter image description here

    autonegotiation is on. Change it to "Manually" and try different Speed and Duplex settings, for example:

    enter image description here

    until the problem is gone. Note that you must press OK for the settings to take effect.

  2. If configure is set to "Manually", change it to "Automatically" and test.

  3. If nothing helps, try another hub or connect your Mac directly to the router. If that solves the problem replace your hub.

share|improve this answer
    
Thanks, sounds promising--when I have time to play with this later today I will do so and report back. –  dodgethesteamroller Jun 13 '13 at 15:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.