Re: small issue with mpe
On Wed, May 24, 2023 at 01:31:56PM +1000, David Gwynne wrote: > > > > On 23 May 2023, at 17:40, Claudio Jeker wrote: > > > > On Tue, May 23, 2023 at 07:09:51AM -, Stuart Henderson wrote: > >> On 2023-05-23, David Gwynne wrote: > >>> On Sat, May 20, 2023 at 09:44:51AM +0200, Holger Glaess wrote: > hi > > > looks like that the patch works , but should not print "tunneldomain" > instead of "rdomain" ? > >>> > >>> that's an interesting question. > >>> > >>> ifconfig does not aim to produce output that can then be used as input > >>> for ifconfig again. printing it as rdomain is at least consistent with > >>> how it's printed on the tunnel: line for things like etherip and gif, > >>> and i guess the assumption is you can figure out that it's tunneldomain > >>> from the context. > >> > >> things are a bit inconsistent here - doesn't this actually take an rtable > >> not an rdomain? (wg uses and prints "wgrtable" for what I think is the > >> equivalent thing). > > > > I think this is a general issue with tunneldomain. It should be > > tunneltable since it used for two things. The route lookup of the tunnel > > endpoints and to alter the mbufs rdomain on encapsulation / decapsulation. > > At least in theory this is how it should work but someone needs to verify > > that all drivers really behave like this. > > ifconfig drv0 rdomain specifies which rdomain and send packets into the > interface, and which rdomain the packets coming out of the interface > will use. this is the same on all interfaces whether they're tunnels or > not. > > ifconfig drv0 tunneldomain specifies the rdomain that the encapsulated > packets operate in. > > rdomain and tunneldomain (if supported) are always in effect and in the > same way. packets sent from an rdomain out a tunnel will get the tunnel > headers added to the packet and the rdomain rewritten to the > tunneldomain value (which could be 0). encapsulated packets from the > remote tunnel endpoint have to match the tunneldomain before the tunnel > interface will match them and decapsulate them, and once they're > decapsulated the rdomain on the packet is set to the interface rdomain > value. I agree with all you wrote. There is one part were the tunneldomain could be considered an rtableid (and not a pure rdomainid). When sending out encapsulated packets a route lookup is done using the tunneldomain value. For this lookup it would make sense to allow an rtableid. This only affects sending out traffic, on the receive side the system needs to lookup the endpoint using the rdomain using rtable_l2() (this is similar on how setrtable(2) and the corresponding getsockopt() work on sockets). Now there was never a feature request to send out gre/gif traffic using an alternate routing table and so I think we can keep this the way it is. -- :wq Claudio
Re: small issue with mpe
> On 23 May 2023, at 17:40, Claudio Jeker wrote: > > On Tue, May 23, 2023 at 07:09:51AM -, Stuart Henderson wrote: >> On 2023-05-23, David Gwynne wrote: >>> On Sat, May 20, 2023 at 09:44:51AM +0200, Holger Glaess wrote: hi looks like that the patch works , but should not print "tunneldomain" instead of "rdomain" ? >>> >>> that's an interesting question. >>> >>> ifconfig does not aim to produce output that can then be used as input >>> for ifconfig again. printing it as rdomain is at least consistent with >>> how it's printed on the tunnel: line for things like etherip and gif, >>> and i guess the assumption is you can figure out that it's tunneldomain >>> from the context. >> >> things are a bit inconsistent here - doesn't this actually take an rtable >> not an rdomain? (wg uses and prints "wgrtable" for what I think is the >> equivalent thing). > > I think this is a general issue with tunneldomain. It should be > tunneltable since it used for two things. The route lookup of the tunnel > endpoints and to alter the mbufs rdomain on encapsulation / decapsulation. > At least in theory this is how it should work but someone needs to verify > that all drivers really behave like this. ifconfig drv0 rdomain specifies which rdomain and send packets into the interface, and which rdomain the packets coming out of the interface will use. this is the same on all interfaces whether they're tunnels or not. ifconfig drv0 tunneldomain specifies the rdomain that the encapsulated packets operate in. rdomain and tunneldomain (if supported) are always in effect and in the same way. packets sent from an rdomain out a tunnel will get the tunnel headers added to the packet and the rdomain rewritten to the tunneldomain value (which could be 0). encapsulated packets from the remote tunnel endpoint have to match the tunneldomain before the tunnel interface will match them and decapsulate them, and once they're decapsulated the rdomain on the packet is set to the interface rdomain value. dlg > > -- > :wq Claudio >
Protectli VP2420 with Dasharo (coreboot+UEFI) v1.1.0 can't load any UEFI bsd.rd
Hi, I search the archive on this and saw many post on this including one from Marc Kettenis on October 30, 2020 in: $OpenBSD: conf.c,v 1.32 2020/10/30 19:39:00 kettenis Exp $ At the time looks like it fixed many issues, but now looks like it is back. Or may be just on my system with the new coreboot from Dasharo (coreboot+UEFI) v1.1.0 I tried as well as some posting suggested to load earlier version, so I did try all the way back to 6.7 as that's the latest version available on ftp.openbsd.org Still same results. The unit does work with the AMI BIOS, but not Dasharo coreboot one. There isn't any way to have Legacy BIOS. They have either Dasharo (coreboot+SeaBIOS) and Dasharo (coreboot+UEFI) So stay old, or go new, and remove the extra to keep it lean and clean. Here is what I get now same end results as before. Anything new possible to do? I would love to send a dmesg, but I can't get one as I can't boot anything. With current probing: pc0 mem[636K 1878M 12M 5M 76K 172K 700K 6M 5M 30732M] disk: hd0 hd1* hd2* hd3* hd4* >> OpenBSD/amd64 BOOTX64 3.64 boot> cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/7.3/amd64/bsd.rd: 3969732+1655808+3882232+0+704512 [109+56+297 056]=0xa74478 entry point at 0x1001000 With 7.3 probing: pc0 mem[636K 1878M 12M 5M 76K 172K 700K 6M 5M 30732M] disk: hd0 hd1* hd2* hd3* hd4* >> OpenBSD/amd64 BOOTX64 3.63 boot> cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/7.3/amd64/bsd.rd: 3924676+1647616+3886216+0+704512 [109+440424+293 778]=0xa667f0 entry point at 0x1001000 with 7.1 probing: pc0 mem[636K 1878M 12M 5M 76K 172K 700K 6M 5M 30732M] disk: hd0 hd1* hd2* hd3* hd4* >> OpenBSD/amd64 BOOTX64 3.63 boot> cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/7.3/amd64/bsd.rd: 3924676+1647616+3886216+0+704512 [109+440424+293 778]=0xa667f0 entry point at 0x1001000
The EuroBSDCon 2023 Call for proposals ends this week (May 26th, 2023), get your submission in now!
This year's EuroBSDCon conference is set in Coimbra, Portugal September 14-17, 2023. The conference (or rather the conference program committee) will accept submissions for consideration for inclusion in the program, talks, lightning talks or tutorials until the end of day (in any time zone) May 26th, 2023. The full Call for proposals can be found at https://2023.eurobsdcon.org/call-for-papers-is-now-open/, where you will also find the link to the submissions system. If you are mulling a submission, mull no more! Get your submission in as soon as possible and at the latest May 26th. We aim to finalize selection and to publish the initial version of the conference program on or before June 1st, 2023. Hoping to see you in Coimbra this September! For the EuroBSDCon 2023 program committee, -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: RSS or Atom syndication for security advisories?
On 2023/05/23 09:35, Xavier wrote: > I did not say that. I did not see that you in particular, or anyone in this > mailing list, make this work. > As a user, I simply suggest creating an RSS channel for security advisories > and *even* I offer myself to help. > > The intention behind was to improve OpenBSD web. Simply. The number of people who work on errata, for obvious reasons, needs to be a small set of people that we know+trust. Sometimes (though fortunately not all that often) that work is very delicate and needs to be done quickly but carefully. High stress situation already. Adding extra steps to the errata process, to merely provide the same information which is _already provided_ but just not in the format you prefer (in the case of pages on www.openbsd.org) and not on the website you prefer (in the case of the rss feed on undeadly.org), can't be of more than minor benefit to you, and no benefit to most people who already receive that information via other methods, yet it adds extra steps (= work) for every erratum that is produced. > Perhaps it's me but I perceived some kind or rudeness in some responses. After being given a workable answer (the rss feed on undeadly), you didn't like it and asked volunteers to do even more work than they already do, to mostly benefit you. Which I think some will consider a bit rude itself. > Oh! Come on! Why don't we concentrate in teach reasons and not in "I don't > want to move my position". Do you think this kind of answer would benefit > the project? There's no need to concentrate on tech reasons because it's not a technical problem.
Re: RSS or Atom syndication for security advisories?
I did not say that. I did not see that you in particular, or anyone in this mailing list, make this work. As a user, I simply suggest creating an RSS channel for security advisories and *even* I offer myself to help. The intention behind was to improve OpenBSD web. Simply. I want to thank Brian and Hiltjo who gave me positives answers with resolutive comments. I missed some guide or collaboration in order to incorporate this change or at least talk about technical pros and cons. Perhaps it's me but I perceived some kind or rudeness in some responses. Oh! Come on! Why don't we concentrate in teach reasons and not in "I don't want to move my position". Do you think this kind of answer would benefit the project? Do you treat people in reality like in the web? Xavier A 22.05.2023 15:11, Theo de Raadt escrigué: I am not going to do any of this work you want. Good bye. Xavier wrote: "Theo de Raadt" said: > I'd be thrilled to do less work on errata! > How about we do RSS, and stop making errata? > We can do static RSS. > Configure and forget. I don't know if you say it seriously. If you do, I think it's the best. Perhaps you could write some semantic file and convert them to desired format (html, RSS, etc.). I saw the www repo (https://github.com/openbsd/www/blob/38884496ed89e3041dcaaeadaf21e20a918581ee/errata73.html) and it seems you make things manually. Don't you think an static site generator or some kind of tool to make things more automatic (I'm thinking in mandoc conversion because all the web is really a big documentation project)? Regards, Xavier
Re: RSS or Atom syndication for security advisories?
Thanks a lot, Brian. Very appreciated. So now the only work is to merge to www A 22.05.2023 15:50, Brian Conway escrigué: On Mon, May 22, 2023, at 9:59 AM, Xavier wrote: I don't know if you say it seriously. If you do, I think it's the best. Perhaps you could write some semantic file and convert them to desired format (html, RSS, etc.). I saw the www repo (https://github.com/openbsd/www/blob/38884496ed89e3041dcaaeadaf21e20a918581ee/errata73.html) and it seems you make things manually. Don't you think an static site generator or some kind of tool to make things more automatic (I'm thinking in mandoc conversion because all the web is really a big documentation project)? Regards, Xavier Done. https://www.mail-archive.com/announce@openbsd.org/maillist.xml Enjoy. Bye. -b
Re: small issue with mpe
On Tue, May 23, 2023 at 07:09:51AM -, Stuart Henderson wrote: > On 2023-05-23, David Gwynne wrote: > > On Sat, May 20, 2023 at 09:44:51AM +0200, Holger Glaess wrote: > >> hi > >> > >> > >> looks like that the patch works , but should not print "tunneldomain" > >> instead of "rdomain" ? > > > > that's an interesting question. > > > > ifconfig does not aim to produce output that can then be used as input > > for ifconfig again. printing it as rdomain is at least consistent with > > how it's printed on the tunnel: line for things like etherip and gif, > > and i guess the assumption is you can figure out that it's tunneldomain > > from the context. > > things are a bit inconsistent here - doesn't this actually take an rtable > not an rdomain? (wg uses and prints "wgrtable" for what I think is the > equivalent thing). I think this is a general issue with tunneldomain. It should be tunneltable since it used for two things. The route lookup of the tunnel endpoints and to alter the mbufs rdomain on encapsulation / decapsulation. At least in theory this is how it should work but someone needs to verify that all drivers really behave like this. -- :wq Claudio
Re: Failure to install on MacBook Pro Retina early 2015
On May 22 23:24:04, dave_t_tur...@barradas.free-online.co.uk wrote: > The MacBookPro uses UEFI and will only boot from a USB stick for the > install. > After using the Apple magic 'alt' key to boot from the USB stick I get > this:- > probing pc0 mem [list of numbers] > disk: hdo* hd1* > > > OpenBSD /amd64 BOOTX64 3.62 > open (hd0a: /etc/boot.conf: Invalid argument > failed (22) will try /bsd I see a similar problem on an old macppc (dmesg below). In my case, the error message is boot.conf: line too long while there is no boot.conf > Using 'set' and 'help' doesn't yield any useful info > to find the boot.conf file. That should be /etc/boot.conf. I guess there is one on the install media - what dfoes it say? > ls gives hd0a Invalid Argument > ls hd0a gives hd0a:hd0a Invalid Argument I am able to boot with > boot hd:/bsd but I only have one disk in. Try that or > boot hd0a:/bsd > set shows the device as hd0. > hd0a is definitely the USB stick. To be sure: you are trying to boot the USB stick to install, right? As opposed to trying to boot the already installed system. > Is this install doomed to fail or am I missing some secret info that > rummaging through the boot(8) > boot_config(8) and boot_configamd64(8) man pages has failed to find? Also, are you sure it's an amd64 machine? (Not related to the boot problem I guess.) Jan [ using 1330724 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A] console in [keyboard], using USB using parent ATY,RockHopper2Paren:: memaddr 9800, size 800 : consaddr 9c008000 : ioaddr 9002, size 2: width 1920 linebytes 2048 height 1080 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (GENERIC) #105: Sat Apr 15 17:07:53 MDT 2023 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1025327104 (977MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: model PowerMac10,2 cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 memc0 at mainbus0: uni-n rev 0xd2 "hw-clock" at memc0 not configured kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 agp at pchb0 not configured radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 drm0 at radeondrm0 radeondrm0: irq 48 mpcpcibr1 at mainbus0 pci: uni-north pci1 at mpcpcibr1 bus 0 macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE macgpio0 at macobio0 offset 0x50 "modem-reset" at macgpio0 offset 0x1d not configured "modem-power" at macgpio0 offset 0x1c not configured macgpio1 at macgpio0 offset 0x9: irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zs0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 aoa0 at macobio0 offset 0x1: irq 30,1,2 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 apm0 at adb0: battery flags 0x0, 0% charged piic0 at adb0 iic1 at piic0 maxtmp0 at iic1 addr 0xc8: max6642 kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x2 irq 24: DMA audio0 at aoa0 ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 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 "Apple 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 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 mpcpcibr2 at mainbus0 pci: uni-north pci2 at mpcpcibr2 bus 0 kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00 wdc1 at kauaiata0 irq 39: DMA wd0 at wdc1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 "Apple UniNorth Firewire" rev 0x81 at pci2 dev 14 function 0 not configured gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address
Re: small issue with mpe
On 2023-05-23, David Gwynne wrote: > On Sat, May 20, 2023 at 09:44:51AM +0200, Holger Glaess wrote: >> hi >> >> >> looks like that the patch works , but should not print "tunneldomain" >> instead of "rdomain" ? > > that's an interesting question. > > ifconfig does not aim to produce output that can then be used as input > for ifconfig again. printing it as rdomain is at least consistent with > how it's printed on the tunnel: line for things like etherip and gif, > and i guess the assumption is you can figure out that it's tunneldomain > from the context. things are a bit inconsistent here - doesn't this actually take an rtable not an rdomain? (wg uses and prints "wgrtable" for what I think is the equivalent thing).
