Ok, thanks - so if I understand correctly then, it is listening on port 22 as a default, and not accepting traffic on any port.
That brings of the question: wouldn’t I be better off changing the SSH-port? And is that so easy as to uncomment the #Port 22 line in the config file and changing the port number to something random, and saving that somewhere? Would I then be able to connect by running ssh myuser@mydomain.com:, or would I need to do anything else to successfully connect?
It happens in my home office, my living room and my actual office. So where I spend 95% of my time with them. So if that were the case, I’d be very disappointed.
As for comfort - I find they are too tight and my head will start hurt (on top) after some time. Loosening them alleviates this somewhat, but they will drag more down on my ears which I find uncomfortable.
Tested with four different machines, one running Linux, two using Windows 10 and one with macOS. Seems to be a codec issue where Linux and Windows defaulted to SBC and macOS to AAC (where it did not occur). Changing to LDAC on Linux helped, although I am certain I had issues with this before with that codec. On Win10 I have no wiggle room as it is my work machine, and I seem to need third party software installed to change.
Rechecked this now, and it’s at about 5% now. The statistics seem a bit weird to me, unless there are some big seasonal changes. Your 12% was recorded in June and July. Maybe with less business activity during these months, the Windows share plummets in favor of home users who are more prone to use Linux.
Hm, yeah. Just checked in macOS, and it is using AAC there. So lack of AAC on my Linux device would mean it is not available here for some reason then I guess, and not an issue with the headset?
I can’t seem find a way to check the same on Windows 10 without using a third-party tool, and since this is a work computer, that is not an option for me. My guess is then that it uses SDC. Seems like AAC is supported natively in Windows 11 though, and the device is scheduled for a Win 11 install soon. Hopefully that will resolve the issue for me during work hours.
For now it seems to work better under Linux with LDAC though, which is my main use case. I swear I’ve had issues with this before, but I just streamed an entire album of high-bitrate FLAC tracks without issue now. Hopefully it stays this way.
That looks very similar to mine, except I don’t have AAC and aptX. I guess the WH1000MX5 only supports SDC and LDAC? As far as I know, I need to use the Headset Head Unit to get microphone input. After a system update some time back, it would switch automatically if I e.g. was on a Signal call. Prior to this, I would have to switch manually to get microphone input.
By the way, I am not entirely sure if I am running PulseAudio or PipeWire, as I get the confusing output below, but it seems to be PulseAudio. Is it likely to improve things if I were to switch to PipeWire?
<span style="color:#323232;">$ pactl info | grep "Server Name"
</span><span style="color:#323232;">Server Name: PulseAudio (on PipeWire 0.3.80)
</span>
As for my Windows issue, it seems LDAC is not natively supported in Windows 10, so I guess it is using SDC. Could my problems simply be that I am trying to stream a too high bitrate? I will need to recheck my settings for stream quality.
Yeah, that is true - I didn’t formulate that quite well. This also happens to me when the kill switch is enabled, as it is disabled when I disconnect. However, it would not disable itself if I simply lost connection, which is in the case where I most want the leak protection. In the other cases, I could make sure to always quit qBittorrent before disconnecting from the VPN. Not ideal, as it would be easy to make a mistake.
tun0 goes away when I am disconnected, so I don’t think anything is keeping it open. I noticed that connections in Proton VPN were set to UDP, so I changed this to TCP and this seems to have worked. Will still want to do more testing to be sure.
I don’t seem to have v3 installed, by the way. The old GUI tool seems to have been uninstalled when upgrading, and the CLI tool I unisntalled myself.
That was the case until the recent update to the Linux GUI client. I had to change the network interface bind in qBittorrent because the proton0-one stopped appearing. I assumed they had just made some changes, but could this mean that something is faulty with my install?
It is the “Torrent Address detection” magnet link I am using, and it is this that reveals my real IP when the VPN is disabled. The traffic in qBittorrent stops though.
EDIT: And as I mentioned in an earlier post, it works as intended if I open the client when not connected to the VPN. It is just if the client is running while I disconnect that this problem occurs, as far as I can tell.