I wonder if this is related to them recently removing the shiny graphs from https://status.github.com/

GitHub engineers: you might want to consider using:

   traceroute -P tcp -p 443

which will use SYN packets to port 443 instead of the default of using udp on a random high numbered port.

and/or:

   traceroute -I

which uses ICMP echo requests.

Both syntaxes should be supported on Linux and macOS.

Notice that the traceroute is from github to the user. I don't think we can assume users have port 443 open.

I'd love to see is a general purpose tool for diagnosing network issues.

Is my router messed up? Is it my neighborhood's node? Is it the destination server? Is it my computer's network card? Wifi? Cell tower?

I've started writing this two or three times. It's so much bigger than I think it will be every time. This would need to either be a big time investment, or a community effort to supply all the tests one can run. And doing a speed test to determine what the bottleneck is in network speed requires a lot of third party bandwidth -- heck, even a million people pinging your server every day would be something to consider if your server is a potato (mine is).

That said, I'd love to see (and/or contribute to) such a tool too!

I wonder if Open Observatory of Network Interference (OONI) could help.

https://ooni.torproject.org/

> Finally, copy & paste the results from your local commands and the above tests into a message for our Support Team.

Okay good, the problem is that the links points to the main website, so if we are having problems connecting to GitHub, this would be a redundant operation, shouldn't they offer the email address that we can use to send them the output of these commands? That way, if the connectivity issues persist, we can at least use a non-github.com email address to contact them.

Two questions.

First of all, I clicked the Test button, and the top end of the traceroute that subsequently appeared contains

  traceroute to 58.167.97.145 (58.167.97.145), 30 hops max, 60 byte packets
   1  c74c4c379cae16e810997134f5cc15c4 (5e2c247dafd7d7f56764b0aa191fc0f6)  0.194 ms
   2  f6e356ef9aa666a92d5f60ea2bc5ea8e (169.254.236.30)  0.149 ms
   3  0e59d32498246ca2e09f3633a00ac557 (d7a8206e439b4b3e3a1fc7748a81efc1)  0.383 ms
   4  6fa566707dc34116d35780236ae52cf0 (6fa566707dc34116d35780236ae52cf0)  0.869 ms
   5  5714851faaed656a09032ba1e48f02b0 (192.30.252.249)  1.319 ms
   6  8-1-5.bear1.Washington111.Level3.net (4.15.136.21)  1.539 ms

What are lines that don't contain IP addresses? That's really interesting. (Am I right to think this is a GH traceroute to me?)

I'm also very curious what 7399:6CC8:00C3:75B09:59C19A46 is; I don't have IPv6...

---

Secondly, I'm also idly curious why this always happens to me.

  $ git clone git@github.com:github/debug-repo /tmp/debug-repo-ssh
  Cloning into '/tmp/debug-repo-ssh'...
  Permission denied (publickey).
  fatal: Could not read from remote repository.

  Please make sure you have the correct access rights
  and the repository exists.

I don't have a local Git configuration (that I can find anywhere).

I also don't have any sort of special SSH configuration.

I generally use HTTPS for GitHub, but I was wondering if there was any particular reason I might want to use SSH for general use.

(The one time I did want to actually `git push` something it took me a couple of double takes to figure out how to get it working. That was on a different machine than I'm on right now, though.)

My guess is that it's a md5 of the IP (with a salt) to hide what the actual IPs on their internal network is. But since they know the salt and the ip ranges they can find out what the IP is.

After posting that I figured that's what was going on, yeah. That seems kind of scary though - I can easily brut--stops mid-sentence

brb, finding out how fast my old i3 really is

Edit: I drowned in the differences between md5 implementations. And all the "superfast" code I've found produces different results than stock /usr/bin/md5sum. So now I want to find an actually-fast and working md5sum implementation, and figure out why I'm getting different results. Yak shaving && stackdepth++

HN will likely lock this thread before I get to completing the above which is kinda sad, but email still works, I guess.

Reminds me of MTR https://en.wikipedia.org/wiki/MTR_(software)

A super useful tool for debugging why a client has trouble accessing a website.

Useful, for them at least, as it's kind of a detailed "down for everyone or just me" tool.

Kind of strange to see it end up here though.