git impossible to push after add git impossible to push after add git git

git impossible to push after add


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).


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.


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)