# Confusing download problem



## anoldguy (May 11, 2016)

I used to at one time be a pretty fair Unix System Administrator, got paid well too... The past few years I have been away from FreeBSD, due to owning a laptop that was not really compatible but have recently switched back to using FreeBSD on my "gaming computer".

10.3 really flies on this system, I have it installed on two SSDs / ZFS mirror, have 16GB ram, and an Intel 4960k CPU, using a sucky A Sync DSL Internet connection via em0. Intel Gb plugged directly into a LAN port on the router.

My Internet connection is not the greatest but its about the best available in the area. With the same computer but with an OS who shall not be named I can download a particular file from an AWS server at around 5Mbps. Takes less than half an hour to complete.

After many attempts to download that file in 10.3 via a browser I finally thought to try to fetch it
while at an appointment today. Started the fetch and went out the door, here's what I found when I got back.


```
fetch https://s3.amazonaws.com/sorry an NDA was agreed to.zip
darned NDA again.zip  6% of 6059 MB  469 kBps 03h26m
fetch: NDA once again.zip appears to be truncated: 405344889/6353875314 bytes
```

That's the same thing that happened with the attempts to download it via a browser.

I have tried that download in Firefox plain, and with a user agent switcher, and as I stated, with fetch.

What the heck is going on with this, anyone have any idea's?


----------



## PacketMan (May 11, 2016)

There can be any number of reasons resulting in poor download speed. Unless the experts chime in an say there is a known issue with FreeBSD 10.3-RELEASE I'm gonna say I doubt its the OS.

I am curious if this is an MTU issue.  Can you verify what your ISP/DSL MTU is, and then verify what the MTU of your computer?  On my machines its 1500 and I know 1500 matches my service provider service. Your computer MTU should be equal or less than the smallest MTU between yourself and your ISP.  Thus check your router too. If you send packet sizes larger than MTU they will get fragmented down, and that causes a performance hit.


----------



## anoldguy (May 11, 2016)

Hmm, that is something I didn't think about. But perhaps I wasn't clear. I have a 40 Mbps connection, speed test's show usually around 38.5. I can fetch pkg's at decent speed, etc. It's just that one particular site/file.
Can't do anymore for a few days, am laying in a hospital bed about to have my neck operated on.


----------



## PacketMan (May 11, 2016)

TCP windowing will cause varying performance based on TCP stack implementation in source and destination OS, and available bandwidth & latency between the two machines. I tell people a single TCP session can experience anywhere between 50 to 95% of the minimum  available bandwidth.


----------



## anoldguy (May 12, 2016)

Well, just got home from hospital. Checked my routers config, it was running at default, found some interesting stuff in there, it was logging all web activity and had QOS setup as default for voip, and a default mtu of 1492, with connection speed of 45.120/5.120 Mbps. Made some changes and disabled the routers firewall and enabled ipfw, set routers mtu @ 1500 to match the default setting in FreeBSD, still no change.

This is a brand new router, its a zyxel C1100z that has 4 1GB lan ports, it does however allow one to setup a lan dmz host. I may give that a try some time, just to see if it makes a difference. I kinda doubt it will. As I stated I can download other files in FreeBSD without probs. And speed tests pass.

I was laying in the hospital bed thinking about this and my paranoid brain thinks someone on that end setup to recognize the actual host that is downloading the file and blocks it unless it matches the OS's they support officially, but it seems that using a user agent switcher would bypass that,I just wanted to see if I could get the file to work on FreeBSD since I have a recovery period in front of me, maybe I will just listen to music instead.


----------



## kpa (May 12, 2016)

MTU of 1492 is often used if the WAN connection is PPPoE and setting it to 1500 is an error because it would break path MTU discovery. Leave it to 1492 in case your WAN connection is in fact PPPoE.


----------



## anoldguy (May 13, 2016)

I did set everything back to default (except for passwords) anyway, so thanks. 
Not putting too much more effort into this right now. But my connection is indeed PPPoE


----------



## anoldguy (May 17, 2016)

ok, so I couldn't leave this one be, just had to know more.

Installed virtual box, and downloaded a Linux ISO. A few minutes later I was online with the "virtual" Os,went to the download site for the file I was after, and whammo! Same download rate as with Linux native. 

In other words a connection is throttled/strangled if not via an approved OS.


----------



## drhowarddrfine (May 17, 2016)

fwiw, my network connection is advertised as 100Mb at home and I download at 132Mb and I don't fiddle with any network settings so it's not the OS.

Your quote does mention a NDA being agreed to which sounds like "Non Disclosure Agreement". It looks like there is some handshaking involved with that and that is where I think the issue is. On the host side.


----------

