"fatal: early EOF" on fetch or pull – NETWORK DEPENDENT

To begin within, I looked at this post which has some of the same symptoms, but mine has a specfic twist to it.

Sometimes, but not always, when I try to fetch or pull from github, it pauses for a very long time partway through “Compressing objects” and then fails hard:

$ git fetch origin
remote: Enumerating objects: 97, done.
remote: Counting objects: 100% (97/97), done.
remote: Compressing objects: 100% (69/69), done.
client_loop: send disconnect: Broken pipe
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: unpack-objects failed

However, I’ve noticed that if I funnel all my network traffic through a VPN (either my work VPN or a commercial VPN I subscribe to), everything works fine. Of course, I’d rather not have to connect to a VPN every time I need to pull, so what I’m wondering is:

  • What network-specific issue(s) might be causing this kind of issue?
  • Is there anything I can check/configure on my machine or in my router/gateway?
  • Is there anything I could look for in wireshark to help diagnose this?
  • If it is specific to my ISP, how would I even begin to have the conversation with them about what’s going on here?

FWIW, my ISP is AT&T fiber. No other real issues with it besides this one.

1 Like

Hey mbklein! :wave: This does indeed sound like a weird one! Did you ever get to the bottom of it?

The main resource I can point you to is this page:


That will give you real time info about which IP addresses and ports need to be open. You might need to share it with your ISP?

Nope. Never resolved it. I wouldn’t even know how to contact anyone at my ISP who would even understand the problem without having to sit through hours of menus and low-level script-driven support questions.

I might try to figure out if the issue affects certain GitHub IP addresses and see if I can route my traffic only to working ones, but that seems a little extreme.

Does switching whether you do Git operations over SSH or HTTPS make a difference?

I’ve been reviewing other cases like this and the ‘client_loop: send disconnect: Broken pipe’ error generally indicates there is a local network issue on the client end, as you’ve already surmised.

As you’re on the Pro plan you could submit a support ticket to us at:


To get some further insight into the problem, could you please visit our debug site from an affected machine and provide the output of the commands for your specific operating system and all of the information shown in the Connection Data box? Please also click on the Test your connection (may take several seconds) button and include those results.


Please note that it may take a short time for the connection data to fully load, and thank you in advance for your time in gathering these additional details for us.

Thanks! I ran the tests and followed up via a support ticket pointing back at this thread. I’ll follow up here if/when there’s a resolution to make sure there’s a searchable record of it.


This post is very close to what I’m seeing and there seems to be a fair bit of overlap with my environment as well. Did you make any progress resolving this?

I find that I cannot fetch from a reasonably large git repo hosted in Github Enterprise. It is also network dependent and I also have AT&T Fiber. Most notably I think this only started happening when I added a Google Mesh/Nest Wifi mesh to my network. What’s even stranger is that it doesn’t seem to happen when I use the guest network I have enabled in the Nest Wifi (which makes me think it has nothing to do with my ISP but I thought I’d mention it since there’s overlap with your environment.)

I get the client_loop: send disconnect: Broken pipe after what looks like a 15 second timeout. As far as I can tell this is a packet flush.


Truncated logging (notice ~15 second timeout):

09:47:36.468348 packfile.c:1631         .git/objects/pack/pack-ee7cf12634e373c41b8799102b0ace01c34e0a7a.pack 181817
09:47:36.470344 pkt-line.c:80           packet:        fetch> 0000
client_loop: send disconnect: Broken pipe
09:47:54.554990 read-cache.c:2306       performance: 0.001026000 s:  read cache .git/index
09:47:54.560598 packfile.c:1631         .git/objects/pack/pack-ee7cf12634e373c41b8799102b0ace01c34e0a7a.pack 641943

I’m happy to report I fixed this with the answer here: https://stackoverflow.com/a/57082400/11605815

And more specifically I had to use IPQoS=0x00 setting, not the IPQoS=throughput setting that I’d seen mentioned a lot before (and I tried before making my comment above). This is on a Mac.

1 Like

@isstabb - THANK YOU SO MUCH! If there was a way to give you more props than just thanks, I would. (I am literally creating an account on GitHub community so I can give you this credit and say thank you).

I have an AT&T Fiber + Netgear Orbi mesh setup and have been unable to clone/push/pull consistently since I got it. I really thought it was the Orbi so almost decided to return it. I have been switching to my phone’s network whenever I have to do any Git operations.

And the most frustrating part is that there are no easily accessible logs to try to figure out what’s happening… so I resigned to the fact that I was going to be by myself and just have to change out the network… and like someone here mentioned, did not want to call Netgear or AT&T support because didn’t want to sit through and explain Git and all that…

Setting IPQoS=0x00 did the trick for me and I’m so happy right now, I could cry :slight_smile:

Thank you!

1 Like

Great news! Thanks for sharing your fix. I ended up moving to a new home and a new ISP so my situation was “resolved” but not specifically “fixed.”