Re: premature end of data for lang/go package (mips64)
Den sön 11 dec. 2022 kl 17:42 skrev void : > Alternatively, is it feasible to build an amd64 vm and cross-compile > there, for mips64/octeon? I think it is. I think I have tried it for simpler stuff but unless I am very mistaken you just set GOARCH and fire off the build, then move the binary over. -- May the most significant bit of your life be positive.
Re: pf question - set skip on wildcards ?
Am 13.12.2022 06:02 schrieb J Doe:
set skip on { lo0, vif* }
in pf.conf(5) the GRAMMAR shows:
ifspec = ( [ "!" ] ( interface-name | interface-group ) ) |
"{" interface-list "}"
So you could do "set skip on { lo0 vif0 vif1 }" for explicit, or you
use interface-group, alas "set skip on vif". If that "one" interface
is e.g. vif7 within vif(4) this MIGHT go: "set skip on { vif !vif7 }".
HTH,
--
pb
pf question - set skip on wildcards ?
Hello,
I have a question regarding: set skip on in pf.conf(5).
I have a host that has a number of dynamic virtual interfaces. I don't
want my ruleset to apply to those interfaces, however, as they are
created and removed dynamically, I don't know what the numbers will be
assigned to those interfaces.
I'd like to use: set skip on, but I am uncertain as to whether I can use
shell globbing to list the interfaces I want to omit.
For example, for a virtual interface: vifn where n can be 0, 1, etc.,
I'd like to use:
set skip on { lo0, vif* }
...however, that is not mentioned in man pf.conf.
If this is not possible, is there a way I can invert this and specify
that the ruleset applies to _one_ interface ?
Thanks,
- J
rdist remove option and default behaviour
Hi, I wanted to clarify. In manpage for rdist I see that we can use option -o remove . remove Remove extraneous files. If a directory is being updated, any files that exist on the remote host that do not exist in the master directory are removed. This is useful for maintaining truly identical copies of directories. However, this seems to be the default anyway. If I specify "install /tmp/" and try to copy /tmp/test.file all the files in /tmp/ on the remote host will be wiped out and only test.file will remain there after copy. This behaviour seems to fit with "directory update" feature of "remove" (like if we do "install -o remove /tmp/"). Yet, "remove" was not specified above. Is my understanding of default behaviour correct? This how it supposed to be working?
Re: sysupgrade fails with "FAILED" when "verifying sets"?
On Mon, Dec 12, 2022 at 8:19 AM Stuart Henderson wrote: > > On 2022-12-12, Amit Kulkarni wrote: > > retry, and all should be ok. > > No, there is a problem with the files. > Sorry for that Robb and Stuart.
Re: sysupgrade fails with "FAILED" when "verifying sets"?
On 12/12/22 07:22, Why 42? The lists account. wrote: Hi All, Today sysupgrade failed for me, but I'm not sure why? Here's the output: [ ... ] There is a problem with the distribution network currently. Hopefully will be resolved soon. Doing a quick check, looks like only amd64 is broke..but of course, that's what you probably want. (good time to upgrade your other platforms!) Nick.
Re: make pppoe not update /etc/resolv.conf
On Tue, Dec 13, 2022 at 12:59:10PM +1100, Jonathan Gray wrote: It can be avoided by disabling resolvd. In /etc/rc.conf.local: resolvd_flags=NO Thank you! (for the explanation also) --
Re: make pppoe not update /etc/resolv.conf
On Tue, Dec 13, 2022 at 01:32:53AM +, void wrote: > Hi misc@ > > I'd like to have it so a pppoe FTTP connection doesn't automatically > obtain and apply the ISP's nameservers to /etc/resolv.conf. The machine > already runs unbound, so resolv.conf has loopback for ipv4 and ipv6 in > it. pppoe adds "nameserver isp.name.server.addr # resolvd: pppoe0" at > the top of /etc/resolv.conf > > I've looked in the man page for pppoe and it doesn't state how it gets > dns. Also checked hostname.if, resolv.conf & resolvd manpages. Where else > should I be looking? See https://marc.info/?l=openbsd-tech=163636889218212=2 which changed sys/net/if_spppsubr.c revision 1.188 date: 2021/11/10 15:04:26; author: bket; state: Exp; lines: +103 -8; commitid: XBZeo53mvivjEc3E; sppp(4) - support PPP IPCP extensions for DNS RFC 1877 extends the family of network control protocols for establishing and configuring the IPCP over PPP, defining the negotiation of primary and secondary DNS addresses. After negotiation, rtm_proposal() is used to send out DNS updates. Feedback from claudio@ and kn@. OK claudio@, kn@ The first release with this change was OpenBSD 7.1. It can be avoided by disabling resolvd. In /etc/rc.conf.local: resolvd_flags=NO > > The IPv4 range is "static" and I understand that the way IPs are delivered > here is the same ip (tied to the connection credentials) is applied > dynamically on authentication. dhcpd is not running, dhcpcd6 > is and has the ipv6only keyword. > > tia, > -- > >
make pppoe not update /etc/resolv.conf
Hi misc@ I'd like to have it so a pppoe FTTP connection doesn't automatically obtain and apply the ISP's nameservers to /etc/resolv.conf. The machine already runs unbound, so resolv.conf has loopback for ipv4 and ipv6 in it. pppoe adds "nameserver isp.name.server.addr # resolvd: pppoe0" at the top of /etc/resolv.conf I've looked in the man page for pppoe and it doesn't state how it gets dns. Also checked hostname.if, resolv.conf & resolvd manpages. Where else should I be looking? The IPv4 range is "static" and I understand that the way IPs are delivered here is the same ip (tied to the connection credentials) is applied dynamically on authentication. dhcpd is not running, dhcpcd6 is and has the ipv6only keyword. tia, --
Re: No
On 12 Dec 2022, at 2:31, Zé Loff wrote: On Sun, Dec 11, 2022 at 04:20:53PM -0800, Randall Gellens wrote: I have a Protectli box that is the router for my home network. The home network uses U-Verse to connect to the outside, and has separate Ethernet networks for servers, wired clients, and Wi-Fi IoT clients. U-Verse supplies their own box (a "Residential Gateway" or RG) that sits at the connection points. The RG throws a tantrum if it detects an internal router or multi-homed devices, so the OpenBSD box is set up as a transparent filtering bridge so the RG thinks all the devices are connected directly to it. The OpenBSD box has Ethernet ports for the U-Verse RG and one for the three internal networks, with pf filtering the packets. The /etc/hostname.if files provide an IP address for the interface for the server network and one for the Wi-Fi interface (these are on different networks). The /etc/hostname.if files for the U-Verse and wired client Ethernet ports have just a description. The Protectli was running (I think) OpenBSD 6.2, but suffered a disk failure and I couldn't find my backup, so I installed a fresh OpenBSD 7.2 on it and added the users and config files (I had current versions of those). The config files are pretty minimal: /etc/hostname.if files for the four Ethernet ports and the bridge, /etc/sysctl.conf to set net.inet.ip.forwarding=1, pf.conf for the rules. There aren't any other services running on the box (other boxes are used for DHCP, DNS, etc.). Initially, the server and Wi-Fi Ethernet ports had traffic and packets were routed between them, but there was no traffic on the wired clients nor U-Verse Ethernet ports, and no packets got between them. A client on Wi-Fi could ping a server and vice versa, and other servers could reach the OpenBSD box. But clients couldn't reach servers, and nothing could get outside. All interfaces looked right when viewed using ifconfig, and the bridge looked right (it was up and had the four interfaces). There were no errors during startup, nor when running netstart. Changing the /etc/hostname.if files for the U-Verse and client ports to add an 'inet' line with a dummy IP address made it all start working. Before, they just had a line with "description" and text. Questions: (1) I'd like to understand the interfaces worked without having IP addresses in OpenBSD 6 but not in OpenBSD 7. They showed as up and as part of the bridge, but no traffic. Without *at least* the applicable /etc/hostname.* files its hard to help you with this. FWIW, I have a 7.1 box with a similar setup that forwards packets adequately (bridging two vlan interfaces, with no IP addresses on the parent interfaces, the vlan interfaces or the bridge). Below are the /etc/hostname.* files as they are now (working). Originally, /etc/hostname.em1 and /etc/hostname.3 were: /etc/hostname.em1 (originally) description "U-Verse DSL" /etc/hostname.em3 (originally): description "Switch for clients" /etc/hostname.em0 and /etc/hostname.em2 did not need changes. Here are the files as they are now: /etc/hostname.em0 inet 192.168.98.1 255.255.255.0 NONE description "to talk to AP" inet alias 192.168.0.210 255.255.255.0 NONE description "factory fallback wireless AP" /etc/hostname.em1 inet 192.168.98.2 255.255.255.0 NONE description "U-Verse DSL" /etc/hostname.em2 inet 99.111.97.160 255.255.255.240 NONE description "Switch for servers" /etc/hostname.em3 inet 192.168.98.3 255.255.255.0 NONE description "Switch for clients" /etc/hostname.em3 inet 192.168.98.3 255.255.255.0 NONE description "Switch for clients" -bash-5.1$ more /etc/hostname.bridge0 add em0 add em1 add em2 add em3 timeout 0 rule pass in on em1 src ac:5d:10:80:7d:11 tag outside # pass on em0 # pass on em1 # pass on em2 # pass on em3 up The "rule pass in" line in the bridge is to add a tag to packets from the outside, because (at least in OpenBSD 6.2) the pf.conf rules saw the packets as coming from a different interface, so they weren't treated as coming from the outside. (2) Also, I have several old machines that can no longer SSH into the OpenBSD 7 box. They get an error "no hostkey alg". Is there an easy way to get the OpenBSD box to accept connections from older clients? Presumably I need to enable older key algorithms, but after hunting through the OpenSSH manual I can't see what I need to do. The packet rules block access to the OpenBSD box from outside. RSA was deprecated some time ago. Add HostKeyAlgorithms=+ssh-rsa PubkeyAcceptedAlgorithms=+ssh-rsa to /etc/ssh/sshd_config, or, better yet, change the clients' config to bring them up to speed (I understand it might not be feasible). Thank you, that worked, I appreciate it. (I know I need to update openssh on the old machines, but that's a big project, and the protectli box isn't accessible from the outside.) --Randall
Re: VMM FAQ - 802.11 Prevents Bridging?
Hi Cory, Just to clarify, bridging typically works from a wireless Access Point ie bridging a wirieless access point to an ethernet interface and vice versa that (should) work and is catered for in the 802.11 standard. however a wireless interface in station / client mode bridged to an ethernet interface requires propietary extensions (and as Stuart has pointed out wont work) if you need a layer 2 Wireless Connection to VMM I would suggest using a an ethernet port in VMM and plug the ethernet port into a propietary wireless Router / Client.. I can give you a steer off list but I dont want to decend into plugging a propietary solution ... I hope this helps Tom Smyth On Mon, 12 Dec 2022 at 22:35, Stuart Henderson wrote: > > On 2022-12-12, c0ry wrote: > > Hey folks, > > > > I noticed this line in the VMM FAQ ( > > https://www.openbsd.org/faq/faq16.html#VMMnet): > > > > "...the IEEE 802.11 standard prevents wireless interfaces from > > participating in network bridges." > > > > Just wanted to confirm what is meant by this - are we just trying to say > > that WDS isn't part of the standard and isn't supported? Does the standard > > actually "prevent" anything? Sorry if this is pedantic, I'm just curious. > > WDS is only partly standardised and doesn't always work cross-vendor; > also OpenBSD doesn't support it at all. > > > > -- > Please keep replies on the mailing list. > -- Kindest regards, Tom Smyth.
Re: premature end of data for lang/go package (mips64)
On Mon, Dec 12, 2022 at 08:52:28AM -, Stuart Henderson wrote: Or you maybe able to workaround by downloading the package and installing it from local atorage rather than over the network. Yes this worked. After downloading it, ran "pkg_add -v -v -m go-1.19.1p0.tgz" which installed it. many thanks, --
Re: VMM FAQ - 802.11 Prevents Bridging?
On 2022-12-12, c0ry wrote: > Hey folks, > > I noticed this line in the VMM FAQ ( > https://www.openbsd.org/faq/faq16.html#VMMnet): > > "...the IEEE 802.11 standard prevents wireless interfaces from > participating in network bridges." > > Just wanted to confirm what is meant by this - are we just trying to say > that WDS isn't part of the standard and isn't supported? Does the standard > actually "prevent" anything? Sorry if this is pedantic, I'm just curious. WDS is only partly standardised and doesn't always work cross-vendor; also OpenBSD doesn't support it at all. -- Please keep replies on the mailing list.
VMM FAQ - 802.11 Prevents Bridging?
Hey folks, I noticed this line in the VMM FAQ ( https://www.openbsd.org/faq/faq16.html#VMMnet): "...the IEEE 802.11 standard prevents wireless interfaces from participating in network bridges." Just wanted to confirm what is meant by this - are we just trying to say that WDS isn't part of the standard and isn't supported? Does the standard actually "prevent" anything? Sorry if this is pedantic, I'm just curious. Thanks!
Re: premature end of data for lang/go package (mips64)
On Mon, Dec 12, 2022 at 08:52:28AM -, Stuart Henderson wrote: This *shouldn't* break like this, but it's possible that if writing to the filesystem is very slow you have a timeout fetching the file. (The go package has a *lot* of small files and with the default mount options, creating a lot of new files on slow storage can take a very long time). The media sustains 11MB/s random write, as tested with dd but the blocksize was 1m. It's much slower with 4k or 512 bytes. But I know what you mean, having seen the problem with git clone and svn co on (other) usb2 snd sdmmc. Unfortunately there's no alternative to usb2 on this device. It might help to mount the filesystem holding /usr/local with the softdep flag. Softdeps are turned on for all filesystems apart from swap Or you maybe able to workaround by downloading the package and installing it from local atorage rather than over the network. Hadn't thought of looking for a local switch for pkg_add; thanks for the suggestion. --
Re: ex/vi 100% CPU when STDIN_FILENO set to O_NONBLOCK
Claudio Jeker wrote: > I think this is the wrong way around. The callers need to be fixed to pass > a blocking stdin to programs since that is what every unix utility > expects. What you propose it to fix every unix utility to have such a check > at the start of main. Sorry but no. That's right. non-blocking or non-canonical input methods are for use inside a program, and must not be actively passed to programs which (cannot) expect the situation.
Re: acpi0: state S3 unavailable on lenovo L13
PS: An update - I have updated the bios on the lenovo L13 gen 3 and, of course, it continues to give trouble. If anyone has one of these modern thinkpads and comes up with a magic combination of MS switches in the BIOS to switch off/on which allows S3 to work again, I would be very thankful if you let me know. There are a lot of options which seem to be hardwired to windows but they might play a role in this... Dunno... Thanks to everybody. Missatge de Mare Dedeu del dia ds., 10 de des. 2022 a les 19:44: > PS: Here dmesg after enabling the S3 "linux" function, I forgot it > > > MX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu3: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 10-way L2 cache, 12MB 64b/line 12-way L3 cache > cpu3: smt 1, core 4, package 0 > cpu4 at mainbus0: apid 16 (application processor) > cpu4: 12th Gen Intel(R) Core(TM) i7-1255U, 1597.06 MHz, 06-9a-04 > cpu4: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu4: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB > 64b/line 16-way L2 cache, 12MB 64b/line 12-way L3 cache > cpu4: smt 0, core 8, package 0 > cpu5 at mainbus0: apid 18 (application processor) > cpu5: 12th Gen Intel(R) Core(TM) i7-1255U, 1596.32 MHz, 06-9a-04 > cpu5: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu5: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB > 64b/line 16-way L2 cache, 12MB 64b/line 12-way L3 cache > cpu5: smt 0, core 9, package 0 > cpu6 at mainbus0: apid 20 (application processor) > cpu6: 12th Gen Intel(R) Core(TM) i7-1255U, 1596.32 MHz, 06-9a-04 > cpu6: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu6: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB > 64b/line 16-way L2 cache, 12MB 64b/line 12-way L3 cache > cpu6: smt 0, core 10, package 0 > cpu7 at mainbus0: apid 22 (application processor) > cpu7: 12th Gen Intel(R) Core(TM) i7-1255U, 1596.32 MHz, 06-9a-04 > cpu7: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu7: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB > 64b/line 16-way L2 cache, 12MB 64b/line 12-way L3 cache > cpu7: smt 0, core 11, package 0 > cpu8 at mainbus0: apid 24 (application processor) > cpu8: 12th Gen Intel(R) Core(TM) i7-1255U, 1596.33 MHz, 06-9a-04 > cpu8: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu8: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB > 64b/line 16-way L2 cache, 12MB
Re: snmp protocol error
Thanks for the detailed review Martijn, I'll follow up with the vendors and see if they can address the issue with a firmware update. On Sat, Dec 10, 2022, at 01:42, Martijn van Duren wrote: > On Fri, 2022-12-09 at 13:35 -0700, Byron Klippert wrote: >> On Fri, Dec 9, 2022, at 12:57, Stuart Henderson wrote: >> > On 2022-12-09, Byron Klippert wrote: >> > > Hello, >> > > >> > > I get an snmp protocol error response when attempting to `snmp get` >> > > certain OIDs on various devices. However `tcpdump` shows that the device >> > > is actually responding with the anticipated result but it appears snmp >> > > isn't able to parse the response correctly? Any suggestions on how to >> > > troubleshoot further are welcome. >> > > >> > > >> > > I'm requesting the mntrFreq OID which is formatted as such: >> > > Name: mntrFreq >> > > OID: .1.3.6.1.4.1.35833.12.3.1 >> > > MIB: DB7000-MIB >> > > Syntax: INTEGER32 (87100..108100) >> > > Access: read-only >> > > Status: current >> > > DefVal: >> > > Indexes: >> > > Descr: "mntr Freq" >> > >> > btw, the information in the mib file doesn't necessarily correspond >> > to what the device actually sends, "snmp get" doesn't care about the >> > mib file at all, just whether the pdu is correctly formatted. >> >> Yup, understood. I've seen a few half-baked snmp implementations in the wild >> to know the MIB docs are often only suggestions as to how devices actually >> respond. >> >> > >> > > imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* >> > > udp:paint-receiver:161 .1.3.6.1.4.1.35833.12.3.1.0 >> > > snmp: get: Protocol error >> > > >> > > imac:/home/admin $ doas tcpdump host paint-receiver >> > > tcpdump: listening on bge0, link-type EN10MB >> > > 10:10:02.804614 192.168.0.4.21246 > paint-receiver.snmp: C=*redacted* >> > > GetRequest(32) E:35833.12.3.1.0 >> > > 10:10:03.231863 paint-receiver.snmp > 192.168.0.4.21246: C=*redacted* >> > > GetResponse(40) E:35833.12.3.1.0=103500 >> > >> > It might be useful to use -X to do a hexdump (and maybe -s1500 to make >> > sure you get full packets); if you need to redact the snmp community >> > (although it probably doesn't really matter all that much seeing as >> > it's on a private lan address) make sure you get the hex digits too >> > >> > That way we can get a better idea of what's actually sent on the wire >> > >> > >> > -- >> > Please keep replies on the mailing list. >> >> imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 >> .1.3.6.1.4.1.35833.12.3.1.0 >> snmp: get: Protocol error >> >> imac:/home/admin $ clear; doas tcpdump -X -s1500 host paint-receiver >> tcpdump: listening on bge0, link-type EN10MB >> 13:23:16.478673 192.168.0.4.11162 > paint-receiver.snmp: C=*redacted* >> GetRequest(32) E:35833.12.3.1.0 >> : 4500 004d ce0a 4011 c0a8 0004 E..M@... >> 0010: c0a8 050c 2b9a 00a1 0039 aac2 302f 0201 +9..0/.. >> 0020: 0104 082a 2a2a 2a2a 2a2a 2aa0 2002 0428 .... ..( >> 0030: f7c4 fb02 0100 0201 0030 1230 1006 0c2b .0.0...+ >> 0040: 0601 0401 8297 790c 0301 0005 00 ..y.. >> >> 13:23:17.366836 paint-receiver.snmp > 192.168.0.4.11162: C=*redacted* >> GetResponse(40) E:35833.12.3.1.0=103500 >> : 4500 0059 f938 fd11 3dfa c0a8 050c E..Y.8=. >> 0010: c0a8 0004 00a1 2b9a 0045 c089 3082 0039 ..+..E..0..9 >> 0020: 0201 0104 082a 2a2a 2a2a 2a2a 2aa2 8200 .... >> 0030: 2802 0428 f7c4 fb02 0100 0201 0030 8200 (..(.0.. >> 0040: 1830 8200 1406 0c2b 0601 0401 8297 790c .0.+..y. >> 0050: 0301 0002 0400 0194 4c L > > The problem is here in the final 4 bytes: 0x0001944c, which is the int > value of the response (0x0204 is the integer preamble). > According to X.690 section 8.3.2: > If the contents octets of an integer value encoding consist of more than > one octet, then the bits of the first octet and bit 8 of the second > octet: > a) shall not all be ones; and > b) shall not all be zero. > NOTE - These rules ensure that an integer value is always encoded in the > smallest possible number of octets > > In this case the 1st byte is all zeroes, violating the rule. A check for > this was introduced to ber.c by rob@ to enforce this: > revision 1.5 > date: 2019/05/12 20:13:08; author: rob; state: Exp; lines: +9 -2; > commitid: 7FpdY7sgslPEOJU0; > Enforce smallest number of contents octets for int (and enum). > > ok claudio@ > > Although the additional byte(s) don't really hurt I'm not sure if > reverting this diff for a single misbehaving device is worth it. > Unless anyone thinks differently I think it'd be better to first > go to the vendor of your device and ask them to fix this. > > martijn@ >> >> >> And here's the OID that responds correctly... >> >> imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 >> .1.3.6.1.4.1.35833.12.2.10.1.0 >> enterprises.35833.12.2.10.1.0 = STRING: DB7000: Paint
Re: sysupgrade fails with "FAILED" when "verifying sets"?
On Mon, Dec 12, 2022 at 07:39:49AM -0600, Amit Kulkarni wrote: > retry, and all should be ok. What's the basis of your statement, did something change? It still fails for me (now @16:15 CET). I also tried a different mirror, same failure (below). @Stuart: Although sysupgrade output says that it fetched and used SHA256.sig, it appears only to save a file SHA256. That's why I tried using SHA256 on the signify command line :) Yours, Robb. > mjoelnir:_sysupgrade 12.12 16:13:38 # sysupgrade -s -n > Fetching from https://ftp.halifax.rwth-aachen.de/pub/OpenBSD/snapshots/amd64/ > SHA256.sig 100% > |*| > 2144 00:00 > Signature Verified > INSTALL.amd64 100% > || > 43554 00:00 > base72.tgz 100% > |*| >332 MB00:40 > bsd 100% > |*| > 22470 KB00:04 > bsd.mp 100% > |*| > 22578 KB00:02 > bsd.rd 100% > |*| > 4546 KB00:01 > comp72.tgz 100% > |*| > 75019 KB00:13 > game72.tgz 100% > |*| > 2745 KB00:00 > man72.tgz100% > |*| > 7610 KB00:01 > xbase72.tgz 100% > |*| > 52860 KB00:06 > xfont72.tgz 100% > |*| > 22967 KB00:03 > xserv72.tgz 100% > |*| > 14815 KB00:03 > xshare72.tgz 100% > |*| > 4573 KB00:01 > Verifying sets. > (SHA256) base72.tgz: FAILED > (SHA256) bsd: FAILED > (SHA256) bsd.mp: FAILED > (SHA256) bsd.rd: FAILED > (SHA256) comp72.tgz: FAILED > (SHA256) game72.tgz: FAILED > (SHA256) man72.tgz: FAILED > (SHA256) xbase72.tgz: FAILED > (SHA256) xfont72.tgz: FAILED > (SHA256) xserv72.tgz: FAILED > (SHA256) xshare72.tgz: FAILED > mjoelnir:_sysupgrade 12.12 16:15:17 [$?==1]# ls -l SHA256* > -rw-r--r-- 1 root wheel 1992 Dec 12 16:13 SHA256
Re: ex/vi 100% CPU when STDIN_FILENO set to O_NONBLOCK
On 2022-12-12 10:01:05 +0100, Claudio Jeker wrote: > I think this is the wrong way around. The callers need to be fixed to pass > a blocking stdin to programs since that is what every unix utility > expects. What you propose it to fix every unix utility to have such a check > at the start of main. Sorry but no. Ah, as it turns out the non-blocking of stdin was to workaround a bug in https://github.com/osa1/tiny/issues/269 https://github.com/microsoft/WSL/issues/3507 so I'll try to convince the tiny folks to only do that on WSL.
Re: sysupgrade fails with "FAILED" when "verifying sets"?
On 2022-12-12, Amit Kulkarni wrote: > retry, and all should be ok. No, there is a problem with the files. >> I have never really used signify before, but this command from the man >> page also generates an error: >> > mjoelnir:_sysupgrade 12.12 13:03:30 # signify -C -p >> > /etc/signify/openbsd-73-base.pub -x SHA256 >> > signify: invalid comment in SHA256; must start with 'untrusted comment: ' Should use SHA256.sig not SHA256. -- Please keep replies on the mailing list.
Re: sysupgrade fails with "FAILED" when "verifying sets"?
retry, and all should be ok. On Mon, Dec 12, 2022 at 7:18 AM Why 42? The lists account. wrote: > > > Hi All, > > Today sysupgrade failed for me, but I'm not sure why? Here's the output: > > # sysupgrade -s -n > > Fetching from http://ftp.fau.de/pub/OpenBSD/snapshots/amd64/ > > SHA256.sig 100% > > |***| > > 2144 00:00 > > Signature Verified > > Verifying old sets. > > base72.tgz 100% > > |***| > >332 MB00:28 > > bsd 100% > > |***| > > 22470 KB00:02 > > bsd.mp 100% > > |***| > > 22578 KB00:02 > > bsd.rd 100% > > |***| > > 4546 KB00:01 > > comp72.tgz 100% > > |***| > > 75019 KB00:07 > > game72.tgz 100% > > |***| > > 2745 KB00:00 > > man72.tgz100% > > |***| > > 7610 KB00:01 > > xbase72.tgz 100% > > |***| > > 52860 KB00:05 > > xfont72.tgz 100% > > |***| > > 22967 KB00:02 > > xserv72.tgz 100% > > |***| > > 14815 KB00:02 > > xshare72.tgz 100% > > |***| > > 4573 KB00:01 > > Verifying sets. > > (SHA256) base72.tgz: FAILED > > (SHA256) bsd: FAILED > > (SHA256) bsd.mp: FAILED > > (SHA256) bsd.rd: FAILED > > (SHA256) comp72.tgz: FAILED > > (SHA256) game72.tgz: FAILED > > (SHA256) man72.tgz: FAILED > > (SHA256) xbase72.tgz: FAILED > > (SHA256) xfont72.tgz: FAILED > > (SHA256) xserv72.tgz: FAILED > > (SHA256) xshare72.tgz: FAILED > > I see that the sha256 digests/checksums in "SHA256" differ from those of > the downloaded files: > > mjoelnir:_sysupgrade 12.12 13:02:53 [$?==1]# grep bsd.rd SHA256 > > SHA256 (bsd.rd) = > > 9065a190be5eaf047c1c0ece2517712e21964c17f39bebe3420aba2372c054ad > > mjoelnir:_sysupgrade 12.12 13:03:15 # sha256 bsd.rd > > SHA256 (bsd.rd) = > > 84ce928ccf6d71ebe5e7673aa198e424a9fdaf409d64723ba6dc8cd9333d9388 > > I don't know if that's the problem though ... > > I have never really used signify before, but this command from the man > page also generates an error: > > mjoelnir:_sysupgrade 12.12 13:03:30 # signify -C -p > > /etc/signify/openbsd-73-base.pub -x SHA256 > > signify: invalid comment in SHA256; must start with 'untrusted comment: ' > > That file starts like this: > > mjoelnir:_sysupgrade 12.12 13:05:09 # head SHA256 > > SHA256 (BOOTIA32.EFI) = > > e05572dc89a5c2c1ac53962cbf6fecda01dad0d4330d95a27e2d645a63b92d6e > > SHA256 (BOOTX64.EFI) = > > c9cf5ec60caba47c4b4ad0dc37dc88409ff9b5adb38814de1e35496759c2eed8 > > SHA256 (BUILDINFO) = > > 4d0249887ed7db9e9f336556c33a7e66024e08aeb5643f517b98c0815917529b > > ... > > Any suggestions? > > Cheers, > Robb. >
sysupgrade fails with "FAILED" when "verifying sets"?
Hi All, Today sysupgrade failed for me, but I'm not sure why? Here's the output: > # sysupgrade -s -n > Fetching from http://ftp.fau.de/pub/OpenBSD/snapshots/amd64/ > SHA256.sig 100% > |***| > 2144 00:00 > Signature Verified > Verifying old sets. > base72.tgz 100% > |***| >332 MB00:28 > bsd 100% > |***| > 22470 KB00:02 > bsd.mp 100% > |***| > 22578 KB00:02 > bsd.rd 100% > |***| > 4546 KB00:01 > comp72.tgz 100% > |***| > 75019 KB00:07 > game72.tgz 100% > |***| > 2745 KB00:00 > man72.tgz100% > |***| > 7610 KB00:01 > xbase72.tgz 100% > |***| > 52860 KB00:05 > xfont72.tgz 100% > |***| > 22967 KB00:02 > xserv72.tgz 100% > |***| > 14815 KB00:02 > xshare72.tgz 100% > |***| > 4573 KB00:01 > Verifying sets. > (SHA256) base72.tgz: FAILED > (SHA256) bsd: FAILED > (SHA256) bsd.mp: FAILED > (SHA256) bsd.rd: FAILED > (SHA256) comp72.tgz: FAILED > (SHA256) game72.tgz: FAILED > (SHA256) man72.tgz: FAILED > (SHA256) xbase72.tgz: FAILED > (SHA256) xfont72.tgz: FAILED > (SHA256) xserv72.tgz: FAILED > (SHA256) xshare72.tgz: FAILED I see that the sha256 digests/checksums in "SHA256" differ from those of the downloaded files: > mjoelnir:_sysupgrade 12.12 13:02:53 [$?==1]# grep bsd.rd SHA256 > > SHA256 (bsd.rd) = > 9065a190be5eaf047c1c0ece2517712e21964c17f39bebe3420aba2372c054ad > mjoelnir:_sysupgrade 12.12 13:03:15 # sha256 bsd.rd > > SHA256 (bsd.rd) = > 84ce928ccf6d71ebe5e7673aa198e424a9fdaf409d64723ba6dc8cd9333d9388 I don't know if that's the problem though ... I have never really used signify before, but this command from the man page also generates an error: > mjoelnir:_sysupgrade 12.12 13:03:30 # signify -C -p > /etc/signify/openbsd-73-base.pub -x SHA256 > signify: invalid comment in SHA256; must start with 'untrusted comment: ' That file starts like this: > mjoelnir:_sysupgrade 12.12 13:05:09 # head SHA256 > SHA256 (BOOTIA32.EFI) = > e05572dc89a5c2c1ac53962cbf6fecda01dad0d4330d95a27e2d645a63b92d6e > SHA256 (BOOTX64.EFI) = > c9cf5ec60caba47c4b4ad0dc37dc88409ff9b5adb38814de1e35496759c2eed8 > SHA256 (BUILDINFO) = > 4d0249887ed7db9e9f336556c33a7e66024e08aeb5643f517b98c0815917529b > ... Any suggestions? Cheers, Robb.
Re: No
On Sun, Dec 11, 2022 at 04:20:53PM -0800, Randall Gellens wrote: > I have a Protectli box that is the router for my home network. The home > network uses U-Verse to connect to the outside, and has separate Ethernet > networks for servers, wired clients, and Wi-Fi IoT clients. U-Verse supplies > their own box (a "Residential Gateway" or RG) that sits at the connection > points. The RG throws a tantrum if it detects an internal router or > multi-homed devices, so the OpenBSD box is set up as a transparent filtering > bridge so the RG thinks all the devices are connected directly to it. The > OpenBSD box has Ethernet ports for the U-Verse RG and one for the three > internal networks, with pf filtering the packets. The /etc/hostname.if files > provide an IP address for the interface for the server network and one for > the Wi-Fi interface (these are on different networks). The /etc/hostname.if > files for the U-Verse and wired client Ethernet ports have just a > description. > > The Protectli was running (I think) OpenBSD 6.2, but suffered a disk failure > and I couldn't find my backup, so I installed a fresh OpenBSD 7.2 on it and > added the users and config files (I had current versions of those). The > config files are pretty minimal: /etc/hostname.if files for the four > Ethernet ports and the bridge, /etc/sysctl.conf to set > net.inet.ip.forwarding=1, pf.conf for the rules. There aren't any other > services running on the box (other boxes are used for DHCP, DNS, etc.). > > Initially, the server and Wi-Fi Ethernet ports had traffic and packets were > routed between them, but there was no traffic on the wired clients nor > U-Verse Ethernet ports, and no packets got between them. A client on Wi-Fi > could ping a server and vice versa, and other servers could reach the > OpenBSD box. But clients couldn't reach servers, and nothing could get > outside. All interfaces looked right when viewed using ifconfig, and the > bridge looked right (it was up and had the four interfaces). There were no > errors during startup, nor when running netstart. > > Changing the /etc/hostname.if files for the U-Verse and client ports to add > an 'inet' line with a dummy IP address made it all start working. Before, > they just had a line with "description" and text. > > Questions: > > (1) I'd like to understand the interfaces worked without having IP addresses > in OpenBSD 6 but not in OpenBSD 7. They showed as up and as part of the > bridge, but no traffic. Without *at least* the applicable /etc/hostname.* files its hard to help you with this. FWIW, I have a 7.1 box with a similar setup that forwards packets adequately (bridging two vlan interfaces, with no IP addresses on the parent interfaces, the vlan interfaces or the bridge). > (2) Also, I have several old machines that can no longer SSH into the > OpenBSD 7 box. They get an error "no hostkey alg". Is there an easy way to > get the OpenBSD box to accept connections from older clients? Presumably I > need to enable older key algorithms, but after hunting through the OpenSSH > manual I can't see what I need to do. The packet rules block access to the > OpenBSD box from outside. RSA was deprecated some time ago. Add HostKeyAlgorithms=+ssh-rsa PubkeyAcceptedAlgorithms=+ssh-rsa to /etc/ssh/sshd_config, or, better yet, change the clients' config to bring them up to speed (I understand it might not be feasible). > Thank you for any help, > > --Randall > --
Re: Need to add dummy IP addresses to interfaces in OpenBSD 7
On 2022-12-12, Randall Gellens wrote: > Changing the /etc/hostname.if files for the U-Verse and client ports to > add an 'inet' line with a dummy IP address made it all start working. > Before, they just had a line with "description" and text. > Questions: > > (1) I'd like to understand the interfaces worked without having IP > addresses in OpenBSD 6 but not in OpenBSD 7. They showed as up and as > part of the bridge, but no traffic. One possibility: They would need the word "up" as well as the description, otherwise the interface would remain inactive. Setting an IP or IPv6 address implicitly brings the interface up. (btw it's not "OpenBSD 7", it's "7.2", or "7.1", or whatever - the first digit doesn't mean anything special, they are just numbers raised by .1 each time). > (2) Also, I have several old machines that can no longer SSH into the > OpenBSD 7 box. They get an error "no hostkey alg". Is there an easy way > to get the OpenBSD box to accept connections from older clients? > Presumably I need to enable older key algorithms, but after hunting > through the OpenSSH manual I can't see what I need to do. The packet > rules block access to the OpenBSD box from outside. See https://www.openssh.com/legacy.html but particularly note "The best resolution for these failures is to upgrade the software at the other end and/or replace the weak key types with safer modern types. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak." If it's possible to update the ssh clients that would be better (there may be other important bugs fixed in them too; for example if any are using old versions of PuTTY there are sdcurity fixes in newer ones too). -- Please keep replies on the mailing list.
Re: ex/vi 100% CPU when STDIN_FILENO set to O_NONBLOCK
On Sun, Dec 11, 2022 at 04:10:41PM -0800, Jeremy Mates wrote:
> ...
> 42136 ex RET read -1 errno 35 Resource temporarily unavailable
> 42136 ex CALL read(0,0x3d94b585400,0xff)
> 42136 ex RET read -1 errno 35 Resource temporarily unavailable
> 42136 ex CALL read(0,0x3d94b585400,0xff)
> ...
>
> this condition can be reproduced with:
>
> #include
> #include
> #include
> #include
> #include
> #define TARGET_FD STDIN_FILENO
> int main(int argc, char *argv[]) {
> int flags, status;
> pid_t pid;
> pid = fork();
> if (pid < 0) err(1, "fork failed");
> if (pid == 0) {
> flags = fcntl(TARGET_FD, F_GETFL, 0);
> if (flags == -1) err(1, "fcntl getfl failed");
> flags |= O_NONBLOCK;
> flags = fcntl(TARGET_FD, F_SETFL, flags);
> if (flags == -1) err(1, "fcntl setfl failed");
> argv++;
> execvp(*argv, argv);
> err(1, "execvp failed");
> }
> wait();
> exit(0);
> }
>
> and then running whatever-the-above-was-compiled-to as
>
> ./whatever /usr/bin/ex
>
> or also under modern code that for some reason sets O_NONBLOCK and
> forgets to turn it off when calling out to an editor, hypothetically
>
> https://github.com/osa1/tiny
>
> and likely other, similar programs. Probably, O_NONBLOCK should be
> disabled on STDIN_FILENO before calling out to unknown programs.
> Probably, vi should be patched to not eat CPU when the previous case is
> not handled.
>
> Thoughts?
I think this is the wrong way around. The callers need to be fixed to pass
a blocking stdin to programs since that is what every unix utility
expects. What you propose it to fix every unix utility to have such a check
at the start of main. Sorry but no.
> diff --git usr.bin/vi/cl/cl_main.c usr.bin/vi/cl/cl_main.c
> index 33614c99594..f87a04cad8b 100644
> --- usr.bin/vi/cl/cl_main.c
> +++ usr.bin/vi/cl/cl_main.c
> @@ -54,7 +54,7 @@ main(int argc, char *argv[])
> CL_PRIVATE *clp;
> GS *gp;
> size_t rows, cols;
> - int rval;
> + int flags, oflags, rval;
> char *ttype;
>
> /* Create and initialize the global structure. */
> @@ -89,6 +89,14 @@ main(int argc, char *argv[])
> /* Ex wants stdout to be buffered. */
> (void)setvbuf(stdout, NULL, _IOFBF, 0);
>
> + /* Ensure blocking I/O to avoid 100% CPU on EAGAIN */
> + if ((flags = fcntl(STDIN_FILENO, F_GETFL, 0)) == -1)
> + exit (1);
> + oflags = flags;
> + flags &= ~O_NONBLOCK;
> + if (fcntl(STDIN_FILENO, F_SETFL, flags) == -1)
> + exit (1);
> +
> /* Start catching signals. */
> if (sig_init(gp, NULL))
> exit (1);
> @@ -102,6 +110,9 @@ main(int argc, char *argv[])
> /* Clean up the terminal. */
> (void)cl_quit(gp);
>
> + /* Restore flags */
> + fcntl(STDIN_FILENO, F_SETFL, oflags);
> +
> /*
>* XXX
>* Reset the O_MESG option.
>
--
:wq Claudio
Re: premature end of data for lang/go package (mips64)
On 2022-12-11, void wrote: > Hello misc@ > > I get the following error when trying to install go (for mips64/octeon): > > # pkg_add go > quirks-6.42 signed on 2022-10-08T21:12:07Z > Ustar > [http://cdn.openbsd.org/pub/OpenBSD/7.2/packages/mips64/go-1.19.1p0.tgz][go/pkg/openbsd_mips64/cmd/compile/internal/reflectdata.a]: > Premature end of archive > Adjusting sha for > /usr/local/go/pkg/openbsd_mips64/cmd/compile/internal/reflectdata.a from > /dvcLn8+FQ5qji2A6mxyIWODWY35KxCB9u4isEHanf0= to > 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= > pkg_add: Installation of go-1.19.1p0 failed, partial installation > recorded as partial-go-1.19.1p0 > > Changing /etc/installurl makes no difference. In addition to the above > CDN, I have tried > www.mirrorservice.org > mirrors.gethosted.online > mirror.laylo.io > > same result. > > How can I get around this problem? I'd like to avoid compiling on the > device itself because it has limited resources for that type of thing. > It is only this pkg with this problem. There are no connectivity issues. This *shouldn't* break like this, but it's possible that if writing to the filesystem is very slow you have a timeout fetching the file. (The go package has a *lot* of small files and with the default mount options, creating a lot of new files on slow storage can take a very long time). It might help to mount the filesystem holding /usr/local with the softdep flag. Or you maybe able to workaround by downloading the package and installing it from local atorage rather than over the network.
