The computer I am using (Windows 7 Enterprise) has two network connections, one which provides access to the internet and university network - this adapter in the the one which should be used for most things. The second adapter is a local network connected to some lab equipment via a router and has no internet access.
I am having an issue with getting git to work in this situation. With the second (local) adapter disabled, everything works as expected. However when the adapter is enabled, powershell fails to reach github - pull requests for example fail stating error 443. Yet the internet still works for everything else outside powershell - e.g. IE/Firefox/cmd/etc. So it seems that powershell is trying to use the second adapter even though it has no internet access.
Interestingly if I run
ping github.com from powershell, the first reply is lost, but then all other replies are received. If I then try to run
git pull again, it connects, but only once. If I try to pull again, it fails. This is repeatable, if I ping github before I run a git command, then it works for that command - but if the command takes too long (like syncing a large repository), it fails half way through.
I am really not sure what is causing this. I've tried several things including manually setting the interface metrics in Windows so that the first adapter is a very low number, and the second a very high number (so it is unfavourable). But this doesn't seem to do anything to help git - it solved the problem I was having with windows accessing the internet, but didn't help with git. I've also tried setting the second adapter to have a static IP with no default gateway (as suggested in this superuser question).
Is there something I am missing?
In response to @LazyBadger, I have run
tracert github.com and get the following result:
Tracing route to github.com [188.8.131.52] over a maximum of 30 hops: 1 ******** [192.168.*.*] reports: Destination host unreachable.
If I run
route print 0*, I get the following:
=========================================================================== Interface List 14...** ** ** ** cd 5e ......Intel(R) I210 Gigabit Network Connection #2 <- This one is the primary adapter 13...** ** ** ** cd 5f ......Intel(R) I210 Gigabit Network Connection 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 129.*.*.* 129.*.*.* 2 =========================================================================== Persistent Routes: None IPv6 Route Table =========================================================================== Active Routes: None Persistent Routes: None
(*) Note: I blanked out the IP addresses and MACs, but the
192.168.*.* is the second adapter which has no internet access, and the
129.*.*.* is the first adapter which does have internet access.
If I then run
ping github.com, I get the following
Pinging github.com [184.108.40.206] with 32 bytes of data: Reply from 192.168.*.*: Destination host unreachable. Reply from 220.127.116.11: bytes=32 time=84ms TTL=52
And then running
tracert github.com I get
Tracing route to github.com [18.104.22.168] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms ********* [129.*.*.*] .............. 7 82 ms 82 ms 83 ms ae-4-90.edge3.Washington4.Level3.net [22.214.171.124] 8 83 ms 83 ms 83 ms GITHUB-INC.edge3.Washington4.Level3.net [126.96.36.199] 9 84 ms 84 ms 84 ms 188.8.131.52 10 84 ms 84 ms 84 ms github.com [184.108.40.206]
After this it doesn't work again - basically the first command after I do a ping will work, but any further commands go back to using the wrong adapter until I do another ping.
tracert works fine for other sites like Google and such. The difference seems to be that any which start with the IP
192. seem to go through the wrong adapter.