Re: Making MS teams work on openbsd
On Wed, Jan 18, 2023 at 10:19:25PM +0200, Divan Santana wrote: > Greetings friends :) > > In short MS teams works via chrome on openbsd7.2 for me except for the > camera. I was on an MS Teams meeting a few weeks ago with camera working. The main issue from my experience was the web client auto disconnecting after a while. > > (The camera with webrtc works fine for other sites, just not teams) > > The screen share too works, but not the camera. It detects the camera, > but when you try switch it on, it remains black. I've seen testing/preview camera output being just a black rectangle, but it worked in the meeting itself. I have package libv4l installed; not sure if that is involved. Otherwise, would check that everything has been set up correctly - correct permissions on /dev/video0 (rw), sysctl kern.video.record=1, and chromium running with ENABLE_WASM=1 in the environment. Do other browser-based video calls work? Can test for example with Zoom here: https://zoom.us/test > Anyway, I'm pretty sure a workaround to get teams video to work via > chrome on openbsd is to create a virtual camera with a res up to 720p > and make chrome use that (or buy another camera). It seems anything > higher, and teams has an issue with it. That seems like a painful workaround; check the above if that helps narrow down the problem.
Re: NAT64 across rdomains
After some digging, what it _appears_ to me that when "af-to" is used
together with "rtable" like the following:
pass in log on re0 inet6 proto {tcp, udp} \
from (re0:network) to 64:ff9b::/96 \
rtable 1 af-to inet from 127.0.0.1
the origin rtable information is not kept in the pf state, and thus the
return packet will be routed using the default rtable (which will fail).
Is my observation correct? And if yes, is this a bug or is it by design?
Thanks!
On 1/18/23 01:41, beebeet...@posteo.de wrote:
Hi misc,
I've been trying to do NAT64 across different rdomains, but haven't had
any success so far. My test setup is as follows:
+---+
| client |
| . . . . . . . . . . . |
| fd00::2/112 |
+---+---+
|
Ethernet |
|
+---+---+
| OpenBSD router |
| . . . . . . . . . . . |
| rdomain 0 |
| re0: fd00::1/112 |
| lo0: ::1/128 |
| . . . . . . . . . . . |
| rdomain 1 |
| lo1: 127.0.0.1/8 |
+---+
There is a "service" running on the OpenBSD router in rdomain 1,
listening to 127.0.0.1 port 1234:
nc -V 1 -vl 127.0.0.1 1234
The client tries to connect the service via:
nc -zv 64:ff9b::7f00:1 1234
pf.conf only contains the following one line:
pass in log on re0 inet6 proto {tcp, udp} \
from (re0:network) to 64:ff9b::/96 \
rtable 1 af-to inet from 127.0.0.1
packet forwarding is enabled :
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
In my imagination, the client should be able to reach the service and
get a response, with the NAT64ed packet translated to a packet of
127.0.0.1 -> 127.0.0.1. However, although the incoming packet shows up
on pflog0 (so it does match the pf rule), it is not detected on the side
of the listening nc.
Any insights into why this setup does not work, or is "rtable"
incompatible with "af-to"?
Thanks!
Making MS teams work on openbsd
Greetings friends :) In short MS teams works via chrome on openbsd7.2 for me except for the camera. (The camera with webrtc works fine for other sites, just not teams) The screen share too works, but not the camera. It detects the camera, but when you try switch it on, it remains black. Firefox has a range of other issues and various workarounds that work for some don't work on my testing. Anyway, I'm pretty sure a workaround to get teams video to work via chrome on openbsd is to create a virtual camera with a res up to 720p and make chrome use that (or buy another camera). It seems anything higher, and teams has an issue with it. It's reported that on Linux one can do this via: ``` apt install v4l2loopback-dkms modprobe v4l2loopback ffmpeg -f v4l2 -i /dev/video0 -vf format=yuv420p,scale=1280x720 -f v4l2 /dev/video1 ``` Would someone know the steps to do this on OpenBSD (if possible)?
Re: Issue with acpi0 on Intel NUC11TNHi3
everyone is missing the point. we can figure out precisely which pin it is But we cannot disable it, because *acpi is supposed to tell us* the purpose of pins but acpi isn't telling us this, or we are doing something wrong, which is why this pin is unmanaged Knowing what it is, and providing people with hacks to disable it, isn't going to solve the problem of bring identifying this pin from a higher level and bringing it under control. These machines are rare. Eventually someone will dive into the acpi code and figure it out. Bradley Latus wrote: > Hi all, > > In terms of finding issues like this, might it be worth adding a dynamic > trace point > in this section of code so people could more easily identify what acpi > interrupt is > being called so often. > > Then the user could make their own patch, or if openBSD decides to implement > a way of > dynamically masking troublesome ones on specific platforms like these NUC or > similar > devices? > > Cheers > > On Thu, 19 Jan 2023, 06:51 Theo de Raadt, wrote: > > Remco wrote: > > > On 1/16/23 03:01, Bradley Latus wrote: > > > Hello Stuart, > > > I noticed that someone else had a similar issue on the openbsd-bugs > > > list.. > > > https://marc.info/?l=openbsd-bugs=166497715729842=2 > > > I was able to apply a patch I found from another user (Joe Miller) > > > which masks out > > > GPE_L6F messages and the problem was resolved. > > > https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365 > > > https://news.ycombinator.com/item?id=33279037 > > > After applying his patch (removing the additional printing parts) > > > My system was restored to what should be expected. > > > > > > > I can confirm the issue, cpu0 mainly busy with something ACPI related, > > cpu1 spinning a lot, the whole system being slow, barely usable. > > > > Applying the patch to mask/ignore the offending interrupt appears to > > solve the problem for me. > > that's great, we'll commit this diff and break ten times as many other > machines that use that specific pin for a different reason >
Re: Issue with acpi0 on Intel NUC11TNHi3
Hi all, In terms of finding issues like this, might it be worth adding a dynamic trace point in this section of code so people could more easily identify what acpi interrupt is being called so often. Then the user could make their own patch, or if openBSD decides to implement a way of dynamically masking troublesome ones on specific platforms like these NUC or similar devices? Cheers On Thu, 19 Jan 2023, 06:51 Theo de Raadt, wrote: > Remco wrote: > > > On 1/16/23 03:01, Bradley Latus wrote: > > > Hello Stuart, > > > I noticed that someone else had a similar issue on the openbsd-bugs > > > list.. > > > https://marc.info/?l=openbsd-bugs=166497715729842=2 > > > I was able to apply a patch I found from another user (Joe Miller) > > > which masks out > > > GPE_L6F messages and the problem was resolved. > > > https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365 > > > https://news.ycombinator.com/item?id=33279037 > > > After applying his patch (removing the additional printing parts) > > > My system was restored to what should be expected. > > > > > > > I can confirm the issue, cpu0 mainly busy with something ACPI related, > > cpu1 spinning a lot, the whole system being slow, barely usable. > > > > Applying the patch to mask/ignore the offending interrupt appears to > > solve the problem for me. > > that's great, we'll commit this diff and break ten times as many other > machines that use that specific pin for a different reason > >
Re: Issue with acpi0 on Intel NUC11TNHi3
Remco wrote: > On 1/16/23 03:01, Bradley Latus wrote: > > Hello Stuart, > > I noticed that someone else had a similar issue on the openbsd-bugs > > list.. > > https://marc.info/?l=openbsd-bugs=166497715729842=2 > > I was able to apply a patch I found from another user (Joe Miller) > > which masks out > > GPE_L6F messages and the problem was resolved. > > https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365 > > https://news.ycombinator.com/item?id=33279037 > > After applying his patch (removing the additional printing parts) > > My system was restored to what should be expected. > > > > I can confirm the issue, cpu0 mainly busy with something ACPI related, > cpu1 spinning a lot, the whole system being slow, barely usable. > > Applying the patch to mask/ignore the offending interrupt appears to > solve the problem for me. that's great, we'll commit this diff and break ten times as many other machines that use that specific pin for a different reason
Re: Issue with acpi0 on Intel NUC11TNHi3
On 1/16/23 03:01, Bradley Latus wrote:
Hello Stuart,
I noticed that someone else had a similar issue on the openbsd-bugs list..
https://marc.info/?l=openbsd-bugs=166497715729842=2
I was able to apply a patch I found from another user (Joe Miller)
which masks out
GPE_L6F messages and the problem was resolved.
https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365
https://news.ycombinator.com/item?id=33279037
After applying his patch (removing the additional printing parts)
My system was restored to what should be expected.
I can confirm the issue, cpu0 mainly busy with something ACPI related,
cpu1 spinning a lot, the whole system being slow, barely usable.
Applying the patch to mask/ignore the offending interrupt appears to
solve the problem for me.
regards,
Remco
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.418
diff -u -p -u -p -r1.418 acpi.c
--- acpi.c 13 Sep 2022 17:14:54 - 1.418
+++ acpi.c 18 Jan 2023 17:32:34 -
@@ -2300,6 +2300,12 @@ acpi_gpe(struct acpi_softc *sc, int gpe,
struct aml_node *node = arg;
uint8_t mask, en;
+ /* mask/ignore the GPE_L6F interrupt */
+ if (gpe == 0x6f) {
+ if ( (sc->gpe_table[gpe].flags & GPE_LEVEL) )
+ return (0);
+ }
+
dnprintf(10, "handling GPE %.2x\n", gpe);
aml_evalnode(sc, node, 0, NULL, NULL);
Re: Script launcher and a suite of basic scripts for music production?
On 2023-01-18 16:51:28+0100, Brian Durant wrote: > On 1/18/23 11:46, Abhishek Chakravarti wrote: > > Brian Durant writes: > > > The only disadvantage that I can see at this point, is that what I am > > > describing would require a number of open terminals on the desktop, > > > which can be confusing to sort through, particularly during a live > > > performance. > > > > Although not a direct answer to your question, perhaps tmux(1) might be > > helpful here? You could have one tmux session window split into several > > panes. Cycling through the panes is quite simple with PREFIX + o (the > > default PREFIX being CTRL+b; in my case it's mapped to CTRL+o > > Thanks for that. I haven't played around with tmux for ages, but you are > correct that could potentially help with terminal clutter. Below are a few > [] FWIW I have my tmux set up to use Alt+# (alt+1, alt+2...) key combinations to switch among tmux panes more easily under X than using Ctrl+b every time, which might be helpful if efficiency is important. It is also easier for me to put in muscle memory. I can provide details off-list if desired.
Re: Script launcher and a suite of basic scripts for music production?
On Wed, Jan 18, 2023 at 04:51:28PM +0100, Brian Durant wrote: > Record audio from USB sound card: > $ aucat -o /home/user/Music/set/1 - ?.wav > > Playback audio file: > $ aucat -i /home/user/Music/set/1 - ?.wav You might want to specify the encoding and other parameters rather than rely on the defaults, which might change. Last year I had to fix a problem for a company who were recording VoIP calls on an OpenBSD system with a simple shell script that invoked aucat twice to record the local and remote audio via separate sndio subdevices. (So the resulting file was stereo, with the local audio on the left channel and the remote party on the right channel.) When the VoIP program ended, the audio was trimmed of digital silence, and then compressed with FLAC, (the choice of which was quite lucky, as you will shortly see). The problem is that they were writing to raw, headerless files rather than wav or au, which I understand was done to make it easier to write the digital silence trimming program. At some point last year, in revision 1.178 of aucat.c, the default file encoding was changed from 16-bit to 24-bit. After upgrading to OpenBSD 7.1, their call recording script continued processing the data as 16-bit, but nobody checked that the call recordings were actually audible. As you can imagine, since the incoming data was actually 24-bit, and yet the two streams were being interleaved as if they were two 16-bit channels, the end result was, if I remember rightly, very bad distortion in the left channel, and pure noise in the right channel. They only noticed the problem after about three weeks because the FLAC processes were taking up a lot more CPU than before, (because they were effectively trying to compress noise). I had to study the exact transformations that their home-grown scripts and programs had performed *, write code to reverse that, decompress all of the FLAC files, (preserving the call metadata that was also stored in them), fix the audio, then re-compress them all with FLAC again. All because: 1. The defaults changed. 2. Their scripts assumed that the defaults would not change. * It was more complicated than it sounds, because the trimming of the digital silence had on some occasions caused further mangling of the data, since it was cutting at the wrong point, and not even at sample boundaries. If the audio data has been compressed with a lossy algorithm, it would have been impossible to recover it. Luckily that was not the case.
Re: Script launcher and a suite of basic scripts for music production?
On 1/18/23 11:46, Abhishek Chakravarti wrote: Hello! Brian Durant writes: The only disadvantage that I can see at this point, is that what I am describing would require a number of open terminals on the desktop, which can be confusing to sort through, particularly during a live performance. Although not a direct answer to your question, perhaps tmux(1) might be helpful here? You could have one tmux session window split into several panes. Cycling through the panes is quite simple with PREFIX + o (the default PREFIX being CTRL+b; in my case it's mapped to CTRL+o Thanks for that. I haven't played around with tmux for ages, but you are correct that could potentially help with terminal clutter. Below are a few thoughts about scripts for music. I will avoid flooding the list with all of my ideas but will simply provide a couple of basic ones. Note that I am new to OpenBSD and have little experience with scripting: OpenBSD music scripts Scan midi/ values (from dmesg or...) and route them to midithru/0 similar to manual commands below: (Is there a use case scenario for rerouting midi/1 - ? by use of midithru/1 -?) $ midicat -d -q midi/0 -q midithru/0 $ midicat -d -q midi/1 -q midithru/0 Record audio from USB sound card: $ aucat -o /home/user/Music/set/1 - ?.wav Playback audio file: $ aucat -i /home/user/Music/set/1 - ?.wav To my knowledge, most USB sound cards have at least two inputs (for microphone and guitar / bass as examples). Important that any script is input sensitive and can automatically number files for each input in order for possible playback with effects by using a simple alias created automatically for the purpose, for the session (?) Also important that monitoring is possible during file creation to avoid pauses while performing a set.
Re: Script launcher and a suite of basic scripts for music production?
Hello! Brian Durant writes: > The only disadvantage that I can see at this point, is that what I am > describing would require a number of open terminals on the desktop, > which can be confusing to sort through, particularly during a live > performance. Although not a direct answer to your question, perhaps tmux(1) might be helpful here? You could have one tmux session window split into several panes. Cycling through the panes is quite simple with PREFIX + o (the default PREFIX being CTRL+b; in my case it's mapped to CTRL+o -- Abhishek Chakravarti abhis...@taranjali.org | Kolkata, IN fifthestate.co.in | refpersys.org | taranjali.org
