Re: OpenBSD Readonly File System
On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen
wrote:
>
> Tuesday, June 9, 2020 7:59 AM, Vertigo Altair
> wrote:
>
> > Hi Misc,
> > I have a firewall device and I'm using OpenBSD on it.
>
> Last year I had to configure an OpenBSD 6.5 firewall for use in a
> remote location, and was concerned about power loss corrupting the
> filesystem and making the system unbootable without manual
> intervention. As I did not want to modify OpenBSD in unsupported ways,
> I decided to test what kind of damage power loss could do, by
> randomly removing and applying power to the firewall, many many times.
>
> What I found was that 99% of the time, the system would just repair the
> filesystem and boot without problems, but if by chance the power was
> removed at a short time window during kernel relinking, the kernel
> would become corrupt and leave the system completely unbootable and
> not easy to repair. It was suggested to me that I tried to mount root
> partition with the sync option, so I arranged the partition layout in a
> way that would make it feasible and added the option to fstab.
>
> Only other problem I found, was that a few times after removing power
> when writing a large file, the system would require me to run fsck -y
> manually, this is by design, but I decided it was more important to me
> that the system could boot unattended, with a minuscule risk of
> completely ruining the filesystem, so I wrote a small unsupported patch
> for the rc script (sorry if the formatting gets messed up by posting):
>
> The patch has only been tested on OpenBSD 6.5.
>
> ---
> Index: src/etc/rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.536
> diff -u -p -u -p -r1.536 rc
> --- src/etc/rc 1 Apr 2019 11:39:46 - 1.536
> +++ src/etc/rc 20 Aug 2019 22:47:49 -
> @@ -1,5 +1,8 @@
> # $OpenBSD: rc,v 1.536 2019/04/01 11:39:46 tedu Exp $
>
> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
> +# automatic file system check fails with exit code 8.
> +
> # System startup script run by init on autoboot or after single-user.
> # Output and error are redirected to console by init, and the console is the
> # controlling terminal.
> @@ -271,8 +274,14 @@ do_fsck() {
> echo "Reboot failed; help!"
> exit 1
> ;;
> - 8) echo "Automatic file system check failed; help!"
> - exit 1
> + 8) echo "Automatic file system check failed; trying fsck -y"
> + fsck -y
> + case $? in
> + 0) ;;
> + *) echo "Could not repair file system unattended; help!"
> + exit 1
> + ;;
> + esac
> ;;
> 12) echo "Boot interrupted."
> exit 1
> ---
>
> After mounting root filesystem with sync option and applying the patch,
> I was no longer able to make the system unbootable by power loss in my
> test setup. It may be possible, but the risk is now so small that it is
> not a concern for me and the risk of something else breaking is
> probably bigger. During operation in remote location, the system has
> always been able to completely boot after a power loss so far.
>
> So while it was not possible for me to not make any unsupported
> modifications at all, I think it is a very small change compared to
> have read only filesystems. Anyone who knows OpenBSD, will be able to
> manage the firewall without special instructions.
>
>
> Regards,
> Mogens Jensen
>
Auto filesystem repair is bad juju.
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: Sun Fire X2100 stops booting
Sun is not for beginners ... At least not for the ones who stopped at 5.9.
Re: Any idea/suggestion for old Cisco router to be use running OpenBSD current for WG?
The hardware is good. After an AC incident, I've had some of those cavium nics melt the cpu thermal paste, dripping all over the mainboard. (this nics are inserted into a riser card, facing down the mainboard) The machine kept running! A quarta, 24/06/2020, 21:12, Pierre Emeriaud escreveu: > Le mer. 24 juin 2020 à 13:01, Stuart Henderson a > écrit : > > > > On 2020-06-23, Daniel Ouellet wrote: > > > OpenBSD does run on some old Cisco routers, it's been done before. Sure > > > it's not officially supported nor does it support all the various > > > interfaces but it's known to work on some. > > Not a router per se, but my home gateway is a Cisco ACE 4710 appliance > running 6.6, with multiple rdomains, tinc vpns, bgp full ipv6 table > and a couple of nics, and a 4GB cf as harddisk. > > > > I am trying to dig up a dmesg showing it too. > > https://dmesgd.nycbug.org/index.cgi?do=view&id=4760 > > > > Here is an example using the4 old Cisco IDS-4215 > > > > > > > https://komlositech.wordpress.com/2018/12/30/revive-a-cisco-ids-into-a-capable-openbsd-firewall/ > > > > > > I was just curious as to what stage it might be now. > > > > That's just someone reusing janky old hardware that is being thrown out, > > there is no particular effort to support it on the OpenBSD side. > > My hardware is really ancient compared to modern servers: > $ sysctl hw.model > hw.model=Intel(R) Pentium(R) 4 CPU 3.40GHz > > It draws power for sure, much more than an APU or similar, but I like it :) > > The install was straightforward, install on the CF from another host > w/ qemu, plug, boot, done. > > > > May be Juniper instead as Juniper is based on FreeBSD anyway and it's > an > > > over price PC with specialize network cards. (; Ok more then that, but > > > you get the picture I think. > > > > they're devices with network forwarding ASICs that happen to use a > > FreeBSD system as the control plane (and are moving to Linux now but > > I digress).. networking on the control plane is really limited and > > only meant for management, beyond that you need to interface with > > the special hardware. > > The Cisco ACE4710 had a specialized nic, a cavium (octeon?), running > linux on a mips cpu, to offload all the heavy lifting. I removed it > and never tried to use it. > > I also tried to install 5.sth on a nokia IP 710 firewall, that didn't > go that well because of some pci & acpi issues iirc, and overall it > was less interesting because of the huge form factor, and the > linecards beeing proprietary. > >
E3372: LCP: timeout sending Config-Requests
Hi, I have the exactly same problem of the following guy: https://marc.info/?l=openbsd-misc&m=151950994024553&w=2 I have a e3372 mobile too but wiht openbsd 6.7. But the guy forgotten to say how he solved the problem. Anyone can help me ? Anyway the following are my connections files: ===> /etc/ppp/peers/telekom cuaU0 user myuser888 nocrtscts defaultroute noipdefault ipcp-accept-local ipcp-accept-remote connect "/usr/sbin/chat -vs -f /etc/ppp/connect.telekom" > /etc/ppp/connect.telekom ABORT 'BUSY' ABORT 'NO CARRIER' ABORT 'VOICE' REPORT CONNECT TIMEOUT 20 'OK-AT-OK' 'ATZ' 'OK' 'AT+CMEE=2' 'OK' 'AT' 'OK\d-AT-OK' 'ATI' 'OK' 'ATZ' 'OK' 'AT' 'OK' AT+CGDCONT=1,"IP","giffgaff.com","0.0.0.0",0,0 'OK' 'ATD*99#' CONNECT and the Errors: pppd[13820]: pppd 2.3.5 started by myuser, uid 0 pppd[13820]: Connect: ppp0 <--> /dev/cuaU0 pppd[13820]: LCP: timeout sending Config-Requests pppd[13820]: Connection terminated. pppd: Exit. Thank you very much for your help.
Re: Any idea/suggestion for old Cisco router to be use running OpenBSD current for WG?
Le mer. 24 juin 2020 à 13:01, Stuart Henderson a écrit : > > On 2020-06-23, Daniel Ouellet wrote: > > OpenBSD does run on some old Cisco routers, it's been done before. Sure > > it's not officially supported nor does it support all the various > > interfaces but it's known to work on some. Not a router per se, but my home gateway is a Cisco ACE 4710 appliance running 6.6, with multiple rdomains, tinc vpns, bgp full ipv6 table and a couple of nics, and a 4GB cf as harddisk. > > I am trying to dig up a dmesg showing it too. https://dmesgd.nycbug.org/index.cgi?do=view&id=4760 > > Here is an example using the4 old Cisco IDS-4215 > > > > https://komlositech.wordpress.com/2018/12/30/revive-a-cisco-ids-into-a-capable-openbsd-firewall/ > > > > I was just curious as to what stage it might be now. > > That's just someone reusing janky old hardware that is being thrown out, > there is no particular effort to support it on the OpenBSD side. My hardware is really ancient compared to modern servers: $ sysctl hw.model hw.model=Intel(R) Pentium(R) 4 CPU 3.40GHz It draws power for sure, much more than an APU or similar, but I like it :) The install was straightforward, install on the CF from another host w/ qemu, plug, boot, done. > > May be Juniper instead as Juniper is based on FreeBSD anyway and it's an > > over price PC with specialize network cards. (; Ok more then that, but > > you get the picture I think. > > they're devices with network forwarding ASICs that happen to use a > FreeBSD system as the control plane (and are moving to Linux now but > I digress).. networking on the control plane is really limited and > only meant for management, beyond that you need to interface with > the special hardware. The Cisco ACE4710 had a specialized nic, a cavium (octeon?), running linux on a mips cpu, to offload all the heavy lifting. I removed it and never tried to use it. I also tried to install 5.sth on a nokia IP 710 firewall, that didn't go that well because of some pci & acpi issues iirc, and overall it was less interesting because of the huge form factor, and the linecards beeing proprietary.
Re: obsd 6.7 - TOR relay (non-exit) & /var folder
After few attempts, I can't still don't understand what's going on it seems that the only way to free up the /var folder is to restart the tor's daemon. "pkill -HUP -u _tor -U _tor -x tor" didn't help ... Other ideas? On 23.06.2020 11:50, Salvatore Cuzzilla wrote: Hi Gabriel, thanks for the hint! I actually use to "rcctl reload tor" to rotate the logs. I now switched to "pkill -HUP -u _tor -U _tor -x tor" let's see if it's helping! Regards, Salvatore. June 23, 2020 12:53 PM, "Salvatore Cuzzilla" wrote: Hi Folks, I’m running a TOR node on my [APU2c4 (SSD) + OBSD 6.7] somehow the TOR process is polluting my /var folder until, after few days, it’s fulfilled (~6G). In the beginning I thought that it was related to the daemon's logs, something misconfigured within newsyslog.conf ... it’s not! the funny thing is that, as soon as shut the daemon the /var folder is free-up back again… - 12:46:44 -ksh root@APU2c4 /var/tor/diff-cache # df -h | grep /var /dev/sd0e 6.3G 1.7G 4.4G 28% /var 12:46:55 -ksh root@APU2c4 /var/tor/diff-cache # rcctl stop tor tor(ok) 12:48:00 -ksh root@APU2c4 /var/tor/diff-cache # df -h | grep /var /dev/sd0e 6.3G 327M 5.7G 5% /var 12:48:00 -ksh root@APU2c4 /var/tor/diff-cache - I’m a bit lost, from where should I start? Regards, Salvatore. --- :wq, Salvatore.
This is the day pf was added
Hi, A little trip down memory lane, to 2001. Jun 24 PF added. Insane amounts of work done by dhartmei@, 2001 Thank you all for those who have worked on and contributed to pf. Keep up the great work! Best, j.b.
Re: OpenBGPd announce fulltables +default
Thanks Stuart ... for the feedback Appreciate it ... On Wed, 24 Jun 2020 at 10:17, Stuart Henderson wrote: > On 2020-06-22, Tom Smyth wrote: > > Hello, > > I notice that in the current manual > > there is an option to export none, default-route with the > > explanation below in the manual > > > > export (none|default-route)If set to none, no UPDATE messages will be > > sent to the neighbor. If set to default-route, only the default route > > will be announced to the neighbor. When export is modified the > > neighbor session needs to be reset to become active. > > > > I was wondering is there an easy way to announce the default + full > > tables for BGP customers who want to choose to migrate from default > > routing to full table without contacting me ... > > > > something inside me says it would be wrong to add 0.0.0.0/0 network > > (although if memory serves me correctly previous versions of OpenBGPd > > would politely decline to do that :) and filter the crap out of that > > for upstream Transit and Peers (non Customers ) ... > > > > Adding to networks is exactly how you do this. > > For filters I would do this in a similar way to "mynetworks" in the > example config (with a different prefix-set and controlled by a > different community number) then you can enable/disable it easily > per peer. Don't filter it *out* though - default to not sending > anything and just permit it to the relevant peers. > > > -- Kindest regards, Tom Smyth.
Re: XFCE menu does not load with keyboard shortcut
You're right Dumitru, this is an old bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/201 I have been using XFCE for a very long time and in the past there was always a keyboard shortcut to open the applications menu on the panel directly. There is a separate shortcut to open the desktop menu (which Robb at y42 mentioned). I suppose we just have to wait for it to be fixed upstream. The .xsession-errors file was the right place to look which was helpful for me so thanks for that Robb. Regards Ed Gray On Wed, 24 Jun 2020 at 09:07, Dumitru Moldovan wrote: > On Tue, Jun 23, 2020 at 07:33:20PM +0100, Ed Gray wrote: > >Hi, > > > >I have an issue with XFCE on OpenBSD 6.6 and current on an amd64 system. > >XFCE works fine except for accessing the applications menu with the Alt + > >F1 keyboard shortcut. Instead of loading the menu it gets highlighted in > >grey and nothing happens. Clicking the menu loads it straight away. > > > >The shortcut is defined in the keyboard settings as the default for > >xfce4-popup-applicationsmenu which is different from the shortcut for the > >desktop menu. Sometimes in another application such as firefox when I > press > >Alt + F1 a second time I get the desktop menu appear, even though firefox > >is maximised and I'm not on the desktop. > > > >I can't confirm at the moment if it is specific to OpenBSD or XFCE in > >general. > > > >Does anyone else have this problem? > > Have seen this on Void Linux as well. Family member needed Netflix on > her laptop, so I couldn't push OpenBSD, even though it ran fine. (Had > to check, and by the way, it was surprising to see how much slower it > ran compared to Alpine or Void.) > > But this is an older Xfce bug, I remember having similar issues when > I last gave it a shot. This used to work reliably in older versions > though, back when Xfce was based on GTK+ 2.x. > > To end in a positive note, one thing I learned on my OpenBSD adventure > is "the best desktop is no desktop". cwm never fails to open its > menus. Keep it stupid simple. > >
Re: Lenovo V130, boot failed with error "entry point at 0x1001000"
Hi, I did some more tests/new installations on this machine. A clean reinstallation of 6.7 release boots without any problems with the loaders 3.50 (release 6.7) and also 3.52 (snapshot 2020-06-23). Kernel 6.7 GENERIC.MP#182 build time 2020-05-07 Also after an syspatch the kernel 6.7 GENERIC.MP#2 build time 2020-06-04 boots without any problems with the loaders 3.50 and 3.52 (snapshot 2020-06-23). So in my opinion the problem is the kernel. I think between 2020-06-04 and 2020-06-23 the where some changes which prevents that the 6.7 and 6.7/current loader boots the kernel on this and maybe on some other Lenovo (e.g. X1 Gen7) machines. The loader always show "entry point at 0x1001000" for some milliseconds, also when the kernel 6.7 gets loaded successfully. Maybe we'll find the changes for the kernel, which are responsible for this error. An another point for the kernel issue is in my opinion that the current RAMDISK kernel (from the latest snapshot) boots also without any problems. I'll do some more testing with a current kernel. Best regards, Sven On 6/23/20 10:20 PM, Matt Kunkel wrote: Here is the offending patch. -current boots fine with it removed: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/stand/efiboot/exec_i386.c.diff?r1=1.2&r2=1.3&f=h Appears bootx64.efi is carrying some board specific workaround for HP / Computrace that breaks many others, including tianocore. Guess I'll submit a patch to reverse it since I don't have an Elitebook to test with? As a workaround, mount the efi partition and copy in boot64.efi from 6.6. -Matt Kunkel June 23, 2020 2:16 PM, "Sven Wolf" wrote: Hi, also after the new installation of the current snapshot the system stops with "entry point at 0x1001000". It's interesting, that a installation via bsd.rd is possible. But after that the system doesn't boot via bsd.mp/bsd.sp. Best regards, Sven On 6/21/20 8:55 PM, Sven Wolf wrote: Hi, the update of the loader didn't help. I've updated the bootx64.efi from 3.48 to 3.52. But the current kernel > doesn't load. I'll try a re-installation. Maybe @Otto can explain why the start of bsd.rd is possible and the > start of bsd.sp/bsd.mp is not possible. Maybe I can build a custom kernel. Best regards, Sven On 6/21/20 8:33 PM, Sven Wolf wrote: Hi, I found the same issue in a thread some weeks ago. https://marc.info/?l=openbsd-misc&m=159039904132502&w=2 I'll test an reinstall/older loader. Boot from mbr isn't an option :( Best regards, Sven On 6/21/20 8:20 PM, Sven Wolf wrote: Hi, I've upgraded my Lenovo V130 from snapshot 6.6 (April 2020) to the >>> snapshot from 2020-06-20. The boot via boot.rd is always possible. But when I load bsd.sp or bsd.rd the boot process stops with the >>> error "entry point 0x1001000". Do you have an idea how I can fix this >>> error? In the past I did't have any problem with openbsd on this machine. I'll try tomorrow the next snapshot. Thanks and best regards, Sven
Re: Any idea/suggestion for old Cisco router to be use running OpenBSD current for WG?
On 6/24/20 11:58 AM, Stuart Henderson wrote: On 2020-06-23, Daniel Ouellet wrote: Have a look through https://www.supermicro.com/en/products/embedded/servers / https://www.supermicro.com/en/products/embedded/rackmount and you'll find quite a few things that give the perception "solid custom network device" rather than either "repurposed server" or "cisco junk, well past it's sell-by date, <$100 on ebay" - things like these https://www.supermicro.com/en/products/system/1U/1019/SYS-1019D-FRN8TP.cfm https://www.supermicro.com/en/products/system/1U/5019/SYS-5019D-4C-FN8TP.cfm (some equipment from other vendors will fit the bill too, but supermicro is a lot easier to buy from than portwell etc). I agree totally here with Stuart! In the past I have built a router using a SuperMicro 4U chassis with Xeon E5 cpu. https://www.supermicro.com/en/products/chassis/4U/842/SC842TQC-668B Originally OpenBSD didn't support the RAID controller so I used the root backup cron dd script. Everything else was fine however, and it's performance has been incredible with the only downtime being during maintenance periods -> transitioning to new version of 'Current'. Consequently it is tied to a Cisco router :-) That is really only to bridge the VDSL2 line to Ethernet - https://tools.ietf.org/html/rfc1483 Another option depending on availability could be Jetway - http://www.jetwayipc.com/product-category/emb-board-en/embedded-x86-en/mini-itx-en/ https://www.jetwaycomputer.com/ Example (yes they do look like vendor based network equipment and not rack mount servers): https://www.jetwaycomputer.com/1U-Rackmount-Barebones.html One common place for their availability is the Mini-ITX store: https://www.mini-itx.com/store/category?type=motherboard&jetway=1&maxram=4GB-or-more&lan-ports=from-1&storage-ports=from-1&sortby=price&page=1 I don't have experience with them in general but if OpenBSD works well on them they could become a really big game changer. Regards, Kaya
Re: Any idea/suggestion for old Cisco router to be use running OpenBSD current for WG?
On 2020-06-23, Daniel Ouellet wrote: > OpenBSD does run on some old Cisco routers, it's been done before. Sure > it's not officially supported nor does it support all the various > interfaces but it's known to work on some. > > I am trying to dig up a dmesg showing it too. > > Plus Cisco have some firewall type of device that are over price PC that > can run OpenBSD. > > Here is an example using the4 old Cisco IDS-4215 > > https://komlositech.wordpress.com/2018/12/30/revive-a-cisco-ids-into-a-capable-openbsd-firewall/ > > I was just curious as to what stage it might be now. That's just someone reusing janky old hardware that is being thrown out, there is no particular effort to support it on the OpenBSD side. > I am not saying it make sense to do really power wise for sure. > > May be Juniper instead as Juniper is based on FreeBSD anyway and it's an > over price PC with specialize network cards. (; Ok more then that, but > you get the picture I think. they're devices with network forwarding ASICs that happen to use a FreeBSD system as the control plane (and are moving to Linux now but I digress).. networking on the control plane is really limited and only meant for management, beyond that you need to interface with the special hardware. >> On Tue, Jun 23, 2020 at 5:03 PM Daniel Ouellet wrote: >>> >>> I also know there was effort and some Cisco router can run OpenBSD very >>> well, however I have no clue as to any of this stand now. Not really "effort" or "very well" ;) >>> I don't have a problem to use APU type or other Ubiquit for small >>> OpenBSD router, but I wonder about using Cisco instead. The only reason >>> is for may be more stability, most likely less performance for sure, but >>> less change to have corrupted reboot on power lost, etc. That is nonsense, "corrupted reboot on power lost" isn't down to the hardware, it's OS/configuration - running OpenBSD on such hardware won't help unless you make a custom system that avoids live writes to the storage devices or at least reduce the risk with sync mounts etc (see recent misc@ thread). >>> And sadly for some customers having what they see as computer as router >>> don't make them fell good, Now that is true ... >>>but seeing a Cisco box kind of wipe out the >>> impression. paint the chassis blue-green and put a sticker on it? ;) >>> I am not saying it's justify, but perception is sometime >>> everything, but if I have my say in it I want all my routers to be >>> OpenBSD as much as I can where the needs is not to multiple Gb in speed. >>> >>> So, any suggestion or updates as to what's now available and hopefully >>> in use now. Have a look through https://www.supermicro.com/en/products/embedded/servers / https://www.supermicro.com/en/products/embedded/rackmount and you'll find quite a few things that give the perception "solid custom network device" rather than either "repurposed server" or "cisco junk, well past it's sell-by date, <$100 on ebay" - things like these https://www.supermicro.com/en/products/system/1U/1019/SYS-1019D-FRN8TP.cfm https://www.supermicro.com/en/products/system/1U/5019/SYS-5019D-4C-FN8TP.cfm (some equipment from other vendors will fit the bill too, but supermicro is a lot easier to buy from than portwell etc). >>> I just have no clue if wireguard needs to be run, what can be achieve as >>> the CPU in all Cisco device is always under power, we all know that. Wireguard performance is pretty good even on relatively weak CPUs but the 20-year-old Celeron in that Cisco thing is ... well ... let's just say it's going to struggle to forward at 100Mb/s *without* encryption.
Sun Fire X2100 stops booting
This is current/amd64 on a Sun Fire X2100. The boot sequence stops at the "root on wd0a ..." line and nothing else happens. No, it's not redirecting the console. Am I missing something obvious? Is anyoney seeing the same? Below is the last working dmesg I have from the machine - sorry it's so late. Jan OpenBSD 5.9-current (GENERIC) #1850: Sat Apr 2 11:38:30 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 2129526784 (2030MB) avail mem = 2060734464 (1965MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf (41 entries) bios0: vendor Sun Microsystems version "1.1.1" date 05/16/2006 bios0: Sun Microsystems Sun Fire(TM) X2100 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT SRAT APIC acpi0: wakeup devices HUB0(S5) XVR0(S5) XVR1(S5) XVR2(S5) XVR3(S5) USB0(S3) USB2(S3) MMAC(S5) MMCI(S5) UAR1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Opteron(tm) Processor 146, 2010.54 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: AMD erratum 89 present, BIOS upgrade may be required mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 201MHz ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (HUB0) acpicpu0 at acpi0: C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB "PNP0501" at acpi0 not configured ipmi at mainbus0 not configured cpu0: Cool'n'Quiet K8 2010 MHz: speeds: 2000 1800 1000 MHz pci0 at mainbus0 bus 0 "NVIDIA nForce4 DDR" rev 0xa3 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 "NVIDIA nForce4 ISA" rev 0xa3 nviic0 at pci0 dev 1 function 1 "NVIDIA nForce4 SMBus" rev 0xa2 iic0 at nviic0 adt0 at iic0 addr 0x2e: sch5017 rev 0x89 spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC3200CL2.5 spdmem1 at iic0 addr 0x51: 512MB DDR SDRAM non-parity PC3200CL2.5 spdmem2 at iic0 addr 0x52: 512MB DDR SDRAM ECC PC3200CL3.0 spdmem3 at iic0 addr 0x53: 512MB DDR SDRAM ECC PC3200CL3.0 iic1 at nviic0 adt1 at iic1 addr 0x2e: sch5017 rev 0x89 spdmem4 at iic1 addr 0x50: 512MB DDR SDRAM non-parity PC3200CL2.5 spdmem5 at iic1 addr 0x51: 512MB DDR SDRAM non-parity PC3200CL2.5 spdmem6 at iic1 addr 0x52: 512MB DDR SDRAM ECC PC3200CL3.0 spdmem7 at iic1 addr 0x53: 512MB DDR SDRAM ECC PC3200CL3.0 ohci0 at pci0 dev 2 function 0 "NVIDIA nForce4 USB" rev 0xa2: apic 2 int 20, version 1.0, legacy support ehci0 at pci0 dev 2 function 1 "NVIDIA nForce4 USB" rev 0xa3: apic 2 int 20 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1 pciide0 at pci0 dev 6 function 0 "NVIDIA nForce4 IDE" rev 0xf2: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) pciide1 at pci0 dev 7 function 0 "NVIDIA nForce4 SATA" rev 0xf3: DMA pciide1: using apic 2 int 20 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 78533MB, 160836480 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6 pciide2 at pci0 dev 8 function 0 "NVIDIA nForce4 SATA" rev 0xf3: DMA pciide2: using apic 2 int 20 for native-PCI interrupt ppb0 at pci0 dev 9 function 0 "NVIDIA nForce4" rev 0xa2 pci1 at ppb0 bus 1 vga1 at pci1 dev 5 function 0 "ATI Rage XL" rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) nfe0 at pci0 dev 10 function 0 "NVIDIA CK804 LAN" rev 0xa3: apic 2 int 20, address 00:e0:81:71:98:45 eephy0 at nfe0 phy 1: 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 11 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci2 at ppb1 bus 2 ppb2 at pci0 dev 12 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci3 at ppb2 bus 3 ppb3 at pci0 dev 13 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci4 at ppb3 bus 4 bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 (0x4101): apic 2 int 5, address 00:e0:81:71:98:46 brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb4 at pci0 dev 14 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci5 at ppb4 bus 5 pchb0 at pci0 dev 24 function 0 "AMD AMD64 0Fh HyperTransport" rev 0x00 pchb1 at pci0 dev 24 function 1 "AMD AMD64 0Fh Address Map" rev 0x00 pchb2 at pci0 dev 24 function 2 "AMD AMD64 0Fh DRAM Cfg" rev 0x00 kate0 at pci0 dev 24 function 3 "AMD AMD64 0Fh Misc Cfg" rev 0x00 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5
Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?
On 2020-06-24, Stuart Henderson wrote: > On 2020-06-23, Why 42? The lists account. wrote: >> >> Hi All, >> >> Has anyone ever tried the Infinite Noise TRNG hardware random number >> generator >> with OpenBSD? >> >> It's a USB stick that contains hardware to generate random numbers. See: >> https://github.com/13-37-org/infnoise >> >> I had a couple of these working with ArchLinux and would like to try using >> them with OpenBSD. >> >> Using either 6.6 or 6.7 the device is recognised at boot time: >>> uftdi0 at uhub0 port 2 configuration 1 interface 0 "13-37.org Infinite Noise >>> TRNG" rev 2.00/10.00 addr 3 ucom0 at uftdi0 portno 1 >> >> With libftdi1-1.4p2 installed I was able to compile the associated software >> using the supplied "Makefile.freebsd". So a pretty easy start ... >>> make -f Makefile.freebsd >>> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >>> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >>> -DGIT_DATE=\"\" -c libinfnoise.c >>> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >>> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >>> -DGIT_DATE=\"\" -c healthcheck.c >>> cc -c -o KeccakF-1600-reference.o Keccak/KeccakF-1600-reference.c -Wall >>> -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I /usr/local/include/libftdi1 >>> -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" -DGIT_DATE=\"\" >>> ar rcs libinfnoise.a libinfnoise.o healthcheck.o KeccakF-1600-reference.o >>> ranlib libinfnoise.a >>> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >>> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >>> -DGIT_DATE=\"\" -fvisibility=hidden -o libinfnoise.so libinfnoise.o >>> healthcheck.o KeccakF-1600-reference.o -L /usr/local/lib -Wl -lftdi1 -lm >>> -shared >>> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >>> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >>> -DGIT_DATE=\"\" -c infnoise.c >>> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >>> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >>> -DGIT_DATE=\"\" -c daemon.c >>> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >>> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >>> -DGIT_DATE=\"\" -o infnoise infnoise.o daemon.o libinfnoise.a -lftdi1 -lm >>> -L. -L /usr/local/lib >> >> This creates an executable "driver" called infnoise which can be run as a >> daemon e.g. >>> doas ./infnoise -h >>> Usage: infnoise [options] >>> Options are: >>> -D, --debug - turn on some debug output >>> -R, --dev-random - write entropy to /dev/random instead of stdout >>> -r, --raw - do not whiten the output >>> -m, --multiplier - write 256 bits * value for each 512 bits >>> written to >>> the Keccak sponge. Default of 0 means write all the entropy. >>> -n, --no-output - do not write random output data >>> -p, --pidfile - write process ID to file >>> -d, --daemon - run in the background >>> -s, --serial - use specified device >>> -l, --list-devices - list available devices >>> -v, --version - show version information >>> -h, --help - this help output >>> ... >> >> The "list-devices" mode works nicely: >>> doas ./infnoise --list-devices >>> ... >>> ID: 0, Manufacturer: 13-37.org, Description: Infinite Noise TRNG, Serial: >>> 1337-ECA4E8A6 >> >> So far, so good ... But if I try getting actual random numbers, I get "read >> failed": >>> doas ./infnoise >>> ... >>> Error: USB read failed >> >> Any suggestions? Where am I going wrong? Maybe I shouldn't have taken that >> shortcut with the freebsd makefile? Or a security issue? >> >> Thanks in advance. >> >> Cheers, >> Robb. >> >> > > Disable uftdi in your kernel config (boot -c, disable uftdi, quit) and > see if that works. The device is attaching as a serial port, but libftdi > probably wants it attaching to ugen. If that helps maybe we can add a > quirk to knock out just this device. Send usbdevs -v output. ...from another little look - If disabling the uftdi device doesn't help then run it under ktrace, kdump to a text file, and send 1000 or so lines from before it prints "read failed". But there's a good chance disabling uftdi will do the trick, the code clearly has some degree of OpenBSD support already. > The FreeBSD makefile shouldn't be a problem. Most of the code behind the > linux --dev-random support would work too but it will need some changes > (get rid of the RNDGETENTCNT ioctl.and just use a timer) or you could > run it periodically and feed stdout into /dev/random (infnoise | cut > -c1-512 > /dev/random or similar would probably do the trick). ...and actually --dev-random may just work as-is once it is able to talk to the device.
Re: OpenBGPd announce fulltables +default
On 2020-06-22, Tom Smyth wrote: > Hello, > I notice that in the current manual > there is an option to export none, default-route with the > explanation below in the manual > > export (none|default-route)If set to none, no UPDATE messages will be > sent to the neighbor. If set to default-route, only the default route > will be announced to the neighbor. When export is modified the > neighbor session needs to be reset to become active. > > I was wondering is there an easy way to announce the default + full > tables for BGP customers who want to choose to migrate from default > routing to full table without contacting me ... > > something inside me says it would be wrong to add 0.0.0.0/0 network > (although if memory serves me correctly previous versions of OpenBGPd > would politely decline to do that :) and filter the crap out of that > for upstream Transit and Peers (non Customers ) ... > Adding to networks is exactly how you do this. For filters I would do this in a similar way to "mynetworks" in the example config (with a different prefix-set and controlled by a different community number) then you can enable/disable it easily per peer. Don't filter it *out* though - default to not sending anything and just permit it to the relevant peers.
Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?
On 2020-06-23, Why 42? The lists account. wrote: > > Hi All, > > Has anyone ever tried the Infinite Noise TRNG hardware random number generator > with OpenBSD? > > It's a USB stick that contains hardware to generate random numbers. See: > https://github.com/13-37-org/infnoise > > I had a couple of these working with ArchLinux and would like to try using > them with OpenBSD. > > Using either 6.6 or 6.7 the device is recognised at boot time: >> uftdi0 at uhub0 port 2 configuration 1 interface 0 "13-37.org Infinite Noise >> TRNG" rev 2.00/10.00 addr 3 ucom0 at uftdi0 portno 1 > > With libftdi1-1.4p2 installed I was able to compile the associated software > using the supplied "Makefile.freebsd". So a pretty easy start ... >> make -f Makefile.freebsd >> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >> -DGIT_DATE=\"\" -c libinfnoise.c >> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >> -DGIT_DATE=\"\" -c healthcheck.c >> cc -c -o KeccakF-1600-reference.o Keccak/KeccakF-1600-reference.c -Wall >> -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I /usr/local/include/libftdi1 >> -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" -DGIT_DATE=\"\" >> ar rcs libinfnoise.a libinfnoise.o healthcheck.o KeccakF-1600-reference.o >> ranlib libinfnoise.a >> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >> -DGIT_DATE=\"\" -fvisibility=hidden -o libinfnoise.so libinfnoise.o >> healthcheck.o KeccakF-1600-reference.o -L /usr/local/lib -Wl -lftdi1 -lm >> -shared >> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >> -DGIT_DATE=\"\" -c infnoise.c >> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >> -DGIT_DATE=\"\" -c daemon.c >> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I >> /usr/local/include/libftdi1 -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" >> -DGIT_DATE=\"\" -o infnoise infnoise.o daemon.o libinfnoise.a -lftdi1 -lm >> -L. -L /usr/local/lib > > This creates an executable "driver" called infnoise which can be run as a > daemon e.g. >> doas ./infnoise -h >> Usage: infnoise [options] >> Options are: >> -D, --debug - turn on some debug output >> -R, --dev-random - write entropy to /dev/random instead of stdout >> -r, --raw - do not whiten the output >> -m, --multiplier - write 256 bits * value for each 512 bits >> written to >> the Keccak sponge. Default of 0 means write all the entropy. >> -n, --no-output - do not write random output data >> -p, --pidfile - write process ID to file >> -d, --daemon - run in the background >> -s, --serial - use specified device >> -l, --list-devices - list available devices >> -v, --version - show version information >> -h, --help - this help output >> ... > > The "list-devices" mode works nicely: >> doas ./infnoise --list-devices >> ... >> ID: 0, Manufacturer: 13-37.org, Description: Infinite Noise TRNG, Serial: >> 1337-ECA4E8A6 > > So far, so good ... But if I try getting actual random numbers, I get "read > failed": >> doas ./infnoise >> ... >> Error: USB read failed > > Any suggestions? Where am I going wrong? Maybe I shouldn't have taken that > shortcut with the freebsd makefile? Or a security issue? > > Thanks in advance. > > Cheers, > Robb. > > Disable uftdi in your kernel config (boot -c, disable uftdi, quit) and see if that works. The device is attaching as a serial port, but libftdi probably wants it attaching to ugen. If that helps maybe we can add a quirk to knock out just this device. Send usbdevs -v output. The FreeBSD makefile shouldn't be a problem. Most of the code behind the linux --dev-random support would work too but it will need some changes (get rid of the RNDGETENTCNT ioctl.and just use a timer) or you could run it periodically and feed stdout into /dev/random (infnoise | cut -c1-512 > /dev/random or similar would probably do the trick).
Re: XFCE menu does not load with keyboard shortcut
On Tue, Jun 23, 2020 at 07:33:20PM +0100, Ed Gray wrote: Hi, I have an issue with XFCE on OpenBSD 6.6 and current on an amd64 system. XFCE works fine except for accessing the applications menu with the Alt + F1 keyboard shortcut. Instead of loading the menu it gets highlighted in grey and nothing happens. Clicking the menu loads it straight away. The shortcut is defined in the keyboard settings as the default for xfce4-popup-applicationsmenu which is different from the shortcut for the desktop menu. Sometimes in another application such as firefox when I press Alt + F1 a second time I get the desktop menu appear, even though firefox is maximised and I'm not on the desktop. I can't confirm at the moment if it is specific to OpenBSD or XFCE in general. Does anyone else have this problem? Have seen this on Void Linux as well. Family member needed Netflix on her laptop, so I couldn't push OpenBSD, even though it ran fine. (Had to check, and by the way, it was surprising to see how much slower it ran compared to Alpine or Void.) But this is an older Xfce bug, I remember having similar issues when I last gave it a shot. This used to work reliably in older versions though, back when Xfce was based on GTK+ 2.x. To end in a positive note, one thing I learned on my OpenBSD adventure is "the best desktop is no desktop". cwm never fails to open its menus. Keep it stupid simple.
Re: Potential grep bug?
Nope. This is a grep of a single file, so procfile() must be overflowing
and this only 'fixes' it by relying on signed overflow, which is undefined
behavior, being handled in a particular way by the compiler. So, luck
(which fails when the compiler decides to hate you). There are more places
that need to change for the reported problem to be handled safely.
Philip Guenther
On Tue, Jun 23, 2020 at 9:58 PM Martijn van Duren <
open...@list.imperialat.at> wrote:
> This seems to fix the issue for me.
>
> OK?
>
> martijn@
>
> On Tue, 2020-06-23 at 19:29 -0700, Jordan Geoghegan wrote:
> > Hello,
> >
> > I was working on a couple POSIX regular expressions to search for and
> > validate IPv4 and IPv6 addresses with optional CIDR blocks, and
> > encountered some strange behaviour from the base system grep.
> >
> > I wanted to validate my regex against a list of every valid IPv4
> > address, so I generated a list with a zsh 1 liner:
> >
> > for i in {0..255}; do; echo $i.{0..255}.{0..255}.{0..255} ; done |
> > tr '[:space:]' '\n' > IPv4.txt
> >
> > My intentions were to test the regex by running it with 'grep -c' to
> > confirm there was indeed 2^32 addresses matched, and I also wanted to
> > benchmark and compare performance between BSD grep, GNU grep and
> > ripgrep. The command I used:
> >
> > grep -Eoc
> >
> "((25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])(/[1-9]|/[1-2][[:digit:]]|/3[0-2])?"
> >
> > My findings were surprising. Both GNU grep and ripgrep were able get
> > through the file in roughly 10 and 20 minutes respectively, whereas the
> > base system grep took over 20 hours! What interested me the most was
> > that the base system grep when run with '-c' returned '0' for match
> > count. It seems that 'grep -c' will have its counter overflow if there
> > are more than 2^32-1 matches (4294967295) and then the counter will
> > start counting from zero again for further matches.
> >
> > ryzen$ time zcat IPv4.txt.gz | grep -Eoc
> "((25[0-5]|(2[0-4]|1{0,1}...
> > 0
> > 1222m09.32s real 1224m28.02s user 1m16.17s system
> >
> > ryzen$ time zcat allip.txt.gz | ggrep -Eoc
> "((25[0-5]|(2[0-4]|1{0,1}...
> > 4294967296
> > 10m00.38s real11m40.57s user 0m30.55s system
> >
> > ryzen$ time rg -zoc "((25[0-5]|(2[0-4]|1{0,1}...
> > 4294967296
> > 21m06.36s real27m06.04s user 0m50.08s system
> >
> > # See the counter overflow/reset:
> > jot 4294967350 | grep -c "^[[:digit:]]"
> > 54
> >
> > All testing was done on a Ryzen desktop machine running 6.7 stable.
> >
> > The grep counting bug can be reproduced with this command:
> > jot 4294967296 | nice grep -c "^[[:digit:]]"
> >
> > Regards,
> >
> > Jordan
> >
> Index: util.c
> ===
> RCS file: /cvs/src/usr.bin/grep/util.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 util.c
> --- util.c 3 Dec 2019 09:14:37 - 1.62
> +++ util.c 24 Jun 2020 06:46:52 -
> @@ -106,7 +106,8 @@ procfile(char *fn)
> {
> str_t ln;
> file_t *f;
> - int c, t, z, nottext;
> + int t, z, nottext;
> + unsigned long long c;
>
> mcount = mlimit;
>
> @@ -169,7 +170,7 @@ procfile(char *fn)
> if (cflag) {
> if (!hflag)
> printf("%s:", ln.file);
> - printf("%u\n", c);
> + printf("%llu\n", c);
> }
> if (lflag && c != 0)
> printf("%s\n", fn);
>
>
