Browsers will not connect to non-https sites on RPi4B

ARM Technical Assistance
1

Manjaro ARM - browsers not connecting to https

I am running Manjaro ARM KDE Plasma on RPi 4B 8Gb with much success EXCEPT in connecting to most of the outside world. For instance, GitHub, SourceForge, Manjaro Forum, Mozilla ……

I used to be able to connect, but cannot identify which Manjaro update caused this to fail. Since it happens with all browsers, I suspect it is not a browser issue.

The system is kept up to date daily.

Symptoms are that non-https sites cannot connect. For instance in Firefox95 the Advanced option button to connect to non-https site is flashed up, but immediately replaced with the Revert default -e don’t connect. The option to select the non-secure connection is not displayed for long enough to be accessed. But it is there …

And running git clone [etc] or similar, eg in yay, will not download.

To date I have tried the following in Firefox (on which I am running UBlock Origin, historically without issues):

1 Cleared all cache and history
2 Disabled (temporarily) firewalld
3 Tried to add sites to the Security Exceptions - they add but adding them makes no difference
4 Tried to select never connecting via HTTPS
5 Tried deselecting http2 in Firefox about:config
6 Tried connecting with no proxy and system proxy
7 Tried different DNS over HTTP options (don’t really understand these)
8 Downgraded NSS to v3.72.1 (which is the correct version for FIrefox95 per https://wiki.mozilla.org/NSS:Release_Versions; the pkg on the mirrors is 3.73 which seems premature …)
9 De- and re-installed Firefox
10 Tried Chromium and Midori

and am out of ideas.

I don’t have this problem on any other architecture - am running Manjaro KDE plasma on AMD64 and OSX v10.11 with Firefox and complete success.

On the RPi I am running realVNC server as I want to use this headless in due course. As this is the biggest difference between the Pi and my other installations, I’ve tried de-installing it, but that does not resolve the problem.

I have not seen any other recent posts relating to a similar issue on the ARM testing branch. I would have thought that it would be headline news if it was a general problem.

Happy to post any inxi or other output.

Yours in Quarantine …
Tks

2

I know that it is a PITA, but have you tried FF with a clean profile and no extensions?

3

Understand no extensions - have cleared cache and cookies though not bookmarks - pls explain?

Tks

4

for instance:
either
move the ~/.mozilla folder to a different place
mv ~/.mozilla ~/.mozilla.original_profile
or
copy it to a backup
cp -a ~/.mozilla ~/.mozilla.backup
and then delete the original
rm -r ~/.mozilla

… so you can restore what was there or import your important data from the old profile into the new …

try starting FF - it will create a new, clean profile

A fresh profile can also be created from within FF - but the above procedure is just easier IMO.

1 Like
5

Sorry, no joy ;(

In addition to removing the cache, I removed all files including ‘firefox’ - and there were a lot particularly in home/.cache/ - and removed firefox and ublock-origin (from both users I have on this machine) and then reinstalled only firefox. I rebooted after each stage of this process.

Initially the mozilla welcome page popped up, but then the page closed and I’m back to exactly the same problem. Same symptoms - flash opportunity to connect insecurely, then back to default - do not connect.

??

Tks

6

So you didn’t do the easy thing and moved/removed the whole ~/.mozilla directory?
Hmm …

7

In fact I did … and the other things.

I will just remove that directory, and try again . Not removing anything else, and not deinstalling anything.

Is that correct?

8

AFAIK, the directory
~/.mozilla
is the only place where firefox stores it’s data.

Remove it (or just move to a different place)
while the browser is fully shut down.

When it is started again - without this directory present - it will be recreated.
You then have a known clean profile and if it then still doesn’t work you have at least ruled this out as a possible cause for your issues.

9

No, it still doesn’t work. And as I mentioned, Chromium has the same issue.

What could cause a more general problem? It’s not firewalld.

Tks

10

I hope I didn’t miss noticing that you already tried to use

  • the same connection with other devices like a laptop or phone
  • a different network connection, such as the internet access your phone might have and using this to provide the network access for your Pi

If different browsers show the same issue, it’s probably network related.

I’m pretty far from being an expert, especially when it comes to networking.
The only easy and maybe useful thought is:
have you defined or do you use a proxy?

Is the network (the internet connection) owned by you and under your control?

btw:
I have only heard of RPi - never owned or used one

11

Not sure I am answering the question here:

1 all the Manjaro computers use the same AP which is a Wi-fi router

2 that is owned by me and under my control.

3 the pi has a static address, I cannot just now determine whether the others do. I will check this and also any address conflicts tmrw.

4 I have tried either no-proxy or system-proxy with no success, but I don’t know how to configure a proxy.

5 not sure what you mean about using a connection used by another device - do you mean configuring the other device to share access and then connecting to it? What would that demonstrate if it succeeds, or if it fails?

Appreciate the help …

12

I meant that to mean: be sure you don’t use one - as this might interfere with https and also adds complexity to resolving your issue.

yes - exactly!

my reasoning:
If it is your current internet connection that is somehow creating your issue
then using a different one (your phone’s, for example)
is unlikely to have or create the same problems

One network connection might be … problematic
the other is unlikely to be problematic as well, at the same time … in the same manner … since it (likely) goes through a different provider, along a different way …

… if (for example) your mobile phone’s internet connection works
but the one that your Pi uses gives problems …

and perhaps check your router’s configuration …

and also perhaps try using a different nameserver
instead of the one that your ISP assigns you to use by default
configure this either directly on your Pi
or on your router, to apply for all devices that are connecting through it

13

It was a networking problem - thanks for putting me on the right track.

There were two issues:

1 firewalld needed to be configured to allow port 53 so that the DNS server response could be recieved by the pi. I had disabled firewalld a couple of times and assumed that this would solve the problem - it didn’t seem to, but equally the need to unblock port 53 was prbly masked by the next issue, and firewalld is now active with port 53 tcp and udp unblocked:

2 I had given the pi a manual network address for the purpose of allowing remote operation. For some reason, in a network reconfiguration exercise at some stage, I had NOT set that address in Network Manager but had left it at Automatic. I suspect that possibly the DNS query from was received at it was kicked out. Or something like that. I have also added an additional DNS server just in case.

Anyway, this issue now seems to be SOLVED.

1 Like
14

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