Re: DMARC/DKIM and OpenBSD Mailinglists
Moin, > > I've disabled the From: rewriting for now after complaints that it > makes things a lot less usable. We'll try preserving messages as > sent instead, which means that text/html parts will now be passed > through (sorry). > Darn, but i see where this can break the workflow of people. I am intentionally double-posting this email (once from my personal domain, once from reads-this-mailinglist.com) to see how well preserving messages as sent works/impacts deliverability. Will let you know :-) With best regards, Tobias
Re: DMARC/DKIM and OpenBSD Mailinglists
Moin, > > I've disabled the From: rewriting for now after complaints that it > makes things a lot less usable. We'll try preserving messages as > sent instead, which means that text/html parts will now be passed > through (sorry). > Darn, but i see where this can break the workflow of people. I am intentionally double-posting this email (once from my personal domain, once from reads-this-mailinglist.com) to see how well preserving messages as sent works/impacts deliverability. Will let you know :-) With best regards, Tobias
Re: Unable to get ip6 address
Hari writes: I have uses mtw wifi firmware. Stuart asked you to provide dmesg output. dmesg output provides more information than simply the name of the firmware: it often provides information like version and revision numbers, as well as warnings and errors regarding the hardware. Some years ago, setting up Linux on a laptop, the dmesg showed why wifi wasn't working: rtw_8821ce :01:00.0: enabling device ( -> 0003) rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12 rtw_8821ce :01:00.0: rfe 4 isn't supported rtw_8821ce :01:00.0: failed to setup chip efuse info rtw_8821ce :01:00.0: failed to setup chip information In general, when people ask for specific information as part of trying to help someone solve a problem, we're typically doing so for specific reasons, based on knowledge and experience, which might not be immediately apparent to the person asking for help. Personally, if someone i'm trying to help keeps not providing the specific information i'm asking for, i'll stop wasting my time, and just walk away from the discussion. Alexis.
Re: USB peripherals hang, nothing in messages
On Fri, Mar 15, 2024 at 01:40:56PM +0100, Dan via misc wrote: > > Interesting.. > > Laurence Tratt via misc : > > > This sounds to me like it might be due to USB stack performance problems, > > though you'll at least want to give `dmesg` output so that those who better > > understand this have a chance of helping. > > > > FWIW, there seem to be notable differences in USB performance on nominally > > similar hardware with OpenBSD. > > Do you suggest to phisically (hub) separate peripherals from > eg. storage devices for who is working in this kind of fashion? > > -Dan > I used a powered USB hub on a laptop that somehow solved a bunch of connectivity problems to the laptop's USB3 port. I needed a powered hub to run both the wifi dongle and a spinning USB hard drive. No idea why it worked, but it did. -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
Re: Unable to get ip6 address
Following is the output of cat /etc/hostanme.mtw0 nwid network Wpakey passwd inet autoconf inet6 autoconf On 15 March 2024 23:08:14 GMT+05:30, "Peter N. M. Hansteen" wrote: >Please keep this on the list unless you want me to start writing invoices. > >On Fri, Mar 15, 2024 at 05:02:27PM +, Pencilgon wrote: >> Sorry for earlier email, I left you some details. >> >> First of all I don't think ip6 work at all, well in theory inet6 autoconf >> should >> work and grant me internet access but it doesn't, I don't get a ip6 address >> at >> all. >> >> Second I am unable to get ip4 address even on wifi. > >This sounds like your wifi interface is not in fact properly configured. > >For this to produce anything even resembling useful results, we need to see at >least the content of your configuration files -- /etc/hostmhame.* and the >output >of ifconfig for the relevant interfaces (if need be with stuff like IP >addresses >and passwords masked). > >-- >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: Unable to get ip6 address
I have uses mtw wifi firmware. I don't know what do you mean by multicast. I works perfectly fine with linux. On 15 March 2024 23:10:52 GMT+05:30, Stuart Henderson wrote: >On 2024-03-15, Hari wrote: >> >> Well I read and tried to this as stated in faq=2E But it doesn't work, well= >> ip6 does work if I trt ethernet but not with wifi=2E > >At least send a dmesg so readers have some idea of the hardware involved. > >One possible problem: IPv6 requires multicast for address resolution >which might not be working properly. > >
Re: Minimum viable HW for OpenBSD
> Could you point out a hardware for this kind of use-case? I would liek to > have something smaller than a regular-Pi SBC. I'm still playing with this kind of stuff. Good luck on your journey, but it will be a rough ride. You already mentioned some issues. I have/had a pair of Raspberry 3B and also a pair of Pine64 SBCs, running OpenBSD 7.x and CARP failover for experimental things. Working, but not as reliable as I would like. You seem to aim at even smaller boards like that, and newer ones should match the specs of Raspi3B or Pine64. However: - there is no fine "sysupgrade" for these platforms, so you need to reinstall every time - which means fiddling with non-OpenBSD "uboot" and EFI definition files - consider creating a network boot infrastructure - these devices are very sensitive to power voltage instabilities, triggering spontaneous reboots. You may want to run them from stable USB power source - I doubt this can be reasonably battery-powered, over longer time periods - storage like SD-card or eMMS draw extra power during operation, writes may be unreliable during voltage drops - storage like SD-card or eMMS will wear out and die hard, sooner or later - Wifi hardware may not be supported - RS232 serial usually provided (and working) by bus pinout, but you need to add a FTDI232 or CH340 adapter That said, I'd like to hear about it if you find interesting hardware :) Olaf
Re: pf nat64 rule not matching
> I don't think there is at present. There are no "only use v4" or "only > use v6" addresses modifiers, and pf isn't figuring out for itself that > it only makes sense to use addresses from the relevant family for > af-to translation addresses (although it _does_ do this for nat-to). Good to know. I was able to get this working by using ($wan) instead of ($wan:0), fwiw. > Ah I meant that the router should not use the local unbound dns64 > resolver for its own traffic - otherwise it won't be able to reach v4 > hosts because there won't be anything to handle the translation. > Either point it off-machine (ISP or public resolver) or run another > local resolver for its own traffic. Ah, that makes sense. I was totally doing this. *facepalm* I've changed it to use Quad9. Thanks for the follow-up! > Please keep replies on the mailing list. My bad! Still getting used to the `mail` client and how this mailing list operates in general, and I see now the default behavior is to do a reply-all that includes your personal email in addition to the mailing list. Apologies!
Re: Saving UKC> list output
On 2024-03-15, Nick Holland wrote: > um... your formatting is giving me Commodore VIC20(1) > flashbacks... There are way more than 22 chars in some of those lines :-)
Re: pf nat64 rule not matching
On 2024-03-15, Evan Sherwood wrote: > > Is there a way to configure this without hard-coding my IPv4 address? > I do not think my IPv4 address from my ISP is static, thus my original > interest in the ($wan:0) form. I don't think there is at present. There are no "only use v4" or "only use v6" addresses modifiers, and pf isn't figuring out for itself that it only makes sense to use addresses from the relevant family for af-to translation addresses (although it _does_ do this for nat-to). >> Regarding the other rules and tests, the ::1 rule is wrong, packets >> outgoing on the network won't have a ::1 address, try "!received-on >> any", and packets sourced from the router itself won't hit the af-to >> rule so tests need to be from another machine (and probably best use >> different DNS servers not doing dns64 on the router). > > Thanks for this follow-up. You're right that I was trying to only target > traffic that originated from the router itself with this rule. I had > figured out that the tests needed to be from another machine, though > that did take me a while. > > What are the reasons for doing dns64 on a different machine? Ah I meant that the router should not use the local unbound dns64 resolver for its own traffic - otherwise it won't be able to reach v4 hosts because there won't be anything to handle the translation. Either point it off-machine (ISP or public resolver) or run another local resolver for its own traffic. -- Please keep replies on the mailing list.
Re: Saving UKC> list output
Oh, so perfect, thx. Believe it or not, I have used a mechanical typewriter before. And also the matrix printers (resulting in partial hearing loss, probably). On Fri, Mar 15, 2024 at 11:36 PM Nick Holland wrote: > > On 3/15/24 07:56, ofthecentury via misc wrote: > > When you want to turn off > > a device on OpenBSD you > > can do it at boot time with > > manual `boot -c` command. > > (Can also be automated) > > After entering entering > > `boot -c` you get UKC> > > configuration prompt. > > I type `list` and get a nice > > list of all drivers I can > > disable with `disable > > mei` or disable `lpc`. > > But how do I get > > that list into a file > > so I can review it? > > Is there some > > way to do it? > > Thx! > > um... your formatting is giving me Commodore VIC20(1) > flashbacks... > > Anyway: > > script > config -e /bsd > ... > ukc> list > [hit enter a bunch of times] > CTRL-C (to get out of config) > CTRL-D (to get out of script) > > ta-da! output in 'typescript'. > > config does some of what boot -c does from a running system. > script captures screen input and output. > man config > man script > > Nick. >
Re: pf nat64 rule not matching
> Try changing ($wan:0) to $(wan) and see what happens. Huh, that worked! Thanks!
Re: Saving UKC> list output
On 3/15/24 07:56, ofthecentury via misc wrote: When you want to turn off a device on OpenBSD you can do it at boot time with manual `boot -c` command. (Can also be automated) After entering entering `boot -c` you get UKC> configuration prompt. I type `list` and get a nice list of all drivers I can disable with `disable mei` or disable `lpc`. But how do I get that list into a file so I can review it? Is there some way to do it? Thx! um... your formatting is giving me Commodore VIC20(1) flashbacks... Anyway: script config -e /bsd ... ukc> list [hit enter a bunch of times] CTRL-C (to get out of config) CTRL-D (to get out of script) ta-da! output in 'typescript'. config does some of what boot -c does from a running system. script captures screen input and output. man config man script Nick.
Re: pf nat64 rule not matching
Try changing ($wan:0) to $(wan) and see what happens.
Re: replying to mailing list message after subscribing
On Fri, 15 Mar 2024 18:57:29 +0100, Evan Sherwood wrote: > Is that something you can do because you're a list administrator or > something? Still wondering if there is a way to do this without asking > someone to resend an email. Yes, it is something I can do because I'm a list administrator. - todd
Re: replying to mailing list message after subscribing
> you should be able to reply to the copy in your "sent" folder Good to know. > I just re-sent the original messages to your new address so you should > now have a copy to reply to. Thanks! Is that something you can do because you're a list administrator or something? Still wondering if there is a way to do this without asking someone to resend an email.
Re: pf nat64 rule not matching
> Can you try if the same happens with a more specific rule (for > testing)? > > i.e.: > > pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96 > af-to inet from "actual IP on igc0"/32 This worked! Specifically, I think the ($wan:0) was the problem. I could've sworn I tried this with the actual IP and it wasn't working before, but I might've deleted the inet6 at that point, so maybe I created a new problem then... which you also pointed out: > I am suspecting that the missing inet6 may lead to some confusion. Is there a way to configure this without hard-coding my IPv4 address? I do not think my IPv4 address from my ISP is static, thus my original interest in the ($wan:0) form. > Alternatively, remove the block rules; URPF may be an issue here, if > you lack a route for the /96. I had tried commenting out all of the block rules and saw no change. Tcpdump also showed no blocks, fwiw. > Regarding the other rules and tests, the ::1 rule is wrong, packets > outgoing on the network won't have a ::1 address, try "!received-on > any", and packets sourced from the router itself won't hit the af-to > rule so tests need to be from another machine (and probably best use > different DNS servers not doing dns64 on the router). Thanks for this follow-up. You're right that I was trying to only target traffic that originated from the router itself with this rule. I had figured out that the tests needed to be from another machine, though that did take me a while. What are the reasons for doing dns64 on a different machine?
Re: Unable to get ip6 address
On Fri, Mar 15, 2024 at 06:38:14PM +0100, Peter N. M. Hansteen wrote: > least the content of your configuration files -- /etc/hostmhame.* and the > output that should of course have been /etc/hostname.* but would be obvious? -- 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: Unable to get ip6 address
On 2024-03-15, Hari wrote: > > Well I read and tried to this as stated in faq=2E But it doesn't work, well= > ip6 does work if I trt ethernet but not with wifi=2E At least send a dmesg so readers have some idea of the hardware involved. One possible problem: IPv6 requires multicast for address resolution which might not be working properly.
Re: Unable to get ip6 address
Please keep this on the list unless you want me to start writing invoices. On Fri, Mar 15, 2024 at 05:02:27PM +, Pencilgon wrote: > Sorry for earlier email, I left you some details. > > First of all I don't think ip6 work at all, well in theory inet6 autoconf > should > work and grant me internet access but it doesn't, I don't get a ip6 address at > all. > > Second I am unable to get ip4 address even on wifi. This sounds like your wifi interface is not in fact properly configured. For this to produce anything even resembling useful results, we need to see at least the content of your configuration files -- /etc/hostmhame.* and the output of ifconfig for the relevant interfaces (if need be with stuff like IP addresses and passwords masked). -- 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: replying to mailing list message after subscribing
On Fri, 15 Mar 2024 18:19:28 +0100, Evan Sherwood wrote: > I sent a message to this list earlier from a ProtonMail account, and > none of the replies have arrived (not even in Junk), even though I see > there are replies via the web archive... so I don't have a message to > reply to. The mailing list does send you a copy of your own messages unless you disable the "selfcopy" flag (which you have not done). However, many email providers discard duplicate messages. This may include ones you have authored yourself if there is already a copy in your "sent" folder. I don't know about ProtoMail, but gmail does do this. If that is the case, you should be able to reply to the copy in your "sent" folder (or whatever they call it). > I've since subscribed to this mailing list on a different email account > where I can author messages on the command line instead of through a web > interface, but there have been no new replies on my original message > since I subscribed, so I still don't have a message to reply to. I just re-sent the original messages to your new address so you should now have a copy to reply to. - todd
Re: DMARC/DKIM and OpenBSD Mailinglists
I notice date an time of your reply. You are quite ridiculus all. Hoping to find any "indipendent head" around OpenBSD or leave.. -Dan Mar 15, 2024 17:13:52 Dan : > Todd C. Miller : > >> I've disabled the From: rewriting > > Indeed it appeared too secure for OpenBSD...
replying to mailing list message after subscribing
Apologies for the newbie question: I'm new to mailing lists. ;D I sent a message to this list earlier from a ProtonMail account, and none of the replies have arrived (not even in Junk), even though I see there are replies via the web archive... so I don't have a message to reply to. I've since subscribed to this mailing list on a different email account where I can author messages on the command line instead of through a web interface, but there have been no new replies on my original message since I subscribed, so I still don't have a message to reply to. How do I send a reply to a thread I have no messages from in my inbox? I'm using the `mail` command. I couldn't find anything that seemed helpful from the majordomo help commands, nor through online searching. I see there are "In-Reply-To" headers on other messages I've received from the mailing list, but they seem like generated values, and as I don't have any messages from the thread I want to reply to I don't know what to set for that. The thread I want to reply to is titled (started in the last 24 hours): Re: pf nat64 rule not matching I know someone could reply to that thread and I'd get it in my inbox and could reply from there, but I am curious how I would do this without that kind of intervention, in case there are other messages that predate my subscription that I'd want to reply to. Thanks for the help!
Re: Minimum viable HW for OpenBSD
Hi Claudio, Thanks for the hint, I have researched the listed boards already, but havent found the ideal board. I consider arm64 boards as generic computers if one have the skills to solve the unavoidable issues, but i dont have those skills. So i keep looking. Nevertheless: let me know if you happen to work on a board, which could be interesting for me. Regards, --ext 2024. márc. 15. 15:13:58 Claudio Miranda : > Supported hardware information is listed here: > https://www.openbsd.org/plat.html > > Each platform's link provides further information. > > On Fri, Mar 15, 2024 at 9:44 AM Mizsei Zoltán wrote: >> >> Hi, >> >> I'd like to build a small, portable system, not entirely different from a so >> called "cyberdeck". For this project I am actively looking for the minimum >> viable HW which supports OBSD. I would like to get some hints, as so far I >> was unable to find the perfect hw (maybe it doesn't even exists). >> >> My requirements are: >> - low power consumption (battery powered) >> - small in sizez >> - ARM / ARM64 / RISC-V or something else >> - CLI >> - UART >> - USB >> - WiFi (ideally integrated, but can be usb attached aswell) >> - replaceable storage (SD card, or similar) >> - ideally some onboard storage (eMMC?) >> - and ideally some kind of supported display output >> >> I would like to either reuse the enclosure of a small handheld device which >> have a display and a keyboard or print an own one and source some >> off-the-shelf components and get them somehow working together. >> >> I was looking at minimum viable computing and found RetroBSD/DiscoBSD [1,2], >> they are BSD 2.x ports for various microcontrollers (100+ Mhz, 1-2MB RAM), >> but they can't realistically support me in the modern world (USB, WiFi). >> >> I have also considered the various SBCs in "Zero" and "Nano" form-factor, >> but i was unable to find any which won't cause me headache with the >> non-upstreamed FDT [3], or they aren't fully supported yet by OBSD, or it is >> impossible to source them anymore, or the bootloader is some vendored fork, >> which a burden to update, etc. >> >> I was looking at Crystal Kolipe's article-series [4] regarding the >> PinePhone, but the screen is not yet usable AFAIK... >> >> Could you point out a hardware for this kind of use-case? I would liek to >> have something smaller than a regular-Pi SBC. >> >> Thank You very much! >> >> [1] https://github.com/RetroBSD/retrobsd/ >> [2] https://github.com/chettrick/discobsd/ >> [3] https://www.geniatech.com/product/xpi-3566-zero/ >> [4] https://research.exoticsilicon.com/series/pinephone_openbsd/part_1/ >> >> --Z-- >>
Re: Unable to get ip6 address
Well I read and tried to this as stated in faq. But it doesn't work, well ip6 does work if I trt ethernet but not with wifi. On 15 March 2024 21:20:35 GMT+05:30, "Peter N. M. Hansteen" wrote: >On Fri, Mar 15, 2024 at 03:32:48PM +, Pencilgon wrote: >> I recently installed openbsd got everything working wifi etc. The problem >> arises >> when I tried to connect ip6 network to it using wifi. I connected sucessfully >> but was unable to get ip6 address. My wifi worked fine with ip4 address. > >If your network offers IPv6 connectivity and you have IPv4 working, simply >adding > >inet6 autoconf > >to the hostname.$if file for the interface and running /etc/netstart $if >*should* take care of things. > >There are any number of other possible variations, but you do need some >'inet6' settings in there. > >- Peter > >-- >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: DMARC/DKIM and OpenBSD Mailinglists
Todd C. Miller : > I've disabled the From: rewriting Indeed it appeared too secure for OpenBSD...
Re: DMARC/DKIM and OpenBSD Mailinglists
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" I want to thank you for the From rewriting. And, opinion, glad for the feature I wish everyone will take advantage on it (eg. not using more to CC to personal accounts)
Re: Unable to get ip6 address
On Fri, Mar 15, 2024 at 03:32:48PM +, Pencilgon wrote: > I recently installed openbsd got everything working wifi etc. The problem > arises > when I tried to connect ip6 network to it using wifi. I connected sucessfully > but was unable to get ip6 address. My wifi worked fine with ip4 address. If your network offers IPv6 connectivity and you have IPv4 working, simply adding inet6 autoconf to the hostname.$if file for the interface and running /etc/netstart $if *should* take care of things. There are any number of other possible variations, but you do need some 'inet6' settings in there. - Peter -- 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: DMARC/DKIM and OpenBSD Mailinglists
On Wed, 13 Mar 2024 11:54:14 -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: > > 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. I've disabled the From: rewriting for now after complaints that it makes things a lot less usable. We'll try preserving messages as sent instead, which means that text/html parts will now be passed through (sorry). - todd
Unable to get ip6 address
Hello there, I recently installed openbsd got everything working wifi etc. The problem arises when I tried to connect ip6 network to it using wifi. I connected sucessfully but was unable to get ip6 address. My wifi worked fine with ip4 address. Thanks
Re: Minimum viable HW for OpenBSD
Supported hardware information is listed here: https://www.openbsd.org/plat.html Each platform's link provides further information. On Fri, Mar 15, 2024 at 9:44 AM Mizsei Zoltán wrote: > > Hi, > > I'd like to build a small, portable system, not entirely different from a so > called "cyberdeck". For this project I am actively looking for the minimum > viable HW which supports OBSD. I would like to get some hints, as so far I > was unable to find the perfect hw (maybe it doesn't even exists). > > My requirements are: > - low power consumption (battery powered) > - small in sizez > - ARM / ARM64 / RISC-V or something else > - CLI > - UART > - USB > - WiFi (ideally integrated, but can be usb attached aswell) > - replaceable storage (SD card, or similar) > - ideally some onboard storage (eMMC?) > - and ideally some kind of supported display output > > I would like to either reuse the enclosure of a small handheld device which > have a display and a keyboard or print an own one and source some > off-the-shelf components and get them somehow working together. > > I was looking at minimum viable computing and found RetroBSD/DiscoBSD [1,2], > they are BSD 2.x ports for various microcontrollers (100+ Mhz, 1-2MB RAM), > but they can't realistically support me in the modern world (USB, WiFi). > > I have also considered the various SBCs in "Zero" and "Nano" form-factor, but > i was unable to find any which won't cause me headache with the > non-upstreamed FDT [3], or they aren't fully supported yet by OBSD, or it is > impossible to source them anymore, or the bootloader is some vendored fork, > which a burden to update, etc. > > I was looking at Crystal Kolipe's article-series [4] regarding the PinePhone, > but the screen is not yet usable AFAIK... > > Could you point out a hardware for this kind of use-case? I would liek to > have something smaller than a regular-Pi SBC. > > Thank You very much! > > [1] https://github.com/RetroBSD/retrobsd/ > [2] https://github.com/chettrick/discobsd/ > [3] https://www.geniatech.com/product/xpi-3566-zero/ > [4] https://research.exoticsilicon.com/series/pinephone_openbsd/part_1/ > > --Z-- >
Minimum viable HW for OpenBSD
Hi, I'd like to build a small, portable system, not entirely different from a so called "cyberdeck". For this project I am actively looking for the minimum viable HW which supports OBSD. I would like to get some hints, as so far I was unable to find the perfect hw (maybe it doesn't even exists). My requirements are: - low power consumption (battery powered) - small in sizez - ARM / ARM64 / RISC-V or something else - CLI - UART - USB - WiFi (ideally integrated, but can be usb attached aswell) - replaceable storage (SD card, or similar) - ideally some onboard storage (eMMC?) - and ideally some kind of supported display output I would like to either reuse the enclosure of a small handheld device which have a display and a keyboard or print an own one and source some off-the-shelf components and get them somehow working together. I was looking at minimum viable computing and found RetroBSD/DiscoBSD [1,2], they are BSD 2.x ports for various microcontrollers (100+ Mhz, 1-2MB RAM), but they can't realistically support me in the modern world (USB, WiFi). I have also considered the various SBCs in "Zero" and "Nano" form-factor, but i was unable to find any which won't cause me headache with the non-upstreamed FDT [3], or they aren't fully supported yet by OBSD, or it is impossible to source them anymore, or the bootloader is some vendored fork, which a burden to update, etc. I was looking at Crystal Kolipe's article-series [4] regarding the PinePhone, but the screen is not yet usable AFAIK... Could you point out a hardware for this kind of use-case? I would liek to have something smaller than a regular-Pi SBC. Thank You very much! [1] https://github.com/RetroBSD/retrobsd/ [2] https://github.com/chettrick/discobsd/ [3] https://www.geniatech.com/product/xpi-3566-zero/ [4] https://research.exoticsilicon.com/series/pinephone_openbsd/part_1/ --Z--
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 2:02 PM Zé Loff via misc wrote: > > Hope this clears things up. > Ah, now I understand. Thank you! :-) -- chs
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 01:07:22PM +0100, Christer Solskogen via misc wrote:
> On Fri, Mar 15, 2024 at 11:43 AM Zé Loff via misc wrote:
>
> > Your cpu*.frequency lines show you that it does.
>
> In that case, what does hw.cpuspeed mean?
>
Jonathan Gray already told you that:
> > hw.cpuspeed is only updated when a set speed is selected by the kernel.
> > With turbo mode the hardware continually changes the speed without
> > notifying the kernel.
You have
cpu0: Enhanced SpeedStep 2693 MHz: speeds: 1701, 1700, 1600, 1500, 1400,
1300, 1200, 1100, 1000, 900, 800 MHz
on your dmesg, so you have a CPU that is meant to run at (up to)
1700MHz, but can go to 2700MHz in turbo mode.
The 1701Mhz speed ("normal max" + 1) is the speed that the kernel needs
to set to get it into turbo mode. So, when
hw.cpuspeed=1701
it means your CPU is running in turbo mode. If you or the kernel wants
to throttle it down to save power, hw.cpuspeed will change to something
lower.
As Jonathan said, when in turbo mode, the CPU it won't tell the kernel
about speed changes, but you can always get them from the
hw.sensors.cpu*.frequency readings. Which, incidentally, might not even
be the same for each CPU core, as they are throttled differently:
$ sysctl hw.sensors | grep frequency0
hw.sensors.cpu0.frequency0=245000.00 Hz
hw.sensors.cpu1.frequency0=27.00 Hz
hw.sensors.cpu2.frequency0=285000.00 Hz
hw.sensors.cpu3.frequency0=235000.00 Hz
Hope this clears things up.
Cheers
Zé
P.S.: I'm by no means whatsoever an authority on this matter. I'm
replying because you asked me directly.
--
Re: pf nat64 rule not matching
On 2024-03-15, Tobias Fiebig via misc wrote: > > Moin, >> # perform nat64 (NOT WORKING) >> pass in to 64:ff9b::/96 af-to inet from ($wan:0) > > Can you try if the same happens with a more specific rule (for > testing)? > > i.e.: > > pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96 > af-to inet from "actual IP on igc0"/32 "actual IP on igc0" is a good idea. If I try a similar rule without () using an interface with v4+v6 addresses, pfctl rejects it due to af mismatch. > I am suspecting that the missing inet6 may lead to some confusion. > Alternatively, remove the block rules; URPF may be an issue here, if > you lack a route for the /96. "match log(matches)" and "tcpdump -neipflog0" is your friend for figuring out which rules are used. I suspect the urpf too. Regarding the other rules and tests, the ::1 rule is wrong, packets outgoing on the network won't have a ::1 address, try "!received-on any", and packets sourced from the router itself won't hit the af-to rule so tests need to be from another machine (and probably best use different DNS servers not doing dns64 on the router).
Re: USB peripherals hang, nothing in messages
Interesting.. Laurence Tratt via misc : > This sounds to me like it might be due to USB stack performance problems, > though you'll at least want to give `dmesg` output so that those who better > understand this have a chance of helping. > > FWIW, there seem to be notable differences in USB performance on nominally > similar hardware with OpenBSD. Do you suggest to phisically (hub) separate peripherals from eg. storage devices for who is working in this kind of fashion? -Dan
Re: USB peripherals hang, nothing in messages
Thanks, this sounds about what I experience. On Linux kernel it complains about some sort of "potential EMI interference" when auto disabling USB ports, and then it complains that it cannot reenable it because it cannot enumerate the device and assign it an address or something. I am curious how it's possible to debug this on OpenBSD. Is there a way to enable debug level verbosity on drivers? /var/log/messages is so bareboned, almost spartan I would dare to put forth. On Fri, Mar 15, 2024 at 5:11 PM Laurence Tratt via misc wrote: > > 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? > > This sounds to me like it might be due to USB stack performance problems, > though you'll at least want to give `dmesg` output so that those who better > understand this have a chance of helping. > > FWIW, there seem to be notable differences in USB performance on nominally > similar hardware with OpenBSD. On an AMD 7900x w/MSI motherboard, I had > very few USB performance problems (though there were other non-USB issues). > On an Intel 13900k w/Asus motherboard I have frequent, significant, USB > performance problems. Every USB peripheral suffers from random disconnects, > particularly under load. This is most notable with USB sound and USB > webcam, which disconnect several times per hour, but the USB keyboard and > USB mouse are also sometimes affected (perhaps once a week, mostly the > mouse). > > I have absolutely no idea what the cause for this difference might be. The > CPU and motherboard differences might be significant or not, I don't know. > And it may, or may not, have any relation to the symptoms you're seeing. > > > Laurie >
Re: USB peripherals hang, nothing in messages
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? This sounds to me like it might be due to USB stack performance problems, though you'll at least want to give `dmesg` output so that those who better understand this have a chance of helping. FWIW, there seem to be notable differences in USB performance on nominally similar hardware with OpenBSD. On an AMD 7900x w/MSI motherboard, I had very few USB performance problems (though there were other non-USB issues). On an Intel 13900k w/Asus motherboard I have frequent, significant, USB performance problems. Every USB peripheral suffers from random disconnects, particularly under load. This is most notable with USB sound and USB webcam, which disconnect several times per hour, but the USB keyboard and USB mouse are also sometimes affected (perhaps once a week, mostly the mouse). I have absolutely no idea what the cause for this difference might be. The CPU and motherboard differences might be significant or not, I don't know. And it may, or may not, have any relation to the symptoms you're seeing. Laurie
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 11:43 AM Zé Loff via misc wrote: > Your cpu*.frequency lines show you that it does. In that case, what does hw.cpuspeed mean?
Saving UKC> list output
When you want to turn off a device on OpenBSD you can do it at boot time with manual `boot -c` command. (Can also be automated) After entering entering `boot -c` you get UKC> configuration prompt. I type `list` and get a nice list of all drivers I can disable with `disable mei` or disable `lpc`. But how do I get that list into a file so I can review it? Is there some way to do it? Thx!
Re: pf nat64 rule not matching
Moin,
> # perform nat64 (NOT WORKING)
> pass in to 64:ff9b::/96 af-to inet from ($wan:0)
Can you try if the same happens with a more specific rule (for
testing)?
i.e.:
pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96
af-to inet from "actual IP on igc0"/32
I am suspecting that the missing inet6 may lead to some confusion.
Alternatively, remove the block rules; URPF may be an issue here, if
you lack a route for the /96.
A minimal (== based on the default pf.conf) config working for me:
```
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
block return# block stateless traffic
pass# establish keep-state
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
pass in on vio0 inet6 from 2a06:d1c0:deac:1:d5:64:a115:1 to
2a06:d1c7:a:4764::/96 af-to inet from 193.104.168.184/29 random
```
With best regards,
Tobias
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 10:09:37AM +0100, Christer Solskogen via misc wrote: > On Fri, Mar 15, 2024 at 10:00 AM Jonathan Gray wrote: > > > > On Fri, Mar 15, 2024 at 08:49:14AM +0100, Christer Solskogen via misc wrote: > > > On Fri, Mar 15, 2024 at 1:15 AM Jonathan Gray wrote: > > > > > > > > > > > The 1MHz higher is the turbo setting. When speedstep speeds are shown > > > > in dmesg it is the highest. > > > > > > > > The sensors use cpu_hz_update_sensor(). > > > > > > > > > > I don't understand. dmesg says this: > > > cpu0: Intel(R) N95, 2693.79 MHz, 06-be-00, patch 0015 > > > > > > But hw.cpuspeed stays the same no matter what happens. > > > > your dmesg will have a "Enhanced SpeedStep" line, for example: > > cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2601, 2600, 2500, 2300, 2100, > > 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800, 600, 500 MHz > > > > hw.cpuspeed is only updated when a set speed is selected by the kernel. > > With turbo mode the hardware continually changes the speed without > > notifying the kernel. > > > > to force the lowest non-turbo mode > > > > sysctl hw.perfpolicy=manual > > sysctl hw.setperf=0 > > > > Ah, yes. > cpu0: Enhanced SpeedStep 2693 MHz: speeds: 1701, 1700, 1600, 1500, > 1400, 1300, 1200, 1100, 1000, 900, 800 MHz > > I wonder why it never reaches 2,6GHz. > Your cpu*.frequency lines show you that it does. --
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 10:00 AM Jonathan Gray wrote: > > On Fri, Mar 15, 2024 at 08:49:14AM +0100, Christer Solskogen via misc wrote: > > On Fri, Mar 15, 2024 at 1:15 AM Jonathan Gray wrote: > > > > > > > > The 1MHz higher is the turbo setting. When speedstep speeds are shown > > > in dmesg it is the highest. > > > > > > The sensors use cpu_hz_update_sensor(). > > > > > > > I don't understand. dmesg says this: > > cpu0: Intel(R) N95, 2693.79 MHz, 06-be-00, patch 0015 > > > > But hw.cpuspeed stays the same no matter what happens. > > your dmesg will have a "Enhanced SpeedStep" line, for example: > cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2601, 2600, 2500, 2300, 2100, > 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800, 600, 500 MHz > > hw.cpuspeed is only updated when a set speed is selected by the kernel. > With turbo mode the hardware continually changes the speed without > notifying the kernel. > > to force the lowest non-turbo mode > > sysctl hw.perfpolicy=manual > sysctl hw.setperf=0 > Ah, yes. cpu0: Enhanced SpeedStep 2693 MHz: speeds: 1701, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz I wonder why it never reaches 2,6GHz.
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 08:49:14AM +0100, Christer Solskogen via misc wrote: > On Fri, Mar 15, 2024 at 1:15 AM Jonathan Gray wrote: > > > > > The 1MHz higher is the turbo setting. When speedstep speeds are shown > > in dmesg it is the highest. > > > > The sensors use cpu_hz_update_sensor(). > > > > I don't understand. dmesg says this: > cpu0: Intel(R) N95, 2693.79 MHz, 06-be-00, patch 0015 > > But hw.cpuspeed stays the same no matter what happens. your dmesg will have a "Enhanced SpeedStep" line, for example: cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2601, 2600, 2500, 2300, 2100, 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800, 600, 500 MHz hw.cpuspeed is only updated when a set speed is selected by the kernel. With turbo mode the hardware continually changes the speed without notifying the kernel. to force the lowest non-turbo mode sysctl hw.perfpolicy=manual sysctl hw.setperf=0
Re: Confusion about hw.cpuspeed
On Fri, Mar 15, 2024 at 1:15 AM Jonathan Gray wrote: > > The 1MHz higher is the turbo setting. When speedstep speeds are shown > in dmesg it is the highest. > > The sensors use cpu_hz_update_sensor(). > I don't understand. dmesg says this: cpu0: Intel(R) N95, 2693.79 MHz, 06-be-00, patch 0015 But hw.cpuspeed stays the same no matter what happens.
