[APP] - matray - Manjaro announcements tray app (the new one)

Contributions Software
107 
Use IPv6 addresses only when resolving hostnames, and not for example try IPv4

So you now your isp is to blame. You probably only get an ipv6 address on your home router, and somewhere all the traffic is gathered from many users and pushed through a common gateway to connect with the ipv4 internet. It works…but can lead to problems if not configured correctly. Like getting automatic captchas not working, or being banned from sites you never visited, or suddenly being logged out. In my case (part of the Vodafone network in Germany), it was exactly like in your case - a couple of sites did not want to open. Everything else was ok, the sites were fine with vpn or other isp. And they did not fixed it for months.

So try the curl with -4 and -6 from your mobile (like making a hotspot from the cell phone) and if it works you know who to blame.

p.s. i tested - works on both protocols, so it is issue on your side - isp, router, pc config…

108

No, that’s not true. I do have an IPv4 address, and IPv4-only sites work just fine, including HTTPS sites. Here’s an example IPv4-only HTTPS site that works just fine here: https://ipv4.jamieweb.net/

Literally all other web services I use work. manjaro.news is the only one that doesn’t.

OK, what’s the difference here?

[alex@alex-pc ~]$ curl -4 --verbose https://manjaro.news/news -d '{"MaxItems":1,"Categories":["All"]}'
* Host manjaro.news:443 was resolved.
* IPv6: (none)
* IPv4: 62.182.81.28
*   Trying 62.182.81.28:443...
* Connected to manjaro.news (62.182.81.28) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* 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_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=manjaro.news
*  start date: Jul 13 11:09:40 2024 GMT
*  expire date: Jan  8 22:59:00 2025 GMT
*  subjectAltName: host "manjaro.news" matched cert's "manjaro.news"
*  issuer: C=NO; O=Buypass AS-983163327; CN=Buypass Class 2 CA 5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://manjaro.news/news
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: manjaro.news]
* [HTTP/2] [1] [:path: /news]
* [HTTP/2] [1] [user-agent: curl/8.8.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [content-length: 35]
* [HTTP/2] [1] [content-type: application/x-www-form-urlencoded]
> POST /news HTTP/2
> Host: manjaro.news
> User-Agent: curl/8.8.0
> Accept: */*
> Content-Length: 35
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 35 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
* Connection #0 to host manjaro.news left intact
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
[ble: exit 92]

[alex@alex-pc ~]$ curl -6 --verbose https://manjaro.news/news -d '{"MaxItems":1,"Categories":["All"]}'
* Host manjaro.news:443 was resolved.
* IPv6: 2a09:2dc0:0:100::1
* IPv4: (none)
*   Trying [2a09:2dc0:0:100::1]:443...
* Connected to manjaro.news (2a09:2dc0:0:100::1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* 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_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=manjaro.news
*  start date: Jul 13 11:09:40 2024 GMT
*  expire date: Jan  8 22:59:00 2025 GMT
*  subjectAltName: host "manjaro.news" matched cert's "manjaro.news"
*  issuer: C=NO; O=Buypass AS-983163327; CN=Buypass Class 2 CA 5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://manjaro.news/news
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: manjaro.news]
* [HTTP/2] [1] [:path: /news]
* [HTTP/2] [1] [user-agent: curl/8.8.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [content-length: 35]
* [HTTP/2] [1] [content-type: application/x-www-form-urlencoded]
> POST /news HTTP/2
> Host: manjaro.news
> User-Agent: curl/8.8.0
> Accept: */*
> Content-Length: 35
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 35 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< server: nginx
< date: Sun, 14 Jul 2024 20:46:11 GMT
< content-type: text/plain; charset=utf-8
< content-length: 289
< x-robots-tag: none
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< 
[
    {
        "GUID": "forum.manjaro.org-topic-165427",
        "URL": "https://forum.manjaro.org/t/testing-update-2024-07-14-tbd/165427",
        "Title": "[Testing Update] 2024-07-14 - TBD",
        "Category": "Testing Updates",
        "PublishedDate": "2024-07-13T18:12:17Z"
    }
* Connection #0 to host manjaro.news left intact
][ble: EOF]

The only difference I see here is that the response from the server is different. The server says there’s a protocol error in the IPv4 one, but responds just fine in the IPv6 one. In the IPv4 one, the IPv4 address resolves just fine and the SSL handshake seems to work just fine, but the server fails to respond correctly.

109 
 omano  ~ $  curl -4 --verbose https://manjaro.news/news -d '{"MaxItems":1,"Categories":["All"]}'
* Host manjaro.news:443 was resolved.
* IPv6: (none)
* IPv4: 62.182.81.28
*   Trying 62.182.81.28:443...
* Connected to manjaro.news (62.182.81.28) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* 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_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=manjaro.news
*  start date: Jul 13 11:09:40 2024 GMT
*  expire date: Jan  8 22:59:00 2025 GMT
*  subjectAltName: host "manjaro.news" matched cert's "manjaro.news"
*  issuer: C=NO; O=Buypass AS-983163327; CN=Buypass Class 2 CA 5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://manjaro.news/news
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: manjaro.news]
* [HTTP/2] [1] [:path: /news]
* [HTTP/2] [1] [user-agent: curl/8.8.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [content-length: 35]
* [HTTP/2] [1] [content-type: application/x-www-form-urlencoded]
> POST /news HTTP/2
> Host: manjaro.news
> User-Agent: curl/8.8.0
> Accept: */*
> Content-Length: 35
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 35 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< server: nginx
< date: Sun, 14 Jul 2024 21:50:51 GMT
< content-type: text/plain; charset=utf-8
< content-length: 289
< x-robots-tag: none
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< 
[
    {
        "GUID": "forum.manjaro.org-topic-165427",
        "URL": "https://forum.manjaro.org/t/testing-update-2024-07-14-tbd/165427",
        "Title": "[Testing Update] 2024-07-14 - TBD",
        "Category": "Testing Updates",
        "PublishedDate": "2024-07-13T18:12:17Z"
    }
* Connection #0 to host manjaro.news left intact
]

It works. You can deny it works, but apparently it works for everyone else. Maybe try what people say instead of saying “no”.

1 Like
110

The other server from @linux-aarhus worked just fine for 11 days until it went down, so it’s possible for the service to work.

Of course I’ll say it doesn’t work when literally everything else I use does work, and it even works with a workaround. Just because yours works without the workaround doesn’t mean the server is configured correctly. I have nothing unusual in my setup.

111

By the same logic, just because it doesn’t work for you doesn’t mean it is broken. I guess you’ll continue to be in denial and won’t try anything else. Have fun.

112

It did not go down - I took the service offline as the manjaro.news service work as expected - therefore no need for the temporary service.

113

Taking it offline makes it go down, and I’m not blaming you or saying anything negative about that. Thank you for when it was up, and I don’t assert any requirement or obligation from you to keep it online. I’m glad for your voluntary action. I was only saying what I said to clarify that there was a service which can work with my setup.

114

Oh my apology for not understanding :slight_smile:

I my vocabulary - the phrase went down means failing as opposed to taking offline which is intentional.

115

Plesse stop arguing, this really helps noone.
@Buju Could you please send me a PM on matrix, I could try exposing matray over a second port which you could use. I would be able to verbosely log those requests only, maybe that would give us more info on what happens.

116

If one googles that error, a couple of interesting suggestions come up in a stack thread. Realistically what can be tried is switching to http1.1. First client side with a curl option, than if this solves it serverside.

117

Cheers everyone,
@Buju and I were able to debug and fix the issue.

In the future, when you experience any problems, please just give me a small notice in the thread or via PM here or on Matrix (@weidenwiesel:matrix.org). I promise I’ll respond faster from now on.

Please refrain from discussing / debugging problems with matray in the thread directly, I would prefer it if we could keep it as clean as possible in here and for “official” announcements from me like planned downtime and so on.

Thanks and see ya around :slight_smile:

2 Likes
118

So what was the issue in the end?

119

In a nutshell:
What @Teo wrote about IPv6 to IPv4 via NAT Gateway was spot-on

Consequently, the packets that arrived at the server were somewhat garbled around. Possibly split up irregularly due to IPv6 to IPv4 translation. I’m no protocol expert so dunno for sure really.
What I know is that my server didn’t like that and dropped them silently. Which, to be clear, should not have happened. So the real fault was that I configured the nginx to be too strict.

4 Likes