0

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 [192.30.252.131]
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 [192.30.252.128] with 32 bytes of data:
Reply from 192.168.*.*: Destination host unreachable.
Reply from 192.30.252.128: bytes=32 time=84ms TTL=52

And then running tracert github.com I get

Tracing route to github.com [192.30.252.128]
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 [4.69.149.210]
      8    83 ms    83 ms    83 ms  GITHUB-INC.edge3.Washington4.Level3.net [4.53.116.102]
      9    84 ms    84 ms    84 ms  192.30.252.201
     10    84 ms    84 ms    84 ms  github.com [192.30.252.128]

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.


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

  • local Git with remote Github repo? – Lazy Badger Jan 5 '16 at 23:16
  • Do not ping, test path with tracert always. And show at least route print 0* – Lazy Badger Jan 5 '16 at 23:19
  • @LazyBadger yes, I am trying to pull from (or push to) a remote repository hosted on Github to a clone of the repository I have locally. I have run tracert and it shows that it tries to go through the second adapter (the one with no internet access) and so fails. Perhaps it is not a git issue at all but a powershell one? – Tom Carpenter Jan 5 '16 at 23:52
  • 1
    That doesn't help too much. :D Please run route print again without additional arguments and provide its output. Git has no special relation to Powershell. ping and tracert are also not Powershell commands. – Daniel B Jan 6 '16 at 0:34
  • @DanielB - full route table is a waste of time (route print 192* will show bad path, IMNSHO). Obviously, Tom have to add persistent route to Github over correct interface, or fix "too wide" netmask on 192.168 local interface – Lazy Badger Jan 6 '16 at 4:22
3

Well, it turns out it was a misconfiguration of the router. For some reason, despite the fact that it's subnet mask is configured to be 255.255.255.0, Windows was setting the second interface to have a subnet mask of 255.0.0.0. After changing some other settings in the router, the correct subnet mask was assigned.

Essentially because the subnet mask was too wide, and Github by chance happens to use 192.x.x.x as its external IP address, all requests to Github were being routed via the second interface. Once the subnet mask was corrected, the issue went away.

This also explains why sites like Google could be reached correctly from PS but Github couldn't.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.