I am experiencing a strange data corruption issue while working on a L2TP VPN, after upgrading from macOS 10.11 to 10.12. Random corrupted data occurs in the middle of somewhat "larger" downloaded files, e. g. JavaScript resources or any other source files with a file size around 1 ~ 2 MB. It seems the corruption comes up occasionally at file sizes < 1 MB, but quite reliable at file sizes above. The position and content appears to be random. I am attaching a screenshot containing an example of the file corruption which occured in a 1.4 MB JavaScript file.

enter image description here

I never had any problems concerning this on macOS 10.10 or 10.11 and the latest issue results in very annoying consequences. E. g. I am not able to access JS-heavy web apps anymore. Furthermore it is risky to work in live systems of enterprise software when downloading, patching and uploading files. People around me using the same VPN on macOS 10.12 have the very same problem, whereas people still working on macOS 10.11 have no trouble at all.

Does anyone else experience this problem? How can I troubleshoot this?

Also relating to an older post in Apple Communities describing a similar (or the same?) issue in older macOS versions: https://discussions.apple.com/message/30908122?start=0&tstart=0#30908122

Edit 2016-11-08

What's interesting: scp (SSH) downloads are interrupted by an error.

xyz-macbook:Downloads xyz$ scp [email protected]:/srv/www/xyz/ext-5.0.1/build/ext-all.js .
[email protected]'s password:
ext-all.js    0%    0     0.0KB/s   --:-- ETACorrupted MAC on input.
ssh_dispatch_run_fatal: Connection to port 22: message authentication code incorrect
lost connection

Whereas curl (HTTP) downloads finish, but contain the above-mentioned corrupted characters.

xyz-macbook:Downloads xyz$ curl "" -o "ext-all.js"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1952k  100 1952k    0     0  1728k      0  0:00:01  0:00:01 --:--:-- 1729k

Edit 2016-11-11

The corrupted data is different with every download of one and the same file:

xyz-macbook:Downloads xyz$ md5 dummy_novpn.txt 
MD5 (dummy_novpn.txt) = ca323efb28ed75534f8f6b7b0237d9da
xyz-macbook:Downloads xyz$ md5 dummy_vpn.txt 
MD5 (dummy_vpn.txt) = 060bbe9846e7845993041a1481c34b93
xyz-macbook:Downloads xyz$ md5 dummy_vpn2.txt 
MD5 (dummy_vpn2.txt) = dacfc661f9a85606afbdfefa72d50516
xyz-macbook:Downloads xyz$ md5 dummy_vpn3.txt 
MD5 (dummy_vpn3.txt) = 8c3f06f9ee440947a9e5864748bd7010
  • 1
    That is an insidious failure. Are you thinking that a web browser (safari or other) is actually not receiving the correct files or are you using rsync or webdav or another way to download these files to the filesystem? Basically - what transport method is failing you over VPN?
    – bmike
    Commented Nov 8, 2016 at 20:22
  • 1
    Good hint! Any transport method. I did a lot of testing and noticed it both while downloading files via web browsers and curl/wget (WebDAV/HTTP), as well as via scp/rsync (SSH). What's interesting: scp (SSH) downloads are interrupted by an error (ETACorrupted MAC on input. / ssh_dispatch_run_fatal: Connection to port 22: message authentication code incorrect / lost connection), whereas curl (HTTP) downloads finish, but contain the above-mentioned corrupted characters.
    – proximus
    Commented Nov 8, 2016 at 21:31
  • I got here researching own MacOS data corruption where a GitHub response header comes misspelled _ransfer-Encoding: chunked. I then found a year 2009 thread on the HTTP/1.1 data corruption, curl.haxx.se/mail/lib-2009-09/0169.html (but I cannot change git to use HTTP/1.0).
    – eel ghEEz
    Commented Feb 21, 2018 at 5:41

2 Answers 2


Do you happen to have a https://eshop.macsales.com/item/OWC/TCDOCK11PSG/ ? I had the same issue, and it turns out if I moved the ethernet from the port on the OWC replicator, to a USB-C Ethernet, the problem went away.


I experienced identical symptoms with a L2TP-over-IPsec tunnel using the built-in wireless interface on a MacBook Pro (2019) with macOS 12.6.

After a bit of experimentation, the fix was to turn off RX hardware checksum offloading with:

sudo sysctl -w net.link.generic.system.hwcksum_rx=0

which resolved 100% of the data corruption issues. Since checksum offloading is a matter of performance, you may wish to reverse it when not using the VPN (i.e. reset the value to 1 rather than 0).

It is possible to persist the setting, if desired, by invoking sysctl at restart. To do so, paste the following into /Library/LaunchDaemons/sysctl.plist:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

and then execute

launchctl load /Library/LaunchDaemons/sysctl.plist

However, I hesitate to recommend doing so, since it may have performance and/or energy consequences. Personally, I keep the manual setting in a small shell script, executed only when needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .