gaming extensions to the kernel

[Alessandro Pistocchi]

Hi all,

I have managed to create some exciting, gaming-specific extensions to the
OpenBSD kernel,
specifically for an arm64 raspberry pi 4.

I would like to turn this into a product that people enjoy if possible and
I would be happy to
make something that benefits the OpenBSD community as well somehow. I am
enjoying
working on OpenBSD and am genuinely happy to give something back if I can.

I started a discussion on other channels about this and got quite a bit of
resistance,
mainly because I wasn't planning to send diffs for what I am doing.

My reasoning for not sending them is that the changes I made could create
security
issues for ordinary users, and I think that it would be a nightmare to
maintain only
to be able to play smoother games on a single platform, which in the grand
scheme
of things is quite small.

To give you an idea, I am giving exclusive access to 3 out of 4 cpu cores
to a game
and I give the game quite a few pages of contiguous memory for the
framebuffer.
I give all that back to openbsd when the game ends. OpenBSD cannot interrupt
the game on those 3 cores, it can only kill the game if needed. That's not
stuff that
should go into the official kernel, right?

What I was thinking was more like "I go on and try to make and sell my
product and
when I make money I donate a percentage of the profits to the OpenBSD
Foundation".

Is that acceptable? Or alternatively, what is the "right" way of doing
something like that?

Thanks :-)
Alessandro

Re: pf questions

[Dave Anderson]

> On Jun 1, 2021, at 16:50, Stuart Henderson  wrote:
> 
> On 2021-05-30, Dave Anderson  wrote:
>> I’m setting up on 6.9-release a (for now) IPv4-only firewall with multiple 
>> public addresses and multiple subnets behind it, and have a couple of 
>> questions related to connections originating from the firewall itself to 
>> which I haven’t found definitive answers.
>> 
>> When not overridden (for example, by ‘ftp-proxy -a ’) which of the 
>> public addresses will be chosen as the source address for connections to the 
>> Internet originating on the firewall? It would make sense to me for the one 
>> address not declared as an alias to always be chosen, but I haven’t found 
>> anything that states this to be true. I want to (for example) keep traffic 
>> from systems I control separate from that from the WiFi subnet (which I’ll 
>> NAT to a different public address).
> 
> The interface address associated with the route used to reach the
> destination. See "if address" in "route -n get $IP".
> 
>> I plan to use tags to control policy, initially tagging each new connection 
>> based mostly (but not entirely) on which interface it arrives through. But, 
>> unless I’m missing something, connections originating on the firewall can’t 
>> be tagged this way since they don’t arrive through any interface. Which also 
>> seems to mean that all policy decisions must be made outbound, since that’s 
>> the only time that connections originating on the firewall will pass through 
>> an interface. And I haven’t found any way of filtering on untagged 
>> connections (something like ‘! tagged any’ would be nice). I’m sure that my 
>> setup isn’t unique, so there must be a good way of dealing with this, but 
>> I’ve no idea what it might be. Suggestions, please!
> 
> You might find "!received-on any" useful to allow a rule to match only
> locally originated connections. I guess you could do something like
> "match !received-on any tag local" if you want to attach a tag to those.

I should have noticed that; evidently I was too fixated on tags. Once I’ve 
identified the local connections I can NAT them to the address I want, so which 
source address is used by default doesn’t matter. Thanks!

Re: pflow on PE router

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
> 
> Oh watch out with sloppy. Keep an eye on your state table size.

Really? Wouldn't sloppy keep the state table smaller if anything since it's 
tracking less specifically?

Anyways I use sloppy across four boxes that run in parallel with pfsync. There 
could easily be 10,000 devices behind it at any given time. I keep my state 
table limit at 1,000,000. It's around 300,000 during this lighter traffic 
period today. I had to do sloppy after moving to several boxes in parallel, I 
didn't notice sloppy making any significant difference?

Chris

Re: Mic mute button doesn't work

[Ashton Fagg]

https://www.openbsd.org/report.html

On Thu, 3 Jun 2021 at 12:26, Subhaditya Nath  wrote:
>
> Hi
>
> I have noticed that the Microphone Mute button on my Thinkpad E495 doesn't
> actually cause the Microphone to be muted.
>
> NOTE: I have already set kern.audio.record=1
>
> Expected behaviour -
> --
> Pressing the MicMute button causes the equivalent of `sndioctl input.mute=!`
> i.e. it toggles the `input.mute` parameter of sndio
>
> Actual behaviour -
> ---
> Pressing the MicMute button does not cause the `input.mute` parameter to be
> toggled. So, the mic audio is not muted.
>
>
> How can I fix this?
>

Mute, FnLock keyboard LEDs don't work

[Subhaditya Nath]

Hi

I have noticed that the Speaker Mute LED and the FnLock LED doesn't work on my
Thinkpad E495.


Behaviour of Speaker mute button -
---
When pressed, it toggles the output.mute parameter in sndioctl.
The sound is muted/unmuted.
The LED doesn't light up in either case.


Behaviour of FnLock button -
-
(I am not aware of any command to toggle FnLock from the command line)
When pressed, it toggles the state of FnLock. (ie. the button is working)
The LED doesn't normally light up. But, if the laptop resumes from sleep with
FnLock enabled, then the FnLock LED lights up. But, it doesn't turn off until
the next sleep-resume cycle.

ie. effectively, the FnLock LED does work, but it is not getting refreshed. It
only gets refreshed when the laptop is sleep and then resume.
(Sorry for my bad english)

The "refresh" issue of FnLock LED was also persistent in the Linux kernel till a
few months ago. It was resolved only recently. See this -
https://bugzilla.kernel.org/show_bug.cgi?id=207841



How can these issues be fixed?

Mic mute button doesn't work

[Subhaditya Nath]

Hi

I have noticed that the Microphone Mute button on my Thinkpad E495 doesn't
actually cause the Microphone to be muted.

NOTE: I have already set kern.audio.record=1

Expected behaviour -
--
Pressing the MicMute button causes the equivalent of `sndioctl input.mute=!`
i.e. it toggles the `input.mute` parameter of sndio

Actual behaviour -
---
Pressing the MicMute button does not cause the `input.mute` parameter to be
toggled. So, the mic audio is not muted.


How can I fix this?

Re: localised office setup, how?

[mashle]

Hi Yoshihiro Kawamata,

Thanks for these pointers. The "-i18n" string is a great hint, using that I 
could https://cdn.openbsd.org/pub/OpenBSD/6.9/packages/amd64/ verify that many 
packages split of their localization in a package named like that.
In the pkg-readme for gnome I could find this:
"GDM greeter language and character set is configured in:
    /etc/gdm/locale.conf
Note that the variables set in this file will be inherited by the user session.
They can be unset/overriden in the user's .profile file"
There are no "-i18n" files for gnome packages, but looking into 
nautilus-3.38.2.tgz/share/locale  it 
looks like gnome packages include localized strings.

Great, so it seems like what I want is indeed possible and easily available, so 
it's time to do it.
Thanks again,
if anybody has more tips related to this, I would be happy to read them.

Regards,
Mashle

-- 
 Sent with Tutanota, the secure & ad-free mailbox: 
 https://tutanota.com


Jun 3, 2021, 01:28 by k...@on.rim.or.jp:

> Hi Mashle,
>
> My native language is Japanese, then I have the following settings in
> my .xsession file.
>
>  export LANG=ja_JP.UTF-8
>  
>  # setups for fcitx-anthy
>  export XMODIFIERS="@im=fcitx"
>  export GTK_IM_MODULE="fcitx"
>  export QT_IM_MODULE="fcitx"
>  fcitx-autostart
>
> The first line sets the locale setting for the language to Unicode for
> Japanese, and most applications will follow this setting.
>
> The third and subsequent lines are settings related to the Input
> Method.
> Since Japanese cannot be input using only an alphanumeric keyboard,
> these settings are necessary. You can omit these if they are not
> necessary for your language.
>
> For Firefox, do
>  pkg_info -Q firefox-i18n
> to search the localisation for your language.
> If found and installed it, then set it in Preferences->Language.
>
> As for LibreOffice, you can search for it with pkg_info as well.
>
> In my case, there was no libreoffice-i18n-ja for Japanese, so I
> downloaded the Japanese language pack (in RPM format for Linux) from
> the official LibreOffice website, unpacked it with rpm2cpio, and
> overwrote it under /usr/local/lib/libreoffice.
>
> As for the fonts, this depends on what your native language is, so I
> can't give you a detailed answer, but I expect you can still find a
> suitable one from packages.
>
> If your native language is French, you may find an OpenBSD
> customization script called isotop helpful.
>  https://www.3hg.fr/Isos/isotop/
>
> Regards,
>
> Yoshihiro Kawamata
> http://fuguita.org/
>

Re: pflow on PE router

[Patrick Dohman]

I suspect that you’ll be out of luck until TLSv1.3 is implemented. 
I’ve found the same to be true with the new 10 gb sfp switches in our 
infrastructure which surprisingly still implement TLSv1.0 & broken CGI web 
server.
Regards
Patrick

> On Jun 1, 2021, at 3:44 PM, Stuart Henderson  wrote:
> 
> On 2021-05-30, Denis Fondras  wrote:
>> Le Fri, May 28, 2021 at 03:30:58PM -0700, Chris Cappuccio a écrit :
>>> You might try "set state-defaults pflow, sloppy", also in some scenarios 
>>> you 
>>> might need "set state-policy floating"
>>> 
>>> If "sloppy" fixes it, there may be some bugs to hunt.
>>> 
>> 
>> "sloppy" seems to fix the issue. I will do more tests this week before 
>> declaring
>> victory :)
>> 
>> Thank you Chris.
>> 
>> 
> 
> Oh watch out with sloppy. Keep an eye on your state table size.
> 

Re: trying to add auth to specific location in httpd.conf

[fm+obsd+misc+list]

My bad.

Just plain authenticate with "/path/to/the/htpasswd/file" above the fastcgi 
line did the trick.

Regards, 

Fabio