Re: "Missing operating system" after i386 dual boot install
On Sat, Aug 4, 2018 at 7:00 PM Sijmen J. Mulder wrote: > After booting the PC pauses for a few seconds before displaying "Missing > operating system". > > What I've tried: > - "boot hd0a:/bsd" from the installation CD: works > - mark partition 0 active: works, brings up NT's bootloader > - "installboot -v wd0": no change > > Any ideas? Boot the install CD, and run 'machine boot hd0c'. This will boot the OpenBSD partition directly, without involving the MBR. (With 'machine boot', hd0a..hd0d are the fdisk partitions, not BSD disklabel entries, so e.g. 'machine boot hd0a' should boot NT.) If that works: the OpenBSD boot loader in its partition is fine, but the MBR is not loading it correctly. Installing new MBR code, e.g. 'fdisk -u wd0', may help. If it doesn't (unlikely, since NTLDR works with the PBR): there is a problem with the PBR, or with the BIOS's ability to boot from it. Using the NT loader menu may end up being a better solution for you, but this should sort out the direct-boot case. -Andrew
PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels
Hi list, I use an OpenVPN based internet access service (like NordVPN, AirVPN etc). The issue with these public VPN services, is the VPN servers are always congested. The most I’ll get is maybe 10Mbits through one server. Local connection is a few hundred mbps.. So I had the idea of running multiple openvpn tunnels to different servers, and load balancing outbound traffic across the tunnels. Sounds simple enough.. However every vpn tunnel uses the same subnet and nexthop gw. This of course won’t work with normal routing. So my question: How can I use rdomains or rtables with openvpn clients, so that each VPN is started in its own logical VRF? And is it then a case of just using PF to push the outbound packets into the various rdomains/rtables randomly (of course maintaining state)? LAN interface would be in the default rdomain/rtable.. My confusion is that an interface needs to be bound to the logical VRF, but the tunX interfaces are created dynamically by openvpn. So I am not sure how to configure this within hostname.tunX etc, or if I’m even approaching this correctly? Thanks, Andy.
Re: pledge & unveil
Also worth searching YouTube for "openbsd pledge" and/or "openbsd unveil". There's at least four talks by Theo on pledge and a recent presentation by Bob Beck on pledge/unveil, as well as many others. On Sun, Oct 21, 2018 at 3:02 PM Heinz Kampmann wrote: > Hello, > > is there a paper on the web that explains work and relationship > from pledge and unveil for dummies? > > Best wishes, > Heinz > > -- andrew fabbro and...@fabbro.org
Cannot mount install.fs disk image to create custom auto_install.conf based USB flash drive
Hi list, I really need some help mounting an install.fs disk image, and hope someone can help :) I have been trying and failing to create an auto-installing USB flash drive for OpenBSD. All of the below steps are being performed using an existing OpenBSD VM 1) Create /auto_install.conf file https://man.openbsd.org/autoinstall http://eradman.com/posts/autoinstall-openbsd.html - Done 2) Install 'upobsd' package pkg_add -i upobsd - Done 3) Inject newly created 'auto_install.conf' into a local 'bsd.rd' RAM disk upobsd -u /auto_install.conf -o /tmp/bsd.rd - Done 4) Add updated 'bsd.rd' file into 'install.fs' 4a) Associate image with a vnd device so disk image can be mounted as a filesystem image vnconfig vnd1 /home/sysadmin/install64.fs - Done 4b) Mount new vnd1c device (this is where I'm stuck) ** Here is where I get lost. All the guides refer only to using install.iso (whos 'a:' and 'c:' partitions are ISO9660 filetypes - for CD based installs), but I need to use the install.fs (for USB based installs) ** fw1# mount /dev/vnd1c /mnt mount_ffs: /dev/vnd1c on /mnt: Invalid argument fw1# mount -t cd9660 /dev/vnd1c /mnt mount_cd9660: /dev/vnd1c on /mnt: Invalid argument fw1# mount -t msdos /dev/vnd1c /mnt mount_msdos: /dev/vnd1c on /mnt: not an MSDOS filesystem fw1# mount -t ext2fs /dev/vnd1c /mnt mount_ext2fs: /dev/vnd1c on /mnt: Input/output error As you can see, none of the the types I know about are working? bsd1# disklabel vnd1 # /dev/rvnd1c: type: vnd disk: vnd device label: fictitious duid: e5445c1e269855f0 flags: bytes/sector: 512 sectors/track: 100 tracks/cylinder: 1 sectors/cylinder: 100 cylinders: 7382 total sectors: 738240 boundstart: 1024 boundend: 737280 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 736256 1024 4.2BSD 2048 16384 16142 c: 7382400 unused i: 960 64 MSDOS I cannot work out what the filesystem should be? It shows as 'unused' here. NB; If I try with the 'install.iso' disk image the vnd mount works fine (with '-t cd9660'). But I need this to work for a flash drive? Assuming I could get past this, I think I would then need to do the following; 4c) Copy in bsd.rd cp /tmp/bsd.rd /mnt/ 4d) Unmount /mnt umount /mnt 4e) Disassociate vnd1 vnconfig -u /dev/vnd1 6) copy modified install.fs image to USB flash.. dd if=install*.fs of=/dev/rsd6c bs=1m Thanks in advance for your time and help. Andy.
Intel Celeron SoC support
Hi, I am running an ASRock J4105B-ITX board and wanting to run OpenBSD on this. https://www.asrock.com/MB/Intel/J4105B-ITX/index.asp#BIOS It boots up, and at the 'boot>' prompt I can use the keyboard find. However after it boots up, the keyboard stops working, and no disks are found by the installer (used auto_install to send test commands). It appears that there is no chipset support, for the Intel Celeron J4105 CPU from what I can work out. To test that it was working fine and is just OpebBSD which is not working, I installed Linux and have included the dmesg below (from Linux). I cannot run a dmesg from the OpenBSD installer as I cannot use the keyboard etc. Will support come for this SoC architecture? Or am I better of selling this board? Think its a Gemini Lake SoC Chipset; [0.00] Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27) [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 root=/dev/mapper/virt1--vg-root ro quiet intel_iommu=on [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[3]: 576, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 640, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0003dfff] usable [0.00] BIOS-e820: [mem 0x0003e000-0x0003] reserved [0.00] BIOS-e820: [mem 0x0004-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0fff] usable [0.00] BIOS-e820: [mem 0x1000-0x12150fff] reserved [0.00] BIOS-e820: [mem 0x12151000-0x76d93fff] usable [0.00] BIOS-e820: [mem 0x76d94000-0x7963dfff] reserved [0.00] BIOS-e820: [mem 0x7963e000-0x7968efff] usable [0.00] BIOS-e820: [mem 0x7968f000-0x796b6fff] ACPI NVS [0.00] BIOS-e820: [mem 0x796b7000-0x799eafff] reserved [0.00] BIOS-e820: [mem 0x799eb000-0x79a9bfff] type 20 [0.00] BIOS-e820: [mem 0x79a9c000-0x7a4c1fff] usable [0.00] BIOS-e820: [mem 0x7a4c2000-0x7a56dfff] reserved [0.00] BIOS-e820: [mem 0x7a56e000-0x7abf] usable [0.00] BIOS-e820: [mem 0x7ac0-0x7fff] reserved [0.00] BIOS-e820: [mem 0xd000-0xd0ff] reserved [0.00] BIOS-e820: [mem 0xd3709000-0xd3709fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe042000-0xfe044fff] reserved [0.00] BIOS-e820: [mem 0xfe90-0xfe902fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.60 by American Megatrends [0.00] efi: ACPI 2.0=0x7968f000 ACPI=0x7968f000 SMBIOS=0x79948000 SMBIOS 3.0=0x79947000 ESRT=0x75cce798 MEMATTR=0x73b5e098 [0.00] SMBIOS 3.1.1 present. [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x18 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00FF00 mask 7FFF00 write-combining [0.00] 1 base 00 mask 7F8000 write-back [0.00] 2 base 007B00 mask 7FFF00 uncachable [0.00] 3 base 007C00 mask 7FFC00 uncachable [0.00] 4 base 01 mask 7F8000 write-back [0.00] 5 base 009000 mask 7FF000 write-combining [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration
Re: PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels
all outbound traffic
match out on $if_ext from any to any nat-to ($if_ext)
match out on tun1 from any to any nat-to (tun1) rtable 1
match out on tun2 from any to any nat-to (tun2) rtable 2
#Allow outbound traffic on egress for vpn tunnel setup etc
pass out quick on { $if_ext } from self to any set prio (3,6)
#Load balance outbound traffic from internal network across tun1 and tun2 -
THIS IS NOT WORKING - IT ONLY USES FIRST TUNNEL
pass in quick on { $if_int } to any route-to { (tun1 10.8.8.1), (tun2
10.8.8.1) } round-robin set prio (3,6)
#Allow outbound traffic over vpn tunnels
pass out quick on tun1 to any set prio (3,6)
pass out quick on tun2 to any set prio (3,6)
# Verify which tunnels are being used
systat ifstat
*This command shows that all the traffic is only flowing over the first
tun1 interface, and the second tun2 is never ever used.*
# NB; I have tried with and without 'set state-policy if-bound'.
I have tried all the load balancing policies; round-robin, random,
least-states and source-hash
If I change the 'route-to' pool to "{ (tun2 10.8.8.1), (tun1 10.8.8.1) }",
then only tun2 is used instead.. :(
So 'route-to' seems to only use the first tunnel in the pool.
Any advice on what is going wrong here. I am wondering if I am falling
victim to some processing-order issue with PF, or if this is a real bug?
Thanks, Andy.
On Wed, Sep 12, 2018 at 5:58 PM Stuart Henderson
wrote:
> On 2018-09-11, Andrew Lemin wrote:
> > Hi list,
> >
> > I use an OpenVPN based internet access service (like NordVPN, AirVPN
> etc).
> >
> > The issue with these public VPN services, is the VPN servers are always
> congested. The most I’ll get is maybe 10Mbits through one server.
> >
> > Local connection is a few hundred mbps..
> >
> > So I had the idea of running multiple openvpn tunnels to different
> servers, and load balancing outbound traffic across the tunnels.
> >
> > Sounds simple enough..
> >
> > However every vpn tunnel uses the same subnet and nexthop gw. This of
> course won’t work with normal routing.
>
> rtable/rdomain with openvpn might be a bit complex, I think it may need
> persist-tun and create the tun device in advance with the wanted rdomain.
> (you need the VPN to be in one, but the UDP/TCP connection in another).
>
> Assuming you are using tun (and so point-to-point connections) rather
> than tap, try one or other of these:
>
> - PF route-to and 'probability', IIRC it works to just use a junk
> address as long as the interface is correct ("route-to 10.10.10.10@tun0",
> "route-to 10.10.10.10@tun1").
>
> - ECMP (net.inet.ip.multipath=1) and multiple route entries with
> the same priority. Use -ifp to set the interface ("route add
> default -priority 8 -ifp $interface $dest").
>
> The "destination address" isn't really very relevant for routing
> on point-to-point interfaces (though current versions of OpenBSD
> do require that it matches the destination address on the interface,
> otherwise they won't allow the route to be added).
>
>
>
Re: Intel Celeron SoC support
Hi Chris, I decided to sell the board and get a different one.. But for others wanting to use this board in the future. I tried both USB and PS2 Native (no adapter) keyboards. Neither work after the installer starts. Bearing in mind none of the SATA ports are detected either.. Cheers, Andy. On Wed, Nov 21, 2018 at 3:42 AM Chris Cappuccio wrote: > Andrew Lemin [andrew.le...@gmail.com] wrote: > > Hi, > > > > I am running an ASRock J4105B-ITX board and wanting to run OpenBSD on > this. > > https://www.asrock.com/MB/Intel/J4105B-ITX/index.asp#BIOS > > > > It boots up, and at the 'boot>' prompt I can use the keyboard find. > > > > However after it boots up, the keyboard stops working, and no disks are > > found by the installer (used auto_install to send test commands). > > It appears that there is no chipset support, for the Intel Celeron J4105 > > CPU from what I can work out. > > > > To test that it was working fine and is just OpebBSD which is not > working, > > I installed Linux and have included the dmesg below (from Linux). > > I cannot run a dmesg from the OpenBSD installer as I cannot use the > > keyboard etc. > > > > The ASRock J4205-ITX (Apollo Lake) works fine, so does the J3710-ITX > (Braswell). > > I use them both headless, but they work fine when I plug in a USB keyboard. > > The J4105-ITX (Gemini Lake) is newer than either. > > What kind of keyboard are you using? If it's not USB, plug in a USB > keyboard. > Although it may not work at the boot> prompt, it will work once you are > booted > up. > > For fun, here are dmesg for the older versions of your board. They both > work > with USB input devices. > > Braswell > > > OpenBSD 6.3-current (GENERIC.MP) #21: Fri Jun 29 17:32:47 PDT 2018 > ch...@r8.nmedia.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8023584768 (7651MB) > avail mem = 7771283456 (7411MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecec0 (18 entries) > bios0: vendor American Megatrends Inc. version "P1.30" date 03/30/2016 > bios0: ASRock J3710-ITX > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT AAFT MCFG HPET SSDT SSDT SSDT UEFI > LPIT CSRT > acpi0: wakeup devices UAR1(S4) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4) > PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) BRCM(S0) PWRB(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.37 MHz > cpu0: > 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN > cpu0: 1MB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 79MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.00 MHz > cpu1: > 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN > cpu1: 1MB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.00 MHz > cpu2: > 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN > cpu2: 1MB 64b/line 16-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.00 MHz > cpu3: > 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN > cpu3: 1MB 64b/line 16-way L2 cache > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec
Re: openbsd 6.4 as guest VM on Xen cannot detect disk
I have no idea what is causing your backend timeout, but your VM config would be useful information, and take a look at xend.log etc. on the host for any related errors (if you have access to it). I'm running OpenBSD 6.4 just fine under Xen; however my Dom0 is only 4.4.4 (dmesg attached). Note that in your 6.0 dmesg, you have "wd0 at pciide0" vs. my "sd0 at scsibus1" via "scsibus1 at xbf0"; the man page for xbf(4) indicates it was added in 6.1, and that it takes over all virtual disks. As a workaround, you might try boot -c and disable xbf, which would presumably present your disk via the emulated IDE controller. -Andrew OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1015713792 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries) bios0: vendor Xen version "4.4.4_34-61.32.1" date 08/17/2018 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2993.06 MHz, 06-17-06 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.68 MHz, 06-17-06 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.4 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4 "vfb" at xen0: device/vfb/0 not configured xbf0 at xen0 backend 0 channel 6: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 4096MB, 512 bytes/sector, 8388608 sectors xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28 xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98 "console" at xen0: device/console/0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown
Re: Automated remote install
On Tue, Dec 18, 2018 at 1:03 AM Frank Beuth wrote: > On Mon, Dec 17, 2018 at 02:35:41PM -0200, Daniel Bolgheroni wrote: > >If you're going to run on some public cloud, they usually offer the > >possibility of keeping a custom image you provide, and use this image to > >deploy new VMs based on it. > > "usually" being the key word here :) > Virtually all of the better KVM hosts offer an OpenBSD ISO, and in my experience, 100% will add it to their library if you request it. Note that I'm referring to KVM providers (traditional VPS providers), not "public cloud". The big boys - AWS, Azure, Google, etc. are not interested in OpenBSD. The mid-tier players - DigitalOcean, Vultr, Linode - are semi-interested. Vultr offers it natively. You can shim on Linode or DO but why bother then the main field of KVM players (there are thousands) offer it. If you search for a VPS provider that offers KVM (not OpenVZ, VIrtuozzo, or Xen) you will find many. -- andrew fabbro and...@fabbro.org
Release schedule/general product engineering
One of the key strengths of OpenBSD that it is well engineered - and consequently robust and reliable. Management of the release engineering is key to this. (Cathedral, not bizarre). However, release engineering is no longer mentioned on the home page of www.openbsd.org, and I could find no mention of it anywhere on the site. I wanted to know approximately when the next release would be available to decide whether to install 6.8, a snapshot or wait for 6.9 for a machine I have prepped and am going to configure "real soon now". I also can no longer find architecture-specific change logs (to see if work has been done that might affect Sparc64 installs, and make things different from when I installed 6.8 on this hardware last time). *** I think it is worth making this info more visible both for existing users (eg me) and potential future users *** I believe there will be future users (Netcraft notwithstanding) - people are often p'd off by other operating systems introducing new features they don't need which clobber the old ones they do - and might want to know there is a better way! (Even if they don't use Sparc64). [Written in anticipation of a general drift away from Intel and towards Arm by both server and workstation users]. There is also the possibility that people who have been hit by malware might want a more secure solution. regards Andrew
Re: Sparc64 LDOM not working past OpenBSD 6.5
I have a T1000, and it runs 6.9 in primary and 7 guests. However, attempts to create and install a new ldom config result in complete loss of the device tree, and consequent inability to boot. restore to factory, and then restore the ldom config created with OBSD 6.3 will produce a working system. This system is available and currently could be used for testing, although not on the public internet, and only during office hours in Europe/London timezone - machine must be shut down out of office hours. Andrew . On Wed, 12 May 2021 at 03:22, Ax0n wrote: > > I have a SunFire T2000 that I originally installed 6.1 on. I set up LDOMs > way back in May 2017. I kept all of the domains up to date until OpenBSD > 6.6. After that, LDOMs would no longer work. The system would not boot > unless I reverted back to the single domain default using > bootmode config="factory-default" > > I kind of just forgot about the machine until 6.7 came out. I upgraded, and > got the same errors upon trying to boot. I re-generated the LDOM config as > outlined in this blog post I wrote: > > http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html > > That is, I dumped the factory-default config, used it as a template for the > new LDOM configuration, edited a config file, applied the config to the > directory and used ldomctl download to apply the LDOM config before > resetting the system. > > Specifically, the errors I get now (and yes, some are repeats, but it's ALL > I get from the console while booting) are: > > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4 > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4 > ERROR: /pci@780: Invalid hypervisor argument(s). function: b5 > WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node > WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node > > And after that, the system hangs and I must exit to the ALOM system > controller prompt to do anything further, such as revert the configuration > and reset to make the system able to boot again. > > I searched and found one other person with this problem a while back ago, > but no resolution. I have hardware right here in front of me and I'm not > afraid to run -CURRENT and/or test patches to help. I am also willing to > provide remote SSH access to the system controller if someone wants to hack > on the hardware directly if it would help, though I think there are a few > LDOM-capable sparc64 machines in developers' hands already. > > dmesg: > console is /virtual-devices@100/console@1 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2021 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.9 (GENERIC.MP) #794: Sun Apr 18 12:34:31 MDT 2021 > dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP > real mem = 34225520640 (32640MB) > avail mem = 33608228864 (32051MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root: Sun Fire T200 > cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu2 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu3 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu4 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu5 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu6 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu7 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu8 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu9 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu10 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu11 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu12 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu13 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu14 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu15 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu16 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu17 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu18 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu19 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu20 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu21 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu22 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu23 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu24 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu25 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu26 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz >
altroot weekly.local
Is there any problem with putting ROOTBACKUP=1 in my weekly.local instead of daily.local? I'm backing up to an SD card and it's maybe not fast enough to back up in 24 hours, plus weekly backup would be fine. Many thanks.
Re: C style in OpenBSD
When you write code by yourself: On Tue, Jun 29, 2021 at 6:15 AM Reuben ua Bríġ wrote: > a style i came up with in imitation of some disgusting haskell code. When you write code with others: On Wed, Jun 30, 2021 at 7:34 AM Todd C. Miller wrote: > It is because consistency makes the code > easier to read for anyone familiar with that style. Part of that > means using common idioms that are immediately recognizable by > someone familiar with the style. This reduces the amount of time > is takes someone to understand the code. -- andrew fabbro and...@fabbro.org
Re: X11 SIGSEGV on VirtualBox
On Fri, Jun 18, 2021 at 3:24 PM Chris Narkiewicz wrote: > > I'm trying to run xenodm on VirtualBox VM. > VirtualBox 6.1.16_Ubuntu r140961 running on Ubuntu 20.04 with Intel > card. VM uses VMSVGA display with NO 3D acceleration. > > Fresh OpenBSD 6.9 install, but I tried latest snapshot - same problem. > > When starting Xorg server, it crashes with SIGSEGV. Does anybody know > why it happens? How can I generate some actionable debug output, such > as stacktrace, to help identify root cause? See the "How to get a core file out of the X server?" section of the Xenocara README [1]. You can then load Xorg and the core file into gdb/lldb. I think ports egdb may do better in some cases? Others who are more knowledgeable can weigh in on that. Potential workarounds: use the "vesa" X driver instead of "vmware"? I think VBox supports that but I don't remember. Another option is efifb/wsfb, which of course requires configuring the VM for UEFI mode and reinstalling. Both probably have lower performance though. -Andrew [1] https://github.com/openbsd/xenocara
Re: Raspberry Pi 4 Model B
Have you read the Raspberry Pi instructions from https://ftp.openbsd.org/pub/OpenBSD/6.9/arm64/INSTALL.arm64 ? What does your UART output show after it boots? Andrew On Fri, Sep 24, 2021 at 2:45 PM Joseph Olatt wrote: > Hi, > > I'm trying to load OpenBSD on a Raspberry Pi 4 Model B and I'm not > having much luck. I've tried OpenBSD 6.9's miniroot69.img and the > install process does not go past the U-Boot prompt. > > I tried miniroot70.img from the snapshots directory, as of today, and > after displaying the following line: > > bwfm0: failed loadfirmware of file > brcmfmac43455-sdio.raspberrypi,4-model-b.bin > > it reboots. > > Anybody else have success installing OpenBSD on this particular > hardware? Any insights or suggestions? > > Thank you. > joseph > >
Re: PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels
Hi. Sorry for extremely slow reply! Did you add the return routes for your internal subnets into each of the per-tun rdomains? To test your tunnels are setup correctly; Once you have the external interface in rdomain 0, and each VPN instance's tun interface is bound to different rdomains etc, you can test that your tunnel setup is working within the rdomain with "ping -V1 1.1.1.1" (to originate a ping within rdomain 1 for example). If the ping works, but gets lost when routing through the interface pair ( https://man.openbsd.org/pair), then check the routing table in rdomain 1 with "route -T1 show". Your tunnel will be the default gateway within that rdomain, but you will still need routes in the rdomain to get the return packets back to your internal networks. For this in my /etc/hostname.pair1 interface (pair interface that sits in rdomain 1), I add the line "!/sbin/route -T1 add 172.16.0.0/12 192.168.251.2" (where 192.168.251.2 is the IP for the peer-pair interface that sits in my internal rdomain 1). On Wed, May 8, 2019 at 12:09 AM mike42 wrote: > Trying to replicate same setup with pairs and different rdomains for each > tun > and also external interface, after a packet goes through pair interfaces > it's just disapears. > > Any ideas? > > routing in rdomain is set like: > > route -T add default tun > route -T add > > > > > > -- > Sent from: > http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html > >
Mellanox driver support details https://man.openbsd.org/mcx.4
Hi. I hope everyone is well and having a great day :) Just a quick question about the mcx (Mellanox 5th generation Ethernet device) drivers https://man.openbsd.org/mcx.4 The man page says nothing more than it supports; ConnectX-4 Lx EN ConnectX-4 EN ConnectX-5 EN ConnectX-6 EN I am looking for some clarity on what features and performance characteristics mcx boasts? For example are the following basic hardware features supported by this driver? IPv4 receive IP/TCP/UDP checksum offload IPv4 transmit TCP/UDP checksum offload VLAN tag insertion and stripping interrupt coalescing And what other features does it support? I also came across a comment in some forum a while back (so high quality information 😉) that mentioned Mellanox drivers in OpenBSD are SMP safe and so not giant-locked. Is this true? Thanks, Andy,
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
I see this question died on its arse! :) This is still an issue for outbound load-balancing over multiple internet links. PF's 'sticky-address' parameter only works on source IPs (because it was originally designed for use when hosting your own server pools - inbound load balancing). I.e. There is no way to configure 'sticky-address' to consider destination IPs for outbound load balancing, so all subsequent outbound connections to the same target IP originate from the same internet connection. The reason why this is desirable is because an increasing number of websites use single sign on mechanisms (quite a few different architectures expose the issue described here). After a users outbound connection is initially randomly load balanced onto an internet connection, their browser is redirected into opening multiple additional sockets towards the website's load balancers / cloud gateways, which redirect the connections to different internal servers for different parts of the site/page, and the SSO authentication/cookies passed on the additional sockets must to originate from the same IP as the original socket. As a result outbound load-balancing does not work for these sites. The ideal functionality would be for 'sticky-address' to consider both source IP and destination IP after initially being load balanced by round-robin or random. Thanks again, Andy. On Sat, Apr 3, 2021 at 12:40 PM Andy Lemin wrote: > Hi smart people :) > > The current implementation of ‘sticky-address‘ relates only to a sticky > source IP. > https://www.openbsd.org/faq/pf/pools.html > > This is used for inbound server load balancing, by ensuring that all > socket connections from the same client/user/IP on the internet goes to the > same server on your local server pool. > > This works great for ensuring simplified memory management of session > artefacts on the application being hosted (the servers do not have to > synchronise the users session data as extra sockets from that user will > always connect to the same local server) > > However sticky-address does not have an equivalent for sticky destination > IPs. For example when doing outbound load balancing over multiple ISP > links, every single socket is load balanced randomly. This causes many > websites to break (especially cookie login and single-sign-on style > enterprise services), as the first outbound socket will originate randomly > from one of the local ISP IPs, and the users login session/SSO (on the > server side) will belong to that first random IP. > > When the user then browses to or uses another part of that same website > which requires additional sockets, the additional sockets will pass the SSO > credentials from the first socket, but the extra socket connection will > again be randomly load-balanced, and so the remote server will reject the > connection as it is originating from the wrong source IP etc. > > Therefore can I please propose a “sticky-address for destination IPs” as > an analogue to the existing sticky-address for source IPs? > > This is now such a problem that we have to use sticky-address even on > outbound load-balancing connections, which causes internal user1 to always > use the same ISP for _everthing_ etc. While this does stop the breakage, it > does not result in evenly distributed balancing of traffic, as users are > locked to one single transit, for all their web browsing for the rest of > the day after being randomly balanced once first-thing in the morning, > rather than all users balancing over all transits throughout the day. > > Another pain; using the current source-ip sticky-address for outbound > balancing, makes it hard to drain transits for maintenance. For example > without source sticky-address balancing, you can just remove the transit > from the Pf rule, and after some time, all traffic will eventually move > over to the other transits, allowing the first to be shut down for whatever > needs. But with the current source-ip sticky-address, that first transit > will take months to drain in a real-world situations.. > > lastly just as a nice-to-have, how feasible would a deterministic load > balancing algorithm be? So that balancing selection is done based on the > “least utilised” path? > > Thanks for your time and consideration, > Kindest regards Andy > > > > Sent from a teeny tiny keyboard, so please excuse typos. >
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
Hi Theo :) Ok sure, I will put on my cape-of-courage and start reading the source.. I may be some time! On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt wrote: > We tend to keep our driver manual pages without detailed promises. > They do ethernet, they do it best effort, etc. > > What you want to know can be found by reading the source, or the > commit logs. Since this is a locally written driver, the code is > surprisingly approachable. > > Andrew Lemin wrote: > > > Hi. I hope everyone is well and having a great day :) > > > > Just a quick question about the mcx (Mellanox 5th generation Ethernet > > device) drivers > > https://man.openbsd.org/mcx.4 > > > > The man page says nothing more than it supports; > > ConnectX-4 Lx EN > > ConnectX-4 EN > > ConnectX-5 EN > > ConnectX-6 EN > > > > I am looking for some clarity on what features and performance > > characteristics mcx boasts? > > > > For example are the following basic hardware features supported by this > > driver? > > IPv4 receive IP/TCP/UDP checksum offload > > IPv4 transmit TCP/UDP checksum offload > > VLAN tag insertion and stripping > > interrupt coalescing > > > > And what other features does it support? > > > > I also came across a comment in some forum a while back (so high quality > > information 😉) that mentioned Mellanox drivers in OpenBSD are SMP safe > and > > so not giant-locked. Is this true? > > > > Thanks, Andy, >
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
Hi Claudio,
So you probably guessed I am using 'route-to { GW1, GW2, GW3, GW4 } random'
(and was wanting to add 'sticky-address' to this) based on your reply :)
"it will make sure that selected default routes are sticky to source/dest
pairs" - Are you saying that even though multipath routing uses hashing to
select the path (https://www.ietf.org/rfc/rfc2992.txt - "The router first
selects a key by performing a hash (e.g., CRC16) over the packet header
fields that identify a flow."), subsequent new sessions to the same dest IP
with different source ports will still get the same path? I thought a new
session with a new tuple to the same dest IP would get a different hashed
path with multipath?
"On rerouting the multipath code reshuffles the selected routes in a way to
minimize the affected sessions." - Are you saying, in the case where one
path goes down, it will migrate all the entries only for that failed path
onto the remaining good paths (like ecmp-fast-reroute ?)
Thanks for your time, Andy.
On Wed, Sep 29, 2021 at 5:21 PM Claudio Jeker
wrote:
> On Wed, Sep 29, 2021 at 02:17:59PM +1000, Andrew Lemin wrote:
> > I see this question died on its arse! :)
> >
> > This is still an issue for outbound load-balancing over multiple internet
> > links.
> >
> > PF's 'sticky-address' parameter only works on source IPs (because it was
> > originally designed for use when hosting your own server pools - inbound
> > load balancing).
> > I.e. There is no way to configure 'sticky-address' to consider
> destination
> > IPs for outbound load balancing, so all subsequent outbound connections
> to
> > the same target IP originate from the same internet connection.
> >
> > The reason why this is desirable is because an increasing number of
> > websites use single sign on mechanisms (quite a few different
> architectures
> > expose the issue described here). After a users outbound connection is
> > initially randomly load balanced onto an internet connection, their
> browser
> > is redirected into opening multiple additional sockets towards the
> > website's load balancers / cloud gateways, which redirect the connections
> > to different internal servers for different parts of the site/page, and
> the
> > SSO authentication/cookies passed on the additional sockets must to
> > originate from the same IP as the original socket. As a result outbound
> > load-balancing does not work for these sites.
> >
> > The ideal functionality would be for 'sticky-address' to consider both
> > source IP and destination IP after initially being load balanced by
> > round-robin or random.
>
> Just use multipath routing, it will make sure that selected default routes
> are sticky to source/dest pairs. You may want the states to be interface
> bound if you need to nat-to on those links.
>
> On rerouting the multipath code reshuffles the selected routes in a way to
> minimize the affected sessions. All this is done without any extra memory
> usage since the hashing function is smart.
>
> --
> :wq Claudio
>
>
> > Thanks again, Andy.
> >
> > On Sat, Apr 3, 2021 at 12:40 PM Andy Lemin
> wrote:
> >
> > > Hi smart people :)
> > >
> > > The current implementation of ‘sticky-address‘ relates only to a sticky
> > > source IP.
> > > https://www.openbsd.org/faq/pf/pools.html
> > >
> > > This is used for inbound server load balancing, by ensuring that all
> > > socket connections from the same client/user/IP on the internet goes
> to the
> > > same server on your local server pool.
> > >
> > > This works great for ensuring simplified memory management of session
> > > artefacts on the application being hosted (the servers do not have to
> > > synchronise the users session data as extra sockets from that user will
> > > always connect to the same local server)
> > >
> > > However sticky-address does not have an equivalent for sticky
> destination
> > > IPs. For example when doing outbound load balancing over multiple ISP
> > > links, every single socket is load balanced randomly. This causes many
> > > websites to break (especially cookie login and single-sign-on style
> > > enterprise services), as the first outbound socket will originate
> randomly
> > > from one of the local ISP IPs, and the users login session/SSO (on the
> > > server side) will belong to that first random IP.
> > >
> > > When the user then browses to or uses another part of that same website
> > > which requires additiona
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
Ah,
Your diagram makes perfect sense now :) Thank you - So it does not have to
undergo a full rehashing of all links (which breaks _lots_ of sessions when
NAT is involved), but also does not have to explicitly track anything in
memory like you say 👍 So better than full re-hashing and cheaper than
tracking.
PS; Thank you for confirming; "It therefor routes the same src/dst pair
over the same nexthop as long as there are no changes to the route".
I was getting hung up on the bit in the RFC that says "hash over the packet
header fields that identify a flow", so I was imagining the hashing was
using a lot of entropy including the ports. I guess I should have thought
around that more and read it as "hash over the IP packet header fields that
identify a flow" ;)
I shall go and experiment :)
On Wed, Sep 29, 2021 at 8:45 PM Claudio Jeker
wrote:
> On Wed, Sep 29, 2021 at 08:07:43PM +1000, Andrew Lemin wrote:
> > Hi Claudio,
> >
> > So you probably guessed I am using 'route-to { GW1, GW2, GW3, GW4 }
> random'
> > (and was wanting to add 'sticky-address' to this) based on your reply :)
> >
> > "it will make sure that selected default routes are sticky to source/dest
> > pairs" - Are you saying that even though multipath routing uses hashing
> to
> > select the path (https://www.ietf.org/rfc/rfc2992.txt - "The router
> first
> > selects a key by performing a hash (e.g., CRC16) over the packet header
> > fields that identify a flow."), subsequent new sessions to the same dest
> IP
> > with different source ports will still get the same path? I thought a new
> > session with a new tuple to the same dest IP would get a different hashed
> > path with multipath?
>
> OpenBSD multipath routing implements gateway selection by Hash-Threshold
> from RFC 2992. It therefor routes the same src/dst pair over the same
> nexthop as long as there are no changes to the route. If one of your
> links drops then some sessions will move links but the goal of
> hash-threshold is to minimize the affected session.
>
> > "On rerouting the multipath code reshuffles the selected routes in a way
> to
> > minimize the affected sessions." - Are you saying, in the case where one
> > path goes down, it will migrate all the entries only for that failed path
> > onto the remaining good paths (like ecmp-fast-reroute ?)
>
> No, some session on good paths may also migrate to other links, this is
> how the hash-threshold algorithm works.
>
> Split with 4 nexthops, now lets assume link 2 dies and stuff gets
> reshuffled:
> +=+=+=+=+
> | link 1 | link 2 | link 3 | link 4 |
> +=+=+===+===+=+=+
> | link 1| link 3| link 4|
> +===+
> Unaffected sessions for drop
> ^ ^^^ ^
> Affected sessions because of drop
># #
> Unsing other ways to split the hash into buckets (e.g. a simple modulo)
> causes more change.
>
> Btw. using route-to with 4 gw will not detect a link failure and 25% of
> your traffic will be dropped. This is another advantage of multipath
> routing.
>
> Cheers
> --
> :wq Claudio
>
> > Thanks for your time, Andy.
> >
> > On Wed, Sep 29, 2021 at 5:21 PM Claudio Jeker
> > wrote:
> >
> > > On Wed, Sep 29, 2021 at 02:17:59PM +1000, Andrew Lemin wrote:
> > > > I see this question died on its arse! :)
> > > >
> > > > This is still an issue for outbound load-balancing over multiple
> internet
> > > > links.
> > > >
> > > > PF's 'sticky-address' parameter only works on source IPs (because it
> was
> > > > originally designed for use when hosting your own server pools -
> inbound
> > > > load balancing).
> > > > I.e. There is no way to configure 'sticky-address' to consider
> > > destination
> > > > IPs for outbound load balancing, so all subsequent outbound
> connections
> > > to
> > > > the same target IP originate from the same internet connection.
> > > >
> > > > The reason why this is desirable is because an increasing number of
> > > > websites use single sign on mechanisms (quite a few different
> > > architectures
> > > > expose the issue described here). After a users outbound connec
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
So I think I have figured out some things Theo browsing through https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c. I can see that some offloading is supported, but have not yet figured out how much is implemented yet. It looks like the offloading capability in these cards are much more granular than I have understood from previous hardware. I was able to decipher some of it using this https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf (this is very well written). And I was quite excited to see what looks like the RDMA access support in the mcx driver! So we should be able to see the super low latency capabilities with this card :) I will keep pushing myself.. Thanks again Theo On Wed, Sep 29, 2021 at 2:21 PM Andrew Lemin wrote: > Hi Theo :) > > Ok sure, I will put on my cape-of-courage and start reading the source.. I > may be some time! > > On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt wrote: > >> We tend to keep our driver manual pages without detailed promises. >> They do ethernet, they do it best effort, etc. >> >> What you want to know can be found by reading the source, or the >> commit logs. Since this is a locally written driver, the code is >> surprisingly approachable. >> >> Andrew Lemin wrote: >> >> > Hi. I hope everyone is well and having a great day :) >> > >> > Just a quick question about the mcx (Mellanox 5th generation Ethernet >> > device) drivers >> > https://man.openbsd.org/mcx.4 >> > >> > The man page says nothing more than it supports; >> > ConnectX-4 Lx EN >> > ConnectX-4 EN >> > ConnectX-5 EN >> > ConnectX-6 EN >> > >> > I am looking for some clarity on what features and performance >> > characteristics mcx boasts? >> > >> > For example are the following basic hardware features supported by this >> > driver? >> > IPv4 receive IP/TCP/UDP checksum offload >> > IPv4 transmit TCP/UDP checksum offload >> > VLAN tag insertion and stripping >> > interrupt coalescing >> > >> > And what other features does it support? >> > >> > I also came across a comment in some forum a while back (so high quality >> > information 😉) that mentioned Mellanox drivers in OpenBSD are SMP safe >> and >> > so not giant-locked. Is this true? >> > >> > Thanks, Andy, >> >
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
And to answer my last question about SMP capabilities, it looks like the only locking going on is when the driver is talking to the Kernel itself through kstat which would make sense. So yes it looks like mcx does have SMP support :) Well its enough for me to buy a card from ebay to play with as the ConnectX-4 Lx cards are pretty cheap now. Warning to others reading my comments, me poking around in kernel code is akin to a blind person in a library before learning braille, so take nothing I say as fact, merely optimistic opinion :) On Wed, Sep 29, 2021 at 9:08 PM Andrew Lemin wrote: > So I think I have figured out some things Theo browsing through > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c. > > I can see that some offloading is supported, but have not yet figured out > how much is implemented yet. It looks like the offloading capability in > these cards are much more granular than I have understood from previous > hardware. > I was able to decipher some of it using this > https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf > (this is very well written). > > And I was quite excited to see what looks like the RDMA access support in > the mcx driver! So we should be able to see the super low latency > capabilities with this card :) > > I will keep pushing myself.. Thanks again Theo > > On Wed, Sep 29, 2021 at 2:21 PM Andrew Lemin > wrote: > >> Hi Theo :) >> >> Ok sure, I will put on my cape-of-courage and start reading the source.. >> I may be some time! >> >> On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt >> wrote: >> >>> We tend to keep our driver manual pages without detailed promises. >>> They do ethernet, they do it best effort, etc. >>> >>> What you want to know can be found by reading the source, or the >>> commit logs. Since this is a locally written driver, the code is >>> surprisingly approachable. >>> >>> Andrew Lemin wrote: >>> >>> > Hi. I hope everyone is well and having a great day :) >>> > >>> > Just a quick question about the mcx (Mellanox 5th generation Ethernet >>> > device) drivers >>> > https://man.openbsd.org/mcx.4 >>> > >>> > The man page says nothing more than it supports; >>> > ConnectX-4 Lx EN >>> > ConnectX-4 EN >>> > ConnectX-5 EN >>> > ConnectX-6 EN >>> > >>> > I am looking for some clarity on what features and performance >>> > characteristics mcx boasts? >>> > >>> > For example are the following basic hardware features supported by this >>> > driver? >>> > IPv4 receive IP/TCP/UDP checksum offload >>> > IPv4 transmit TCP/UDP checksum offload >>> > VLAN tag insertion and stripping >>> > interrupt coalescing >>> > >>> > And what other features does it support? >>> > >>> > I also came across a comment in some forum a while back (so high >>> quality >>> > information 😉) that mentioned Mellanox drivers in OpenBSD are SMP >>> safe and >>> > so not giant-locked. Is this true? >>> > >>> > Thanks, Andy, >>> >>
Re: Server certs expired higher up the chain, imaps and https
On Thu, Sep 30, 2021 at 4:00 PM Sebastian Benoit wrote: > This is an issue with an expired root/intermediate certificate (DST Root X3) > in use by Let's Encrypt. > > [...] > An errata has just been published, you can install it using syspatch. Thanks for the quick patch! I can verify this fixes fetching with ftp(1) from https servers which use Let's Encrypt certificates. It looks like this is "workaround 2" as described in this OpenSSL blog [1]? I'm surprised this was even needed, as I thought this problem was "fixed" last year after the AddTrust External CA Root expiration. It seems to be a similar case of "while waiting for widespread acceptance of a new root, the intermediate is cross-signed". In that case the cert chain configured on your web server was: - host cert, signed by: - InCommon RSA Server CA (or several other intermediates), signed by: - USERTrust RSA Certification Authority, signed by: - AddTrust External CA Root (which expired 2020-05-30; recommended not to send the top-level root since it's in the client store and thus redundant). A few years before that expiration, they got a new USERTrust root into browser/OS certificate stores, and intermediates like InCommon were also signed by this new root. Browsers would ignore that last USERTrust intermediate cert since it wasn't needed, but OpenSSL before 1.1 would still consider it expired because of that intermediate. This seems to be a similar scenario, with: - host cert, signed by: - Let's Encrypt R3, signed by: - ISRG Root X1, signed by: - DST Root CA X3 (which just expired) Likewise, there's a new ISRG Root X1. The "alternate" or "short" chain on your server would consist of host + R3, but certbot etc. are defaulting to the "long" chain which adds the X1 intermediate. Unlike the USERTrust/AddTrust scenario, where the intermediate USERTrust cert expired the same time as the AddTrust root, the intermediate X1 cert doesn't expire until 2024-09-30. That seems to go against accepted standards of not issuing certificates expiring after the issuer expires, but maybe they got special dispensation. (And apparently Android doesn't care if the root expired, if everything else is valid? Also, apparently there was a different, older R3 intermediate which _also_ expired a couple days ago.) The immediate fix last year was to stop sending the unnecessary expired intermediate cert (i.e. only send host cert and InCommon RSA, not the USERTrust intermediate), but I thought a fix went into LibreSSL then to not consider a host "expired" if it was possible to generate a valid chain of trust, regardless of "extra" certs sent by the server? Indeed, Let's Encrypt's own documentation [2] thinks that only LibreSSL < 3.2.0 is affected, but that is not the case. LibreSSL 3.3.2 in OpenBSD 6.9 (before the new syspatch) still considered servers expired, as does the somewhat older version bundled in macOS. -Andrew [1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ [2] https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
Re: Is it true that `dd` is almost not needed?
"The era of magnetic tapes" has not ended. It is just that some people mysteriously believe their data is safer "in the cloud" where they cannot monitor it, than on a tape in a fire safe under their own supervision. I have read back tapes I wrote myself 30 years earlier. Have you tried getting your data back from a deceased "cloud provider"? That is why we get all these stories of ransomware attacks. Also, for many of us that have spent half a century learning Unix, we do not want our well proven tools snatched from our hands. There is room for more than one knife in a virtual tool box. On Sat, 11 Dec 2021 at 23:58, Stuart Longland wrote: > On Sat, 11 Dec 2021 18:06:43 +0200 > wrote: > > > The Cult of DD > > Mar 17, 2017 > > You'll often see instructions for creating and using disk images on Unix > > systems making use of the dd command. This is a strange program of > > [obscure provenance](https://en.wikipedia.org/wiki/Dd_(Unix)) that > > somehow, still manages to survive in the 21st century. > > > > Actually, using dd is almost never necessary, and due to its highly > > nonstandard syntax is usually just an easy way to mess things up. For > > instance, you'll see instructions like this asking you to run commands > > like: > > > > […snip…] > > > > > > End of article and my questions: > > > > Is the author right in general? > > Is the author right for Linux environment? > > Is the author right for OpenBSD environment? > > Can `cat`/`tail` et all, create a "sparse" file? > > vk4msl-gap$ dd if=/dev/zero bs=1M count=1 seek=9 of=sparsefile > > 1+0 records in > > 1+0 records out > > 1048576 bytes transferred in 0.009 secs (108639200 bytes/sec) > > vk4msl-gap$ ls -lh sparsefile > > -rw-r--r-- 1 stuartl stuartl 10.0M Dec 12 08:42 sparsefile > > vk4msl-gap$ du -hs sparsefile > > 1.0Msparsefile > > Very useful for "thin provisioning" of raw disk images with virtual > machines. > > Can `cat`/`tail` et all read bytes from the middle of a file? > > vk4msl-gap$ echo -n '000102030405060708090a0b0c0d0e0f' > test > > vk4msl-gap$ dd if=test of=test.part bs=2 skip=4 count=4 > > 4+0 records in > > 4+0 records out > > 8 bytes transferred in 0.000 secs (66541 bytes/sec) > > vk4msl-gap$ cat test.part > > 04050607 > > Can `cat`/`tail` et all overwrite specific bytes in the middle of a file? > > vk4msl-gap$ echo -n 'aaabacad' | dd of=test bs=2 count=4 seek=8 > conv=notrunc > > 4+0 records in > > 4+0 records out > > 8 bytes transferred in 0.000 secs (98985 bytes/sec) > > vk4msl-gap$ cat test > > 0001020304050607aaabacad0c0d0e0f > > I think you'll find `dd` was written in the era of magnetic tapes as a > storage medium, and so the ability to seek to a specific part of a tape > then perform a read or write, was seen as a critical feature of the day. > > That same feature is handy when doing various low-level disk operations > as well (e.g. backing-up/restoring the boot sector/partition table). > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere. > >
Re: ikev2 fails with mschap-v2
On Wed, Feb 23, 2022 at 10:10 PM wrote:
>
> I honestly have no idea where the logs would even be stored or what
> the daemon runs as under MacOS 12.2.1 (Monterey).
I don't have a Monterey system handy, but at least under macOS
Catalina, VPN connections use setkey and racoon, similar to FreeBSD.
Parts of the FreeBSD handbook's chapter on IPsec VPN may be relevant.
The global conf is in /etc/racoon.conf, which has some logging options
(and the associated man pages are installed), and there's a
/var/log/racoon.log. setkey [ -P ] -D looks useful, but may not apply
if it's failing before establishing SA entries.
It also uses pppd, at least for L2TP over IPsec; a handy feature of
which is support for your own scripts at /etc/ppp/ip-{up,down}.
-Andrew
Re: Microsoft's war on plain text email in open source
On Wed, Aug 26, 2020 at 2:36 AM Frank Beuth wrote: > “It is a fairly specific workflow that is a challenge for some newer > developers to engage with. As an example, my partner submitted a patch > to OpenBSD a few weeks ago, and he had to set up an entirely new mail > client which didn’t mangle his email message to HTML-ise or do other > things to it, so he could even make that one patch. That’s a barrier to > entry that’s pretty high for somebody who may want to be a first-time > contributor.”" > If someone struggles to send a plain-text email, what are the odds their OpenBSD patch is going to be accepted... -- andrew fabbro and...@fabbro.org
Approved way to update installed ports after system upgrade?
What's the standard way to upgrade installed ports after a system upgrade? I've been trying to figure out how to do this properly, and it doesn't seem to have any mention in the FAQ. Thanks in advance.
Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states
The missing 256 MB memory is probably stolen by the onboard video; it may be possible to reduce this to a smaller amount via a BIOS setting. You might also try fiddling with any available ACPI settings, e.g. sleep states, etc. (IIRC my VIA Epia M had a setting for whether "sleep" meant S1 or S3.) And I kinda wonder if that unexplained 10-pin CN2 header might be a serial port? Although since it doesn't show up in dmesg, maybe not... I was about to ask if the ACPI dump differed between PXE vs. hdd boot, but then I realized that was impossible to check given the crash. :-) If you could boot another OS from both hdd and PXE, maybe compare ACPI dumps to see if the BIOS changes something? Another workaround would be to 'boot -c' and disable acpi0, but that of course doesn't help fix the bug. -Andrew
How to unlock a serial port
Hi I am running OpenBSD on a T2000 (Sparc64). I was trying to use the serial port from the primary domain, connected via ssh, and my network lost the connection. My tty00 is now locked: jay# stty -f /dev/tty00 stty: /dev/tty00: Device busy I do not want to reboot the primary, as the guests are running various live services. I cannot find evidence of a lock file in /dev/spool/lock. Is there a way out of this predicament? Andrew
pkg_info(1) manpage issue
Hello everyone, it appears that there may be a way to misinterpret the man page for pkg_info(1) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The uninstalled packages are supposed to be listed together with their one-line summary. The manual page accessible with $ man 1 pkg_info; reads: [quote] When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package, so that it is possible to run pkg_info pkgname.tgz to obtain a longer package description, and pkg_add -n pkgname.tgz to check that the installation would proceed cleanly, including dependencies. [\quote] Copy-pasting the command "pkg_info -I *.tgz" from the manual page into the terminal yields the following error: computer$ pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Even calling pkg_info(1) with doas(1) yields the same behaviour: computer$ doas pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Note that there is a relatively long pause between the two "Invalid spec" messages both with and without doas(1). In which way am I misunderstanding the manual page for pkg_info(1) for the specific operation of browsing uninstalled packages and showing a summary line? === Affected Man-Page File === /usr.sbin/pkg_add/pkg_info.1 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Kind regards, Andrew Easton
boot_config(8) man page issue; and possibly openbsd.org/report.html
Hello everyone, it appears that there may be a way to misinterpret the man page for boot_config(8) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The boot_config(8) man page reads: [quote] The Ethernet card is not detected at boot because the kernel configuration does not match the physical hardware configuration, e.g. wrong IRQ in OpenBSD/i386. [...] UKC> find ne [...] 25 ne1 at isa0 port 0x300 size 0 iomem -1 iosiz 0 irq 10 drq -1 drq2 -1 flags 0x0 [...] ne1 seems to match the configuration except it uses IRQ 5 instead of IRQ 10. [...] UKC> change ne1 [...] irq [10] ? 5 [\quote] Note, that the line that is longer than 72 characters in this email is also longer than 72 characters in the original manual page. I selfishly chose a more accurate quote of the manual page over breaking the line. Plese let me know, in case this is a serious problem. Maybe https://www.openbsd.org/report.html should be augmented to refer to this specific quotation problem, in case it is important enough to document properly. The sentence "ne1 seems to match the configuration except it uses IRQ 5 instead of IRQ 10" has two ways of being interpreted: (1) the kernel configuration is using IRQ 5 and (2) the hardware configuration is using IRQ 5. After having misunderstood the sentence by assuming meaning (1) and noticing the inconsintency with the other relevant lines in the above quote of the man page, I suggest clarifying the sentence like so (change marked with square brackets): "ne1 seems to match the configuration except it [is supposed to use] IRQ 5 instead of IRQ 10" . One even more explicit option is: "ne1 [in the kernel configuration] seems to match [the hardware] configuration except [for the IRQ being used. The kernel currently uses IRQ 10 and the hardware uses IRQ 5, so the kernel configuration needs to be adjusted to match the hardware configuration.]" I want to thank the tireless efforts which have gone and are currently going into maintaining the exceptionally high documentation standards of OpenBSD. In case my suggestions above are overly pedantic, I sincerely apologize. === Affected Man Page File === /share/man/man8/boot_config.8 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Thank you very much for your time. Kind regards, Andrew Easton
Re: native wireguard + nat
Please provide your whole pf.conf file and ifconfig output. It's difficult to help with only a small subset of the configuration. There are PF macros referenced, but they weren't included either. On Thu, Mar 4, 2021 at 10:53 AM Riccardo Giuntoli wrote: > root@ganesha:/etc# cat pf.conf | grep wg > > > > block in on wg > match out on $ext_if from wg0:network to any nat-to $ext_if:0 > pass in on wg from wg:network to ! modulate state > root@ganesha:/etc# > root@ganesha:/etc# ping -c 1 10.10.10.2 > PING 10.10.10.2 (10.10.10.2): 56 data bytes > 64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=84.140 ms > > --- 10.10.10.2 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 84.140/84.140/84.140/0.000 ms > root@ganesha:/etc# > > root@ganesha:/etc# tcpdump -i vio0 host 10.10.10.2 > tcpdump: listening on vio0, link-type EN10MB > 17:51:48.596335 10.10.10.2.41470 > > m71os.services.getactivationkey.com.https: S 2252122240:2252122240(0) win > 65535 (DF) > ^C > 74 packets received by filter > 0 packets dropped by kernel > root@ganesha:/etc# > > PF nat doesn't translate. > > On Thu, Mar 4, 2021 at 6:43 PM Ashton Fagg wrote: > > > Riccardo Giuntoli writes: > > > > > Hi list. A pleasure to. > > > > > > Got a strange error with native wireguard for roadwarrior config. > > > > Pasting the full error makes people more likely to help you. > > > > > PF NAT doesn't work. > > > > Ok, but what's the error? "doesn't work" isn't very descriptive. > > > > > Someone with the same problem. > > > > > > root@ganesha:/etc# sysctl kern.version > > > kern.version=OpenBSD 6.8 (GENERIC) #5: Mon Feb 22 04:04:49 MST 2021 > > > r...@syspatch-68-amd64.openbsd.org: > > > /usr/src/sys/arch/amd64/compile/GENERIC > > > > > > root@ganesha:/etc# > > > > > -- > Name: Riccardo Giuntoli > Email: tag...@gmail.com > Location: sant Pere de Ribes, BCN, Spain > PGP Key: 0x67123739 > PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 > Key server: hkp://wwwkeys.eu.pgp.net >
curl-8.0.1 exists in two non-comparable versions (Someone forgot to bump a REVISION)
This happened when I ran 'pkg_add -u' after upgrading an i386 system from 7.2 to 7.3: ==== andrew@bilbo:~$ doas pkg_add -u quirks-6.121 signed on 2023-04-22T01:10:43Z quirks-6.42->6.121: ok bash-5.2.15:libiconv-1.17->1.17: ok bash-5.2.15:gettext-runtime-0.21p1->0.21.1: ok bash-5.1.16->5.2.15: ok Couldn't find ngtcp2 in first signature Couldn't find nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Couldn't find www/nghttp3 in first signature Couldn't find net/ngtcp2 in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1:ngtcp2-0.13.1: ok curl-8.0.1:nghttp3-0.9.0: ok curl-8.0.1:nghttp2-1.49.0->1.52.0: ok Couldn't find nghttp3 in first signature Couldn't find ngtcp2 in first signature Couldn't find net/ngtcp2 in first signature Couldn't find www/nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1->8.0.1: ok iperf3-3.10.1->3.12: ok libsodium-1.0.18p1->1.0.18p1: ok par2cmdline-0.7.4p0->0.7.4p0: ok smartmontools-7.3->7.3p0: ok vim-9.0.0192-no_x11->9.0.1388-no_x11: ok xz-5.2.5p2->5.4.1: ok Read shared items: ok andrew@bilbo:~$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD It seems that it succeeded in the end, but what happened? Is there a 7.3-stable curl pkg with new dependencies but the same revision as 7.3? (Or maybe a 7.2-stable pkg, since I was apparently at 8.0.1 already?) Thanks, Andrew
Re: hardware
That's been my motto as well. Except I recently picked up an R86s with older Mellanox ConnectX-3 10GbE SFPs, only to discover that OpenBSD only supports the newer ConnectX-4 and 5s :( I'd love to contribute in writing a driver in some way, but don't even know where to begin. On 4/28/23 13:55, Mihai Popescu wrote: Gustavo Rios wrote: What is the best supported servers by OpenBSD ? The older, the better! Take the oldest machine that will suit your needs. If it old enough, then someone: o released some (in)complete documentation o was pissed enough to start writing drivers and code for it o noticed bugs and reported them o ... already! Good luck!
Re: PC Engines APU platform EOL
I'm in the midst of testing the R86S as an alternative to my APU. My biggest issues so far with it: - No UART port, or even one to solder a header to. That means you're stuck with HDMI during install or to do any rescue work. - The SFPs in the taller version are Mellanox ConnectX-3s, which aren't supported in OpenBSD like the 4s and 5s. My ISP does fibre to the home, so I was hoping to directly connect my SFP to my firewall, bypassing my modem entirely. If you don't need SFP support, then the 2.5GbE ports seem to be supported. Otherwise it does seem like a very capable machine. On 5/4/23 00:23, Damian McGuckin wrote: On Thu, 4 May 2023, Maksim Rodin wrote: Is there any problem with fanless x86_64 mini PCs with several NICs, sold on aliexpress? Maybe, or give up on the rackmount and buy the R86S, as in https://www.aliexpress.com/i/1005004765507664.html An alternative is to buy 3 APU4s now 3 to cover failures and spares over the next few years. Hopefully, they still have some left. Thanks - Damian Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
Unfortunately it looks like sh -x does not trace into functions, and it is something inside "main" which is crashing: > > set -x or something. > Sorry, I should have started with that. > > test73# doas -u _pfbadhost pf-badhost -O openbsd > [ ... ] > + command -v typeset > + > /dev/null > + 2>&1 > + main -O openbsd > Illegal instruction > [ ... ] > Illegal instruction (core dumped) > > No blocklist changes... > Illegal instruction (core dumped) Both sh and ksh seem to behave that way, but bash will trace inside functions. Try calling the script with 'bash -x' and hopefully you can pinpoint which binary called by main() is crashing. -Andrew
Intel E823-L Ethernet interfaces not detected
Hi @misc, I just installed OpenBSD 7.3-release on a new amd64 system to replace an old one that had been on OpenBSD 5.5 (it was set it and forget it till the CPU fried!). I've found that some of the Ethernet interfaces aren't seen in ifconfig, so I suspect there's no driver/support yet. dmesg also reflects unknown ethernet devices (full output attached at the bottom of this message). I searched @misc and @tech archives and didn't succeed in finding any discussions, so starting one here (apology if I missed something). The non-working interfaces are using an Intel E823-L controller, while the working interfaces are using an Intel X550 controller. The mainboard is an Intel Xeon-D 1700 SoC platform (Supermicro X12SDV-4C-SPT4F). Of course I'd love some easy solution but hey, it is what it is if the support just isn't there. :) Searching online, I did find an Intel driver link for this controller that supports FreeBSD: https://www.intel.com/content/www/us/en/download/18332/ intel-network-adapter-freebsd-virtual-function-driver-for-intel-ethernet -controller-700-and-e810-series.html I also found a verbose lspci dump for the controller: https://www.servethehome.com/supermicro-x12sdv-4c-sp6f-review-25gbe-and- intel-xeon-d-1718t/supermicro-intel-e823-l-lspci-vvv/ ^ I think that's probably from Linux though. If my message in any way comes off as urgent - please know, it is not. I know the OpenBSD devs are busy. No expectations on my part at all. Although, I am willing to help any way I can. If somebody would like the use of the system, happy to lend it out, etc. Cheers, Andrew Full dmesg follows: OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33909121024 (32338MB) avail mem = 32862027776 (31339MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x6c252000 (48 entries) bios0: vendor American Megatrends International, LLC. version "1.1" date 10/05/2022 bios0: Supermicro Super Server efi0 at bios0: UEFI 2.8 efi0: American Megatrends rev 0x50018 acpi0 at bios0: ACPI 6.4 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP SPMI FIDT SSDT TCPA SSDT ERST BERT SSDT MCFG BDAT HMAT HPET WDDT APIC SLIT SRAT OEM4 OEM1 SSDT HEST DMAR TPM2 SSDT SSDT WSMT acpi0: wakeup devices RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) PXSX(S0) RP06(S0) PXSX(S0) RP07(S0) PXSX(S0) RP08(S0) PXSX(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0x8000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu0: 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,DCA,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 10MB 64b/line 20-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu1: 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,DCA,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 10MB 64b/line 20-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu2: 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,
Re: Intel E823-L Ethernet interfaces not detected
Hi Jonathan, This at least confirms the behavior is expected, thanks for the clarity. In the mean time, I've got plenty of new things to explore on the 7.3 release - with a pair of two perfectly good X550 Ethernet interfaces to do it with! For now I'll leave a standing offer: Any time into the future, if somebody at the project is thinking "Gee, wish I had an Intel E800 platform to evaluate" - reach out to me and I'd be happy to lend mine, and cover costs too. :) Thanks to you and all other contributors for the stellar software! -Andrew
PF queue bandwidth limited to 32bit value
Hi all, Hope this finds you well. I have discovered that PF's queueing is still limited to 32bit bandwidth values. I don't know if this is a regression or not. I am sure one of the objectives of the ALTQ rewrite into the new queuing system we have in OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I am imagining it.. Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN routing with 10Gbps trunks, and I cannot set the queue bandwidth higher than a 32bit value? Setting the bandwidth value to 4295M results in a value overflow where 'systat queues' shows it wrapped and starts from 0 again. And traffic is indeed restricted to such values, so does not appear to be just a cosmetic 'systat queues' issue. I am sure this must be a bug/regression, 10Gbps on OpenBSD is trivial and common nowadays.. Tested on OpenBSD 7.3 Thanks for checking my sanity :) Andy.
Re: PF queue bandwidth limited to 32bit value
Hi Stuart. On Wed, Sep 13, 2023 at 12:25 AM Stuart Henderson wrote: > On 2023-09-12, Andrew Lemin wrote: > > Hi all, > > Hope this finds you well. > > > > I have discovered that PF's queueing is still limited to 32bit bandwidth > > values. > > > > I don't know if this is a regression or not. > > It's not a regression, it has been capped at 32 bits afaik forever > (certainly was like that when the separate classification via altq.conf > was merged into PF config, in OpenBSD 3.3). > Ah ok, it was talked about so much I thought it was part of it. Thanks for clarifying. > > > I am sure one of the > > objectives of the ALTQ rewrite into the new queuing system we have in > > OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I > am > > imagining it.. > > I don't recall that though there were some hopes expressed by > non-developers. > Haha, it is definitely still wanted and needed. prio-only based ordering is too limited > > > Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN > routing > > with 10Gbps trunks, and I cannot set the queue bandwidth higher than a > > 32bit value? > > > > Setting the bandwidth value to 4295M results in a value overflow where > > 'systat queues' shows it wrapped and starts from 0 again. And traffic is > > indeed restricted to such values, so does not appear to be just a > cosmetic > > 'systat queues' issue. > > > > I am sure this must be a bug/regression, > > I'd say a not-implemented feature (and I have a feeling it is not > going to be all that simple a thing to implement - though changing > scales so the uint32 carries bytes instead of bits per second might > not be _too_ terrible). > Following the great work to SMP unlock in the VLAN interface, and recent NIC optimisations (offloading and interrupt handling) in various drivers, you can now push packet filtered 10Gbps with modern CPUs without breaking a sweat.. A, thats clever! Having bandwidth queues up to 34,352M would definitely provide runway for the next decade :) Do you think your idea is worth circulating on tech@ for further discussion? Queueing at bps resolution is rather redundant nowadays, even on the very slowest links. > > 10Gbps on OpenBSD is trivial and > > common nowadays.. > > While using interfaces with 10Gbps link speed on OpenBSD is trivial, > actually pushing that much traffic (particularly with more complex > processing e.g. things like bandwidth controls, and particularly with > smaller packet sizes) not so much. > > > -- > Please keep replies on the mailing list. > >
Re: PF queue bandwidth limited to 32bit value
On Wed, Sep 13, 2023 at 3:43 AM Andrew Lemin wrote: > Hi Stuart. > > On Wed, Sep 13, 2023 at 12:25 AM Stuart Henderson < > stu.li...@spacehopper.org> wrote: > >> On 2023-09-12, Andrew Lemin wrote: >> > Hi all, >> > Hope this finds you well. >> > >> > I have discovered that PF's queueing is still limited to 32bit bandwidth >> > values. >> > >> > I don't know if this is a regression or not. >> >> It's not a regression, it has been capped at 32 bits afaik forever >> (certainly was like that when the separate classification via altq.conf >> was merged into PF config, in OpenBSD 3.3). >> > > Ah ok, it was talked about so much I thought it was part of it. Thanks for > clarifying. > > >> >> > I am sure one of the >> > objectives of the ALTQ rewrite into the new queuing system we have in >> > OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I >> am >> > imagining it.. >> >> I don't recall that though there were some hopes expressed by >> non-developers. >> > > Haha, it is definitely still wanted and needed. prio-only based ordering > is too limited > I have noticed another issue while trying to implement a 'prio'-only workaround (using only prio ordering for inter-VLAN traffic, and HSFC queuing for internet traffic); It is not possible to have internal inter-vlan traffic be solely priority ordered with 'set prio', as the existence of 'queue' definitions on the same internal vlan interfaces (required for internet flows), demands one leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into the 'default' queue despite queuing not being wanted, and so unintentionally clamping all internal traffic to 4294M just because full queuing is needed for internet traffic. In fact 'prio' is irrelevant, as with or without 'prio' because queue's are required for internet traffic, all internal traffic becomes bound by the 'default' HSFC queue. So I would propose that the mandate on the 'default' keyword is relaxed (or a new keyword is provided for match/pass rules to force flows to not be queued), and/or implement the uint32 scale in bytes, instead of bits? I personally believe both are valid and needed? > > >> >> > Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN >> routing >> > with 10Gbps trunks, and I cannot set the queue bandwidth higher than a >> > 32bit value? >> > >> > Setting the bandwidth value to 4295M results in a value overflow where >> > 'systat queues' shows it wrapped and starts from 0 again. And traffic is >> > indeed restricted to such values, so does not appear to be just a >> cosmetic >> > 'systat queues' issue. >> > >> > I am sure this must be a bug/regression, >> >> I'd say a not-implemented feature (and I have a feeling it is not >> going to be all that simple a thing to implement - though changing >> scales so the uint32 carries bytes instead of bits per second might >> not be _too_ terrible). >> > > Following the great work to SMP unlock in the VLAN interface, and recent > NIC optimisations (offloading and interrupt handling) in various drivers, > you can now push packet filtered 10Gbps with modern CPUs without breaking a > sweat.. > > A, thats clever! Having bandwidth queues up to 34,352M would > definitely provide runway for the next decade :) > > Do you think your idea is worth circulating on tech@ for further > discussion? Queueing at bps resolution is rather redundant nowadays, even > on the very slowest links. > > >> > 10Gbps on OpenBSD is trivial >> and >> > common nowadays.. >> >> While using interfaces with 10Gbps link speed on OpenBSD is trivial, >> actually pushing that much traffic (particularly with more complex >> processing e.g. things like bandwidth controls, and particularly with >> smaller packet sizes) not so much. >> >> >> -- >> Please keep replies on the mailing list. >> >> Thanks again, Andy.
Re: PF queue bandwidth limited to 32bit value
On Wed, Sep 13, 2023 at 8:22 PM Stuart Henderson wrote: > On 2023-09-12, Andrew Lemin wrote: > > A, thats clever! Having bandwidth queues up to 34,352M would > definitely > > provide runway for the next decade :) > > > > Do you think your idea is worth circulating on tech@ for further > > discussion? Queueing at bps resolution is rather redundant nowadays, even > > on the very slowest links. > > tech@ is more for diffs or technical questions rather than not-fleshed-out > quick ideas. Doing this would solve some problems with the "just change it > to 64-bit" mooted on the freebsd-pf list (not least with 32-bit archs), > but would still need finding all the places where the bandwidth values are > used and making sure they're updated to cope. > > Yes good point :) I am not in a position to undertake this myself at the moment. If none of the generous developers feel included to do this despite the broad value, I might have a go myself at some point (probably not able until next year sadly). "just change it to 64-bit" mooted on the freebsd-pf list - I have been unable to find this conversation. Do you have a link? > > -- > Please keep replies on the mailing list. > >
Re: PF queue bandwidth limited to 32bit value
On Wed, Sep 13, 2023 at 8:35 PM Stuart Henderson wrote: > On 2023-09-13, Andrew Lemin wrote: > > I have noticed another issue while trying to implement a 'prio'-only > > workaround (using only prio ordering for inter-VLAN traffic, and HSFC > > queuing for internet traffic); > > It is not possible to have internal inter-vlan traffic be solely priority > > ordered with 'set prio', as the existence of 'queue' definitions on the > > same internal vlan interfaces (required for internet flows), demands one > > leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into > > the 'default' queue despite queuing not being wanted, and so > > unintentionally clamping all internal traffic to 4294M just because full > > queuing is needed for internet traffic. > > If you enable queueing on an interface all traffic sent via that > interface goes via one queue or another. > Yes, that is indeed the very problem. Queueing is enabled on the inside interfaces, with bandwidth values set slightly below the ISP capacities (multiple ISP links as well), so that all things work well for all internal users. However this means that inter-vlan traffic from client networks to server networks are restricted to 4294Mbps for no reason.. It would make a huge difference to be able to allow local traffic to flow without being queued/restircted. > > (also, AIUI the correct place for queues is on the physical interface > not the vlan, since that's where the bottleneck is... you can assign > traffic to a queue name as it comes in on the vlan but I believe the > actual queue definition should be on the physical iface). > Hehe yes I know. Thanks for sharing though. I actually have very specific reasons for doing this (queues on the VLAN ifaces rather than phy) as there are multiple ISP connections for multiple VLANs, so the VLAN queues are set to restrict for the relevant ISP link etc. > > "required for internet flows" - depends on your network layout.. the > upstream feed doesn't have to go via the same interface as inter-vlan > traffic. I'm not sure what you mean. All the internal networks/vlans are connected to local switches, and the switches have trunk to the firewall which hosts the default gateway for the VLANs and does inter-vlan routing. So all the clients go through the same VLANs/trunk/gateway for inter-vlan as they do for internet. Strict L3/4 filtering is required on inter-vlan traffic. I am honestly looking for support to recognise that this is a correct, valid and common setup, and so there is a genuine need to allow flows to not be queued on interfaces that have queues (which has many potential applications for many use cases, not just mine - so should be of interest to the developers?). Do you know why there has to be a default queue? Yes I know that traffic excluded from queues would take from the same interface the queueing is trying to manage, and potentially causes congestion. However with 10Gbps networking which is beyond common now, this does not matter when the queues are stuck at 4294Mbps Desperately trying to find workarounds that appeal.. Surely the need is a no brainer, and it is just a case of trying to encourage interest from a developer? Thanks :)
Re: PF queue bandwidth limited to 32bit value
On Thu, Sep 14, 2023 at 7:23 PM Andrew Lemin wrote: > > > On Wed, Sep 13, 2023 at 8:35 PM Stuart Henderson < > stu.li...@spacehopper.org> wrote: > >> On 2023-09-13, Andrew Lemin wrote: >> > I have noticed another issue while trying to implement a 'prio'-only >> > workaround (using only prio ordering for inter-VLAN traffic, and HSFC >> > queuing for internet traffic); >> > It is not possible to have internal inter-vlan traffic be solely >> priority >> > ordered with 'set prio', as the existence of 'queue' definitions on the >> > same internal vlan interfaces (required for internet flows), demands one >> > leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into >> > the 'default' queue despite queuing not being wanted, and so >> > unintentionally clamping all internal traffic to 4294M just because full >> > queuing is needed for internet traffic. >> >> If you enable queueing on an interface all traffic sent via that >> interface goes via one queue or another. >> > > Yes, that is indeed the very problem. Queueing is enabled on the inside > interfaces, with bandwidth values set slightly below the ISP capacities > (multiple ISP links as well), so that all things work well for all internal > users. > However this means that inter-vlan traffic from client networks to server > networks are restricted to 4294Mbps for no reason.. It would make a huge > difference to be able to allow local traffic to flow without being > queued/restircted. > > >> >> (also, AIUI the correct place for queues is on the physical interface >> not the vlan, since that's where the bottleneck is... you can assign >> traffic to a queue name as it comes in on the vlan but I believe the >> actual queue definition should be on the physical iface). >> > > Hehe yes I know. Thanks for sharing though. > I actually have very specific reasons for doing this (queues on the VLAN > ifaces rather than phy) as there are multiple ISP connections for multiple > VLANs, so the VLAN queues are set to restrict for the relevant ISP link etc. > Also separate to the multiple ISPs (I wont bore you with why as it is not relevant here), the other reason for queueing on the VLANs is because it allows you to get closer to the 10Gbps figure.. Ie, If you have queues on the 10Gbps PHY, you can only egress 4294Mbps to _all_ VLANs. But if you have queues per-VLAN iface, you can egress multiple times 4294Mbps on aggregate. Eg, vlans 10,11,12,13 on single mcx0 trunk. 10->11 can do 4294Mbps and 12->13 can do 4294Mbps, giving over 8Gbps egress in total on the PHY. It is dirty, but like I said, desperate for workarounds... :( > > >> >> "required for internet flows" - depends on your network layout.. the >> upstream feed doesn't have to go via the same interface as inter-vlan >> traffic. > > > I'm not sure what you mean. All the internal networks/vlans are connected > to local switches, and the switches have trunk to the firewall which hosts > the default gateway for the VLANs and does inter-vlan routing. > So all the clients go through the same VLANs/trunk/gateway for inter-vlan > as they do for internet. Strict L3/4 filtering is required on inter-vlan > traffic. > I am honestly looking for support to recognise that this is a correct, > valid and common setup, and so there is a genuine need to allow flows to > not be queued on interfaces that have queues (which has many potential > applications for many use cases, not just mine - so should be of interest > to the developers?). > > Do you know why there has to be a default queue? Yes I know that traffic > excluded from queues would take from the same interface the queueing is > trying to manage, and potentially causes congestion. However with 10Gbps > networking which is beyond common now, this does not matter when the queues > are stuck at 4294Mbps > > Desperately trying to find workarounds that appeal.. Surely the need is a > no brainer, and it is just a case of trying to encourage interest from a > developer? > > Thanks :) >
OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
Hi, I have been testing the Wireguard implementation on OpenBSD and noticed that the ToS field is not being copied from the inner unencrypted header to the outer Wireguard header, resulting in ALL packets going into the same PF Prio / Queue. For example, ACKs (for Wireguard encrypted packets) end up in the first queue (not the priority queue) despite PF rules; queue ext_iface on $extif bandwidth 1000M max 1000M queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M queue data on $extif parent ext_iface flows 1000 bandwidth 100M default match on $extif proto tcp set prio (3, 6) set queue (data, pri) All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, and payload packets go into 'data' queue. However for Wireguard encrypted packets, _all_ packets (including SYNs and ACKs) go into the 'data' queue. I thought maybe you need to force the ToS/prio/queue values, so I also tried sledgehammer approach; match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri But sadly all encrypted SYNs and ACKs etc still only go into the data queue no matter what. This can be confirmed with wireshark that all ToS bits are lost This results in poor Wireguard performance on OpenBSD. OpenVPN has the --passtos directive to copy the ToS Bits, which means OpenVPN is faster than Wireguard on OpenBSD. Thanks, Andy.
Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
On Mon, Sep 18, 2023 at 10:59 PM Stuart Henderson wrote: > On 2023-09-17, Andrew Lemin wrote: > > I have been testing the Wireguard implementation on OpenBSD and noticed > > that the ToS field is not being copied from the inner unencrypted header > to > > the outer Wireguard header, resulting in ALL packets going into the same > PF > > Prio / Queue. > > > > For example, ACKs (for Wireguard encrypted packets) end up in the first > > queue (not the priority queue) despite PF rules; > > > > queue ext_iface on $extif bandwidth 1000M max 1000M > > queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M > > queue data on $extif parent ext_iface flows 1000 bandwidth 100M default > > > > match on $extif proto tcp set prio (3, 6) set queue (data, pri) > > > > All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, and > > payload packets go into 'data' queue. > > However for Wireguard encrypted packets, _all_ packets (including SYNs > and > > ACKs) go into the 'data' queue. > > > > I thought maybe you need to force the ToS/prio/queue values, so I also > > tried sledgehammer approach; > > match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri > > match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri > > > > But sadly all encrypted SYNs and ACKs etc still only go into the data > queue > > no matter what. > > This can be confirmed with wireshark that all ToS bits are lost > > > > This results in poor Wireguard performance on OpenBSD. > > Here's a naive untested diff that might at least use the prio internally > in OpenBSD... > Awesome! Thank you so much Stuart :D I will test this weekend.. > > Index: if_wg.c > === > RCS file: /cvs/src/sys/net/if_wg.c,v > retrieving revision 1.29 > diff -u -p -r1.29 if_wg.c > --- if_wg.c 3 Aug 2023 09:49:08 - 1.29 > +++ if_wg.c 18 Sep 2023 12:47:02 - > @@ -1525,6 +1525,8 @@ wg_encap(struct wg_softc *sc, struct mbu > */ > mc->m_pkthdr.ph_flowid = m->m_pkthdr.ph_flowid; > > + mc->m_pkthdr.pf.prio = m->m_pkthdr.pf.prio; > + > res = noise_remote_encrypt(&peer->p_remote, &data->r_idx, &nonce, >data->buf, plaintext_len); > nonce = htole64(nonce); /* Wire format is little endian. */ > > >
Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
On Fri, Sep 22, 2023 at 12:27 PM David Gwynne wrote: > On Mon, Sep 18, 2023 at 12:47:52PM -, Stuart Henderson wrote: > > On 2023-09-17, Andrew Lemin wrote: > > > I have been testing the Wireguard implementation on OpenBSD and noticed > > > that the ToS field is not being copied from the inner unencrypted > header to > > > the outer Wireguard header, resulting in ALL packets going into the > same PF > > > Prio / Queue. > > > > > > For example, ACKs (for Wireguard encrypted packets) end up in the first > > > queue (not the priority queue) despite PF rules; > > > > > > queue ext_iface on $extif bandwidth 1000M max 1000M > > > queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M > > > queue data on $extif parent ext_iface flows 1000 bandwidth 100M > default > > > > > > match on $extif proto tcp set prio (3, 6) set queue (data, pri) > > > > > > All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, > and > > > payload packets go into 'data' queue. > > > However for Wireguard encrypted packets, _all_ packets (including SYNs > and > > > ACKs) go into the 'data' queue. > > > > > > I thought maybe you need to force the ToS/prio/queue values, so I also > > > tried sledgehammer approach; > > > match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri > > > match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri > > > > > > But sadly all encrypted SYNs and ACKs etc still only go into the data > queue > > > no matter what. > > > This can be confirmed with wireshark that all ToS bits are lost > > > > > > This results in poor Wireguard performance on OpenBSD. > > > > Here's a naive untested diff that might at least use the prio internally > > in OpenBSD... > > > > Index: if_wg.c > > === > > RCS file: /cvs/src/sys/net/if_wg.c,v > > retrieving revision 1.29 > > diff -u -p -r1.29 if_wg.c > > --- if_wg.c 3 Aug 2023 09:49:08 - 1.29 > > +++ if_wg.c 18 Sep 2023 12:47:02 - > > @@ -1525,6 +1525,8 @@ wg_encap(struct wg_softc *sc, struct mbu > >*/ > > mc->m_pkthdr.ph_flowid = m->m_pkthdr.ph_flowid; > > > > + mc->m_pkthdr.pf.prio = m->m_pkthdr.pf.prio; > > + > > res = noise_remote_encrypt(&peer->p_remote, &data->r_idx, &nonce, > > data->buf, plaintext_len); > > nonce = htole64(nonce); /* Wire format is little endian. */ > > > > > > i think this should go in, ok by me. > > implementing txprio and rxprio might be useful too, but requires more > plumbing than i have the energy for now. > Hi David, Just to make sure I understand currently, you mean also copying the priority to/from txprio/rxprio for the VLAN/CoS priorities? Thanks. I plan to test Stuart's patch this weekend and will confirm here, but I'm confident it will work first time knowing him :)
Re: MCU recommendations to program on OpenBSD?
> On Mar 3, 2024, at 18:36, Chris Narkiewicz wrote: > > On Sun, Mar 03, 2024 at 05:11:17PM +0800, Sadeep Madurange wrote: >> Any recommendations for MCUs with C >> language SDKs supported by OpenBSD? > > AVR - 8 bit > ARM - 32 bit > > Especially AVRs are top of the game when it comes to > open source toolchain support. You can probably keep developing esp32, at least: https://openports.pl/path/devel/arduino-esp32
Re: TLS suddenly not working over IKED site-to-site - SOLVED?
On Thu, Dec 20, 2018 at 6:54 PM Theodore Wynnychenko wrote: > Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, > https (and imaps) were working without an issue from openbsd, Windows 7, and > Macs! > > Just to be sure, I updated this am to the 12/19 amd64 snapshot. > > When I turn on ipcomp, https/imaps hangs for most connections; when I turn > ipcomp off, https/imaps works. I can confirm this behavior. I've set up a simple RSA key VPN as described at http://www.openbsd.org/faq/faq17.html#site2site, which does not include ipcomp by default, and everything works fine, including https. After reading this I decided to test enabling ipcomp, and sure enough, loading an https page across the VPN fails. With ipcomp I also see some "unprotected" packets when running tcpdump on enc0, e.g.: 13:32:19.600062 (authentic,confidential): SPI 0xee345270: 10.95.10.236.57254 > 10.95.0.233.443: P 273:518(245) ack 5604 win 455 (DF) (encap) 13:32:19.614996 (unprotected): SPI 0x5a04: 10.95.0.233.443 > 10.95.10.236.57254: . 5604:7052(1448) ack 518 win 252 (DF) (encap) I don't know why that is happening, but as everything seems to work well and perform decently without ipcomp, I'll be leaving it disabled. > I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing this > is the code that is involved) in the log (I think) was about 3 months ago, > and at this point, I can't recall if my last updated (prior to the one where > the instability began) was before or after that change. > > I was going to try to recompile it with the change undone, but am not sure > how to do that, or even if it can be done for just that one part of sys. Yes, just use git or cvs (whatever you checked out the code with) to fetch an earlier revision of that file (not the whole repo) and then build a new kernel. Sometimes you'd need to also revert other related changes, but that does not appear to be the case here, assuming you're referring to [1]. Note that some previous commits did touch multiple files. > And, after removing ipcomp from iked.conf, my subjective observation is that > things load a lot faster than they seemed to in the past with ipcomp on; so, > I am happy with where I am. > > I was just posting my observations in case anyone else has a similar issue. Thank you for sharing. I had (I think) been using ipcomp in my old ikev1 (ipsec.conf/isakmpd) setup but had not yet gotten around to enabling it in the ikev2 setup. Based on this, I won't bother. -Andrew [1] https://github.com/openbsd/src/commit/4b5fa55
Re: OpenBSD on Macbook 12" 2017?
Interesting - I thought SPI was as old as the hills, but I see Intel has an "enhanced" SPI now. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface On Fri, Mar 15, 2019 at 10:31 AM joshua stein wrote: > On Fri, 15 Mar 2019 at 09:18:02 +0100, Harald Dunkel wrote: > > Hi folks, > > > > does it work, OpenBSD on a 12" Macbook 2017? I tried Linux once, > > but keyboard and trackpad were not working, so I kept MacOS. > > The keyboard and touchpad are connected over SPI now, so they > require a new Intel SPI controller driver and then two custom > drivers for the keyboard and touchpad. > > So no, the device does not work on OpenBSD unless you use a USB > keyboard/mouse. > > -- andrew fabbro and...@fabbro.org
syspatch(8) and patches requiring fw_update
In the latest mds errata patch, I noticed that one of the steps is to run fw_update. From briefly looking over the syspatch script, I don't see it calling fw_update once a patch is applied. Would you welcome a diff to add support for this? If so I can look at writing one. It would check against the .sig patch file itself, since the .tgz syspatch binary patch doesn't contain any details about needing to run fw_update. A rough set of steps would be: - Pull .sig patch from mirror and verify signature - Parse for fw_update - Once the patch has been applied, run fw_update Please let me know of any feedback to this approach. Andrew
pflow version 10 not set on boot
I noticed that my pflow device keeps rebooting with Netflow version 5, despite "pflowproto 10" being set in /etc/hostname.pflow0. I'm running OpenBSD 6.5 with the latest patches. ifconfig: pflow0: flags=41 mtu 1448 index 9 priority 0 llprio 3 pflow: sender: [] receiver: []:2055 version: 5 groups: pflow /etc/hostname.pflow0: up flowdst []:2055 flowsrc [] pflowproto 10 After boot, if I manually initiate "sh /etc/netstart pflow0", it then starts using version Netflow v10 as expected. I may be able to add to /etc/rc.local to do this on reboot, but thought I'd see if there was anything else that it could be. Thanks, Andrew
Re: What is you motivational to use OpenBSD
On Wed, Aug 28, 2019 at 7:45 AM Mohamed salah wrote: > I wanna put something in discussion, what's your motivational to use > OPENBSD The vastly superior mascot and soundtrack. -- andrew fabbro and...@fabbro.org
Re: OpenBSD on AWS - pciide/wd issue
On Wed, Sep 4, 2019 at 12:56 PM Pavel Korovin wrote: > The logs showed where it stuck: > > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying I can reproduce this on my local Xen environment with the latest bsd.rd snapshot (OpenBSD 6.6-beta (RAMDISK_CD) #270: Wed Sep 4 11:46:05 MDT 2019); 6.5 works just fine. > For some reason, the boot volume was recognized also as > wd0 at pciide0 channel 0 drive 0: > and then as > sd0 at scsibus1 targ 0 lun 0: SCSI5 0/direct > > As a quick fix I disabled pciide/wd, the instance booted and runs fine. I noticed that in the problematic snapshot, pciide is listed in dmesg *before* any xen stuff, whereas in 6.5, xen0/xbf0/sd0 are listed first, and pciide comes later and says "channel 0 disabled (no drives)". I believe xbf(4) and xnf(4) disable any emulated devices (e.g. wd0, re0) when they load, so maybe they need to load first? Here's a "known good" dmesg from OpenBSD 6.5 + syspatches (up through 010_frag6ecn): OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1015353344 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries) bios0: vendor Xen version "4.4.4_40-61.43.2" date 03/21/2019 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2494.24 MHz, 06-17-06 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2493.89 MHz, 06-17-06 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.4 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4 "vfb" at xen0: device/vfb/0 not configured "console" at xen0: device/console/0 not configured xbf0 at xen0 backend 0 channel 6: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 4096MB, 512 bytes/sector, 8388608 sectors xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28 xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown -Andrew
Re: BACK TO BASICS
On Fri, Oct 11, 2019 at 9:09 AM wrote: > Deep down, I'm actually so saddened to see the original, and still > performing, UNIX has become so divided first splitting into three > *BSD communities, and then further diluted efforts with GNU and the > Linux kernel... > The Unix landscape was fragmented long, long before Linux or the three modern BSDs even existed. -- andrew fabbro and...@fabbro.org
Re: vendor list (was: dmesg IBM x3650 OpenBSD 4.3 )
On Mon, Oct 13, 2008 at 10:28:37AM -0700, Charles Smith wrote: > > to create a web section listing the reasonable and bastard vendors? > > I think it would be useful in two points: > > > > * helps to OpenBSD community to choose the right hardware > > * make good or bad publicity depending on real vendor's position > > > > Anyway it's only an idea. > > +1 > I very like the idea. > Check the archives, it has been tried in the past. http://vendorwatch.org/ According to the Internet Archive's Wayback Machine, they have been reviving it since somewhere between February and June 2007. Apparently too many people are like me and think that it is a good idea, but don't have to time to maintain it. (definitely read the archives before even imagining that you would consider suggesting that it be maintained by developers) l8rZ, -- andrew - ICQ# 253198 - Jabber: [EMAIL PROTECTED] BOFH excuse of the day: Sysadmin accidentally destroyed pager with a large hammer.
Re: Multipath to CISCO
On Wed, Nov 05, 2008 at 09:40:02AM +, Stuart Henderson wrote:
> On 2008-11-05, Mikel Lindsaar <[EMAIL PROTECTED]> wrote:
> > The other option I believe would be using PF to round robin the packets on
> > both destinations using route-to rules. Would this work?
>
> it should, but you might need to make the rules stateless ("no state").
>
It works, and you do.
# san2 and san3 are in interface group att
att_if0="san2"
att_if1="san3"
pass in log on att to self
pass in on att to $my_net no state flags any
pass out on att from { $my _net self } no state flags any
pass out on { $att_if0 $att_if1 } route-to { \
($att_if0 $att_if0:peer) \
($att_if1 $att_if1:peer) \
} round-robin from $my_net tag ROUTED ! tagged ROUTED \
no state flags any
pass out on att to att:network
this is on a multiple AT&T T1 link, but it should work mostly the same.
However, you probably won't have the :peer address and will have to
specify the address.
l8rZ,
--
andrew - ICQ# 253198 - Jabber: [EMAIL PROTECTED]
BOFH excuse of the day: Typo in the code
Re: Laptop keyboard pictures
Heres a pic of a portion of the eee keyboard (excuse the crappy photo): http://www.copyandwaste.com/wp-content/uploads/2008/11/img_0055.jpg Not sure if this is completely useful... but here is a comparison on the size of the eee and an old fujitsu lifebook http://www.copyandwaste.com/2008/09/16/asus-netbook/ -a On Thu, Nov 6, 2008 at 10:45 PM, Ted Unangst <[EMAIL PROTECTED]> wrote: > On Thu, Oct 30, 2008 at 7:42 PM, Ted Unangst <[EMAIL PROTECTED]> > wrote: > > Can people with these new tiny notebooks send me a nice high res (1k x 1k > is > > good) pic showing the keyboard layout? Maybe with a quarter or euro to > show > > scale? Off list of course. I'd like to make a gallery because the > keyboard > > is critical and it's hard to find decent pics of the keyboard sometimes. > > http://ted.unangst.googlepages.com/laptopkeyboards > > If anyone has one of the Lenovo IdeaPad U110, I'm particularly > interested. From the web photos, it seems they have moved the tilde.
Re: Missing security announcements
On Thu, Nov 13, 2008 at 12:55:36PM -0500, Ted Unangst wrote:
> On Thu, Nov 13, 2008 at 12:35 PM, Aaron W. Hsu <[EMAIL PROTECTED]> wrote:
> > Is security-announce an open list? If not, give me access and I'll
> > keep it reasonably up to date, give or take a day or so of release of
> > the Security Errata on the website, unless there is an even faster way
> > of checking it out, such as CVS.
>
> It is moderated, and really, outsiders should not be posting to it
> because then it appears that they have some position of authority.
> The only person who should be posting to the list is the person who
> made the fix, because they are the security contact. When people
> reply, it is important they are talking to the right person.
I just wrote something quick in perl that scrapes the errata pages of
the two most recent releases and sends a nicely formatted email for any
that are have change since the last check.
It does require a couple of packages be installed (p5-libwww and
p5-HTML-Tree) but if there were enough interest from someone who could
do something with it, I could probably make it work with just what is
available in the base system.
There are lots of ways to break something that scrapes html, but it is
at least automated.
l8rZ,
--
andrew - ICQ# 253198 - Jabber: [EMAIL PROTECTED]
#!/usr/bin/perl -T
use strict;
use warnings;
%ENV = ();
#Additional modules needed
use LWP::Simple; # pkg_add p5-libwww
use HTML::TreeBuilder;# pkg_add p5-HTML-Tree
# Core modules
use Text::Wrap;
use Fcntl ':flock'; # import LOCK_* constants
# should end with a /
my $base_url = 'http://www.OpenBSD.org/';
my $start_page = 'errata.html';
my $sender= '[EMAIL PROTECTED]';
my $recipient = '[EMAIL PROTECTED]';
# should end with a /
my $base_dir = '/home/andrew/.openbsd_errata_notifier/';
my $max_versions_to_process = 2;
#*#*# Nothing to change beyond this point #*#*#
my $tree = HTML::TreeBuilder->new();
my $content = get( $base_url . $start_page )
or die "Could't get [$start_page]: $!";
$tree->parse($content)->eof;
my @errata_urls;
foreach my $link ( @{ $tree->extract_links('a') } ) {
my ( $url, $element, $attr, $tag ) = @{$link};
if ( $url =~ /^errata\d+\.html\Z/xms ) {
push @errata_urls, $base_url . $url;
}
}
$tree->delete;
my $processed = 0;
URL: foreach my $url ( reverse @errata_urls ) {
$processed++;
last URL if $processed > $max_versions_to_process;
my $tree = HTML::TreeBuilder->new();
my $content = get($url) or die "Couldn't get [$url]: $!";
$tree->parse($content)->eof;
my $title = $tree->find('title')->as_trimmed_text;
my ($version) = $title =~ /\b ( \d+ \. \d ) \b/xms;
foreach my $entry ( reverse $tree->find('ul')->find('li') ) {
my $errata = process_errata_entry($entry);
$errata->{version} = $version;
$errata->{url} = $url;
my $message = format_errata_message($errata);
my $file= make_errata_dir($errata);
if ( should_send( $message, $file ) ) {
mail($message);
}
}
$tree->delete;
}
sub process_errata_entry {
my ($errata) = @_;
my $id = $errata->find('a')->attr('name');
my ( $num, $type, $date ) = split /:\s*/xms,
$errata->find('strong')->as_trimmed_text;
my $arch = $errata->find('i')->as_trimmed_text;
my %errata = (
id => $id,
number => $num,
type => $type,
date => $date,
arch => $arch,
);
foreach my $content ( $errata->content_list ) {
if ( ref $content eq 'HTML::Element' ) {
if ( my $href = $content->attr('href') ) {
if ( $href =~ m{ftp\.openbsd\.org.*patch\Z}ixms ) {
$errata{patch} = {
href => $href,
text => $content->as_trimmed_text,
};
$content->delete;
}
elsif ( $href =~ m{CVE-} ) {
push @{ $errata{cve} },
{
href => $href,
text => $content->as_trimmed_text,
};
$content->delete;
}
}
}
}
foreach my $br ( $errata->find('br') ) {
$br->replace_with("\n");
}
my @descr = split /\n/, $errata->as_text;
shift @descr;
pop @descr;
foreach my $m (@descr) {
$m =~ s/^\s+//xms;
$m =~ s/\.\W+\Z/\./xms;
}
$errata{description} = [EMAIL PROTECTED];
return \%errata;
soekris net4501 and openbsd 4.4 constant reboot problem
To all:
I've noticed that my soekris net4501 box constantly reboots with
openbsd 4.4 patchlevel 005. It's just a pf/nat router on a
residential broadband cable modem. My guess is perhaps there is
something wrong with the
actual sis0 interface?.?.? Anybody else having these problems? Fwiw,
the net4501 has three interfaces, eth0, eth1 eth2. eth0 is the
internet side of the box, gets a dynamic ip address from the cable
company, and eth1 (sis1) is a static 192.168.20/24 that serves dhcp to
all of it's 5 clients. Eth2 is not being used yet.
Initially this box was an IPSEC endpoint - that used a gre tunnel to
another openbsd box - it rebooted - every 4 hours, and now that I took
down the IPSEC tunnel, the box will reboot every < 48 hours. weird.
below is output from dmesg. Any help would be appreciated. I had 4.2
running on this boxand it seemed real stable. I'll probably go
back to 4.2 and test or i'll try to use eth1 and eth2 instead.
regards,
-andrew-
Nov 16 14:52:43 hostname.com.com/bsd: uvm_fault(0xd083df80,
0x9980, 0, 3) -> e
Nov 16 14:52:43 hostname.com.com /bsd: kernel: page fault trap, code=0
Nov 16 14:52:43 hostname.com.com/bsd: Stopped atsis_rxeof+0xcf:
movl%edi,
Nov 16 14:52:43hostname.com.com /bsd: OpenBSD 4.4 (GENERIC) #1: Sun
Nov 9 02:47:08 EST 2008
OpenBSD 4.4 (GENERIC) #1: Sun Nov 9 02:47:08 EST 2008
:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Am486DX4 W/B or Am5x86 W/B 150 ("AuthenticAMD" 486-class)
cpu0: FPU
real mem = 66678784 (63MB)
avail mem = 55017472 (52MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/80/03, BIOS32 rev. 0 @
0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
elansc0 at pci0 dev 0 function 0 "AMD ElanSC520 PCI" rev 0x00:
product 0 stepping 1.1, CPU clock 133MHz, reset 0
gpio0 at elansc0: 32 pins
sis0 at pci0 dev 18 function 0 "NS DP83815 10/100" rev 0x00,
DP83816A: irq 10, address 00:00:24:ca:cb:68
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 19 function 0 "NS DP83815 10/100" rev 0x00,
DP83816A: irq 11, address 00:00:24:ca:cb:69
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 20 function 0 "NS DP83815 10/100" rev 0x00,
DP83816A: irq 5, address 00:00:24:ca:cb:6a
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
wdc0 at isa0 port 0x1f0/8 irq 14
wd0 at wdc0 channel 0 drive 0:
wd0: 4-sector PIO, LBA, 1953MB, 4001760 sectors
wd0(wdc0:0:0): using BIOS timings
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
biomask f3c5 netmask ffe5 ttymask
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
Edgeport/421 (TI version) serial is ugen
I recently got an Edgeport/421 (4 USB, 2 RS-232 DB-9, 1 parallel) that seemed like it would be really handy since this computer is legacy free and doesn't have any serial ports and having serial ports would be really handy. http://www.digi.com/products/usb/edgeport.jsp Everything seems to work great. Except the serial ports. Are there any suggestions on what I might need to do to make the serial ports work? >From looking and then taking it apart, it appears to be the newer TI version that is mostly just a TUSB5052 with one of the free ports hooked to a USB Parallel port. http://focus.ti.com/docs/prod/folders/print/tusb5052.html Is there already a USB serial driver that supports the TUSB5052 chip that I can just add the detection to? I am currently looking at uticom.c, but it claims: "XXX: multiport chips are not supported yet" More information if it helps. Snipped from a dmesg with UGEN_DEBUG set and ugendebug set to 10: uhub3 at uhub1 port 3 "Inside Out Networks product 0x028c" rev 1.10/1.51 addr 2 ulpt0 at uhub3 port 5 configuration 1 interface 0 "Inside Out Networks Edgeport/(4)21 Parallel" rev 1.00/1.00 addr 3 ulpt0: using bi-directional mode ugen0 at uhub3 port 6 "Inside Out Networks Edgeport/421" rev 1.10/0.01 addr 4 ugen_set_config: ugen0 to configno 1, sc=0x80127000 ugen_set_config: ifaceno 0 ugen_set_config: endptno 0, endpt=0x81(1,128), sce=0x80127468 ugen_set_config: endptno 1, endpt=0x01(1,0), sce=0x80127310 ugen_set_config: endptno 2, endpt=0x82(2,128), sce=0x80127718 ugen_set_config: endptno 3, endpt=0x02(2,0), sce=0x801275c0 ugen_set_config: endptno 4, endpt=0x87(7,128), sce=0x80128488 Some of the output from usbdevs -vd: Controller /dev/usb1: port 3 addr 2: full speed, self powered, config 1, product 0x028c(0x028c), Inside Out Networks(0x1608), rev 1.51 uhub3 port 1 powered port 2 powered port 3 powered port 4 powered port 5 addr 3: full speed, power 98 mA, config 1, Edgeport/(4)21 Parallel(0x000b), Inside Out Networks(0x1608), rev 1.00 ulpt0 port 6 addr 4: full speed, self powered, config 1, Edgeport/421(0x020c), Inside Out Networks(0x1608), rev 0.01, iSerialNumber V50419195-0 ugen0 I did ask the Google, and marc.info, and although I did find the Linux and Sun drivers that Digi provides, I did not find anything that was useful to me. l8rZ, -- andrew - ICQ# 253198 - Jabber: [EMAIL PROTECTED] BOFH excuse of the day: the butane lighter causes the pincushioning
Re: Trouble ticket system suggestions
On Tue, Dec 23, 2008 at 08:23:16PM +0100, Marc Balmer wrote: > ... > > for otrs I have a port. we use it since years, it is nice. Seconds for OTRS; obsd has been running it well for me for the last four years.
Re: Trouble ticket system suggestions
fortune _fill_in_the_blank has no bearing whatsoever. I've used RT for a few things and it's worked out. If you aren't happy with anything that exists... make your own. p.s. the rt mailing list is pretty active with progressive results. this has nothing to do with openbsd. -a On Tue, Dec 23, 2008 at 9:04 PM, Ted Unangst wrote: > On Tue, Dec 23, 2008 at 7:49 PM, Johan Beisser wrote: > > I don't think any are bankrupt due to RT. > > No, but the general implication with these "X is used by Fortune 9000" > endorsements is that their selection process/judgment/whatnot is > obviously superior, so if they use something, it has to be good. > Really, it has no bearing on anything. Just a pet peeve, and it > seemed especially discordant now.
Re: Trouble ticket system suggestions
since when does fortune _ _ _ _ _ have policy? Seriously, production is a joke. -a On Tue, Dec 23, 2008 at 9:19 PM, bofh wrote: > On Tue, Dec 23, 2008 at 10:04 PM, Ted Unangst > wrote: > > On Tue, Dec 23, 2008 at 7:49 PM, Johan Beisser wrote: > >> I don't think any are bankrupt due to RT. > > > > No, but the general implication with these "X is used by Fortune 9000" > > endorsements is that their selection process/judgment/whatnot is > > obviously superior, so if they use something, it has to be good. > > Really, it has no bearing on anything. Just a pet peeve, and it > > seemed especially discordant now. > > Conversely, if a F100 company actually uses any open source software, > given the moronic things in place (for example, the current place > *must have* paid support for anything in production use, no matter > _how_ small, for example, syslog-ng), it should be seen that it was > implemented *IN SPITE* of corporate policies. This means that piece > of software is that good, or the people implementing it were that good > that they could push something like this through. > > > -- > http://www.glumbert.com/media/shift > http://www.youtube.com/watch?v=tGvHNNOLnCk > "This officer's men seem to follow him merely out of idle curiosity." > -- Sandhurst officer cadet evaluation. > "Securing an environment of Windows platforms from abuse - external or > internal - is akin to trying to install sprinklers in a fireworks > factory where smoking on the job is permitted." -- Gene Spafford > learn french: http://www.youtube.com/watch?v=j1G-3laJJP0&feature=related
Re: Release IP-adress OpenBSD 3.8
On Tue, Jan 6, 2009 at 3:11 PM, Stuart Henderson wrote: > Release is an optional part of DHCP but some servers won't reassign the > IP address to a client with another MAC unless it happens. In that case > the best option is probably to try another DHCP client from ports/packages. > > At least in the current OpenBSD version you have a couple of options; > the ISC client allows this with the -r flag, and the WIDE client allows > it with SIGUSR2. It's good to know that the isc-dhcp-client from ports lets you do this; it would be nice if the dhclient in base had this functionality. If it's a matter of "we don't have time -- submit a patch", I'd be happy to port that functionality (disclaimer: assuming the code isn't extremely hairy; I haven't delved into it yet), but I don't want to waste my time if it's not likely to be accepted. My reason for needing this is that my ISP (actually, I know of several like this) is like the server you describe, in that it refuses to hand out another DHCP lease if I have an active lease for a different MAC address. After releasing that lease, I can then obtain a new one. This is most likely to happen if I swap out the box acting as my firewall/router, swap ethernet cards (or which ethernet card my DSL modem is connected to), or switch between using an OpenBSD box and a hardware router, etc. Without the DHCPRELEASE functionality, the only option is to wait until the old lease expires. Luckily my current ISP gives leases of 1 hour (maybe 2, don't remember for sure) rather than a full day. And granted, I don't do this very often, as once my firewall is set up I tend to leave it alone (aside from applying errata) but during initial setup, and/or when trying to debug why my net connection isn't working right, it does come in handy. Andrew
OpenOSPFd configure
I'am configuring ospfd on FreeBSD 6.4
I want transfer, for exmple x.x.x.0/24, network to cisco routers with the
next config:
# cat /usr/local/etc/ospfd.conf
# Global Configuration
router-id yy.yy.yy.yy
redistribute zz.zz.zz.0/27 (ospfd host and cisco network)
redistribute x.x.x.0/24
area 0.0.0.0 {
auth-type crypt
auth-md 1 "KE34rt#2d3)"
auth-md-keyid 1
interface vr0 { hello-interval 5
router-dead-time 20
}
}
When i start ospfd:
]# ospfd -d
startup
if_del: interface vr0
rde_asext_get: zz.zz.zz.0/27 is net LSA
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vr0
if_fsm: event UP resulted in action START and changing state for interface
vr0 from DOWN to WAIT
spf_calc: area 0.0.0.0 calculated
if_act_elect: interface vr0 old dr none new dr yy.yy.yy.yy, old bdr none new
bdr none
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vr0
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vr0
if_fsm: event WAITTIMER resulted in action ELECT and changing state for
interface vr0 from WAIT to DR
rde_asext_get: zz.zz.zz.0/27 is net LSA
rde_asext_get: zz.zz.zz.0/27is net LSA
No route on cisco from ospfd daemon. Where I make mistakes?
Re: Creating release using site48.tgz
On Mon, May 09, 2011 at 04:59:17PM -0700, Stefan N wrote: > Are my steps correct? Close, but install sets are created in /usr/release and extracted relative to root so you need something more like this: tar -czf /usr/release/site48.tgz etc/pf.conf etc/rc.firsttime etc/backup.sh Although I would also recommend creating site49.tgz and installing 4.9. l8rZ, -- andrew - http://afresh1.com There are two ways to write error-free programs; only the third one works.
Re: Creating release using site48.tgz
On Mon, May 09, 2011 at 05:28:12PM -0700, Stefan N wrote:
> Thanks. By the way, I don't see the release directory inside the source
> file(/usr/src) directory.
> Does it mean that I need to create directory mkdir /usr/release first if my
> source files is at /usr/src?
The release man page does describe creating RELEASEDIR
# mkdir -p ${DESTDIR} ${RELEASEDIR}
I generally set RELEASEDIR=/usr/release, but it can really be a path
anywhere you want your sets. The important part is that site48.tgz is
in the same directory as the rest of the install sets.
l8rZ,
--
andrew - http://afresh1.com
Computer Science: solving today's problems tomorrow.
Re: Dmesg for thinkpad x220 tablet
On Mon, May 09, 2011 at 11:25:51AM -0300, Christiano F. Haesbaert wrote: > Hi, does anyone have a dmesg for a thinkpad x220 ? I got one for the x220 tablet I got to set up today. Attached are dmesg from both the amd64 and i386 kernels as well as the output from sysctl hw and glxinfo. The touch pad does paste when using left+right click to emulate the third button. The touchscreen didn't work in the default install, but I didn't have time to try to make it work. l8rZ, -- andrew - http://afresh1.com Microsoft Windows: Proof that P.T. Barnum was correct OpenBSD 4.9-current (GENERIC.MP) #111: Wed May 11 10:41:28 MDT 2011 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 4176080896 (3982MB) avail mem = 4050870272 (3863MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xbae23000 (66 entries) bios0: vendor LENOVO version "8DET41WW (1.11 )" date 03/28/2011 bios0: LENOVO 4294CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2691.65 MHz cpu0: 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2691.26 MHz cpu1: 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2691.26 MHz cpu2: 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2691.26 MHz cpu3: 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4879" serial 9051 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK docked (15) cpu0: Enhanced SpeedStep 2691 MHz: speeds: 2701, 2700, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel GT2+ Video" rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp at vga1 not configured "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured "Intel 6 Series KT" rev 0x04 at pci0 dev 22 function 3 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: apic 2 int 20, address f0:de:f1:5c:c6:4b ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x04: apic 2 int 22 azalia0: codecs: Conexant/0x506e, Intel/0x2805, using Conexant/0x506e audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: apic 2 int 16 pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb4: apic 2 int 17 pci2 at ppb1 b
Relayd.conf -- Default closing of connection
Hello, In the default relayd.conf, we have, in the "httpssl" protocol, the directive `header change "Connection" to "close"`. What about relayd makes this desirable (why close connections when we can reuse them or let them time out?), and what are the consequences of NOT having this directive? -- Thanks, Andrew Klettke Systems Admin Optic Fusion NOC 253-830-2943
Re: Relayd.conf -- Default closing of connection
Anybody?
What makes this even more confusing is that in the man page for
relayd.conf, it specifies a protocol called "http_ssl" that does NOT
have this directive:
http protocol "http_ssl" {
header append "$REMOTE_ADDR" to "X-Forwarded-For"
header append "$SERVER_ADDR:$SERVER_PORT" to
"X-Forwarded-By"
header change "Keep-Alive" to "$TIMEOUT"
query hash "sessid"
cookie hash "sessid"
path filter "*command=*" from "/cgi-bin/index.cgi"
ssl { sslv2, ciphers "MEDIUM:HIGH" }
}
The protocol in the default relayd.conf DOES, however:
http protocol httpssl {
header append "$REMOTE_ADDR" to "X-Forwarded-For"
header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
header change "Connection" to "close"
# Various TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
I'm just after an explanation of what closing the connection is
attempting to accomplish, and why it seems to be arbitrarily inserted
into the default relayd.conf.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion NOC
253-830-2943
On 05/31/2011 10:34 AM, Andrew Klettke wrote:
Hello,
In the default relayd.conf, we have, in the "httpssl" protocol, the
directive `header change "Connection" to "close"`.
What about relayd makes this desirable (why close connections when we
can reuse them or let them time out?), and what are the consequences
of NOT having this directive?
Home owners building cover
Home Owners (Building) Insurance
http://www.homeowners-insurance.co.za/?sourceID=1036&campaignID=51
Benefits
Enjoy a minimum saving of 20% on Home Owners (Building) Insurance.
As offered by the bonding banks. When insurance companies offer up to 20%
reduction this could be anything from 0% to 20%.
http://www.homeowners-insurance.co.za/?sourceID=1036&campaignID=51
Easy to process.
We will deal with your existing Home Owners insurer and handle everything on
your behalf. All you need to do is give us permission to save you money every
month.
We will never expose you to under-insurance.
Under-insurance occurs when the amount for which the property is insured, is
less than the replacement value of such property. We are the only company in
South Africa that offers this.
We offer full geyser warranty.
We are available 24/7 - 365 whether it's an emergency or not.
Terms and conditions apply.
Be advised that product benefits and offering may differ from insurer to
insurer. If you feel you received this communication by mistake, please
select this link {--unsubscribe--} to stop receiving any promotional offers
or important news.
136 Glen Avenue, Hurlingham, 2194
[demime 1.01d removed an attachment of type image/jpeg which had a name of
dshome_button.jpg]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
dshome-header.jpg]
bioctl + ami panic "Non dma-reachable buffer" on 5.0/amd64
2MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 7 ioapic1 at mainbus0: apid 8 pa 0xfec8, version 20, 24 pins ioapic1: misconfigured as apic 0, remapped to apid 8 ioapic2 at mainbus0: apid 9 pa 0xfec83000, version 20, 24 pins ioapic2: misconfigured as apic 0, remapped to apid 9 acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PALO) acpiprt2 at acpi0: bus 2 (DOBA) acpiprt3 at acpi0: bus 3 (DOBB) acpiprt4 at acpi0: bus 4 (PBLO) acpiprt5 at acpi0: bus 8 (VPR0) acpiprt6 at acpi0: bus 5 (PBHI) acpiprt7 at acpi0: bus 6 (PXB1) acpiprt8 at acpi0: bus 7 (PXB2) acpiprt9 at acpi0: bus 9 (PICH) acpicpu0 at acpi0 acpicpu1 at acpi0 ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x09 ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x09 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 "Intel IOP332 PCIE-PCIX" rev 0x06 pci2 at ppb1 bus 2 ami0 at pci2 dev 14 function 0 "Dell PERC 4e/Di" rev 0x06: apic 8 int 14 ami0: Dell 16c, 32b, FW 5B2D, BIOS vH435, 256MB RAM ami0: 1 channels, 0 FC loops, 1 logical drives scsibus0 at ami0: 40 targets sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct fixed sd0: 69880MB, 512 bytes/sector, 143114240 sectors scsibus1 at ami0: 16 targets safte0 at scsibus1 targ 6 lun 0: SCSI2 3/processor fixed ppb2 at pci1 dev 0 function 2 "Intel IOP332 PCIE-PCIX" rev 0x06 pci3 at ppb2 bus 3 ppb3 at pci0 dev 4 function 0 "Intel E7520 PCIE" rev 0x09 pci4 at ppb3 bus 4 ppb4 at pci0 dev 5 function 0 "Intel E7520 PCIE" rev 0x09 pci5 at ppb4 bus 5 ppb5 at pci5 dev 0 function 0 "Intel 6700PXH PCIE-PCIX" rev 0x09 pci6 at ppb5 bus 6 em0 at pci6 dev 7 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: apic 9 int 0, address 00:18:8b:2e:2d:c2 ppb6 at pci5 dev 0 function 2 "Intel 6700PXH PCIE-PCIX" rev 0x09 pci7 at ppb6 bus 7 em1 at pci7 dev 8 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: apic 9 int 1, address 00:18:8b:2e:2d:c3 ppb7 at pci0 dev 6 function 0 "Intel E7520 PCIE" rev 0x09 pci8 at ppb7 bus 8 uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 7 int 16 uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: apic 7 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: apic 7 int 18 ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: apic 7 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb8 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2 pci9 at ppb8 bus 9 vga1 at pci9 dev 13 function 0 "ATI Radeon VE" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 7 int 18 drm0 at radeondrm0 pcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02 pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus2 at atapiscsi0: 2 targets cd0 at scsibus2 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec mtrr: Pentium Pro MTRR support uhub4 at uhub0 port 3 "Dell product 0xa001" rev 2.00/0.00 addr 2 uhidev0 at uhub3 port 2 configuration 1 interface 0 "Avocent APC AP5631" rev 1.10/1.00 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes, country code 33 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub3 port 2 configuration 1 interface 1 "Avocent APC AP5631" rev 1.10/1.00 addr 2 uhidev1: iclass 3/1, 3 report ids ums0 at uhidev1 reportid 1: 5 buttons, Z dir wsmouse0 at ums0 mux 0 uhid0 at uhidev1 reportid 2: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (07d4420bed41129f.a) swap on sd0b dump on sd0b Thanks, Andrew Daugherity
Relayd -- Downloading large files fails with "Cannot allocate memory"
Running 4.9, downloading large files (>250MB) from a website behind a
firewall clustered with relayd fails with the following error in our logs:
Dec 6 12:14:15 fw01 relayd[5615]: relay httpproxy, session 768464 (23
active), 0, * -> 192.168.15.101:80, Cannot allocate memory
Here are the applicable relayd.conf directives:
relay httpproxy {
listen on $relayd_addr port $relayd_port
protocol "httpfilter"
forward to port 80 mode loadbalance check http "/"
code 200
}
http protocol "httpfilter" {
tcp { nodelay, sack, socket buffer 65536, backlog 50 }
return error
header append "$REMOTE_ADDR" to "X-Forwarded-For"
header change "Keep-Alive" to "$TIMEOUT"
}
Any thoughts? Has anyone seen anything like this before? vmstat shows
plenty of free RAM.
--
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
253-830-2943
Relayd -- No longer logging relays after upgrade to 5.0
Hey all, Relayd seems to have stopped logging relays by default in 5.0; and neither the "-v" flag when starting relayd nor specifying "log all" or "log updates" in relayd.conf is working. For reference, /var/log/daemon used to be filled with relay logs like so: Oct 29 11:05:04 fw01 relayd[20205]: relay httpproxy, session 125663 (2 active), 0, ***.***.66.206 -> 192.168.15.102:80, last write (done) These are no longer appearing. Any ideas? -- Thanks, Andrew Klettke Systems Admin Optic Fusion 253-830-2943
Relayd -- Logging Weirdness
2 uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 18 ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92 pci7 at ppb6 bus 17 vga1 at pci7 dev 3 function 0 "ATI ES1000" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 2 int 22 drm0 at radeondrm0 pciide0 at pci7 dev 4 function 0 "ITExpress IT8213F" rev 0x00: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 2 int 23 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) ichpcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02: PM disabled pciide1 at pci0 dev 31 function 2 "Intel 82801I SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using apic 2 int 17 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6 ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 2 int 17 iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627HF wbng0 at iic0 addr 0x2f: w83793g spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x52: 1GB DDR2 SDRAM ECC PC2-6400CL5 pciide2 at pci0 dev 31 function 5 "Intel 82801I SATA" rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide2: using apic 2 int 18 for native-PCI interrupt "Intel 82801I Thermal" rev 0x02 at pci0 dev 31 function 6 not configured usb2 at uhci0: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41 lm2 at wbsio0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 mtrr: Pentium Pro MTRR support lm1: disabling sensors vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a swap on wd0b dump on wd0b -- Thanks, Andrew Klettke Systems Admin Optic Fusion 253-830-2943
Re: 4.6 patch support
On Mon, Mar 22, 2010 at 01:36:45PM +0200, Andreas Gerdd wrote: > I've an OpenBSD 4.6-Stable system. I wanted to ask how long will > OBSD4.6 has patch/update support? If you already follow -stable, it is the same process to upgrade to newer release. The main differences are that you get newer versions of packages and when you run sysmerge it asks a few more questions. There may be a few other small things, but they should all be mentioned in the upgrade guide. It confuses me when people want support for older versions. Somehow they can follow -stable but upgrading to a new release is too hard? Perhaps they assume that as long as the fixes are committed to the -stable cvs tag, the -release code on their machine somehow magically has it because the version numbers are the same. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net - Twitter: @AFreshOne BOFH excuse of the day: secretary plugged hairdryer into UPS
Radius Auth and Insecurity Outputs
Hello all, I'm having a (cosmetic) problem with a couple of OpenBSD boxes that are using RADIUS authentication. When I install the OS, I create a local user with local authentication. After the box's network config is all done, I then change the login class of the user to so I can use RADIUS, by modifying /etc/master.passwd with `vipw', so it looks like this: (removed):*:1000:10:radius:0:0::/home/(removed):/bin/ksh The problem then occurs when /etc/security runs, as it gives the following output: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. This login is being used successfully with RADIUS, all is working as expected, I just want to get rid of this error. Any input? -- Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 Subscribe to Optic Fusion's Twitter service for up to the minute network issues and maintenance notifications. http://www.twitter.com/opticfusion
Re: Radius Auth and Insecurity Outputs
Ted, You mean the "*" field? I've replaced that with "radius", as you suggested, so it looks like so: (removed):radius:1000:10:radius:0:0:nocstaff:/home/(removed):/bin/ksh It works, the user can log in fine still; however, OpenBSD still isn't happy about it: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. Any thoughts? Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 Subscribe to Optic Fusion's Twitter service for up to the minute network issues and maintenance notifications. http://www.twitter.com/opticfusion On 04/19/2010 02:34 PM, Ted Unangst wrote: On Mon, Apr 19, 2010 at 3:14 PM, Andrew Klettke wrote: When I install the OS, I create a local user with local authentication. After the box's network config is all done, I then change the login class of the user to so I can use RADIUS, by modifying /etc/master.passwd with `vipw', so it looks like this: (removed):*:1000:10:radius:0:0::/home/(removed):/bin/ksh The problem then occurs when /etc/security runs, as it gives the following output: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. This login is being used successfully with RADIUS, all is working as expected, I just want to get rid of this error. Any input? Looks like changing the password field to "radius" will work.
Re: Radius Auth and Insecurity Outputs
Thanks again Ted, This is an ugly hack (and one that I'll have to keep performing with these types of installs), but if it's the only way to get /etc/security to stop complaining, then I guess that's what I'll have to do. Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 Subscribe to Optic Fusion's Twitter service for up to the minute network issues and maintenance notifications. http://www.twitter.com/opticfusion On 04/19/2010 03:04 PM, Ted Unangst wrote: On Mon, Apr 19, 2010 at 5:42 PM, Andrew Klettke wrote: You mean the "*" field? I've replaced that with "radius", as you suggested, so it looks like so: (removed):radius:1000:10:radius:0:0:nocstaff:/home/(removed):/bin/ksh It works, the user can log in fine still; however, OpenBSD still isn't happy about it: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. Guess my awk isn't as awesome as it used to be. I'd just edit /etc/security. There's a check in there to make sure the password isn't skey. Add another check that's it's not radius.
Hang booting kernel >4.5 on i386 system.
Hello,
I have a system which hangs if I try to boot bsd or bsd.rd from 4.6 or
4.7-current, but which works with 4.5. The system is a small form factor
"firewall box" - a Fabiatech FX5621. I've attached the output of dmesg and
lspci from when running the generic 4.5 kernel. When attempting to boot a
more recent kernel the output gets only as far as:
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
mem address conflict 0xe000/0x1000
Let me know if I need to submit this via sendbug(1).
Regards,
Andrew
--
Andrew Back
mailto:and...@osmosoft.com
http://carrierdetect.com
OpenBSD 4.5 (RAMDISK_CD) #1112: Sat Feb 28 15:06:26 MST 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR
real mem = 502886400 (479MB)
avail mem = 47984 (457MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/16/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS
rev. 2.5 @ 0xfc390 (47 entries)
bios0: vendor American Megatrends Inc. version "080014" date 01/16/2009
acpi at bios0 function 0x0 not configured
mpbios at bios0 function 0x0 not configured
pcibios0 at bios0: rev 3.0 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf5780/336 (19 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x1106 product 0x3287
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #130 is the last bus
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xd2000/0x1000
0xd3000/0x1000
cpu0 at mainbus0: (uniprocessor)
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA CN700 Host" rev 0x00
pchb1 at pci0 dev 0 function 1 "VIA CN700 Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA CN700 Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA PT890 Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA CN700 Host" rev 0x00
pchb5 at pci0 dev 0 function 7 "VIA CN700 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA VT8377 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "VIA S3 Unichrome PRO IGP" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
rl0 at pci0 dev 9 function 0 "Realtek 8139" rev 0x10: irq 10, address
00:04:a7:08:93:b5
rlphy0 at rl0 phy 0: RTL internal PHY
rl1 at pci0 dev 10 function 0 "Realtek 8139" rev 0x10: irq 11, address
00:04:a7:08:93:b4
rlphy1 at rl1 phy 0: RTL internal PHY
rl2 at pci0 dev 11 function 0 "Realtek 8139" rev 0x10: irq 5, address
00:04:a7:08:93:b3
rlphy2 at rl2 phy 0: RTL internal PHY
rl3 at pci0 dev 12 function 0 "Realtek 8139" rev 0x10: irq 3, address
00:04:a7:08:93:b2
rlphy3 at rl3 phy 0: RTL internal PHY
pciide0 at pci0 dev 15 function 0 vendor "VIA", unknown product 0x5287 rev
0x20: DMA (unsupported), channel 0 configured to native-PCI, channel 1
configured to native-PCI
pciide0: using irq 11 for native-PCI interrupt
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x07: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide1:0:0): using PIO mode 4, DMA mode 2
pciide1: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x91: irq 10
ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x90: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "VIA EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0 dev 17 function 0 "VIA VT8251 ISA" rev 0x00
pchb6 at pci0 dev 17 function 7 "VIA VT8251 VLINK" rev 0x00
ppb1 at pci0 dev 19 function 0 "VIA VT8251 PCIE" rev 0x00
pci2 at ppb1 bus 128
ppb2 at pci2 dev 0 function 0 "VIA VT8251 PCIE" rev 0x00
pci3 at ppb2 bus 130
et0 at pci3 dev 0 function 0 "AT&T/Lucent ET1310" rev 0x03: irq 10, address
00:04:a7:05:9a:e0
etphy0 at et0 phy 0: ET1011 10/100/1000baseT PHY, rev. 2
ppb3 at pci2 dev 0 function 1 "VIA VT8251 PCIE" rev 0x00
pci4 at ppb3 bus 129
et1 at pci4 dev 0 function 0 "AT&T/Lucent ET1310" rev 0x03: irq 10, address
00:04:a7:05:9a:e1
etphy1 at et1 phy 0: ET1011 10/100/1000baseT PHY, rev. 2
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "VIA UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf
Re: Help contacting Richard Stallman
On Wed, May 26, 2010 at 02:52:50PM -0500, Vanessa Kraus wrote: > For what it's worth, I am on a good number of oss lists (including > Linux), and there are no other mentions of RMS anywhere. Also FWIW, saw a lot of OpenBSD + RMS chatter on the Twitter in the last 24 hours. http://search.twitter.com/search?ands=openbsd&phrase=&ors=stallman+rms Just stay away from the rest of the thread you may end up linked to. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net - Twitter: @AFreshOne BOFH excuse of the day: Someone's tie is caught in the printer, and if anything else gets printed, he'll be in it too.
Ospfd.conf, fib-update, and Syntax Errors
All,
I'm having a really strange issue with a 4.7 box running -stable and the
option "fib-update no" in ospfd.conf:
Here's my ospfd.conf:
# cat /etc/ospfd.conf
# $OpenBSD: ospfd.conf,v 1.4 2007/06/19 16:49:56 reyk Exp $
# Global Config
router-id ***.***.***.***
fib-update no
area 0.0.0.31 {
interface fxp0 {
auth-type crypt
auth-md-keyid **
auth-md 1
}
interface lo1 {
passive
}
}
Now, when I try to bring up ospfd...
# ospfd -n
/etc/ospfd.conf:5: syntax error
Line 5, of course, is the "fib-update no" line. I know this is the
correct synatx ( or at least the man page for ospfd.conf says so), so
what gives?
--
Thanks,
Andrew Klettke
Optic Fusion NOC
253-830-2943
Re: Why I left OpenBSD
On Thu, Jun 10, 2010 at 11:28:40AM +0300, Dexter Tomisson wrote: > http://www.trollaxor.com/2010/06/why-i-left-openbsd.html On Wed, Jun 16, 2010 at 11:24:01AM +1000, Ted wrote: > http://www.trollaxor.com/2010/06/why-i-almost-gave-openbsd-10-didnt.html Since for some reason this thread is still here, I will copy and paste what I believe to be the most relevant text on either of those pages. It is duplicated on both, but I will only quote it once. Disclaimer This site contains works of fiction. If you don't realize that you're reading fiction, you shouldn't be here. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net - Twitter: @AFreshOne BOFH excuse of the day: Our POP server was kidnapped by a weasel.
Re: Open Source hardware (Re: can't get vesa @ 1280x800 or nv)
On Sat, Dec 5, 2009 at 2:30 PM, Matthieu Herrb wrote: > On Sat, Dec 5, 2009 at 9:02 PM, rhubbell wrote: > >> Yes, I'd like to see some pointers also. I recall that there was >> discussion (might've been on linux kernel) a while ago about a >> partially-open video card. Why doesn't the community support that? > > You mean http://www.opengraphics.org ? > What makes you say that? How did *you* contribute? > >> I recall that price was a factor in lack of uptake. >> Seems to me that opensource is farsical if it runs on closesource hardware. >> So where's the opensource hardware? Seems like the new world order isn't >> going to allow that. The trend in hardware looks like a race to keep >> control. Seems like we are going to be paying for the hardware but not >> owning; instead leasing. >> >> Or am I behind the times and there's salvation from some beneficent >> hardware maker in Taiwan? > > Making hardware is a lot more difficult than writing software. So it takes > more resources and more skills. This is probably why there aren't so > many of them. A graphics card is about both, and I don't think hardware is that 'hard' (if I can do it it must be easy :-). The real barriers to entry are economic. A mask set for a current generation ASIC (say 45nm) is somewhere upwards of one million US $. (http://www.eetimes.com/showArticle.jhtml?articleID=198900081) so unless you have terrific volumes to amortize over, custom chips are pretty much out of play. You could see if you can swing a deal with someone to roll the mask costs into the piece price, but you'll have to convince them that you'll run enough pieces to make it worth their while. In general the specialized design software needed to make a design that will work costs a similar amount (digital and analog simulators, logic synthesis, Design rule checkers, place and route, design for test, etc). That pretty much leaves you in the FPGA world like the opengraphics people are. You can use the FPGA vendor's volumes to get access to leading edge process technology, but are stuck with their architecture. Usually the premium FPGAs start at around $100 ea. and go up into the $1000 range, so you end up looking at the 'value' parts (spartan and cyclone for brand X and brand A) to keep costs down which limits what you can do even more. The one nice thing about FPGA is that the vendors usually make the parts for a long time, so availability and control is good.
Again, OpenBSD r0x! Thank you.
Setting up a new firewall, OpenBSD is making it easy. in /etc/pf.macros ftp_int=$srv01 ftp_ext=$external01 ftp_port=21 in /etc/pf.conf include "/etc/pf.macros" ... # NAT/Filter Rules for FTP Server (additon to above) pass in on egress proto tcp to $ftp_ext port $ftp_port pass out on internal proto tcp to $ftp_int port $ftp_port user proxy in /etc/rc.local . /etc/pf.macros echo -n ' ftp-proxy (internal)'; /usr/sbin/ftp-proxy -R $ftp_int -p $ftp_port -b $ftp_ext Thank you! (for that and much more) l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net A printer consists of three main parts: the case, the jammed paper tray and the blinking red light.
Re: Again, OpenBSD r0x! Thank you.
On Thu, Dec 31, 2009 at 09:13:45AM +1100, Aaron Mason wrote: > Hang on... isn't ftp_proxy defined in rc.conf? It is, but I had already set ftpproxy_flags="" in rc.conf.local so users could ftp out, so I needed a second instance for inbound connections. http://www.openbsd.org/faq/pf/ftp.html#natserver "Note that if you want to run ftp-proxy(8) to protect an FTP server as well as allow clients to FTP out from behind the firewall that two instances of ftp-proxy will be required." If I did only need the one, I could have done a similar thing in rc.conf.local as I did in rc.local, just setting ftpproxy_flags instead of starting the additional instance. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net BOFH excuse of the day: root rot
Re: Recommend T1 Card for 4.6
On Wed, Jan 06, 2010 at 01:01:26PM -0700, Brandan Rowley wrote: > Is there anyone using a T1 card for data on 4.6? Perhaps a T1 to > Ethernet converter? I'm interested to find out how others have resolved > this and what hardware was used. We're using a Soekris 5501. I am (still) using Sangoma cards. They work "fine" but a warm boot instead of a cold boot sometimes causes a DDB. I have not tried any other solutions on OpenBSD. I do know there was another card that I believe an OpenBSD developer was helping make but I don't know that there was ever a product you could purchase. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net BOFH excuse of the day: Melting hard drives
Re: Recommend T1 Card for 4.6
On Wed, Jan 06, 2010 at 03:27:23PM -0700, Brandan Rowley wrote: > Thanks Andrew, Steve and David for your replies. You're welcome. > I did check the man pages for WAN devices and did a little research. > Here's what I found: > > *Accoom Networks Artery T1/E1 WAN interfaces (art) (G) This is the one I heard about. Supposedly good stuff, but were announced a month after I got my san cards so I didn't get to try to buy any. > *SBE (formerly Lan Media Corporation) SSI (T1)/HSSI/DS1/DS3 WAN > interfaces (lmc) (G) Haven't heard anything memorable about or tried. > *Sangoma Technologies AFT T1/E1 WAN interfaces (san) (G) This (A102u) I have working on 4.6 $ dmesg | grep -e OpenBSD -e san OpenBSD 4.6-stable (GENERIC.MP) #7: Tue Nov 24 10:26:10 MST 2009 san0 at pci0 dev 4 function 0 "Sangoma A10x" rev 0x01 apic 3 int 1 (irq 11) san1 at pci0 dev 8 function 0 "Sangoma A10x" rev 0x01 apic 3 int 6 (irq 10) $ ifconfig | grep ^san san0: flags=8051 mtu 1500 san1: flags=8051 mtu 1500 san2: flags=8051 mtu 1500 san3: flags=8051 mtu 1500 > Sangoma has a ton of links and info, but Sangoma has not supported > OpenBSD since 2007 as per the man page. I did purchase a Sangoma A101 > which is not recognized by 4.6 and the drivers won't install without > error. The Sangoma installation instructions on the internet are for > OpenBSD3.6 which seems pretty dated. > > Steve, How did you get your Sangoma card to work? Is it an A101u? I > believe the one I purchased was an A101c which Sangoma said replaced the > A101u. I have several of the A102u, but if I remove the daughter board it is magically an A101u, tho I have not tried that on 4.6, but did (successfully) in earlier versions. I have several messages in the archives and on gnats from when I was getting them going, but when I upgraded to 4.6 they just "worked" same as they have since I installed them. They actually seem to DDB less and less as I upgrade to newer versions of OpenBSD. Not that they would ever DDB often, generally only if I reboot instead of halt and powercycle or if something goes on with an AT&T line and they run their automated tests. One of their tests used to cause it, and may still, but I haven't had reason to find out. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net BOFH excuse of the day: Incorrectly configured static routes on the corerouters.
Re: 802.11QinQ support
On Wed, Mar 03, 2010 at 06:36:05PM +0200, Ross Cameron wrote: > Does anyone know off hand if OpenBSD 4.6 or -CURRENT supports > 802.1QinQ aka netsted VLans? > > If so, how do I configure it as I've tried the usual "ifconfig vlan? > create" and tried stipulating that the secondary VLan's parent > interface it the primary VLan interface. But this doesn't seem to work > :( I have been able to QinQ. # ifconfig vlan101 vlandev bce0 # ifconfig vlan201 vlandev vlan101 vlan101: flags=8843 mtu 1500 vlan: 101 priority: 0 parent interface: bce0 vlan201: flags=8843 mtu 1496 vlan: 201 priority: 0 parent interface: vlan101 A tcpdump when I actually tried it showed the nested vlans although I seem to have lost them. l8rZ, -- andrew - ICQ# 253198 - Jabber: and...@rraz.net - Twitter: @AFreshOne BOFH excuse of the day: sticky bit has come loose
ospf6d.conf -- Man page discrepancy
Running 5.1-RELEASE. According to ospf6d.conf(5): *router-dead-time* /seconds/ Set the router dead time, a.k.a. neighbor inactivity timer. The default value is 40 seconds; valid range is 2-2147483647 seconds. When a neighbor has been inactive for router-dead-time its state is set to DOWN. Neighbors that have been inactive for more than 24 hours are completely removed. However, when I try to set this value to, say, 60 seconds (well within the range specified above), I get the following when starting ospf6d: /etc/ospf6d.conf:13: router-dead-time out of range (2-65535) Just thought I'd bring this up, see if anyone could shed some light on this. -- Thanks, Andrew Klettke Systems Admin Optic Fusion 253-830-2943
Re: OpenBSD forked
On 14/06/2012 3:44 AM, Dominguez, Roland wrote: I just came across this article and was wondering if it's legit: http://www.h-online.com/open/news/item/OpenBSD-forked-to-create-Bitrig-161695 4.html Those who do not study history... https://www.bitrig.org/viewgit/?a=viewblob&p=bitrig&h=59fc82dbaf7eaff6cf9ee6aa607951587f5d6d7f&hb=HEAD&f=usr.bin/banner/banner.1
My first macppc install going poorly as well
I got a nice G5 from work and would like to run OpenBSD macppc on it. However, when I attempt to install I get to what is described as step 4 for i386 and amd64 in the FAQ: booting hd0a:/bsd 4464500+838332 [58+204240+181750]=0x56cfd0 http://openbsd.org/faq/faq14.html#Boot386 Except that line does not fully complete and the screen goes blank white. I get the same results booting from CDs from 4.9, 5.1 and a fairly recent snapshot. The Apple Service Diagnostic disk claims everything is in great shape. It is a Power Mac G5 Dual 1.8GHz with the NVIDIA GeForceFX 5200 Ultra video card. I believe the original "Q37" but could be a June 2004 model, no idea how to tell for sure. https://en.wikipedia.org/wiki/Power_Mac_G5 Any suggestions? Did I just get a bad one? If I had a dmesg to attach I wouldn't be asking this question. :-) l8rZ, -- andrew - http://afresh1.com Life's unfair - but root password helps!
Re: Some probelms configuring dhcpd with iPXE options
On 1/09/2012 8:22 PM, C. L. Martinez wrote: Hi all, I am trying to configure dhcpd daemon in a OpenBSD 5.1 host to use iPXE options for booting vm guests via iscsi. To do this, I have configured dhcpd.conf with these options: option space ipxe; option ipxe-encap-opts code 175 = encapsulate ipxe; ... Same configuration works for RHEL/CentOS 6.x dhcpd hosts ... What am I doing wrong?? The base dhcpd won't work this method of breaking the infinite loop, you need to create an undionly.kpxe with an embedded script. The embedded script can be as complex as you like, but it is easiest to update if you embed a simple script which chainloads your 'real' script. http://ipxe.org/howto/chainloading FWIW, you can boot OpenBSD by using memdisk to load the install iso.
Re: My first macppc install going poorly as well
On Mon, Sep 03, 2012 at 09:31:25PM +0400, Kirill Bychkov wrote: > On Sun, September 2, 2012 22:44, Kirill Bychkov wrote: > > On Sun, September 2, 2012 20:24, Andrew Fresh wrote: > >> It is a Power Mac G5 Dual 1.8GHz with the NVIDIA GeForceFX 5200 Ultra > >> video card. I believe the original "Q37" but could be a June 2004 > >> model, no idea how to tell for sure. > >> https://en.wikipedia.org/wiki/Power_Mac_G5 > > Go to OpenFirmware and then try "dev /cpus" and "ls". I will show you info > about CPU. OpenFirmware says my PowerPC,G5@0 is cpu-version 0039020 which according to the Internet is a I did need to dev /cpus/PowerPC,G5 then ".properties" to get the cpu-version, but thank you for the pointer. > I had a look at > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/macppc/macppc/cpu.c?rev=1.67 > and see only 970FX processors mentioned. As I understand 970 != 970FX. My G5 > have 970, as OpenFirmware shows. M.B. problem is hiding in it? Based on some old netbsd supported model lists I believe you are correct that 970 != 970FX. Looking up the serial number on Apple's website http://support.apple.com/specs/ it claims I have a "Power Mac G5 (June 2004)" version http://support.apple.com/kb/SP80 which is supposed to have the 970FX http://www.apple-history.com/g5_june_04 But unfortunately it seems that is not the case because my 0039020 is a 970 not a 970FX http://everythingapple.blogspot.com/2004/11/130-nm-g5-is-alive-and-well.html l8rZ, -- andrew - http://afresh1.com Computer programmers know how to use their hardware.
Re: Signatures for distribution sets and packages?
On 5/09/2012 1:36 PM, Rowdy OpenBSD wrote: Is there any way to verify that distribution sets and packages that I have downloaded have not been tampered with (e.g., by someone with access to the mirror from which I downloaded them)? Compare them to the CD set.
Re: pxeboot, machine dependent kernel
On 8/09/2012 6:14 AM, russell wrote: ... my intention is to hack boot.c(my guess, at this point I am still just looking at source) to check for and use some sort of global kernel macaddress var pxeboot claims to set. ... I played with a similar patch from here many years ago: http://nbender.com/install.netboot/install.html These days I use iPXE instead, it is fairly painless to set up.
npppd, framed_ip_address
Hm. I can't seem to get npppd to map users to static addresses in the
npppd-users file, after trying various permutations of "pool-address
##-## " and such. The client is an iPhone running iOS 6.0,
and is definitely able to set up a working vpn over l2tp/ipsec with
the npppd server (many thx, btw), but the client is then always
assigned a random address from the pool (and never the static one,
incidentally... but that could just be chance).
Did I screw something up in the configuration or has this particular
feature not been implemented yet? Has anyone else had troubles with
this?
(By the way, the daemon goes absolutely bananas if you use a
"framed-ip-address" on a different subnet than those in the pool.
Bananas! I don't recommend this error. ^^)
/etc/npppd/npppd-users
turnip:\
:password=[...]:\
:framed-ip-address=172.16.2.2:
/etc/npppd/npppd.conf
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 0.0.0.0
}
tunnel L2TP_ipv6 protocol l2tp {
listen on ::
}
ipcp IPCP {
pool-address 172.16.2.2-172.16.2.6
dns-servers 172.16.2.1
}
interface pppx0 address 172.16.2.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
bind tunnel from L2TP_ipv6 authenticated by LOCAL to pppx0
/etc/ipsec.conf
ike passive esp transport \
proto udp from pppoe0 to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "aes" \
psk [...]
(npppd -d) output
3:15:21:NOTICE: Load configuration from='/etc/npppd/npppd.conf' successfully.
3:15:21:INFO: pppx0 Started pppx
3:15:21:INFO: Listening /var/run/npppd_ctl (npppd_ctl)
3:15:21:INFO: ipcp=IPCP pool
dyn_pool=[172.16.2.2/31,172.16.2.4/31,172.16.2.6/32]
pool=[172.16.2.2/31,172.16.2.4/31,172.16.2.6/32]
3:15:21:INFO: Loading pool config successfully.
3:15:21:INFO: l2tpd Listening 0.0.0.0:1701/udp (L2TP LNS) [L2TP_ipv4]
3:15:21:INFO: l2tpd Listening [::]:1701/udp (L2TP LNS) [L2TP_ipv6]
3:15:37:NOTICE: l2tpd ctrl=1 logtype=Started RecvSCCRQ
from=[...]:65293/udp tunnel_id=1/28 protocol=1.0 winsize=4
hostname=Elephant-Triumph vendor=(no vendorname) firm=
3:15:37:INFO: l2tpd ctrl=1 SendSCCRP
3:15:38:INFO: l2tpd ctrl=1 RecvSCCN
3:15:38:INFO: l2tpd ctrl=1 SendZLB
3:15:38:INFO: l2tpd ctrl=1 call=24105 RecvICRQ session_id=362
3:15:38:INFO: l2tpd ctrl=1 call=24105 SendICRP session_id=24105
3:15:39:INFO: l2tpd ctrl=1 call=24105 RecvICCN session_id=362
calling_number= tx_conn_speed=100 framing=async
3:15:39:NOTICE: l2tpd ctrl=1 call=24105 logtype=PPPBind ppp=0
3:15:39:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4([...]:65293)
3:15:39:INFO: l2tpd ctrl=1 call=24105 SendZLB
3:15:42:INFO: ppp id=0 layer=lcp logtype=Opened mru=1360/1360
auth=MS-CHAP-V2 magic=[...]/[...]
3:15:43:INFO: ppp id=0 layer=chap proto=mschap_v2 logtype=Success
username="radish" realm=LOCAL
3:15:44:INFO: ppp id=0 layer=ipcp IP Address peer=0.0.0.0 our=172.16.2.6.
3:15:44:INFO: ppp id=0 layer=base unhandled protocol ipv6cp, 32855(8057)
3:15:45:INFO: ppp id=0 layer=ccp CCP is stopped
3:15:45:INFO: ppp id=0 layer=ipcp logtype=Opened ip=172.16.2.6
assignType=dynamic
3:15:45:NOTICE: ppp id=0 layer=base logtype=TUNNELSTART user="turnip"
duration=6sec layer2=L2TP_ipv4 layer2from=[...]:65293 auth=MS-CHAP-V2
ip=172.16.2.6 iface=pppx0
3:15:45:NOTICE: ppp id=0 layer=base Using pipex=yes
--
Drew
npppd, framed_ip_address
Hello again, On 28 September 2012 03:17, YASUOKA Masahiko > wrote: > Hi, > > On Thu, 27 Sep 2012 13:41:52 -0400 > Andrew Ngo > wrote: >> Hm. I can't seem to get npppd to map users to static addresses in the >> npppd-users file, after trying various permutations of "pool-address >> ##-## " and such. The client is an iPhone running iOS 6.0, >> and is definitely able to set up a working vpn over l2tp/ipsec with >> the npppd server (many thx, btw), but the client is then always >> assigned a random address from the pool (and never the static one, >> incidentally... but that could just be chance). >> >> Did I screw something up in the configuration or has this particular >> feature not been implemented yet? Has anyone else had troubles with >> this? > > The feature was broken by the my configuration syntax change work. > Thank you for your report. Attached diff will fix the problem. > I tested the diff and it works over here; thanks. >> (By the way, the daemon goes absolutely bananas if you use a >> "framed-ip-address" on a different subnet than those in the pool. >> Bananas! I don't recommend this error. ^^) > > npppd will assign ip address dynamically on that case. > Can you explain your recommendation? I only managed to replicate the error using "pool-address [ip4] [ip4] for static" in the pre-patched npppd, so it's probably a result of the same bug. (When I said "bananas", I was just talking about the deluge of "unhandled option" messages. :) Anyway, I've attached the output -- it looks like a consequence of npppd thinking it has no addresses to allocate. 10:15:17:NOTICE: Starting npppd pid=12849 version=5.0.0 10:15:17:NOTICE: Load configuration from='/etc/npppd/npppd.conf' successfully. 10:15:17:INFO: pppx0 Started pppx 10:15:17:INFO: Listening /var/run/npppd_ctl (npppd_ctl) 10:15:17:INFO: ipcp=IPCP pool pool=[ 172.16.2.2/31,172.16.2.4/31,172.16.2.6/32] 10:15:17:INFO: Loading pool config successfully. 10:15:17:INFO: l2tpd Listening 0.0.0.0:1701/udp (L2TP LNS) [L2TP_ipv4] 10:15:17:INFO: l2tpd Listening [::]:1701/udp (L2TP LNS) [L2TP_ipv6] 10:15:27:NOTICE: l2tpd ctrl=1 logtype=Started RecvSCCRQ from=[...]:49950/udp tunnel_id=1/38 protocol=1.0 winsize=4 hostname=Rhinoceros vendor=(no vendorname) firm= 10:15:27:INFO: l2tpd ctrl=1 SendSCCRP 10:15:27:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ from=[...]:49950/udp tunnel_id=2/38 protocol=1.0 winsize=4 hostname=Rhinoceros vendor=(no vendorname) firm= 10:15:27:INFO: l2tpd ctrl=2 SendSCCRP 10:15:28:INFO: l2tpd ctrl=1 RecvSCCN 10:15:28:INFO: l2tpd ctrl=1 SendZLB 10:15:28:INFO: l2tpd ctrl=1 call=4645 RecvICRQ session_id=849 10:15:28:INFO: l2tpd ctrl=1 call=4645 SendICRP session_id=4645 10:15:28:INFO: l2tpd ctrl=1 RecvZLB 10:15:29:INFO: l2tpd ctrl=1 call=4645 RecvICCN session_id=849 calling_number= tx_conn_speed=100 framing=async 10:15:29:NOTICE: l2tpd ctrl=1 call=4645 logtype=PPPBind ppp=0 10:15:29:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4([...]:49950) 10:15:29:INFO: l2tpd ctrl=1 call=4645 SendZLB 10:15:29:DEBUG: l2tpd ctrl=1 SendZLB 10:15:30:INFO: l2tpd ctrl=1 RecvZLB 10:15:33:INFO: ppp id=0 layer=lcp logtype=Opened mru=1360/1360 auth=MS-CHAP-V2 magic=[...]/[...] 10:15:34:INFO: ppp id=0 layer=chap proto=mschap_v2 logtype=Success username="turnip" realm=LOCAL 10:15:34:NOTICE: ppp id=0 layer=base No free address in the pool. 10:15:34:NOTICE: ppp id=0 layer=base No free address in the pool. 10:15:35:INFO: ppp id=0 layer=base unhandled protocol ipv6cp, 32855(8057) 10:15:35:INFO: ppp id=0 layer=ccp CCP is stopped 10:15:35:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:36:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:36:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:37:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:38:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:38:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:39:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:39:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:40:NOTICE: l2tpd ctrl=2 timeout waiting ack for ctrl packets. 10:15:40:NOTICE: l2tpd ctrl=2 logtype=Finished 10:15:40:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:40:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:41:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:41:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:42:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:42:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:43:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 10:15:43:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10 ^C 10:15:44:INFO: l2tpd ctrl=1 call=4645 SendCDN result=ADMINISTRATIVE_REASON/3 10:15:44:NOTICE: l2tpd ctrl=1 call=4645 logtype=PPPUnbind 10:15:44:NOTICE: ppp id=0 layer=bas
