To check what driver is being used for your nvidia card:

chris@rigel:~/bin$ lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF104 High Definition Audio Controller (rev a1)

Check the video card as follows (updating the address if necessary).

chris@rigel:~/bin$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Gigabyte Technology Co., Ltd GF104 [GeForce GTX 460]
	Flags: bus master, fast devsel, latency 0, IRQ 34
	Memory at f4000000 (32-bit, non-prefetchable) [size=32M]
	Memory at e8000000 (64-bit, prefetchable) [size=128M]
	Memory at e4000000 (64-bit, prefetchable) [size=64M]
	I/O ports at ac00 [size=128]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia
	Kernel modules: nvidia

The last two lines should say nouveau if that's being used (I'm using the nvidia driver so I can run CUDA apps on the card).

Could some moderator please move this thread to Off-topic ? It has nothing to do with Devuan.

What country are you in? There was problem affecting several banking sites in the UK yesterday. So it might not be firefox (although it probably is if it affected other sites as well).

Running shellcheck against wondershaper would be a reasonable start if it's a shell script.

Then try adding set -x as the second line and see if that tells you what it's trying to do when it fails.

But I'm only guessing because I don't have wondershaper installed.

Re post 89 by soren (at 09:32:57) my first response would be:
ls -li /lib/x86_64-linux-gnu/libsystemd.so.0 /usr/lib/x86_64-linux-gnu/libsystemd.so.0
and see if one was a symlink to the other or if they are hard links (same inode numbers). If different files but the same size I'd then try diff /lib/x86_64-linux-gnu/libsystemd.so.0 /usr/lib/x86_64-linux-gnu/libsystemd.so.0 to see if one is a copy of the other.

If they are the same inode numbers I'd check if /lib and /usr/lib are symlinks (ls -lid /lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ then ls -lid /lib/ /usr/lib/). That would give me a better idea what state things are in.

It's probably a bit late now, but did you save a copy of /home/groucho/.wine from before you restored it from the snapshot? Or just output from ls -lr /home/groucho/.wine ? Comparing permissions from then and now might show what was wrong.

If anyone else hits this issue that would be worth trying.

Try e2fsck -V to find out what version is *really* on each system. (You may need /sbin/e2fsck -V if you're not running as root.)

traceroute will only learn the IP address if it gets a response from the system. So in this case it's only going to work intermittently.

I suspect your traffic may be routed through two or more paths, one via a system that generates timout responses and one or more that don't. So it's a matter of chance whether you get a response.

But it's not a worry because your traffic is always passed on to later sites.

That's past my knowledge of networking. It seems to have only replied to 2 of the 61 test packets sent to it. But passed on all the packets sent to later links.

If you are really interested you could ping it and see how often it replies. But it's probably won't get you anywhere unless you ask the telco that owns it, who probably won't be interested because it's passing packets on OK.

host host39.181-89-51.telecom.net.ar should tell you it's IP address. But again that isn't likely to tell you anything useful.

Your telco may well have an equivalent on their website. Which they might be more willing to believe since it *should* only be going through their hardware to get to it. So they can't blame congestion on the internet between their kit and the site in question.

I had a period when I was getting bad performance from my connection. It showed up as ping'ing sites on the internet got lost and duplicate packets. I used traceroute to my telco's website, then pinged each hop to find out where the fault seemed to be (in my case the first hop past my router). But I hope you don't need to do that.

I just hover my mouse pointer over chopped URLs and the browser shows the full link on the bottom bar. By now it's a habit.

It also helps on web pages where the link doesn't match the visible text. Eg hover on the name of a poster.

A quck test gave me a clue (output truncated for brevity):

$ netstat -tulpen
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          15476      -                   
tcp        0      0 0.0.0.0:60799           0.0.0.0:*               LISTEN      105        14342      - 

And as root:

$ sudo netstat -tulpen
[sudo] password for chris: 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          15476      2240/exim4          
tcp        0      0 0.0.0.0:60799           0.0.0.0:*               LISTEN      105        14342      1343/rpc.statd  

So netstat can't find out the PID/Program name if it's not running as root unless the program that opened the socket is running as you.