Http://nmcheck.gnome.org/check_network_status.txt returns 302

Infrastructure
1

I have some software that does a status check on http://nmcheck.gnome.org/check_network_status.txt to check whether or not it’s connected to a network with a captive portal.
It just started returning a 302 last night.
This seems like it would affect every linux machine packaged with gnome and network manager, am I missing something?
Doesn’t network manager check it’s internet status using that URL, specifically http so it re-directs when connected to a captive portal?
Below is the response headers + status code

code 302, headers: HeadersList {
      [Symbol(headers map)]: Map(3) {
          'content-length' => { name: 'content-length', value: '0' },
              'location' => {
              name: 'location',
              value: 'https://nmcheck.gnome.org/check_network_status.txt'
          },
          'cache-control' => { name: 'cache-control', value: 'no-cache' }
      },
    [Symbol(headers map sorted)]: null
}
2

I’m not sure, but I don’t see much of the URL being used from a quick search in debian code search.

https://codesearch.debian.net/search?q=check_network_status.txt

3

Change http to https in your config?

Have you confirmed network manager can’t handle the HTTP redirect? If so I suggest to move your topic to the Infrastructure category.

I suppose with the recent migration to AWS maybe — intentionally or not — the subdomain is now also defaulting to https. I suppose that’s a good thing but if using it with software that can’t handle a HTTP redirect it needs a config change on the client side to use https instead of http.

4

It’s more of an environmental factor, some captive portals redirect with invalid certificates, meaning HTTPS is not an option. Thats why you’ll see chrome (Network Portal Detection) and apple use http instead of https.

5

sorry meant to reply to you

6

No problem. I tried it with network manager and after a nmcli general reload get this in the journal:

NetworkManager[1179]: [1730818808.3373] connectivity: use of HTTPS for connectivity checking is not reliable and is discouraged (URI: https://nmcheck.gnome.org/check_network_status.txt)

So you’re right, the check shouldn’t be using https.

8

Awesome, thanks for confirming!

I moved the topic to infrastructure per your suggestion.
I got a call from my boss this morning that our 1k+ machines were offline, I about pooped my pants. :rofl: I’m working on removing our dependency of that site, but at least wanted to flag it since it seemed like it would affect other systems.

1 Like
9

Should be fixed by now, thanks for reporting this!

3 Likes
10 
$ while [ 1 ]; do curl -s -L -I http://nmcheck.gnome.org/check_network_status.txt | head -1; done
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
^C
1 Like
11

Thank you! Life saver!

12

Unfortunately, I need to reopen this issue, as the check is returning “limited” since a few days again. If I check with curl, I get the following response:

curl -s https://nmcheck.gnome.org/check_network_status.txt -v
*   Trying 54.82.185.92:443...
* Connected to nmcheck.gnome.org (54.82.185.92) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.apps.openshift.gnome.org
*  start date: Dec  7 13:11:37 2024 GMT
*  expire date: Mar  7 13:11:36 2025 GMT
*  subjectAltName does not match nmcheck.gnome.org
* SSL: no alternative certificate subject name matches target host name 'nmcheck.gnome.org'
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):

So it seems an issue with the certificate that was created on the 7th of December.
Can you please check?

1 Like
13

network-manager 1.15.2 assigning route metric values with 20000 added to them (#116) · Issues · NetworkManager / NetworkManager · GitLab

14

This should be fixed, also moved the service to an edge location which comes with IPv6 support, please let me know how it goes!

3 Likes
15

I confirm that it works again. Thank you for the quick reaction!

16

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.