Il computer che sto utilizzando (Windows 7 Enterprise) ha due connessioni di rete, una che fornisce l'accesso a Internet e alla rete universitaria: questa scheda è quella che dovrebbe essere utilizzata per la maggior parte delle cose. Il secondo adattatore è una rete locale collegata ad alcune apparecchiature di laboratorio tramite un router e non ha accesso a Internet.
Ho un problema con far funzionare git in questa situazione. Con il secondo adattatore (locale) disabilitato, tutto funziona come previsto. Tuttavia, quando l'adattatore è abilitato, PowerShell non riesce a raggiungere Github - le richieste pull, ad esempio, falliscono affermando l'errore 443. Eppure Internet funziona ancora per tutto il resto al di fuori di PowerShell - ad esempio IE / Firefox / cmd / ecc. Quindi sembra che PowerShell stia tentando di utilizzare il secondo adattatore anche se non ha accesso a Internet.
È interessante notare che se corro ping github.comda PowerShell, la prima risposta viene persa, ma poi vengono ricevute tutte le altre risposte. Se poi provo a eseguire di git pullnuovo, si connette, ma solo una volta. Se provo a tirare di nuovo, fallisce. Questo è ripetibile, se eseguo il ping di github prima di eseguire un comando git, allora funziona per quel comando - ma se il comando impiega troppo tempo (come la sincronizzazione di un grande repository), fallisce a metà.
Non sono davvero sicuro di cosa stia causando questo. Ho provato diverse cose tra cui l'impostazione manuale delle metriche dell'interfaccia in Windows in modo che il primo adattatore sia un numero molto basso e il secondo un numero molto alto (quindi è sfavorevole). Ma questo non sembra fare nulla per aiutare Git - ha risolto il problema che avevo con Windows che accedeva a Internet, ma non ha aiutato con Git. Ho anche provato a impostare il secondo adattatore per avere un IP statico senza gateway predefinito (come suggerito in questa domanda del superutente ).
C'è qualcosa che mi manca?
In risposta a @LazyBadger, ho corso tracert github.come ho ottenuto il seguente risultato:
Tracing route to github.com [192.30.252.131]
over a maximum of 30 hops:
1 ******** [192.168.*.*] reports: Destination host unreachable.
Se corro route print 0*, ottengo quanto segue:
===========================================================================
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
(*) Nota: ho cancellato gli indirizzi IP e i MAC, ma 192.168.*.*è il secondo adattatore che non ha accesso a Internet e 129.*.*.*il primo adattatore che ha accesso a Internet.
Se poi corro ping github.com, ottengo quanto segue
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
E poi correndo tracert github.comho capito
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]
Dopodiché non funzionerà più - fondamentalmente il primo comando dopo che eseguirò un ping funzionerà, ma qualsiasi ulteriore comando tornerà a utilizzare l'adattatore sbagliato fino a quando eseguirò un altro ping.
Interessante. tracertfunziona bene per altri siti come Google e simili. La differenza sembra essere che quelli che iniziano con l'IP 192.sembrano passare attraverso l'adattatore sbagliato.
tracertsempre. E mostra almenoroute print 0*
tracerte mostra che tenta di passare attraverso il secondo adattatore (quello senza accesso a Internet) e quindi non riesce. Forse non è affatto un problema git ma un PowerShell?
route printnuovo senza argomenti aggiuntivi e fornire il relativo output. Git non ha alcuna relazione speciale con Powershell. pinge non tracertsono anche comandi Powershell.
route print 192*mostrerà percorso errato, IMNSHO). Ovviamente, Tom deve aggiungere un percorso persistente a Github tramite l' interfaccia corretta o correggere una maschera di rete "troppo ampia" sull'interfaccia locale 192.168