Re: Frequent isc-bind lookup failure (problem/solution)
> I run isc-bind as both a resolver and an authoritative name server in > a very simple configuration. > > Starting sometime during period I was running in OpeBSD 7.5, after one > of the updates (syspatch / pkg_add -u) something changed, manifested > as sporadic lookup failures (SERVFAIL) e.g.,: > > $ host anoncvs4.usa.openbsd.org. > anoncvs4.usa.openbsd.org has address 66.111.2.37 > anoncvs4.usa.openbsd.org has IPv6 address 2610:1c0:0:5::37 > Scratching my head, I started to wonder if isc-bind was trying to use > ipv6 to send out some of the queries, and then falling back to using > ipv4. I don't have any ipv6 uplink, nor any actual interfaces > configured for ipv6. The only ones I see are on lo0. Looking through > the isc-bind option list in named.conf(5) (so many options!) I > wondered if "query-source-v6 none;" might be "the drones I'm looking > for"(tm). Sure enough, it seems to have alleviated all these issues. > > A bit of a curious problem, which I thought I would share in case > anyone else finds themselves in a similar situation. > > Since I suspected my uplink to my ISP, I didn't keep track of queries, > so I can't say definitively, but I do wonder if these issues perhaps > coincided with OpenBSD deploying ipv6 and ipv6 authoritative servers? If you don't have ipv6 on any interface (except lo0), you would not have routes for ipv6, and hence bind should not even attempt to use v6. What does it look like if you ask the routing table for which interface to use to reach a v6 ip? A v6-connected host would say something like this: $ route get -inet6 2610:1c0:0:5::37 route to: 2610:1c0:0:5::37 destination: :: mask: :: gateway: 2a03:6000:6f65:626::1 [...] whereas a v4-only host says: $ route get -inet6 2610:1c0:0:5::37 get host 2610:1c0:0:5::37: not in table Still, the bug would be in isc-bind for trying to use v6 when its trivial to deduce it is not possible to use that protocol. -- May the most significant bit of your life be positive.
Re: aarch64 assembly "hello world"
On Fri, Mar 14, 2025 at 12:50:27PM +, jbra...@dismail.de wrote: > March 14, 2025 at 5:41 AM, "Computer Planet" mailto:open...@cpnetserver.net?to=%22Computer%20Planet%22%20%3Copenbsd%40cpnetserver.net%3E > > wrote: > > > > > > > Hi guys! > > Please, could someone tell me how to print a very simple "Hello, world!" in > > assembly for aarch64? > > Thanks for reply. > > > https://peterdn.com/post/2020/08/22/hello-world-in-arm64-assembly/ > This won't work. OpenBSD uses a different ABI than Linux. -Otto
Re: aarch64 assembly "hello world"
> Hmm, doesn't gcc/llvm have a command line flag to take a C file and output > assembly? > Maybe they could take the minimal hello.c file from that blog and run > > gcc --output-this-c-file-to-assembly hello.c -S, but the main problem on OpenBSD is not so much there as it is to build it into a valid ELF file with all the magics in it so it actually starts. Running clang with -v shows all flags used at the assembly and linking steps: $ cc -v -O2 -pipe -o hello hello2.s OpenBSD clang version 16.0.6 Target: aarch64-unknown-openbsd7.7 Thread model: posix InstalledDir: /usr/bin "/usr/bin/cc" -cc1as -triple aarch64-unknown-openbsd7.7 -filetype obj -main-file-name hello2.s -target-cpu generic -target-feature +neon -target-feature +v8a -target-feature +strict-align -fdebug-compilation-dir=/root/src/hello -dwarf-debug-producer "OpenBSD clang version 16.0.6" -dwarf-version=2 -mrelocation-model pic -o /tmp/hello2-a7ddcd.o hello2.s "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker /usr/libexec/ld.so -o hello /usr/lib/crt0.o /usr/lib/crtbegin.o -L/usr/lib /tmp/hello2-a7ddcd.o -lcompiler_rt -lc -lcompiler_rt /usr/lib/crtend.o I'm sure not all are 100% needed, but you still save a lot of time and effort if you let obsd use it's defaults. Perhaps someone can dream up a set of magic incantations to shorten this, but if your goal was really to code arm64 asm then doing it this way for a while should be enough to get you started. -- May the most significant bit of your life be positive.
Re: accented characters not showingutomatically started xterm:
Hello I did restart xenocara. It is the same. Bye
Re: Frequent isc-bind lookup failure (problem/solution)
On Fri, Mar 14, 2025 at 1:46 AM Janne Johansson wrote: > > > I run isc-bind as both a resolver and an authoritative name server in > > a very simple configuration. > > > > Starting sometime during period I was running in OpeBSD 7.5, after one > > of the updates (syspatch / pkg_add -u) something changed, manifested > > as sporadic lookup failures (SERVFAIL) e.g.,: > > > > $ host anoncvs4.usa.openbsd.org. > > anoncvs4.usa.openbsd.org has address 66.111.2.37 > > anoncvs4.usa.openbsd.org has IPv6 address 2610:1c0:0:5::37 > > > Scratching my head, I started to wonder if isc-bind was trying to use > > ipv6 to send out some of the queries, and then falling back to using > > ipv4. I don't have any ipv6 uplink, nor any actual interfaces > > configured for ipv6. The only ones I see are on lo0. Looking through > > the isc-bind option list in named.conf(5) (so many options!) I > > wondered if "query-source-v6 none;" might be "the drones I'm looking > > for"(tm). Sure enough, it seems to have alleviated all these issues. > > > > A bit of a curious problem, which I thought I would share in case > > anyone else finds themselves in a similar situation. > > > > Since I suspected my uplink to my ISP, I didn't keep track of queries, > > so I can't say definitively, but I do wonder if these issues perhaps > > coincided with OpenBSD deploying ipv6 and ipv6 authoritative servers? > > If you don't have ipv6 on any interface (except lo0), you would not > have routes for ipv6, and hence bind should not even attempt to use > v6. > What does it look like if you ask the routing table for which > interface to use to reach a v6 ip? > > A v6-connected host would say something like this: > > $ route get -inet6 2610:1c0:0:5::37 >route to: 2610:1c0:0:5::37 > destination: :: >mask: :: > gateway: 2a03:6000:6f65:626::1 > [...] > > whereas a v4-only host says: > $ route get -inet6 2610:1c0:0:5::37 > get host 2610:1c0:0:5::37: not in table $ route get -inet6 2610:1c0:0:5::37 get host 2610:1c0:0:5::37: not in table ISC bind is listening on lo0 interfaces: $ netstat -afinet6 -n | grep \\.53 tcp6 0 0 fe80::1%lo0.53 *.*LISTEN tcp6 0 0 ::1.53 *.*LISTEN udp6 0 0 fe80::1%lo0.53 *.* udp6 0 0 ::1.53 *.* > Still, the bug would be in isc-bind for trying to use v6 when its > trivial to deduce it is not possible to use that protocol. Does seem that way. I am uncertain whether this was introduced in some interim isc-bind version or if this behavior is a consequence of ipv6 NS being deployed. Time permitting I will try to look into this with isc-bind's site/mailing list(s). Cheers, --patrick
Re: CVS Web crippled
Am 14.03.2025 23:47 schrieb Nick Owens:
"fixed" it with robots.txt which the particular crawler ("claudebot")
respected. robots.txt:
Esp "claude" is known to me to be very ignorant of robots.txt (kinda
that way it is funny that it is downloading everything BUT robots.txt
...)
one can muse to block it - it's just all AWS ranges.. consider if your
USERs are sitting "behind" aws VMs (or their proxy...).
burn with fire..
--
pb
printf portability
Hi @misc, I recently stumbled upon an issue with GNU printf(1). I was using echo(1) in a testsuite.at on OpenBSD successfully, but that failed on linux badly. The OpenBSD man page of echo(1) contains this sentence: Where portability is paramount, use printf(1). So I replaced echo(1) with printf(1). This leads to... OpenBSD: x500$ printf -0 -0x500$ printf -something -somethingx500$ which is the expected output. On linux I get schulte@vps:~$ printf -0 -bash: printf: -0: invalid option printf: usage: printf [-v var] format [arguments] schulte@vps:~$ printf -something -bash: printf: -s: invalid option printf: usage: printf [-v var] format [arguments] Would you rate this a bug in GNU printf(1)? -- Christian
Re: aarch64 assembly "hello world"
If you do that it will just tell you to link call libc. Which works and is probably a good idea but might not be what he's looking for. --Stephen On Fri, Mar 14, 2025 at 03:06:17PM +, jbra...@dismail.de wrote: > March 14, 2025 at 10:08 AM, "Otto Moerbeek" mailto:o...@drijf.net?to=%22Otto%20Moerbeek%22%20%3Cotto%40drijf.net%3E > > wrote: > > > > > > > On Fri, Mar 14, 2025 at 12:50:27PM +, jbra...@dismail.de wrote: > > > > > > > > March 14, 2025 at 5:41 AM, "Computer Planet" > > mailto:open...@cpnetserver.net?to=%22Computer%20Planet%22%20%3Copenbsd%40cpnetserver.net%3E > > > > wrote: > > > > > > > > > > > > > > > Hi guys! > > > Please, could someone tell me how to print a very simple "Hello, world!" > > > in assembly for aarch64? > > > Thanks for reply. > > > > > > > > > https://peterdn.com/post/2020/08/22/hello-world-in-arm64-assembly/ > > > > > This won't work. OpenBSD uses a different ABI than Linux. > > > > -Otto > > > Hmm, doesn't gcc/llvm have a command line flag to take a C file and output > assembly? > > Maybe they could take the minimal hello.c file from that blog and run > > gcc --output-this-c-file-to-assembly hello.c > > ? >
Re: aarch64 assembly "hello world"
March 14, 2025 at 10:08 AM, "Otto Moerbeek" mailto:o...@drijf.net?to=%22Otto%20Moerbeek%22%20%3Cotto%40drijf.net%3E > wrote: > > On Fri, Mar 14, 2025 at 12:50:27PM +, jbra...@dismail.de wrote: > > > > > March 14, 2025 at 5:41 AM, "Computer Planet" > mailto:open...@cpnetserver.net?to=%22Computer%20Planet%22%20%3Copenbsd%40cpnetserver.net%3E > > > wrote: > > > > > > > > > > Hi guys! > > Please, could someone tell me how to print a very simple "Hello, world!" > > in assembly for aarch64? > > Thanks for reply. > > > > > > https://peterdn.com/post/2020/08/22/hello-world-in-arm64-assembly/ > > > This won't work. OpenBSD uses a different ABI than Linux. > > -Otto Hmm, doesn't gcc/llvm have a command line flag to take a C file and output assembly? Maybe they could take the minimal hello.c file from that blog and run gcc --output-this-c-file-to-assembly hello.c ?
problems with "xz" on 7.6 hppa
Hi, I've built "xz" from ports and it doesn't work: hppa$ echo bla | xz > /tmp/bla.xz hppa$ echo bla | xz -9 > /tmp/bla.xz xz: (stdin): Cannot allocate memory hppa$ uname -a OpenBSD hppa.groessler.org 7.6 GENERIC#1132 hppa hppa$ echo bla | xz -9 > /tmp/bla.xz [xz]12853/208633 sp=75820030 inside 78022000-78421fff: not MAP_STACK Segmentation fault (core dumped) hppa$ regards, chris [ using 824556 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2024 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.6 (GENERIC) #1132: Mon Sep 30 09:06:51 MDT 2024 dera...@hppa.openbsd.org:/usr/src/sys/arch/hppa/compile/GENERIC HP 9000/785/C3700 PA-RISC 2.0a real mem = 3221225472 (3072MB) rsvd mem = 524288 (512KB) avail mem = 3145949184 (3000MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root [flex fff8] pdc0 at mainbus0 power0 at mainbus0 offset 400804 lcd0 at mainbus0 offset 5d0008: model 0 cpu0 at mainbus0 offset ffa irq 31: PCXW2 L1-A 875MHz, FPU PCXW2 rev 1 cpu0: 768K(64b/l) Icache, 1536K(64b/l) wr-back Dcache, 240 coherent TLB mem0 at mainbus0 offset ed10200: size 3072MB astro0 at mainbus0 offset ed0: Astro rev 2.1 elroy0 at astro0 offset ed3c000: Elroy TR4.0 APIC ver 20, 7 pins pci0 at elroy0 sti0 at pci0 dev 2 function 0 "Hewlett-Packard Visualize FX4" rev 0x02 sti0: rev 8.13;9, ID 0x35ACDA3009A02587 sti0: A1262A, 1280x1024 frame buffer, 1280x1024x32 display sti0: 10x20 font type 1, 40 bpc, charset 0-255 elroy1 at astro0 offset ed38000: Elroy TR4.0 APIC ver 20, 7 pins pci1 at elroy1 sti1 at pci1 dev 1 function 0 "Hewlett-Packard Visualize FX4" rev 0x02 sti1: rev 8.13;9, ID 0x35ACDA3009A02587 sti1: A1262A, 1280x1024 frame buffer, 1280x1024x32 display sti1: 10x20 font type 1, 40 bpc, charset 0-255 elroy2 at astro0 offset ed32000: Elroy TR4.0 APIC ver 20, 7 pins pci2 at elroy2 ohci0 at pci2 dev 6 function 0 "NEC USB" rev 0x41: line 0 irq 2, version 1.0 ohci1 at pci2 dev 6 function 1 "NEC USB" rev 0x41: line 3 irq 3, version 1.0 ehci0 at pci2 dev 6 function 2 "NEC USB" rev 0x02: line 4 irq 5 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 elroy3 at astro0 offset ed3: Elroy TR4.0 APIC ver 20, 7 pins pci3 at elroy3 dc0 at pci3 dev 12 function 0 "DEC 21142/3" rev 0x41: line 2 irq 6, address 00:30:6e:48:3d:a7 lxtphy0 at dc0 phy 1: LXT970, rev. 3 "Analog Devices AD1889 Audio" rev 0x00 at pci3 dev 13 function 0 not configured pciide0 at pci3 dev 14 function 0 "NS PC87415 IDE" rev 0x03: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using line 0 irq 7 for native-PCI interrupt atapiscsi0 at pciide0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: removable cd0(pciide0:0:0): using BIOS timings, DMA mode 2 ssio0 at pci3 dev 14 function 1 "NS 87560 Legacy I/O" rev 0x01: line 0 irq 7 com0 at ssio0 offset 3f8 irq 4: ns16550a, 16 byte fifo com1 at ssio0 offset 2f8 irq 3: ns16550a, 16 byte fifo lpt0 at ssio0 offset 378 irq 7 ohci2 at pci3 dev 14 function 2 "NS USB" rev 0x02: line 0 irq 7, version 1.0, legacy support ohci2: SMM does not respond, will reset siop0 at pci3 dev 15 function 0 "Symbios Logic 53c896" rev 0x07: line 1 irq 8, using 8K of on-board RAM scsibus2 at siop0: 16 targets, initiator 7 siop0: switching to single-ended mode siop1 at pci3 dev 15 function 1 "Symbios Logic 53c896" rev 0x07: line 1 irq 8, using 8K of on-board RAM scsibus3 at siop1: 16 targets, initiator 7 sd0 at scsibus3 targ 5 lun 0: eui.0e110057d264 sd0: 34732MB, 512 bytes/sector, 71132960 sectors sd1 at scsibus3 targ 6 lun 0: eui.0004ceba327d sd1: 70007MB, 512 bytes/sector, 143374738 sectors usb3 at ohci2: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "NS OHCI root hub" rev 1.00/1.00 addr 1 siop1: target 5 now using tagged 16 bit 40.0 MHz 31 REQ/ACK offset xfers siop1: target 6 now using tagged 16 bit 40.0 MHz 31 REQ/ACK offset xfers uhub1: device problem, disabling port 3 uhidev0 at uhub3 port 1 configuration 1 interface 0 "Adomax USB/PS2 Scroll Mouse" rev 1.10/0.00 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhidev1 at uhub3 port 2 configuration 1 interface 0 "vendor 0x046a product 0x0023" rev 2.00/2.20 addr 3 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes wskbd0 at ukbd0: console keyboard uhidev2 at uhub3 port 2 configuration 1 interface 1 "vendor 0x046a product 0x0023" rev 2.00/2.20 addr 3 uhidev2: iclass 3/0, 2 report ids ucc0 at uhidev2 reportid 1: 1024 usages, 20 ke
Re: problems with "xz" on 7.6 hppa
Christian Groessler: > I've built "xz" from ports and it doesn't work: > > hppa$ echo bla | xz > /tmp/bla.xz So it works? > hppa$ echo bla | xz -9 > /tmp/bla.xz > xz: (stdin): Cannot allocate memory The xz(1) man page has a table that shows how much memory is required by the compression levels 0..9. Compare with your process memory limits. -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS Web crippled
hello. As you may have noticed, cvsweb.openbsd.org has been having issues. This time, it is due to effectively a Distributed Denial of Service, though I don't actually believe it is /deliberately/ malicious. Speculation is someone is trying to feed a so-called AI application from cvsweb. While I admire the idea of training an AI from the work of some of the best programmers in the world, cvsweb is a perl script that writes a lot of temp files. The current system is many times the first cvsweb HW I set up many years ago, and won't even notice humans using it, when hundreds of simultaneous automated queries are happening, things get bad quickly. FOR NOW, I've stopped the ability of cvsweb to show diffs of file revisions. This is where both much of the abuse was happening, and also much of the load on the system came from. YES, that's horribly annoying, but you can still download any individual version of a file and you can still see the annotated output. I'll be thinking about a longer-term solution (which may also be "wait until they get bored and move on"). Sorry for the inconvenience. Nick.
Re: CVS Web crippled
On Fri, Mar 14, 2025 at 3:39 PM Nick Holland
wrote:
>
> hello.
> As you may have noticed, cvsweb.openbsd.org has been having
> issues. This time, it is due to effectively a Distributed Denial of
> Service, though I don't actually believe it is /deliberately/
> malicious. Speculation is someone is trying to feed a so-called AI
> application from cvsweb. While I admire the idea of training an AI
> from the work of some of the best programmers in the world, cvsweb
> is a perl script that writes a lot of temp files. The current
> system is many times the first cvsweb HW I set up many years ago,
> and won't even notice humans using it, when hundreds of simultaneous
> automated queries are happening, things get bad quickly.
>
> FOR NOW, I've stopped the ability of cvsweb to show diffs of file
> revisions. This is where both much of the abuse was happening, and
> also much of the load on the system came from.
> YES, that's horribly annoying, but you can still download any
> individual version of a file and you can still see the annotated
> output. I'll be thinking about a longer-term solution (which may
> also be "wait until they get bored and move on").
sorry to hear about AI's latest victim. i had this problem on my gitea
instance running on openbsd, where the crawler decided to follow every
link to every revision of my mirrors of openbsd src and linux, and i
"fixed" it with robots.txt which the particular crawler ("claudebot")
respected. robots.txt:
User-agent: *
Disallow: /
>
> Sorry for the inconvenience.
>
> Nick.
>
Re: iked interfering with carp?
On Wed, 2025-03-12 at 18:26 +1000, David Gwynne wrote: > i know it's been a while since you posted this. hopefully you got > something working, but i have some notes here. [...] > in this situation you should set up separate tunnels between FW1 and > FW2a, and FW1 and FW2b. [...] Thanks, David. Based on your and Stuart's comments, I've altered the configuration that I posted down-thread (subject: "iked.conf syntax?"), which is making use of rdomains. I'm still using gre(4) now instead of sec(4) [just because it was already in place although I suspect sec(4) would be fine] but I've taken your advice and set up two distinct tunnels over IPSec, transport mode: FW1 <--> FW2a FW1 <--> FW2b With the SAs separate, I've disabled sasyncd and instead configured bgpd on the three (one private AS on FW1, and a second private AS shared on FW2a and FW2b). Net2 is now advertised by the FW2 BGP daemons, for use by FW1, with the "depend on carp5" clause. I also found that I needed to use 'active' rather than 'passive' in the iked.conf for FW2a and FW2b, otherwise fail-back when rebooting FW2a resulted in about a 3.5 minute outage (fail-over was fine). The outage in passive mode would last until new SAs were established from FW1. Now with active on both sides I see no packet loss as new SAs are created while the old are timing out. Works like a charm. > rport(4) might be useful if you're tinkering with rdomains. Based on your comment, I successfully tried rport(4) instead of using 'rtable' in pf.conf. Very cool, thanks for adding it to 7.6, and impeccible timing. In retrospect it makes sense, but it did take me a bit to realize that for traffic traversing from one rdomain to another, I needed to have essentially duplicate 'in' pf rules in place, both on the FW interface of the originating rdomain and on the rport on the destination side of the rport pair. Or maybe the rules on the destination rport are completely redundant and I can get away with a single "allow anything" or "skip"? I'm not sure, I don't have a good enough feel for it as yet, so I'm being conservative. Hopefully the above bread crumbs are useful to the next person who goes down this road. The only downside that I've seen so far on rport(4) is discoverability. There's a reference to it in the 7.6 change log but (I think) nowhere else. It could at least use a reference under "SEE ALSO" in the rdomain(4) man page. Yes, I could submit a patch for the man page. No, I do not (yet) have a source tree checked out on a machine running -current. I had such a machine on the test bench but I needed to prematurely promote it to production and I'm waiting on replacement hardware to continue that bench work. > hope this helps. It did, very much. Thanks. Updated diagram: ISP1 --- FW1 --- routable Net1 (a.a.a.a/26) || gre0 || gre1 (both over IPSec transport mode) || | /- |-/--- routable Net2 (b.b.b.b/26); carp5 |/ |/ FW2a FW2b |\ |\ | \- |-\--- unroutable Net3 (multiple RFC1918 nets // NATed to FW2 carp1, outbound through ISP2) ISP2 --// All IPs are static: FW1 external (vio0): c.c.c.c/29 FW1 internal (vio1): a.a.a.1/26 FW1 tunnel (gre0): 192.168.48.1 FW1 tunnel (gre1): 192.168.48.3 FW2a tunnel (gre0): 192.168.48.2 FW2b tunnel (gre0): 192.168.48.4 FW2 internal (carp5): b.b.b.193/26 FW2a internal (vlan5): b.b.b.194/26 FW2b internal (vlan5): b.b.b.195/26 FW2 external (carp1) d.d.d.114/29 FW2a external (em1)d.d.d.115/29 FW2b external (re1)d.d.d.117/29
