Reputation: 3205

Github - unexpected disconnect while reading sideband packet

I've got quite interesting problem. I tried to send some projects via bash to repo and recently there was a problem with sending it.

Enumerating objects: 27, done.
Counting objects: 100% (27/27), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (25/25), 187.79 KiB | 9.39 MiB/s, done.
Total 25 (delta 1), reused 0 (delta 0), pack-reused 0
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

The funny part is that 10 min earlier I can send it without any problems.

I tried with getting new repo, creating new file, reinstalling git, git config --global http.postBuffer 524288000 with bigger numbers as well, also https.postBuffer and so on. Also install desktop version the same issue come in.

I've got problems mostly with React apps.

Anyone know the solution ? What could go wrong ?

Upvotes: 320

Answers (30)

Pushkar Sinha

Reputation: 13

None of the above option worked for me. I tried using GitHub Desktop and it worked for me.

Upvotes: 0

Onat Korucu

Reputation: 1042

In my case I just had to login gitlab from my browser. It asked for a mail verification, and after that, retrying "git push" worked fine.

Upvotes: 0

rmtheis

Reputation: 5836

There's a known issue in Git for Windows version 2.47.0.windows.1 that can lead to this error, and it can be resolved by installing a different version:

https://github.com/git-for-windows/git/issues/5199

Upvotes: 1

Jim Moores

Reputation: 307

I was running Windows 11 on ARM on an M1 under Parallels. Kept getting the side-channel error. Tried all the solutions. Eventually installed Preview of native openssh via winget, installed Beta ARM build of git for Windows and configured that to use OpenSSH instead of bundled one. That resolved the issue. Could have been the OpenSSH or the ARM build, not sure.

Upvotes: 0

Linar

Reputation: 1354

Whatever you need:

 git config --global http.postBuffer 524288000  # Set a larger buffer size
 git config --global core.compression 0         # Disable compression

Upvotes: 8

ATJ ShraOne Devade

Reputation: 11

I forgot to include .git at the end of the repository URL, but after adding it, it's working.

https://github.com/<your_repo_name>.git

Upvotes: 0

Tamtomo Abdi Negoro

Reputation: 326

Though some of the offered solution are similar, I tried them all and failed. Figured I tried a new approach, split my source into 4 repos, the root files and 3 of its sub folders are now assigned to each repo. Did a push and voila, it works. Thank God, blame myself for being too dependent on git. If all else above failed, please try my approach, been working for 3 days now and me with the team has made quite a lot of mods, pushes,and pulls since day 1

Upvotes: 0

obaylis

Reputation: 3034

I suggest connected to git using SSH. Doing this and retrying the push gave us the cause of the error.

In my case it was a Branch Policy that was failing in our Azure DevOps hosted repo. Pushing over http and you just get an unhelpful 503 response.

Upvotes: 0

FabianoLothor

Reputation: 2985

I tries a bunch of the solutions provided here without any luck, what really worked for me was way simpler.

I turned off my wifi connection.
I turned on my wifi connection.
I tried to do a push again.

No more errors.

Upvotes: 0

vaind

Reputation: 2414

None of the above worked for me, git config --global pack.window 1 did.

For what this does, see https://git-scm.com/docs/git-pack-objects in particular the --window argument:

"The objects are first internally sorted by type, size and optionally names and compared against the other objects within --window to see if using delta compression saves space."

So setting the window to 1 effectively disables delta compression (delta compression means only differences between objects are stored to save space when pushing commits)

Upvotes: 95

Mohammad Imani

Reputation: 547

None of the above worked for me. But this is worked for me:

Let's try to resolve the issue by increasing buffer:

git config --global http.postBuffer 52428800

Turn off the compression

git config --global core.compression 0

Try the workaround here:

$ git clone --depth 1 https://innersource.%2A.com/*repoName.git 
$ cd repository
$ git fetch --unshallow

Upvotes: 28

Hamza Muazzam

Reputation: 384

First, turn off compression:

git config --global core.compression 0

Next, let's do a partial clone to truncate the amount of info coming down:

git clone --depth 1 <repo_URI>

When that works, go into the new directory and retrieve the rest of the clone:

git fetch --unshallow

or, alternately,

git fetch --depth=2147483647

Now, do a regular pull:

git pull --all

Upvotes: 3

Mohamed Allal

Reputation: 20920

Connection, VPN, Antivirus, Firewall

Most probable reason. Especially if your git is up to date (if not you can update it).

The first thing to try is to check your connection and that it is stable.

My connection is excellent ===> wait Are you using VPN ?

=> Disable it. And try. (VPN's are big culprit for such a problem)

Still doesn't work? ==> Check for antivirus and firewalls.

Internet stable.

VPN VPN VPN => Big culprit

firewall and antivirus

git up to date

If that doesn’t work see the below:

VPN `dynamic IP rotation` is the culprit

If all works well after disabling the VPN. If you still need to use the VPN. Try to use a static IP instead. As mainly it makes a lot of sense. It's working working. Then bghghgh. It's VPN IP rotation with dynamic IP issue. (If you switch to static and it works for you. Please drop a comment. To sustain that statically.)
Experiment I led
- Cloned [email protected]:microsoft/vscode.git repo with a VPN with a static IP, cloning at 100kib/s overage (took 2 hrs cloning +).
  - This repo is so large. It fails to clone if a VPN with a dynamic IP is used.
  - Result - Works fine with a VPN with static IP ✅

Git cache, buffers and memory

https://stackoverflow.com/a/29355320/7668448

Open git global config:

git config --global -e

And add those entries:

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Try to clone again.

If that doesn't work! =>

You can try the partial fetch method and disabling compression:

https://stackoverflow.com/a/22317479/7668448

One command at a time

git config --global core.compression 0
git clone --depth 1 <repo_URI>
git fetch --unshallow

On Linux

Execute the following in the command line before executing the Git command:

export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

On Windows

Execute the following in the command line before executing the Git command:

set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

In addition:

git config --global core.compression 0
git clone --depth 1 <repo_URI>
# cd to your newly created directory
git fetch --unshallow 
git pull --all

For PowerShell users:

As kodybrown said in comments:

$env:GIT_TRACE_PACKET=1
$env:GIT_TRACE=1
$env:GIT_CURL_VERBOSE=1

Upvotes: 235

Mr Smith

Reputation: 3486

I tried many of the suggestions above, but none worked. I finally upgraded my git client from 2.37 to 2.41 & the problem went away.

Note, I've been getting random "your connection was interrupted" so my PC seems to have issues, which is another story.

Upvotes: 3

daptordarattler

Reputation: 96

All options above didn't solve the issue for me. I noticed that some helped and went past the initial limit, but still stopped halfway.

My issue was that, I was not able to fetch/clone/pull my repos due to some large files in the commit history that exceeded the 100mb mark. Also my slow internet made it impossible to fetch bad repos that still had those commit history to resolve the problem locally before pushing online.

Based on some of the comments that focused on the issue being a network/internet problem, I decided to focus on my SSH config and improve it for performance to see if it could help solve the problem. And Viola!!! Problem solved. I still maintained some of the configurations from previous suggestions, expecially the one related to the .git/config cache settings

[core] 
  packedGitLimit = 512m 
  packedGitWindowSize = 512m 
[pack] 
  deltaCacheSize = 2047m 
  packSizeLimit = 2047m 
  windowMemory = 2047m

This is how I updated by SSH confi at .ssh/config :

To improve Git download speed Linux, you can modify the SSH client configuration to optimize the SSH connection. Here are a few configuration options you can consider:

Use a faster SSH algorithm: By default, OpenSSH prioritizes the ssh-rsa algorithm for SSH connections. However, the ecdsa-sha2-nistp256 algorithm is generally faster. You can add the following line to your ~/.ssh/config file to use it:

Host *
  HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa

Enable connection multiplexing: SSH connection multiplexing allows reusing existing SSH connections, which can significantly reduce the overhead of establishing new connections. Add the following lines to your ~/.ssh/config file to enable connection multiplexing:


Host *
  ControlMaster auto
  ControlPath ~/.ssh/control:%h:%p:%r
  ControlPersist yes

Increase SSH connection timeout: In case you have a slow or unstable network, increasing the SSH connection timeout can prevent premature connection terminations. Add the following line to your ~/.ssh/config file to increase the timeout to 60 seconds:

Host *
  ServerAliveInterval 60

Use a faster cipher: You can try using a faster cipher algorithm to improve SSH performance. However, keep in mind that it may require the remote SSH server to support the chosen cipher. For example, to use the [email protected] cipher, add the following line to your ~/.ssh/config file:

Host *
  Ciphers [email protected]

After making any changes to the SSH client configuration, save the file and try using Git again to see if there is an improvement in download speed.

After assessing all, I combined them and put this at the end of my .ssh/config file:

Host *
  HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa
  ControlMaster auto
  ControlPath ~/.ssh/control:%h:%p:%r
  ControlPersist yes
  ServerAliveInterval 60
  Ciphers [email protected]

Remember to exercise caution and be mindful of security implications when modifying SSH configuration options. Some options may require compatibility with the remote SSH server and its configuration.

Upvotes: 3

Mehmet Fide

Reputation: 1794

On Windows 11, I solved this problem by upgrading build-in OpenSSH which is in C:\Windows\System32\OpenSSH folder.

You can download the latest binaries here: https://github.com/PowerShell/Win32-OpenSSH/releases

See #2012 in the release notes which solves the problem:

v9.2.2.0p1-Beta Latest
This is a beta-release (non-production ready)

This release includes:

Security Fixes:

Upgrade to LibreSSL 3.7.2. Please refer to https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.7.2-relnotes.txt
MSI: change inbound firewall rule that opens port 22 to apply to Private networks only
Non-Security Fixes:

Add U2F/Fido2 keys to the agent from other clients: #1961 - thanks @ddrown!
Fix output codepage after executing scp/sftp/ssh/ssh-keygen command: #2027 - thanks @kemaruya!
Fix early EOF termination when running git fetch over ssh: #2012 - thanks @cwgreene!
Revert mark-of-the-web for SCP/SFTP file downloads: #2029

Upvotes: 12

Matteo

Reputation: 1219

If you are under Windows and the credential manager path did not yield results you might have problems in your local copy of the repository.

You might need to execute some maintenance on it, be careful that the following set of commands will also remove your git stash contents and there is no turning back.

git fetch --prune   // align local state
git branch -vv | grep -i 'gone' | awk '{print $1}' | xargs git branch -D // Delete branches marked as gone by the remote server
git fsck --full // verifies the connectivity and validity of the objects in the database
git reflog expire --expire=now --all // manage reflog information
git repack -a -d -l // pack unpacked objects in the repository
git gc --prune=now --aggressive // cleanup unnecessary files and optimize the local repository

Comments are intentionally in the way of a copy-paste to give you time to read and decide if you want to continue.

This will remove all the local branches marked as deleted by the remote copy, dangling commits and other dead things.

After you have cleaned your local copy you can retry the operation that failed before.

Upvotes: 0

vishvAs vAsuki

Reputation: 3147

git config --global http.version HTTP/1.1

solved the problem for me. I was unable to push large commits in multiple different github repositories earlier.

Upvotes: 62

Weightlessness33

Reputation: 41

Adding to a previous solution, what solved the issue for me was to disable jumbo frames on my network, in addition to the mentioned config value.

I have no idea if the problem was my ISP or local (or maybe even Github), but it doesn't hurt to try for whoever reads this.

Upvotes: 1

rakeeee

Reputation: 1073

I have faced the similar issue and solved by using setting the remote url as SSH one.

git remote set-url origin <SSH URL>

My repo was cloned initially with SSH and then changed to HTTPS caused the problem for me. So, I have set again the remote origin as SSH and it starts working as usual.

Upvotes: 1

Konrads

Reputation: 2274

Nothing of the above worked, but switching from OpenSSH to plink did work:

$env:GIT_SSH="C:\ProgramData\chocolatey\bin\PLINK.EXE"

My setup is:

C:\windows\System32\OpenSSH\ssh.exe (8.1.0.1)
C:\Program Files\Git\cmd\git.exe (2.37.3.1)
Microsoft Windows [Version 10.0.19044.2604]

Upvotes: 1

Nathan Raine

Reputation: 431

For me, a quick restart of my router solved the problem. No other configuration changes were needed, but situations may vary.

Upvotes: 1

Codemaker2015

Reputation: 15649

It might be your network issue. If the network is too slow, then it might disconnect the connection unexpectedly.

If you have good internet and are still getting this message, then it might be an issue with your post buffer. Use this command to increase it (for example) to 150 MiB:

git config --global http.postBuffer 157286400

According to git-config Documentation for http.postBuffer:

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

So this is only a mitigation in cases where the server is having issues. This is most likely not going to fix push problems to GitHub or GitLab.com.

Upvotes: 245

Bravo Stack

Reputation: 161

Try pushing from your Vscode's git GUI. It worked for me.

Upvotes: 1

Edil

Reputation: 31

I got this problem today out of nowhere — the same repo was working the day before with no problems. I solved it by deleting my SSH key on the Github config panel and adding it again, as described in Github docs. I did not need to create new SSH keys.

Upvotes: 0

01SagarArora

Reputation: 9

Because of unknown reason previous attempt to install homebrew failed ... u should now uninstall it using following command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

then re-install using:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Upvotes: -1

Merl

Reputation: 403

This is a problem sending bits over https protocol. You can configure git to use ssh instead.

First create an ssh-key on your workstation, then copy that key to Github to authenticate your computer without a password. Then configure git to use ssh protocol instead of https.

Create ssh key

No need to repeat Github's excellent instructions here.

Simple way

Use git protocol for the clone command:

git clone [email protected]:repo-name

General method: Configure git to use ssh (git) protocol instead of https

This option is good if you are using GitHub Desktop and don't have direct control over the clone URL.

git config --global url."[email protected]:".insteadOf "https://github.com/"

For Github enterprise, make your local translations for your instance rather than public github.

After this, you should be able clone without this error.

Upvotes: 5

Github - unexpected disconnect while reading sideband packet

Answers (30)

Connection, VPN, Antivirus, Firewall

VPN dynamic IP rotation is the culprit

Git cache, buffers and memory

On Linux

On Windows

For PowerShell users:

Create ssh key

Simple way

General method: Configure git to use ssh (git) protocol instead of https

Related Questions

VPN `dynamic IP rotation` is the culprit