Cannot Reach Github Domain

Caseeon · 2024-09-19 20:59:18

After about a day of trouble shooting I have come here to explain and ask.

I am able to ping github.com(multiple times) and reach github.com within Firefox once, anytime after that, GitHub stops responding completely. This has inhibited me from installing anything, cloning anything, etc.

I've tried changing to custom DNS, installing and enabling dhclient, reinstalling NetworkManager. Nothing has really worked.

Any help would be appreciated.

seth · 2024-09-19 21:48:17

This is limited to github?
And what IP does ping resolve and when/how does it fail?
(Timeout, package loss, unable to resolve an IP, …)

Can you still ping that IP? Can you "ping -n" it ?
Can you reliably

ping -c3 140.82.121.4 # github server in germany

enabling dhclient, reinstalling NetworkManager

Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Caseeon · 2024-09-19 21:57:23

seth wrote:

This is limited to github?
And what IP does ping resolve and when/how does it fail?
(Timeout, package loss, unable to resolve an IP, …)
Can you still ping that IP? Can you "ping -n" it ?
Can you reliably
ping -c3 140.82.121.4 # github server in germany
enabling dhclient, reinstalling NetworkManager
Please post the output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Just GitHub. Say I boot up, I can ping github.com, CTRL+C, ping github.com, and repeat with no issue. As soon as I load up Firefox and load github.com in the browser, it will load the first time, and when I refresh it, it won't load. If I refresh and I am actively pinging it, that will stop as well. I can ping -n it and it resolves to "140.82.113.4" It just stops until it eventually times out (ping).

dbus-fi.w1.wpa_supplicant1.service       | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service   | system
display-manager.service                  | system
dnsmasq.service                          | multi-user.target.wants
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
systemd-userdbd.socket                   | sockets.target.wants
tlp.service                              | multi-user.target.wants
wireplumber.service                      | pipewire.service.wants
wpa_supplicant.service                   | multi-user.target.wants

Last edited by Caseeon (2024-09-19 21:58:27)

seth · 2024-09-19 22:19:45

NM starts wpa_supplicant itself, so disable that service - but ifit's limited to github, that's unlikely the cause.

To be clear, once you can't ping github.com any longer "ping -n 140.82.113.4" fails as well?
Does

tracepath -b 140.82.113.4

show the stall?
(This will likely starve, the question is whether it makes it beyond your LAN/ISP)

Does it help to disable dnsmasq?

Caseeon · 2024-09-19 22:32:34

seth wrote:

NM starts wpa_supplicant itself, so disable that service - but ifit's limited to github, that's unlikely the cause.
To be clear, once you can't ping github.com any longer "ping -n 140.82.113.4" fails as well?
Does
tracepath -b 140.82.113.4
show the stall?
(This will likely starve, the question is whether it makes it beyond your LAN/ISP)
Does it help to disable dnsmasq?

Disabled both services and still no reply on attempts to connect

I do get a couple of replies with tracepathiding a couple of the addresses lol

Also may be important to mention because I read online it caused problems for other users, but I had to mess around with the time and date on the computer and I feel like that was the last thing I had modified before this started.

?: [LOCALHOST]                      pmtu 1500
 1:  10.129. (10.129.)                           4.805ms
 1:  10.129. (10.129.)                           3.486ms
 2:  10.233. (10.233.)                      12.696ms
 3:  192.30. (192.30.)                        11.755ms
 4:  no reply
 5:  static-host-66-18-40-30.epbinternet.com (66.18.40.30)  36.527ms <--- Local ISP
 6:  no reply
 7:  no reply

Last edited by Caseeon (2024-09-19 22:34:38)

seth · 2024-09-19 22:54:35

The system time will be relevant for ssh & https, but not the ICMP request (though there's a timestamp)

timedatectl

The odd part is the FF involvement - do you use https://wiki.archlinux.org/title/Firefo … over_HTTPS or https://wiki.archlinux.org/title/Firefox/Privacy#Disable/enforce_'Trusted_Recursive_Resolver' ?

What happes if you add

140.82.121.4       github.com

to your /etc/hosts ?

Caseeon · 2024-09-19 23:18:00

seth wrote:

The system time will be relevant for ssh & https, but not the ICMP request (though there's a timestamp)
timedatectl
The odd part is the FF involvement - do you use https://wiki.archlinux.org/title/Firefo … over_HTTPS or https://wiki.archlinux.org/title/Firefox/Privacy#Disable/enforce_'Trusted_Recursive_Resolver' ?
What happes if you add
140.82.121.4       github.com
to your /etc/hosts ?

While I have used FireFox and Firefox only, I did not think it would be the issue. I completely overlooked that actually haha. I'll do a little bit more testing with other browsers.

privacy.trackingprotection.enabled is fasle
network.protocol-handler.expose.magnet has not been created
modifying the host file also did not work.

Caseeon · 2024-09-19 23:38:34

Alright so the issue is definitely FF. I installed Brave and ran through the same steps with no issue. Uninstalling and reinstalling FF did not fix the issue there, so I assume there is some config file that needs to be reset/deleted in order to fix the issue.

Edit: Removing the FF profile and uninstalling/reinstalling fixed it. Thank you Seth I really appreciate it.

Last edited by Caseeon (2024-09-19 23:43:30)

seth · 2024-09-20 07:38:22

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Though still kinda weird how connecting an IP w/ FF would block that IP for other PIDs, the only explanation I can come up with is that FF ends up creating a gazillion connections and github quotas you in response.
If this flares up again, check the connections w/ ss, netstat or wireshark. It's probably been som FF extension.

Arch Linux

#1 2024-09-19 20:59:18

Cannot Reach Github Domain

#2 2024-09-19 21:48:17

Re: Cannot Reach Github Domain

#3 2024-09-19 21:57:23

Re: Cannot Reach Github Domain

#4 2024-09-19 22:19:45

Re: Cannot Reach Github Domain

#5 2024-09-19 22:32:34

Re: Cannot Reach Github Domain

#6 2024-09-19 22:54:35

Re: Cannot Reach Github Domain

#7 2024-09-19 23:18:00

Re: Cannot Reach Github Domain

#8 2024-09-19 23:38:34

Re: Cannot Reach Github Domain

#9 2024-09-20 07:38:22

Re: Cannot Reach Github Domain

Board footer