Re: Is this a security issue?
Hi, On Thu, 14 Mar 2024, at 00:25, ofthecentury wrote: >. And I was under the impression there would be no graphics > errors week 1 of me using OpenBSD due to the way OpenBSD was > centered around code auditing and only releasing something very > stable and tested, especially something so senstive as graphics. A nice but naive assumption, I think. There’s a wild variety of hardware out there and AIUI developers are mostly volunteers who probably give their paid jobs, family, etc a higher priority. John
Re: Looking for a well supported wireless card
On Wed, 13 Mar 2024 20:58:12 +0100 Stefan Sperling wrote: > ... > > iwm should work just fine. I don't doubt it. I did some more research on my device (Intel AC 7260, should have put it in my original message but I forgot to), and it doesn't support MU-MIMO, which the router in the residence I'm staying was set to use. I got the admin to disable this on the router, and it seems to be working better. Either way, I decided to order an Intel AX210, which appears to be supported by iwx(4). I would have gone for an Atheros device, but it seems 802.11ac support hasn't been added for those yet (looking at ath(4) and athn(4)). > Please make sure that both antennas are connected properly. I reconnected the antennas, no different results.
Re: [TUHS] Re: SunOS 4 in 2024
Prepare yourself,I feel Jan is around searching to bit anyone.. :-/ "Alexis via misc" wrote: > > Sorry for accidentally sending this here, rather than to the TUHS > list. :-/ > > Alexis writes: > [snip] >
Re: [TUHS] Re: SunOS 4 in 2024
Sorry for accidentally sending this here, rather than to the TUHS list. :-/ Alexis writes: [snip]
Re: [TUHS] Re: SunOS 4 in 2024
Henry Bent writes: Now, I find that there is a fragmentation happening. There are those of us who still cling to mailing lists - like this one! - and those who are willing to navigate the realms of increasingly compartmentalized other forms of community, Discord included. The fact that there is not a recognized central repository of unpaid support for a product, like sun-managers, I find to be frustrating. i basically agree. i won't dwell on this too much further because i recognise that i'm going off-topic, list-wise, but: i think part of the problem is related to different people having different preferences around the interfaces they want/need for discussions. What's happened is that - for reasons i feel are typically due to a lock-in-oriented business model - many discussion systems don't provide different interfaces/'views' to the same underlying discussions. Which results in one community on platform X, another community on platform Y, another community on platform Z Whereas, for example, the 'Rocksolid Light' BBS/forum software provides a Web-based interface to an underlying NNTP-based system, such that people can use their NNTP clients to engage in forum discussions. i wish this sort of approach was more common. Alexis.
Re: Badwolf and LC_CTYPE
For the same reason.. Looking to my dev env tcl/tk utilities..also tcl/tk renders textbox's text in different way causing text or windows'objects to overlap too. Dan wrote: > Hello, > > Setting LC_CTYPE to zh_CN.UTF-8 in .xinitrc makes Badwolf (webkit) > opening websites in chinese language by default while Firefox remains > in English. > > Thxs! > > -Dan
Badwolf and LC_CTYPE
Hello, Setting LC_CTYPE to zh_CN.UTF-8 in .xinitrc makes Badwolf (webkit) opening websites in chinese language by default while Firefox remains in English. Thxs! -Dan
Re: DMARC/DKIM and OpenBSD Mailinglists
Moin, On Wed, 2024-03-13 at 11:54 -0600, Todd C. Miller wrote: > I've just added support to our majordomo for rewriting the From: > header when the sender's domain has a DMARC policy. Messages from > domains using DMARC will now have a From: header like: Awesome, thanks! > I could relax this but I worry that doing so will lower the IP or > domain "reputation" in Google's eyes (something that is already a > black box). Yeah, it tends to be... difficult. Did you already give https://email-security-scans.org/ a spin? Small service we threw together, checking some stuff about sending behavior. With best regards, Tobias
webGL viewer, networkload without proper session, burning bun..
Hello, After some hours my station was unused shell messages appeared from Badwolf: [...] ERR: Display.cpp:1038 (initialize): ANGLE Display::initialize error 12289: Could not dlopen native EGL: File not found ERR: Display.cpp:1038 (initialize): ANGLE Display::initialize error 12289: Could not dlopen native EGL: File not found Attempted to create a NetworkLoad with a session (id=9223372036854775815) that does not exist. Attempted to create a NetworkLoad with a session (id=9223372036854775815) that does not exist The first two lines are probably still related to the webGL animation playing on my new website (actually it is played by a web viewer from a 3rd party portal probably using some special javascript api).. Average temperature was stuck on 64C per core, against a normal temperature of 54C. I closed Badwolf and the temperature returned normal. Don't say me that I can expect to get a silicon burned sandwich inside my station like being under Windows.. -Dan
Looking for a well supported wireless card
I'm looking for a new M.2 wireless card for my Framework laptop (no bios restrictions), and I'm wondering what would be the best supported for use on OpenBSD. Currently I'm using an old intel device with the iwm(4) driver, and I'm finding it's having trouble (lots of dropped packets (even with a strong signal), weak signal) on newer network configurations. Only requirements for the new device is that it must support at least the 802.11ac standard (preferably 802.11ax), and be the M.2 2230 form factor (See here: https://guides.frame.work/Guide/WiFi+Replacement+Guide/96). Bonus things I would want, if you know of any: 802.11ax support, for whenever that's added Requires no badly licensed/proprietary firmware Open hardware a modem??? :D
Re: DMARC/DKIM and OpenBSD Mailinglists
On March 13, 2024 1:54:14 PM EDT, "Todd C. Miller" wrote: >I've just added support to our majordomo for rewriting the From: >header when the sender's domain has a DMARC policy. Messages from >domains using DMARC will now have a From: header like: > >From: "John Connor via misc" > >and the original From: address is preserved in the X-Original-From: >header if one is not already present. > >This seems like the only reliable way to address the problem given >that the mailing list server often reformats or otherwise modifies >the message body. > >The rewriting currently happens even for a DMARC policy of "none" >since some large senders (for example gmail.com) use a policy of >"none" but receivers may still enforce SPF. I could relax this but >I worry that doing so will lower the IP or domain "reputation" in >Google's eyes (something that is already a black box). > > - todd > Thank you! -Josh-
Re: DMARC/DKIM and OpenBSD Mailinglists
I've just added support to our majordomo for rewriting the From: header when the sender's domain has a DMARC policy. Messages from domains using DMARC will now have a From: header like: From: "John Connor via misc" and the original From: address is preserved in the X-Original-From: header if one is not already present. This seems like the only reliable way to address the problem given that the mailing list server often reformats or otherwise modifies the message body. The rewriting currently happens even for a DMARC policy of "none" since some large senders (for example gmail.com) use a policy of "none" but receivers may still enforce SPF. I could relax this but I worry that doing so will lower the IP or domain "reputation" in Google's eyes (something that is already a black box). - todd
Re: mailman on OpenBSD - linking problem
On Wed, Mar 13, 2024 at 1:58 PM Michael Hekeler wrote: > > Anything else I should pay attention to? > > Make sure that your TLS setup is okay. > Read mailman's docs and also the pkg-readme (e.g. setting up cronjobs) > - and pay attention to configuration of your mailserver > > > > It's a basic mailing list for few gaming discussions really, > > so escaping from chroot was not really that scary, at least in that case. > > I wouldn't deploy old python scripts outside chroot (python 2.7 was > end-of-life since 01.01.2020!) > This is why I suggested he should run Mailman3 from the word go. ...but I also think I wouldn't setup any huge software just to deploy > "a basic mailing list for few gaming discussions" > They can us WhatsApp/Telegram/etc ? :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
net.inet.ip.multipath=1 ( ~7.5 )
Wow, You guys "fixed" it But it does strange stuff for example it fails the last icmp of a ping, but only the last ( ping -c 4 => 25 loss, ping -c 10 => 10 % loss ) Binding the source address fix it ( ping -I do something ) These is new behavior to me, Is there some updated guideline to stick a state to a route so once a state is created in pf it stays in I also notice ftp requires the -s flag now. Very nice ?
Re: Is this a security issue?
Thanks, Ze. In all fairness, people jump at an opportunity to attack someone, but it actually takes a certain level of expertise to interpret highly technical search results. I google. I don't write intel graphics drivers. And I was under the impression there would be no graphics errors week 1 of me using OpenBSD due to the way OpenBSD was centered around code auditing and only releasing something very stable and tested, especially something so senstive as graphics. On Wed, Mar 13, 2024 at 5:42 PM Zé Loff wrote: > > On Wed, Mar 13, 2024 at 05:01:57PM +0500, ofthecentury wrote: > > Just saw this in my /var/log/messages: > > > > '/bsd: drm:pid1338:intel_pipe_update_start *ERROR* > > [drm] *ERROR* Potential atomic update failure on pipe B' > > > > Intel_pipe_update??? > > > > No, it isn't a security issue, it's an underrun on the graphics driver. > > > A quick search would have told you so. This is a mailing list, with > people that actually have to take some of their time to reply, not a > search engine. > > > > -- >
Re: USB peripherals hang, nothing in messages
Messages like this are worse than useless for actually diagnosing the issue. Basically, we have no idea what hardware you are running on, or for that matter what software you are trying out. If there is a real issue, please learn how to use sendbug (https://man.openbsd.org/sendbug) or at least provide some actually relevant information besides log messages that you fail to interpret. On Wed, Mar 13, 2024 at 05:12:29PM +0500, ofthecentury wrote: > My USB mouse and keyboard hang intermittently. > > Very weird things happen, i.e. my mouse's red LED > light begins to flicker in a very weird fashion, or my > keyboard stops responding and my sound output > is suddenly muted by itself (I don't even touch sound). > > This was in the /var/log/messages regarding sound: > wrapper-2.0: vfprintf %s NULL in "[xfce-mixer-plugin. > c:374 xfce_mixer_plugin_set_property]: could not > set sound-card to '%s', trying the default card instead" > wrapper-2.0: vfprintf %s NULL in "%s: muted" > > Nothing else to show up in /var/log/messages. Is there > a more detailed log? > > How do I gather info about this from the system? > -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Is this a security issue?
On Wed, Mar 13, 2024 at 05:01:57PM +0500, ofthecentury wrote: > Just saw this in my /var/log/messages: > > '/bsd: drm:pid1338:intel_pipe_update_start *ERROR* > [drm] *ERROR* Potential atomic update failure on pipe B' > > Intel_pipe_update??? > A fairly simple web search would have provided potetially useful information such as https://marc.info/?l=openbsd-bugs=2=1=Potential+atomic+update+failure=b Try fw_update (possibly after reading its man page) and see if it makes a difference. Also, *complete* dmesg output would have told anyone trying to help diagnose the issue a lot more. As somebody (sorry, I forget who) posted earlier, https://idownvotedbecau.se/ is actually worth reading. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Is this a security issue?
On Wed, Mar 13, 2024 at 05:01:57PM +0500, ofthecentury wrote: > Just saw this in my /var/log/messages: > > '/bsd: drm:pid1338:intel_pipe_update_start *ERROR* > [drm] *ERROR* Potential atomic update failure on pipe B' > > Intel_pipe_update??? > No, it isn't a security issue, it's an underrun on the graphics driver. A quick search would have told you so. This is a mailing list, with people that actually have to take some of their time to reply, not a search engine. --
USB peripherals hang, nothing in messages
My USB mouse and keyboard hang intermittently. Very weird things happen, i.e. my mouse's red LED light begins to flicker in a very weird fashion, or my keyboard stops responding and my sound output is suddenly muted by itself (I don't even touch sound). This was in the /var/log/messages regarding sound: wrapper-2.0: vfprintf %s NULL in "[xfce-mixer-plugin. c:374 xfce_mixer_plugin_set_property]: could not set sound-card to '%s', trying the default card instead" wrapper-2.0: vfprintf %s NULL in "%s: muted" Nothing else to show up in /var/log/messages. Is there a more detailed log? How do I gather info about this from the system?
Is this a security issue?
Just saw this in my /var/log/messages: '/bsd: drm:pid1338:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe B' Intel_pipe_update???
Re: 'xset' not authorized
Not default here for some reason. Didn't change $HOME at all. On Wed, Mar 13, 2024 at 4:14 PM Stuart Henderson wrote: > > On 2024-03-13, ofthecentury wrote: > > After poking around, it turns out you just need to > > add an environmental variable XAUTHORITY in XFCE terminal. > > 'export XAUTHORITY=$HOME/.Xauthority' > > Add it to $HOME/.xsession to make it permanent. > > That's the default and you shouldn't need to set it explicitly unless > you've set $HOME to something strange. > >
Re: 'xset' not authorized
On 2024-03-13, ofthecentury wrote: > After poking around, it turns out you just need to > add an environmental variable XAUTHORITY in XFCE terminal. > 'export XAUTHORITY=$HOME/.Xauthority' > Add it to $HOME/.xsession to make it permanent. That's the default and you shouldn't need to set it explicitly unless you've set $HOME to something strange.
Re: 'xset' not authorized
After poking around, it turns out you just need to add an environmental variable XAUTHORITY in XFCE terminal. 'export XAUTHORITY=$HOME/.Xauthority' Add it to $HOME/.xsession to make it permanent. > Maybe the issue is running it in XFCE from an xfce4-terminal. On Sun, Mar 10, 2024 at 5:22 AM Stuart Henderson wrote: > > On 2024-03-09, ofthecentury wrote: > > For the droves who have/will have the same question: > > You can disable DPMS by tweaking the Xorg config > > out. First, get the monitor identifier from your > > /var/log/Xorg.0.log. Then, add a dpms.conf file to > > /usr/X11R6/share/X11/xorg.conf.d/ with this: > > Section "Monitor" > > Identifier "LVDS0" [insert your monitor identifier] > > Option "DPMS" "false" > > EndSection > > Kill xenodm and launch xenodm again. > > Confirm by running 'xset q' that DPMS is disabled. > > Laptop screen will not shut off on you again. > > "xset -dpms" and "xset s off" work fine for me.. > >
Re: mailman on OpenBSD - linking problem
> Anything else I should pay attention to? Make sure that your TLS setup is okay. Read mailman's docs and also the pkg-readme (e.g. setting up cronjobs) - and pay attention to configuration of your mailserver > It's a basic mailing list for few gaming discussions really, > so escaping from chroot was not really that scary, at least in that case. I wouldn't deploy old python scripts outside chroot (python 2.7 was end-of-life since 01.01.2020!) ...but I also think I wouldn't setup any huge software just to deploy "a basic mailing list for few gaming discussions"