git impossible to push after add

Question

Ok, I've a trouble that I'm not able to fix since some week. I use git (on github) to store my projects. Recently I've added some new files in it without problems, but, when I use "git push" I've a timeout error.

I use Ubuntu 12.04, with ssh (default) and https.

So, I decide to make fresh copy of the depo (git clone). After this I modify an existing file, commit it and push it ... with success !

So, I add the others (in the new copy), commit them and push them. And the problem come again: unable to push Here is the console output:

time git push
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 16.61 KiB, done.
Total 11 (delta 2), reused 0 (delta 0)
^C

real    7m59.383s
user    0m0.008s
sys 0m0.004s

I really don't understand what i doing wrong here. I in other depo, same problem, but my collaborator don't have any troubles.

I remove git, and reinstall it with no change.

If you have any idea to solve this.

edit 1

git remote -v

origin  [email protected]:Krozark/projet_compilation.git (fetch)
origin  [email protected]:Krozark/projet_compilation.git (push)

edit: Solution

sudo ifconfig [wlan0] mtu 1460 (lower than 1500)

Answer 1

I saw this exact same problem that a colleague was having and it was network related with SSH, we were using a VPN connection at the time and it ended up being the network MTU setting being too high (it was 1492 if I remember correctly), we tinkered around with smaller values until it started working. So something to do with network packet splitting it seemed.

Not sure if this is the case for you however although it doesn't hurt to try change your network MTU to a lower value to see if it works.

Of course if it's an issue on Github's side, this won't be a factor (the fact you can create a new repo and push up leads me to believe it's not MTU related).

Answer 2

As you've suggested that pinning your MTU has been effective at alleviating the problem, I'd recommend a more targeted solution.

iptables -t mangle -I OUTPUT 1 -o wlan0 -d 207.97.227.239 \
    -p tcp --dport 22 --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1420

This hijacks the initial TCP negotiation with the server (only for SSH on github.com's IP), and forces the MSS to 1420. This is effectively the same as setting the MTU, but is more selective. It's good in some situations where you can't easily save the MTU change, and would need to re-apply it each time the interface was taken down/up.

The MSS needs to be 40 less than the MTU to allow for the 40 byte TCP header + the data segment (MSS is Max Segment Size).

The most common reason for needing to do something like this (ie, getting MTU below 1500), is VPNs and tunnels. PMTU is meant to solve this, but it fails in far too many situations, leaving you to manually need to adjust the MTU for certain paths. Using the iptables rule allows you to tailor your traffic differently for different problem paths, rather then forcing you to set you MTU to the lowest common denominator for all paths. The problem with doing that is that you slowly diminish your effective bandwidth by increasing your header to data ratios.

Answer 3

If the local is fine (ie your git and ssh are working fine), then it should be an issue on the remote side:

Check GitHub Status.

Today

3:22 UTC We are investigating issues with one of our fileservers, a small number of repositories are unavailable.

It could be possible you are affected by the current recurrent access issues mentioned on GitHub.

---

Or it is a connection issue (like a missing VPN route)