Wayland/sway binary package available
Hi, In the latest amd64 packages snapshot there is now a #sway package (other arches will follow). Installing it allows you to try #Wayland on OpenBSD. Just run the provided startsway.sh script from a text console after stopping xenodm if X was running. See the sway(1) and sway(5) manual pages for details and /etc/sway/config for the default key bindings. For now only a few applications will display using Wayland natively. All others will use Xwayland(1) automatically. In particular the provided sway config will use xterm(1) as a terminal. Also note that there are several known limitations that you don't need to report again: - no pointer accelleration - no VT switching - keyboard and/or pointer dont work after suspend/resume This is to be considered as highly experimental and not production-ready. Try it at your own risks. -- Matthieu Herrb
Re: forwarding email to outlook,com fails
On Tue, Dec 5, 2023 at 10:27 AM F Bax wrote: > > A couple of email addresses on my OpenBSD server are forwarded to microsoft > domains. For quite some time; this has worked flawlessly. Recently > something changed. Now, an email sent from sendgrid.com to my server > results in a bounced message from outlook.com with this error. > > received-spf: Fail (protection.outlook.com: domain of > u3352509.wl010.sendgrid.net does not designate 64.140.xxx.yyy as permitted > sender) receiver=protection.outlook.com; client-ip=64.140.xxx.yyy; helo= > myserver.ca; > > Where xxx,yyy & myserver hide real values. > It seems outlook.com believes my server is "sending" email for sendgrid; > whereas originating server is valid and my server is just forwarding. > Anyone else encounter this situation; is there a way to resolve this? I would suspect that this is because you unwittingly are - if the email gets forwarded as is rather than changing the To: field in transit, the email goes out as "bounce+blahblahhardtofilterbulls...@u3352509.wl010.sendgrid.net" rather than something like "postmas...@myserver.ca", triggering Sendgrid's SPF protection. I'm guessing Outlook Online/MS364 is being more aggressive in SPF checks now. As for a way to resolve, that may depend on your MTA (base or one from ports? Not a safe assumption to make), but as I'm not doing this or using an MTA on OpenBSD, I'm not at a liberty to say. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
forwarding email to outlook,com fails
A couple of email addresses on my OpenBSD server are forwarded to microsoft domains. For quite some time; this has worked flawlessly. Recently something changed. Now, an email sent from sendgrid.com to my server results in a bounced message from outlook.com with this error. received-spf: Fail (protection.outlook.com: domain of u3352509.wl010.sendgrid.net does not designate 64.140.xxx.yyy as permitted sender) receiver=protection.outlook.com; client-ip=64.140.xxx.yyy; helo= myserver.ca; Where xxx,yyy & myserver hide real values. It seems outlook.com believes my server is "sending" email for sendgrid; whereas originating server is valid and my server is just forwarding. Anyone else encounter this situation; is there a way to resolve this?
Re: Microphone on Thinkpad X1 carbon 7th Gen
Corl3ss writes: > Hi everyone, > > > Everything but the microphone is working well on my Thinkpad X1 carbon 7th Gen > (20QD). > > I have reviewed [1] and [2] without solution. > Below some useful data. > > Do you have any solution or tips ? Did I missed something ? or is it just not > supported ? > > Thanks in advance for your help !! > > Grateful to the OpenBSD community :) > > > Corl3ss > > > [1] https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/install74.img > [2] https://jcs.org/2019/08/14/x1c7#openbsd-support-log > > == > # mixerctl > inputs.dac-2:3=112,112 > inputs.dac-0:1=112,112 > record.adc-0:1_mute=off > record.adc-0:1=252,252 > record.adc-2:3_mute=off > record.adc-2:3=252,252 > outputs.spkr_source=dac-2:3 > outputs.spkr_mute=off > outputs.spkr_eapd=on > outputs.spkr2_source=dac-0:1 > outputs.spkr2_mute=off > outputs.spkr2_boost=off > inputs.mic=85,85 > outputs.mic_dir=input-vr80 > outputs.hp_source=dac-0:1 > outputs.hp_mute=off > outputs.hp_boost=off > outputs.hp_eapd=on > record.adc-2:3_source=mic > record.adc-0:1_source=mic > outputs.mic_sense=unplugged > outputs.hp_sense=unplugged > outputs.spkr_muters=hp > outputs.master=112,112 > outputs.master.mute=off > outputs.master.slaves=dac-2:3,dac-0:1,spkr,spkr2,hp > record.volume=255,255 > record.volume.mute=off > record.volume.slaves=adc-0:1,adc-2:3 > record.enable=sysctl > > > = > /var/log/messages extract: > azalia0 at pci0 dev 31 function 3 "Intel 300 Series HD Audio" rev 0x11: msi > azalia0: codecs: Realtek ALC285, Intel/0x280b, using Realtek ALC285 > audio0 at azalia0 > > == > # pcidump -v (extract of audio items only) > 0:31:3: Intel 100 Series HD Audio > 0x: Vendor ID: 8086, Product ID: 9d70 > 0x0004: Command: 0106, Status: 0010 > 0x0008: Class: 04 Multimedia, Subclass: 03 HD Audio, > Interface: 00, Revision: 21 > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 20, > Cache Line Size: 00 > 0x0010: BAR mem 64bit addr: 0xef22/0x4000 > 0x0018: BAR empty () > 0x001c: BAR empty () > 0x0020: BAR mem 64bit addr: 0xef20/0x0001 > 0x0028: Cardbus CIS: > 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 > 0x0030: Expansion ROM Base Address: > 0x0038: > 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 > 0x0050: Capability 0x01: Power Management > State: D0 > 0x0060: Capability 0x05: Message Signalled Interrupts (MSI) > Enabled: yes > [...] > 0:31:3: Intel 300 Series HD Audio > 0x: Vendor ID: 8086, Product ID: 9dc8 > 0x0004: Command: 0006, Status: 0010 > 0x0008: Class: 04 Multimedia, Subclass: 03 HD Audio, > Interface: 80, Revision: 11 > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, > Cache Line Size: 00 > 0x0010: BAR mem 64bit addr: 0xea23c000/0x4000 > 0x0018: BAR empty () > 0x001c: BAR empty () > 0x0020: BAR mem 64bit addr: 0xea00/0x0010 > 0x0028: Cardbus CIS: > 0x002c: Subsystem Vendor ID: 17aa Product ID: 2292 > 0x0030: Expansion ROM Base Address: > 0x0038: > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > 0x0050: Capability 0x01: Power Management > State: D0 > 0x0080: Capability 0x09: Vendor Specific > 0x0060: Capability 0x05: Message Signalled Interrupts (MSI) > Enabled: yes Have you enabled the appropriate sysctl ? (see: https://www.openbsd.org/faq/faq13.html#recordaudio) # sysctl kern.audio.record=1 # echo kern.audio.record=1 >> /etc/sysctl.conf Cheers, Carsten
Re: efiboot: change default partition from hd0a
> you may have to compile your own bootloader. you just need someone to give > you the patch needed to default you to partition l. Thanks for the suggestion! I dug through the code and changed the default partition myself. In case anyone is looking for it, it is in devboot() function: /usr/src/sys/arch/amd64/stand/efiboot/dev_i386.c > I looked at the .so file that builds the .EFI and I didn't see anything about > msdos file system. I only saw things like: cd9660 nfs ufs ufs2 tftp. It may > be possible if you compiled in msdos support to read in your config from your > EFI partition. I would like that feature. Interesting observation. I will try to look further into this possibility as well. -Johnathan
Re: 7.4 pfsync possible state update loop?
> On 4. Dec 2023, at 10:59, Stuart Henderson wrote: > > On 2023-12-01, Christian Gut wrote: >> Hi List, >> >> I just updated two carp/pfsync firewalls from 7.3 to 7.4. After updating the >> second box I see a massive increase in traffic on the sync interface. I now >> reproduced this with another pair of firewalls - same thing. >> >> Both firewall have three physical interfaces: external, internal and sync. >> Sync interface is connected via ethernet cable directly. Syncinterface has >> an ip address. >> >> Configuration of hostname.pfsync0: >> syncdev em2 >> up >> >> The way I updated these boxes, lets call them primary and secondary: >> >> 1. update secondary to 7.4, including the change in hostname.pfsync0 >> 2. change hostname.carp0 to promote to master - reboot >> 3. secondary is now master >> 4. update primary to 7.4 >> => traffic on syncif increases >> >> I tried so far - without any improvements: >> - reboot both machines after another >> - promote primary again >> - ifconfig pfsync0 down; pfctl -F states; ifconfig pfsync0 up > > When you tried down/flush/up did you do it on both firewalls at the same > time? (i.e. down pfsync on both, then flush on both, then up pfsync)? I did this only on the slave, as doing it on the master firewall would affect production. > >> I think they might see some kind of loop updating the states between each >> other. Could someone point me to how I could diagnose further? > > pfsync was largely rewritten between 7.3 and 7.4, we found one problem > like this but it was fixed before release. > > Best way to proceed is probably to capture traffic on the pfsync > interface with tcpdump and see if it relates to any particular state/s > and if there's anything special about them or the rules that generate > them. > > bugs@ might be a better place than misc@ to continue this. I will try to gather more input and send it to bugs@ - thanks.
Re: Scanning (documents) no longer works: scanner not found?
On Mon, Dec 04, 2023 at 05:48:55PM +0100, Why 42? The lists account. wrote: > > Hi All, > > I just noticed that "simple-scan" no longer works, it cannot find my > scanner. This used to work just fine. > > I'm running the latest (installed today) snapshot, but I don't know when > this stopped working - I try not to do much scanning :-) > > The scanner is a Canon Pixma "Multi Function" device, connected via > Ethernet. (I never ever got it to print.) How did simple-scan find the scanner? Is the IP address hardcoded somewhere in its config? Maybe the printer/scanner got a different IP from the DHCP server. (BTW, this is a very good reason for NOT putting network printers with dynamic IPs. I've seen one instance of Windows having 7 or 8 different "copies" of the same printer, all automatically setup each time the printer got a different address, and the user then had to go round-robin trying to figure out which was the IP-of-the-day.) > > Running simple-scan in debug mode doesn't show me much, I see: > > simple-scan -d > > [+0.00s] DEBUG: simple-scan.vala:2015: Starting simple-scan 44.0, PID=91216 > > [+0.01s] DEBUG: unsetenv() is not thread-safe and should not be used after > > threads are created > > [+0.04s] DEBUG: _g_io_module_get_default: Found default implementation gvfs > > (GDaemonVfs) for ‘gio-vfs’ > > [+0.18s] DEBUG: Portal not found: > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > > org.freedesktop.portal.Desktop was not provided by any .service files > > [+0.18s] DEBUG: Portal not found: > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > > org.freedesktop.portal.Desktop was not provided by any .service files > > [+0.18s] DEBUG: Portal not found: > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > > org.freedesktop.portal.Desktop was not provided by any .service files > > [+0.18s] DEBUG: _g_io_module_get_default: Found default implementation > > dconf (DConfSettingsBackend) for ‘gsettings-backend’ > > [+0.18s] WARNING: Using GtkSettings:gtk-application-prefer-dark-theme > > together with HdyStyleManager is unsupported. Please use > > HdyStyleManager:color-scheme instead. > > [+0.66s] DEBUG: app-window.vala:2002: Loading state from > > /home/robb/.config/simple-scan/state > > [+0.66s] DEBUG: app-window.vala:1981: Restoring window to 1002x1235 pixels > > [+0.72s] DEBUG: scanner.vala:1619: sane_init () -> SANE_STATUS_GOOD > > [+0.72s] DEBUG: scanner.vala:1625: SANE version 1.2.1 > > [+0.72s] DEBUG: scanner.vala:1686: Requesting redetection of scan devices > > [+0.72s] DEBUG: scanner.vala:863: Processing request > > [+0.86s] DEBUG: app-window.vala:2078: Saving state to > > /home/robb/.config/simple-scan/state > > [+2.67s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD > > [+2.67s] DEBUG: platform does not do hotplug, using polling > > ... > > I have the saned daemon running, it seems to run OK. No matter what I > tried I have been unable to trick it into logging any debug output e.g. > even with "-d 32" I just see this logged: > > mjoelnir:log 4.12 17:10:14 # grep sane * > > messages:Dec 4 10:02:07 mjoelnir pkg_add: Added > > sane-backends-1.2.1p0->1.2.1p0 > > messages:Dec 4 16:58:31 mjoelnir pkg_add: Added xsane-0.999p7 saned is for sharing a local scanner to over the network (i.e. as a server, not as a client). I don't think you need it. > (The second message is me adding xsane, but it also fails to find the > scanner.) > > The README "sane-backends" ends with this cryptic (to me) advice, but > I don't know what a "scanner device node" is for a thing with an IP > address: > > ... > > NETWORK > > === > > By default, the saned(8) daemon runs as _saned, so you need to allow the > > _saned user access to the scanner device node. Yes, this is for local (scsi/parallel/usb/etc) devices. > What am I missing? Any tips for me? According to the SANE project's webpage, your device is probably supported by the pixma backend (you don't specify the model, so I can't be sure). This means that, in theory, all you need is to enable it in /etc/sane.d/dll.conf, by making sure it is uncommented. You can comment everything else in there. /etc/sane.d/pixma.conf configures the backend itself. Defaults should be enough for most cases but, as the comments in the file state, network detection is none via broadcast, so both the scanner and your machine must be on the same subnet. Otherwise you need to specify the scanner's address. "scanimage -L" should find it. Otherwise, I've had success in the past with a networked epson multifunction device by using xsane like this: xsane epson2:net:10.17.18.40 where 10.17.18.40 is the IP address of the scanner. Best of luck. Cheers Zé > (Oh, I also tried "pfctl -d" to disable the local firewall, didn't seem > to make any difference.) > > Cheers, > Robb. > > mjoelnir:/etc 4.12 17:14:41 # uname -a > OpenBSD mjoelnir.fritz.box 7.4 GENERIC.MP#1471 amd64
Microphone on Thinkpad X1 carbon 7th Gen
Hi everyone, Everything but the microphone is working well on my Thinkpad X1 carbon 7th Gen (20QD). I have reviewed [1] and [2] without solution. Below some useful data. Do you have any solution or tips ? Did I missed something ? or is it just not supported ? Thanks in advance for your help !! Grateful to the OpenBSD community :) Corl3ss [1] https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/install74.img [2] https://jcs.org/2019/08/14/x1c7#openbsd-support-log == # mixerctl inputs.dac-2:3=112,112 inputs.dac-0:1=112,112 record.adc-0:1_mute=off record.adc-0:1=252,252 record.adc-2:3_mute=off record.adc-2:3=252,252 outputs.spkr_source=dac-2:3 outputs.spkr_mute=off outputs.spkr_eapd=on outputs.spkr2_source=dac-0:1 outputs.spkr2_mute=off outputs.spkr2_boost=off inputs.mic=85,85 outputs.mic_dir=input-vr80 outputs.hp_source=dac-0:1 outputs.hp_mute=off outputs.hp_boost=off outputs.hp_eapd=on record.adc-2:3_source=mic record.adc-0:1_source=mic outputs.mic_sense=unplugged outputs.hp_sense=unplugged outputs.spkr_muters=hp outputs.master=112,112 outputs.master.mute=off outputs.master.slaves=dac-2:3,dac-0:1,spkr,spkr2,hp record.volume=255,255 record.volume.mute=off record.volume.slaves=adc-0:1,adc-2:3 record.enable=sysctl = /var/log/messages extract: azalia0 at pci0 dev 31 function 3 "Intel 300 Series HD Audio" rev 0x11: msi azalia0: codecs: Realtek ALC285, Intel/0x280b, using Realtek ALC285 audio0 at azalia0 == # pcidump -v (extract of audio items only) 0:31:3: Intel 100 Series HD Audio 0x: Vendor ID: 8086, Product ID: 9d70 0x0004: Command: 0106, Status: 0010 0x0008: Class: 04 Multimedia, Subclass: 03 HD Audio, Interface: 00, Revision: 21 0x000c: BIST: 00, Header Type: 00, Latency Timer: 20, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xef22/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR mem 64bit addr: 0xef20/0x0001 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management State: D0 0x0060: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: yes [...] 0:31:3: Intel 300 Series HD Audio 0x: Vendor ID: 8086, Product ID: 9dc8 0x0004: Command: 0006, Status: 0010 0x0008: Class: 04 Multimedia, Subclass: 03 HD Audio, Interface: 80, Revision: 11 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xea23c000/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR mem 64bit addr: 0xea00/0x0010 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 2292 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management State: D0 0x0080: Capability 0x09: Vendor Specific 0x0060: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: yes
Scanning (documents) no longer works: scanner not found?
Hi All, I just noticed that "simple-scan" no longer works, it cannot find my scanner. This used to work just fine. I'm running the latest (installed today) snapshot, but I don't know when this stopped working - I try not to do much scanning :-) The scanner is a Canon Pixma "Multi Function" device, connected via Ethernet. (I never ever got it to print.) Running simple-scan in debug mode doesn't show me much, I see: > simple-scan -d > [+0.00s] DEBUG: simple-scan.vala:2015: Starting simple-scan 44.0, PID=91216 > [+0.01s] DEBUG: unsetenv() is not thread-safe and should not be used after > threads are created > [+0.04s] DEBUG: _g_io_module_get_default: Found default implementation gvfs > (GDaemonVfs) for ‘gio-vfs’ > [+0.18s] DEBUG: Portal not found: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.freedesktop.portal.Desktop was not provided by any .service files > [+0.18s] DEBUG: Portal not found: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.freedesktop.portal.Desktop was not provided by any .service files > [+0.18s] DEBUG: Portal not found: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.freedesktop.portal.Desktop was not provided by any .service files > [+0.18s] DEBUG: _g_io_module_get_default: Found default implementation dconf > (DConfSettingsBackend) for ‘gsettings-backend’ > [+0.18s] WARNING: Using GtkSettings:gtk-application-prefer-dark-theme > together with HdyStyleManager is unsupported. Please use > HdyStyleManager:color-scheme instead. > [+0.66s] DEBUG: app-window.vala:2002: Loading state from > /home/robb/.config/simple-scan/state > [+0.66s] DEBUG: app-window.vala:1981: Restoring window to 1002x1235 pixels > [+0.72s] DEBUG: scanner.vala:1619: sane_init () -> SANE_STATUS_GOOD > [+0.72s] DEBUG: scanner.vala:1625: SANE version 1.2.1 > [+0.72s] DEBUG: scanner.vala:1686: Requesting redetection of scan devices > [+0.72s] DEBUG: scanner.vala:863: Processing request > [+0.86s] DEBUG: app-window.vala:2078: Saving state to > /home/robb/.config/simple-scan/state > [+2.67s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD > [+2.67s] DEBUG: platform does not do hotplug, using polling > ... I have the saned daemon running, it seems to run OK. No matter what I tried I have been unable to trick it into logging any debug output e.g. even with "-d 32" I just see this logged: > mjoelnir:log 4.12 17:10:14 # grep sane * > messages:Dec 4 10:02:07 mjoelnir pkg_add: Added > sane-backends-1.2.1p0->1.2.1p0 > messages:Dec 4 16:58:31 mjoelnir pkg_add: Added xsane-0.999p7 (The second message is me adding xsane, but it also fails to find the scanner.) The README "sane-backends" ends with this cryptic (to me) advice, but I don't know what a "scanner device node" is for a thing with an IP address: > ... > NETWORK > === > By default, the saned(8) daemon runs as _saned, so you need to allow the > _saned user access to the scanner device node. What am I missing? Any tips for me? (Oh, I also tried "pfctl -d" to disable the local firewall, didn't seem to make any difference.) Cheers, Robb. mjoelnir:/etc 4.12 17:14:41 # uname -a OpenBSD mjoelnir.fritz.box 7.4 GENERIC.MP#1471 amd64 mjoelnir:/etc 4.12 17:14:46 # pkg_info | egrep '(scan|sane)' arp-scan-1.10.0p1 ARP scanning and fingerprinting tool nmap-7.91p5 scan ports and fingerprint stack of network hosts py3-ruamel.yaml.clib-0.2.8 C based reader/scanner and emitter for ruamel.yaml sane-backends-1.2.1p0 API for accessing scanners, backends simple-scan-44.0p0 simple scanning utility unpaper-7.0.0 post-processing tool for scanned paper sheets xsane-0.999p7 scanner frontend for SANE mjoelnir:/etc 4.12 17:15:55 # ps aux | grep sane root 55249 0.0 0.0 880 1236 ?? S 4:36PM0:00.07 /usr/local/libexec/saned -a -d 32 root 5814 0.0 0.0 3956 2016 p1 R+/25:15PM0:00.00 grep sane (zsh) robb 24135 0.0 0.0 1628 2656 p3 I+p11:52AM0:00.01 less sane-backends
Re: Realtek 8723BE unsupported
On Dec 04 11:16:04, da...@gwynne.id.au wrote: > On Sun, Dec 03, 2023 at 06:02:03PM +0100, Jan Stary wrote: > > (please keep replies on the list) > > > > On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote: > > > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote: > > > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below). > > > > Everything works, except the wifi seems to be unsupported: > > > > > > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured > > > > > > What does pcidump -v show? > > > > First of all, pcidump -v (but not pcidump) fucks up re(4): > > > > rgephy0 detached > > re0 detached > > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU > > (0x5080), msi, address 7c:d3:0a:21:eb:f5 > > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > > re0: cannot create re-stats kstat > > rgephy0 detached > > re0 detached > > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU > > (0x5080), msi, address 7c:d3:0a:21:eb:f5 > > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > > re0: cannot create re-stats kstat > > > > Is anyone seeing that, i.e. devices detaching > > when they are being probed by pcidump? > > > > After doing the pcidump -v localy and rebooting to upload, I get this. > > Note that the Realtek 8168 entry seems mangled (related to the above?). > > pcidump causing a device to detach is a problem, but the kstat bit is a > separate problem too. > > the diff below consolidates the detach code in re(4) and adds the code > to tear the kstat down when the device goes away. With the diff, this is what messages say during pcidump -v: rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 So it seems re0 detaches and re-ataches. Understandably, it loses the IP address, re0: flags=8802 mtu 1500 lladdr 7c:d3:0a:21:eb:f5 index 5 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active but an /etc/netstart works as on boot and renews the dhcp lease. re0: flags=808843 mtu 1500 lladdr 7c:d3:0a:21:eb:f5 index 5 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.11.28 netmask 0xff00 broadcast 192.168.11.255 The diff in the actual pcidump output is indeed in the re section (see previous): @@ -303,10 +303,6 @@ Domain /dev/pci0: 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) Enabled: no; table size 4 (BAR 4:0) 0x00d0: Capability 0x03: Vital Product Data (VPD) - 00 - 00 - 00 - 00 7f: [|vpd] Anyway, why does re detach at all. And does this reveal anything about the original question Realtek 8723BE support? Jan Domain /dev/pci0: 0:0:0: Intel Core 6G Host 0x: Vendor ID: 8086, Product ID: 1904 0x0004: Command: 0106, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 08 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel HD Graphics 520 0x: Vendor ID: 8086, Product ID: 1916 0x0004: Command: 0007, Status: 0010 0x0008: Class: 03 Display, Subclass: 00 VGA, Interface: 00, Revision: 07 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xee00/0x0100 0x0018: BAR mem prefetchable 64bit addr: 0xd000/0x1000 0x0020: BAR io addr: 0xf000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x09: Vendor Specific 0x0070: Capability 0x10: PCI Express Max Payload Size: 128 / 128 bytes Max Read Request Size: 128 bytes 0x0100: Enhanced Capability 0x1b: Process Address Space ID 0x0200: Enhanced Capability 0x0f: Address Translation Services 0x0300: Enhanced Capability
Re: wired rdiff-backup doc
Ok, I will manage to do it thnx. -- Nowarez Market Dec 4, 2023 10:58:59 Michael Hekeler : > maybe to help other users of rdiff-backup you want to post your > experiences onn their mailing-list? > Or you can open an issue on github because that's what the devs > suggested.
Re: FAT names exceeding spec length
I limit myself to report the problem of my system. And the problem of OpenBSD in this case is the easie to let me lose the info contained in the filenames coming from Android. Then the fix doesn't depend on my attitude. == Nowarez Market Dec 4, 2023 11:59:23 Michael Hekeler : >>> To be honest I don't understand the problem you described. >> >> It is simple, when you come from Android (tested Android 11 tablet) with >> file names exceeding the FAT spec >> these are cut to 8.3 format in OpenBSD. > > > You mean android allows to create filenames >255 on FAT32? > Then you should report this non-compliance on android > (https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison#limits)
Re: FAT names exceeding spec length
> > To be honest I don't understand the problem you described. > > It is simple, when you come from Android (tested Android 11 tablet) with file > names exceeding the FAT spec > these are cut to 8.3 format in OpenBSD. You mean android allows to create filenames >255 on FAT32? Then you should report this non-compliance on android (https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison#limits)
Re: Realtek 8723BE unsupported
On Mon, Dec 04, 2023 at 11:16:04AM +1000, David Gwynne wrote:
> On Sun, Dec 03, 2023 at 06:02:03PM +0100, Jan Stary wrote:
> > (please keep replies on the list)
> >
> > On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote:
> > > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote:
> > > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below).
> > > > Everything works, except the wifi seems to be unsupported:
> > > >
> > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured
> > >
> > > What does pcidump -v show?
> >
> > First of all, pcidump -v (but not pcidump) fucks up re(4):
> >
> > rgephy0 detached
> > re0 detached
> > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU
> > (0x5080), msi, address 7c:d3:0a:21:eb:f5
> > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> > re0: cannot create re-stats kstat
> > rgephy0 detached
> > re0 detached
> > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU
> > (0x5080), msi, address 7c:d3:0a:21:eb:f5
> > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> > re0: cannot create re-stats kstat
> >
> > Is anyone seeing that, i.e. devices detaching
> > when they are being probed by pcidump?
> >
> > After doing the pcidump -v localy and rebooting to upload, I get this.
> > Note that the Realtek 8168 entry seems mangled (related to the above?).
>
> pcidump causing a device to detach is a problem, but the kstat bit is a
> separate problem too.
>
> the diff below consolidates the detach code in re(4) and adds the code
> to tear the kstat down when the device goes away.
Makes sense. One question below.
OK claudio@
> Index: ic/re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.216
> diff -u -p -r1.216 re.c
> --- ic/re.c 10 Nov 2023 15:51:20 - 1.216
> +++ ic/re.c 4 Dec 2023 01:03:30 -
> @@ -2608,6 +2630,27 @@ freedma:
> destroy:
> bus_dmamap_destroy(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
> free:
> + free(re_ks_sc, M_DEVBUF, sizeof(*re_ks_sc));
> +}
> +
> +void
> +re_kstat_detach(struct rl_softc *sc)
> +{
> + struct kstat *ks = sc->rl_kstat;
> + struct re_kstat_softc *re_ks_sc;
> +
> + if (ks == NULL)
> + return;
> +
> + kstat_remove(ks);
> + re_ks_sc = ks->ks_ptr;
> + kstat_destroy(ks);
> +
> + bus_dmamap_unload(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
> + bus_dmamem_unmap(sc->sc_dmat,
> + (caddr_t)re_ks_sc->re_ks_sc_stats, sizeof(struct re_stats));
> + bus_dmamem_free(sc->sc_dmat, _ks_sc->re_ks_sc_seg, 1);
Shouldn't this use re_ks_sc->re_ks_sc_nsegs?
Or actually why save re_ks_sc_nsegs when it is known to be 1?
It is just confusing to see a difference with re_kstat_attach() in this
regard.
> + bus_dmamap_destroy(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
> free(re_ks_sc, M_DEVBUF, sizeof(*re_ks_sc));
> }
> #endif /* NKSTAT > 0 */
--
:wq Claudio
Re: 7.4 pfsync possible state update loop?
On 2023-12-01, Christian Gut wrote: > Hi List, > > I just updated two carp/pfsync firewalls from 7.3 to 7.4. After updating the > second box I see a massive increase in traffic on the sync interface. I now > reproduced this with another pair of firewalls - same thing. > > Both firewall have three physical interfaces: external, internal and sync. > Sync interface is connected via ethernet cable directly. Syncinterface has an > ip address. > > Configuration of hostname.pfsync0: > syncdev em2 > up > > The way I updated these boxes, lets call them primary and secondary: > > 1. update secondary to 7.4, including the change in hostname.pfsync0 > 2. change hostname.carp0 to promote to master - reboot > 3. secondary is now master > 4. update primary to 7.4 >=> traffic on syncif increases > > I tried so far - without any improvements: > - reboot both machines after another > - promote primary again > - ifconfig pfsync0 down; pfctl -F states; ifconfig pfsync0 up When you tried down/flush/up did you do it on both firewalls at the same time? (i.e. down pfsync on both, then flush on both, then up pfsync)? > I think they might see some kind of loop updating the states between each > other. Could someone point me to how I could diagnose further? pfsync was largely rewritten between 7.3 and 7.4, we found one problem like this but it was fixed before release. Best way to proceed is probably to capture traffic on the pfsync interface with tcpdump and see if it relates to any particular state/s and if there's anything special about them or the rules that generate them. bugs@ might be a better place than misc@ to continue this.
Re: wired rdiff-backup doc
> Hello, > > 7.4, rdiff-backup > > After the upgrade to 7.4 I have been invited to update my > outdated command line to *the new one* by rdiff-backup. > > The puzzle was not so easy to solve as "rdiff-backup --new --help" > suggested a good mix of options; "man rdiff-backup" gave out an other > set of options and two examples, one with the [kind of operation] > declared just after rdiff-backup, the other one with the > [kind of operation] declared just after the option lists; a little > overwhelming: when you make a mistake the shell show off the *good > options* suggesting among the others --new, --nonew, etc (not > recognized) and missing to list all the various --except options among > the others. I save you from quoting the options listed by > "rdiff-backup backup --help". > > In the end after 10min of tries I was able to launch my > backup.. maybe to help other users of rdiff-backup you want to post your experiences onn their mailing-list? Or you can open an issue on github because that's what the devs suggested.
Re: efiboot: change default partition from hd0a
> This is not the end of the world, but it feels like it should be possible > to have a boot.conf somewhere other than the 'a' partition. Is it? you may have to compile your own bootloader. you just need someone to give you the patch needed to default you to partition l. steps: *apply your patch* cd /usr/src/sys/arch/amd64/stand/efiboot/bootx64 make doas make install doas installboot hd0 > Is it possible to have a conf file in the EFI partition alongside the > bootloader itself? I looked at the .so file that builds the .EFI and I didn't see anything about msdos file system. I only saw things like: cd9660 nfs ufs ufs2 tftp. It may be possible if you compiled in msdos support to read in your config from your EFI partition. I would like that feature. -alfred
