Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I have a brand new MacMini straight from apple preinstalled with 10.6.4. Summary of the problem is when downloading a file larger than 1meg after 800k or so the download slows tremendously to 1 or 2k a second when connected to our main private network.

Right out of the box. A brief overview of our network layout: we have 5 switch rooms that go to a core switch which goes to our firewall (which is our DHCP server) then to our router/ISP. We also have two other ISPs, we have a public wireless network and a separate line we have for webcasting/teleconferencing.

So, If the MacMini is plugged in directly to our webcasting line (no DHCP server, it must be configured manually) works fine, beautifully, every download finishes. Same goes if it's on our public wireless, a bit choppier but it completes the job. The MacMini needs to be on our main network where all our file servers are and everything. Without fail between 700k to 900k the download seems to bottleneck. Downloads off our NAS and SAN work just fine so we are thinking it might be a port 80 issue. Every other mac on our network is fine. We switched to several public DNS's and also assigned it a manual ip and tried a static ip and it's the same problem. We have reformatted and applied all the updates, we have used images from working machines and applied it to this machine, and it's the same problem every time. We have returned the MacMini twice and are on our third machine.

I am trying to rule out hardware but i doubt it might be the ethernet NIC on the newer macmini's because I put it on a wireless access point on our private network and the bottle neck still happens.

share|improve this question
Lots of details, but lots of variables. Keep it simple, stick with troubleshooting it via the NIC, and thow wireshark on there and see what its really doing. – SpacemanSpiff Mar 18 '11 at 17:50
Interestingly enough, if I put it on 10baseT/UTP, full-duplex, flow-control at standard MTU, it works, slow on the network drives, but managble. Any theories? – user75010 Mar 18 '11 at 19:04
If you can replicate the issue, port to port on the same switch, then take the switch out and replicate it with a crossover cable device to device. Process of elimination will probably figure this out. Did Wireshark reveal any odd behavior? – SpacemanSpiff Mar 18 '11 at 21:01
yeah, when the bottleneck happens i get about 50 TCP Dup ACK, the window size doesn't change however but the speed is still much much slower. – user75010 Mar 21 '11 at 14:16
I just used a crossover cable and also cat-6 on a gigabit switch we have no progress. The problem is that when I use our private wireless. The problem still happens, which leads me to believe that it is our firewall. Our public wireless works just fine. Both systems have Sonicwall's however they are configured differently. Maybe the macmini is requesting some ports that we have blocked? – user75010 Mar 21 '11 at 15:53

I think this is an incompatibility between your Sonicwall and the modern MacOS. A similar issue can occur with Win7. I had this issue on our Network, and it took several calls to Sonicwall support before we got lucky with an engineer that knew the problem. He had to pull the info of a non-public KB resource only they had access to. Essentially, anything that uses DPI can cause downloads to bomb. Odds are, DPI/IPS/etc is enabled on the LAN segment you're having problems with.

The fix involved going to the Sonicwall diagnostics page at https://yourfirewall/diag.html. Then check the box for Enable enforcement of a limit on maximum allowed advertised TCP window with any DPI-based service enabled. Then in the next line, set the maximum limit to 256.

This resulted in vastly improved downloads on our Win7 and Mac machine. No more random stops.

--Christopher Karel

share|improve this answer
Must be a different software version, diagnostics just brings up fancy ways of reporting. I went through all the menus, I didn't see anything with DPI or Deep Packet Inspection. Sonicwall said they will take 48 hours to respond to my ticket, so for now I play the waiting game. – user75010 Mar 28 '11 at 15:48
The diag.html URL I mentioned is completely different from the System->Diagnostic menu option available through the Firewall's main GUI. You have to go to the diag.html URL directly. It's basically the 'secret' settings behind the firewall, and isn't reachable through the main GUI. That being said, what firmware/model are you using? – Christopher Karel Mar 28 '11 at 19:39
I'm using a PRO 3060 Standard and firmware version: SonicOS Standard this is the diag.html settings. this is what my diag.html says Perhaps Strict TCP stateful inspection is similar? – user75010 Mar 29 '11 at 14:21
Hmm...that's definitely the correct screen, but it's still quite a bit different from the options I see with SonicOS Enhance v5. Doesn't look like you have the tuning setting I was referencing. – Christopher Karel Mar 29 '11 at 15:14
After talking with sonicwall under IPS Network Services, Enable IP Reassembly needed to be checked. After all this it comes down to a checkbox. – user75010 Mar 29 '11 at 17:14

Your Answer


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.