Unitymedia Zugriff auf Github (git clone) über Unitymedia

[strongly-typed]

Moin,

ich habe eine TC7200 Router, der mir WLAN und Ethernet bereitstellt. Der Anschluss ist IPv6 mit DSLite.

Von dem Anschluss aus funktioniert kein git clone. Problemlos klappt es über das Handynetz per eigenem Hotspot.

git clone --verbose git://github.com/sbyx/odhcpd.git
Cloning into 'odhcpd'...
Looking up github.com ... done.
Connecting to github.com (port 9418) ... fatal: unable to connect to github.com:
github.com[0: 192.30.252.129]: errno=Operation timed out

Ich verwende eine MBP mit OSX 10.11.4.

Mit wireshark sehe ich nur die SYN Pakete an die IPv4 Adresse, aber ich bekomme kein SYN, ACK.

Jemand die gleiche Erfahrung gemacht?

Beste Grüße

Dave

 

[johnripper]

Traceroute?

 

[GoaSkin]

Ich sage nur so viel: Github funktioniert ohne Probleme; verwende es ständig. Also: User-Error.

 

[strongly-typed]

git clone per http://github.com funktioniert.
Per git://github.com jedoch nicht über UM, per Handy schon.

Tja, traceroute funktioniert gar nicht, auch nicht zu Google. Sonst klappt aber gefühlt alles (Web, Mail, ...)

traceroute 192.30.252.129
traceroute to 192.30.252.129 (192.30.252.129), 64 hops max, 52 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * *
10 * * *
11 * * *

 

[strongly-typed]

Man kann git umbiegen das https://-Protokoll statt git:// zu verwenden [1]

git config --global url."https://".insteadOf git://

Irgendwer in der Unitymedia-Infrastruktur scheint den Port 9418 zu blocken. Meiner Rechner scheint das nicht zu sein, denn per Handy-Hotspot funktioniert es problemlos.

[1] http://stackoverflow.com/a/18889129

 

[Leseratte10]

Also ich kann von meinem UM-Business-Anschluss problemlos über das git-Protokoll clonen - eventuell sperren die ja im AFTR-Gateway? Aber mir würde da kein Grund für einfallen ...

 

[johnripper]

Also ich kann von meinem UM-Business-Anschluss problemlos über das git-Protokoll clonen

Ja, kann ich so unterschreiben.

 

[tq1199]

Irgendwer in der Unitymedia-Infrastruktur scheint den Port 9418 zu blocken.

Nein, das stimmt nicht:

<i>
</i>:~$ sudo nping -c 3 --tcp --flags syn,ecn,cwr --delay 1s -g 5678 -p 9418 github.com
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2016-04-02 22:58 CEST
SENT (0.0283s) TCP 192.168.178.21:5678 > 192.30.252.122:9418 SEC ttl=64 id=9514 iplen=40 seq=3905013604 win=1480
RCVD (0.1674s) TCP 192.30.252.122:9418 > 192.168.178.21:5678 SAE ttl=50 id=0 iplen=44 seq=578346455 win=14360 <mss 1436>
SENT (1.0289s) TCP 192.168.178.21:5678 > 192.30.252.122:9418 SEC ttl=64 id=9514 iplen=40 seq=3905013604 win=1480
RCVD (1.1405s) TCP 192.30.252.122:9418 > 192.168.178.21:5678 SAE ttl=50 id=0 iplen=44 seq=593512622 win=14360 <mss 1436>
SENT (2.0305s) TCP 192.168.178.21:5678 > 192.30.252.122:9418 SEC ttl=64 id=9514 iplen=40 seq=3905013604 win=1480
RCVD (2.1434s) TCP 192.30.252.122:9418 > 192.168.178.21:5678 SAE ttl=50 id=0 iplen=44 seq=609213831 win=14360 <mss 1436>
Max rtt: 138.868ms | Min rtt: 111.482ms | Avg rtt: 121.032ms
Raw packets sent: 3 (120B) | Rcvd: 3 (132B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.28 seconds

<i>
</i>:~$ mtr -4nr -c 2 -i 2 192.30.252.129
HOST: xyxyxy Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.178.1 0.0% 2 2.0 6.8 2.0 11.7 6.9 2.|-- 109.###.###.1 0.0% 2 14.0 12.7 11.4 14.0 1.8 3.|-- 172.30.10.77 0.0% 2 10.3 11.3 10.3 12.3 1.4 4.|-- 84.116.190.129 0.0% 2 12.3 16.5 12.3 20.7 6.0 5.|-- 84.116.190.9 0.0% 2 16.1 13.4 10.6 16.1 3.9 6.|-- 84.116.190.2 0.0% 2 13.5 13.7 13.5 13.9 0.3 7.|-- 80.81.192.182 0.0% 2 41.9 47.8 41.9 53.7 8.3 8.|-- 207.88.15.77 0.0% 2 31.7 29.7 27.8 31.7 2.7 9.|-- 207.88.13.202 0.0% 2 116.5 120.1 116.5 123.7 5.1 10.|-- 207.88.12.104 0.0% 2 121.5 126.5 121.5 131.5 7.1 11.|-- 207.88.12.134 0.0% 2 133.9 131.8 129.7 133.9 3.0 12.|-- 207.88.14.181 0.0% 2 120.6 122.0 120.6 123.3 1.9 13.|-- 209.48.43.110 0.0% 2 113.1 113.2 113.1 113.2 0.1 14.|-- 192.30.252.213 0.0% 2 110.5 111.8 110.5 113.1 1.9 15.|-- 192.30.252.129 0.0% 2 113.4 114.0 113.4 114.7 0.9

 

[strongly-typed]

sudo nping -c 3 --tcp --flags syn,ecn,cwr --delay 1s -g 5678 -p 9418 github.com
Starting Nping 0.7.12 ( https://nmap.org/nping ) at 2016-04-03 01:59 CEST
SENT (0.0108s) TCP 192.168.0.16:5678 > 192.30.252.121:9418 SEC ttl=64 id=56911 iplen=40 seq=1510592353 win=1480
SENT (1.0125s) TCP 192.168.0.16:5678 > 192.30.252.121:9418 SEC ttl=64 id=56911 iplen=40 seq=1510592353 win=1480
SENT (2.0179s) TCP 192.168.0.16:5678 > 192.30.252.121:9418 SEC ttl=64 id=56911 iplen=40 seq=1510592353 win=1480
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (120B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.02 seconds

Das "Irgendwer" ist die "Firewall" im TC7200 (das zähle ich noch zur UM-Infrastruktur, weil die mir das vor die Nase setzen und remote administrieren) in den Stufen "Mittel" und "Hoch". Nur bei "Aus" und "Niedrig" funktioniert es auch bei mir.

nping -c 3 --tcp --flags syn,ecn,cwr --delay 1s -g 5678 -p 9418 github.com
Starting Nping 0.7.12 ( https://nmap.org/nping ) at 2016-04-03 01:58 CEST
SENT (0.7978s) TCP 192.168.0.16:5678 > 192.30.252.121:9418 SEC ttl=64 id=54978 iplen=40 seq=4108675492 win=1480
RCVD (0.9187s) TCP 192.30.252.121:9418 > 192.168.0.16:5678 SAE ttl=53 id=0 iplen=44 seq=1202579463 win=14360 <mss 1420>
SENT (1.7980s) TCP 192.168.0.16:5678 > 192.30.252.121:9418 SEC ttl=64 id=54978 iplen=40 seq=4108675492 win=1480
RCVD (1.9242s) TCP 192.30.252.121:9418 > 192.168.0.16:5678 SAE ttl=53 id=0 iplen=44 seq=2865896571 win=14360 <mss 1420>
SENT (2.8003s) TCP 192.168.0.16:5678 > 192.30.252.121:9418 SEC ttl=64 id=54978 iplen=40 seq=4108675492 win=1480
RCVD (2.9245s) TCP 192.30.252.121:9418 > 192.168.0.16:5678 SAE ttl=52 id=0 iplen=44 seq=380898611 win=14360 <mss 1420>
Max rtt: 126.285ms | Min rtt: 120.918ms | Avg rtt: 123.732ms
Raw packets sent: 3 (120B) | Rcvd: 3 (132B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.93 seconds

Ich biege das einfach auf das https-Protokoll um, da geht es. Gut zu wissen für spätere Probleme und danke für die Unterstützung.