Re: [gentoo-user] LiveGUI USB Image
> > > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress > > > > Replace the obvious bits. > > I've tried a few values of block size over the years, but so far I haven't > noticed any difference. I haven't run any proper tests though. > I think it's just that the default blocksize is (or was) very small (512 bytes?) so setting it to anything non-small helps a lot. eg one example (from https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with-diskdump-dd#234204) seems to show that most gains are in by around 16k. There's probably a lot of testing noise in these results. $ ./dd_obs_test.sh block size : transfer rate 512 : 11.3 MB/s 1024 : 22.1 MB/s 2048 : 42.3 MB/s 4096 : 75.2 MB/s 8192 : 90.7 MB/s 16384 : 101 MB/s 32768 : 104 MB/s 65536 : 108 MB/s 131072 : 113 MB/s 262144 : 112 MB/s 524288 : 133 MB/s 1048576 : 125 MB/s 2097152 : 113 MB/s 4194304 : 106 MB/s 8388608 : 107 MB/s 16777216 : 110 MB/s 33554432 : 119 MB/s 67108864 : 134 MB/s
[gentoo-user] Choosing --param l2-cache-size
>From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444 it appears that l2-cache-size is a misnomer; "A comment in driver-i386.c says: /* Let the L3 replace the L2. This assumes inclusive caches and single threaded program for now. */ if (level3.sizekb) level2 = level3;" "Probably the --param should be renamed to last-level-cache". So for the CPUs below that means L3. For the CPUs i have handy; AMD 3900X $ lscpu | grep '[23] cache' L2 cache: 6 MiB (12 instances) L3 cache: 64 MiB (4 instances) AMD FX-8350 $ lscpu | grep '[23] cache' L2 cache: 8 MiB (4 instances) L3 cache: 8 MiB (1 instance) Intel i5-1340P $ lscpu | grep '[23] cache' L2 cache: 9 MiB (6 instances) L3 cache: 12 MiB (1 instance) What is gcc using when using -march=native? (I use distcc so cant use =native). AMD 3900X $ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | sed 's/--param/\n--param/g' | grep '^--param l2-' | cut -d' ' -f1,2 --param l2-cache-size=512 >>> so this is the l2 size divided by the number of instances, 6MB / 12 = 512 AMD FX-8350 $ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | sed 's/--param/\n--param/g' | grep '^--param l2-' | cut -d' ' -f1,2 --param l2-cache-size=2048 >>> so this is the l2 size divided by the number of instances, 8MB / 4 = 2MB Intel i5-1340P $ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | sed 's/--param/\n--param/g' | grep '^--param l2-' | cut -d' ' -f1,2 --param l2-cache-size=12288 >>> this is the l3 size So i'm thinking the Intel CPU l2-cache-size is correct but; for the FX-8350 it should be l3 / instances, ie 8192 / 1 = 8192 for the 3900X it should be l3 / instances, ie 65536 / 4 = 16384 Am I correct? Thanks
Re: [gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh
Hi Hoël, thanks for your response! On 2024-01-03 18:11, Hoël Bézier wrote: I’ve encountered the same issue as you. I fixed it by removing the persist-tun option from my configuration file. The way I understand this configuration option, is that OpenVPN allows itself to destroy and recreate tun interfaces if needed. I’m not sure whether it means you may end up on the internet without going through your VPN. I tried again to remove the "persist-tun" option, and indeed I can now reconnect also via SIGUSR1 without problems. Also all traffic is blocked / dropped while waiting for the server timeout, so at least I'm not left open in the wild without VPN. I’d be very interested if anyone had further information on that matter, whether they would contredict my claims or support them. Yes, even though USR1 works now without falling back to no-VPN routing, if someone can give a little more insight if removing "persist-tun" is the way to go here would be nice! So at least one of the issues is "solved" for now, but the main problem still remains: How can I properly detect Mesh roaming and react timely to send HUP or USR1 to OpenVPN? I'm still thinking about some sort of wpa_supplicant "hook" mechanism for these roaming events, but I cannot find something like this in the docs ... Kind regards FloGa
Re: [gentoo-user] Off topic: - imagemagic command line, strange behaviour
On 1/3/24 09:09, Florian Gamböck wrote: On 2023-12-28 19:46, the...@sys-concept.com wrote: @echo off cd "C:\Users\Server\Desktop\" magick convert -density 300 document.pdf -fuzz 45% -fill white +opaque black converted_document.pdf pause Just a wild guess without looking too deep into it: Might the "%" be a special character in a Batch file, being interpreted as some sort of variable? Can you escape it, maybe putting the whole "45%" in quotes? Kind regards FloGa I got this one. Yes, you are correct changing "45%" to "45%%" solved the problem.
[gentoo-user] Re: udev rule for periodic polling of USB gamepad?
On 03/01/2024 19:53, Michael Cook wrote: On 1/3/24 12:33, Nikos Chantziaras wrote: Is it possible to have a USB controller (8BitDo Pro 2) polled every second or so with a udev rule? Or through some other mechanism? This controller has a quirk where it disconnects every 4 seconds or so and rubmbles when it does so. [...] I do not have this issue. I have the switch on the back of the controller set to the X position and just connect over bluethooth without any issues. Mine does not have bluetooth. It's the "wired" version. It also doesn't have switch. Switching modes works by simply holding down one of the buttons when connecting. It auto detects X-Input when connecting it to a PC. Holding down the X button will unfortunately not prevent it from still doing auto-detection stuff when it doesn't get polled for several seconds. https://codeberg.org/fabiscafe/game-devices-udev I do have these udev rules installed, unsure if they fix the issue you're talking about. I have those too.
Re: [gentoo-user] udev rule for periodic polling of USB gamepad?
On 1/3/24 12:33, Nikos Chantziaras wrote: Is it possible to have a USB controller (8BitDo Pro 2) polled every second or so with a udev rule? Or through some other mechanism? This controller has a quirk where it disconnects every 4 seconds or so and rubmbles when it does so. It also changes device number when this happens. It does this because it tries to auto-detects the kind of system it has been plugged into (like an XBox, Android, a Nintendo Switch, whatever.) Support for this controller was added in kernel 6.3 or so, but the support is extremely half-assed because it doesn't deal with this specific quirk. Currently on 6.6.9 here but this was never fixed. I do not have this issue. I have the switch on the back of the controller set to the X position and just connect over bluethooth without any issues. https://codeberg.org/fabiscafe/game-devices-udev I do have these udev rules installed, unsure if they fix the issue you're talking about.
[gentoo-user] udev rule for periodic polling of USB gamepad?
Is it possible to have a USB controller (8BitDo Pro 2) polled every second or so with a udev rule? Or through some other mechanism? This controller has a quirk where it disconnects every 4 seconds or so and rubmbles when it does so. It also changes device number when this happens. It does this because it tries to auto-detects the kind of system it has been plugged into (like an XBox, Android, a Nintendo Switch, whatever.) Support for this controller was added in kernel 6.3 or so, but the support is extremely half-assed because it doesn't deal with this specific quirk. Currently on 6.6.9 here but this was never fixed.
Re: [gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh
Am Wed, Jan 03, 2024 at 05:50:52PM +0100 schrieb Florian Gamböck:
[snip]
What bugs me however is, that OpenVPN loses connection to the VPN server
after such an AP change and is not able to reconnect automatically
again.
[snip]
While this is happening, I cannot access the internet. I suspect, this
is because of the "persist-tun" setting in the OpenVPN config, but I
don't want to remove it because I'd rather have no internet at all than
having suddenly internet without VPN ("kill switch").
I can manually "repair" this situation by sending SIGHUP to OpenVPN,
which causes a hard reconnect.
Now, with this background information, I need your help to come up with
a strategy to survive an automatic Mesh WiFi reconnect, without the need
of manually restarting OpenVPN all the time.
I’ve encountered the same issue as you. I fixed it by removing the persist-tun
option from my configuration file.
The way I understand this configuration option, is that OpenVPN allows itself
to destroy and recreate tun interfaces if needed. I’m not sure whether it means
you may end up on the internet without going through your VPN.
What I’m sure of is that sending SIGHUP to OpenVPN tells it to destroy and
recreate that tun interface of yours, bypassing the persist-tun instruction you
gave it in your configuration file.
Others may have more satisfying answers than mine, but I believe the
appropriate way to fix your issue is by allowing OpenVPN to recreate tun
interfaces when needed, such as after a disconnect, and so you need to remove
the persist-tun option. You might want to wait confirmation from other people
around before doing so, though.
I’d be very interested if anyone had further information on that matter,
whether they would contredict my claims or support them.
Hoël
signature.asc
Description: PGP signature
[gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh
Dearest collective knowledge of gentoo-user,
I'm using netifrc with wpa_supplicant (no custom settings in netifrc)
for accessing a FRITZ!Box network at my parents house. They have some
WiFi repeaters set up, connected via AVM's Meshing capabilities.
Also, I am using OpenVPN to connect to VPN servers from ProtonVPN.
From time to time, I would see this in the syslog:
Jan 3 16:37:01 georgi kernel: wlp0s20f3: disconnect from AP 04:b4:fe:b3:3f:71
for new auth to 3c:a6:2f:ed:5b:1b
Jan 3 16:37:01 georgi kernel: wlp0s20f3: authenticate with 3c:a6:2f:ed:5b:1b
Jan 3 16:37:01 georgi kernel: wlp0s20f3: 80 MHz not supported, disabling VHT
Jan 3 16:37:01 georgi kernel: wlp0s20f3: send auth to 3c:a6:2f:ed:5b:1b (try
1/3)
Jan 3 16:37:01 georgi kernel: wlp0s20f3: authenticated
Jan 3 16:37:01 georgi kernel: wlp0s20f3: associate with 3c:a6:2f:ed:5b:1b (try
1/3)
Jan 3 16:37:01 georgi kernel: wlp0s20f3: RX ReassocResp from 3c:a6:2f:ed:5b:1b
(capab=0x1431 status=0 aid=9)
Jan 3 16:37:01 georgi kernel: wlp0s20f3: associated
Jan 3 16:37:38 georgi kernel: wlp0s20f3: disconnect from AP 3c:a6:2f:ed:5b:1b
for new auth to 04:b4:fe:b3:3f:71
Jan 3 16:37:39 georgi kernel: wlp0s20f3: authenticate with 04:b4:fe:b3:3f:71
Jan 3 16:37:39 georgi kernel: wlp0s20f3: 80 MHz not supported, disabling VHT
Jan 3 16:37:39 georgi kernel: wlp0s20f3: send auth to 04:b4:fe:b3:3f:71 (try
1/3)
Jan 3 16:37:39 georgi kernel: wlp0s20f3: send auth to 04:b4:fe:b3:3f:71 (try
2/3)
Jan 3 16:37:39 georgi kernel: wlp0s20f3: authenticated
Jan 3 16:37:39 georgi kernel: wlp0s20f3: associate with 04:b4:fe:b3:3f:71 (try
1/3)
Jan 3 16:37:39 georgi kernel: wlp0s20f3: RX ReassocResp from 04:b4:fe:b3:3f:71
(capab=0x1431 status=0 aid=3)
Jan 3 16:37:39 georgi kernel: wlp0s20f3: associated
This happens even without setting "bgscan" or similar in
wpa_supplicant.conf, so I highly suspect, this is the magic of a Mesh
WiFi to pass me to a more fitting AP in the same network from time to
time. All fine so far, I don't lose WiFi connection, so this seems
normal to me.
What bugs me however is, that OpenVPN loses connection to the VPN server
after such an AP change and is not able to reconnect automatically
again.
Dec 31 19:06:08 georgi openvpn[14956]: [node-ch-11.protonvpn.net] Inactivity
timeout (--ping-restart), restarting
Dec 31 19:06:08 georgi openvpn[14956]: /etc/openvpn/down.sh proton0 1500 0
10.96.0.39 255.255.0.0 restart
Dec 31 19:06:08 georgi openvpn[14956]: SIGUSR1[soft,ping-restart] received,
process restarting
Dec 31 19:06:09 georgi openvpn[14956]: NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts
Dec 31 19:06:09 georgi openvpn[14956]: TCP/UDP: Preserving recently used remote
address: [AF_INET]138.199.6.178:1194
Dec 31 19:06:09 georgi openvpn[14956]: NOTE: setsockopt TCP_NODELAY=1 failed
Dec 31 19:06:09 georgi openvpn[14956]: UDPv4 link local: (not bound)
Dec 31 19:06:09 georgi openvpn[14956]: UDPv4 link remote:
[AF_INET]138.199.6.178:1194
Dec 31 19:06:29 georgi openvpn[14956]: Server poll timeout, restarting
Dec 31 19:06:29 georgi openvpn[14956]: /etc/openvpn/down.sh proton0 1500 0
10.96.0.39 255.255.0.0 restart
Dec 31 19:06:29 georgi openvpn[14956]: SIGUSR1[soft,server_poll] received,
process restarting
Dec 31 19:06:29 georgi openvpn[14956]: NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts
Dec 31 19:06:29 georgi openvpn[14956]: TCP/UDP: Preserving recently used remote
address: [AF_INET]138.199.6.179:51820
Dec 31 19:06:29 georgi openvpn[14956]: NOTE: setsockopt TCP_NODELAY=1 failed
Dec 31 19:06:29 georgi openvpn[14956]: UDPv4 link local: (not bound)
Dec 31 19:06:29 georgi openvpn[14956]: UDPv4 link remote:
[AF_INET]138.199.6.179:51820
The lines from 19:06:29 are repeated every 20 seconds
(server-poll-timeout 20), with varying IP addresses, so it seems to
cycle infinitely through all servers without success.
While this is happening, I cannot access the internet. I suspect, this
is because of the "persist-tun" setting in the OpenVPN config, but I
don't want to remove it because I'd rather have no internet at all than
having suddenly internet without VPN ("kill switch").
I can manually "repair" this situation by sending SIGHUP to OpenVPN,
which causes a hard reconnect.
Now, with this background information, I need your help to come up with
a strategy to survive an automatic Mesh WiFi reconnect, without the need
of manually restarting OpenVPN all the time.
- Might there be a problem with my OpenVPN config? I'm mostly using
the default config that can be downloaded from ProtonVPN, with some
additional "route" statements to make VPN unfriendly websites happy, and
I renamed the device name to have proper logs (see code block directly
below this bullet point). Has anyone a similar setup and did some
adjustments to make it work properly?
dev proton0
dev-type tun
- If there is nothing wrong
Re: [gentoo-user] Off topic: - imagemagic command line, strange behaviour
On 2023-12-28 19:46, the...@sys-concept.com wrote: @echo off cd "C:\Users\Server\Desktop\" magick convert -density 300 document.pdf -fuzz 45% -fill white +opaque black converted_document.pdf pause Just a wild guess without looking too deep into it: Might the "%" be a special character in a Batch file, being interpreted as some sort of variable? Can you escape it, maybe putting the whole "45%" in quotes? Kind regards FloGa
