GM45 gpu hung error
Hello, I'm running the latest snapshot on a thinkpad T400 witha an intel GM45 intel video card. After some use I get errors in dmesg and sometimes it glxinfo reports switching to sw rendering, it can always be triggered simply by trying to use youtube in chromium. Even when glxinfo reports still using the hw renderer the performance is severely degraded. Here's my dmesg: OpenBSD 5.4-current (GENERIC) #124: Sun Nov 10 22:49:21 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 4166717440 (3973MB) avail mem = 4047708160 (3860MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (74 entries) bios0: vendor LENOVO version "7UET66WW (2.16 )" date 04/22/2009 bios0: LENOVO 2768HJ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.34 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 265MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS: resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "92P1137" serial25 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2527 MHz: speeds: 2534, 2533, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1440x900 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel GM45 PT IDER" rev 0x07: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel GM45 KT" rev 0x07: ports: 1 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 15 bytes em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:22:68:12:2d:ef uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23 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 82801I HD Audio" rev 0x03: msi azalia0: codecs: Conexant CX20561, Conexant/0x2c06, using Conexant CX20561 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, MoW, address 00:21:6a:63:9e:ca ppb2 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi pci3 at ppb2 bus 5 ppb3 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x03: msi pci4 at ppb3 bus 13 uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 16 uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 17 uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 18 ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x03:
Re: GM45 gpu hung error
On Wed, Nov 13, 2013 at 12:12:47PM +, Alexey E. Suslikov wrote: > Tomas Bodzar gmail.com> writes: > > > Right, my fault. Missed complete path in output. Those are for Haswell > > Looking at mentioned commits, at least cursor update diffs aren't > strictly Haswell related. So Mesa update. > I've tried with the latst snapshot but there are still issues: dmesg: OpenBSD 5.4-current (GENERIC) #126: Tue Nov 12 16:30:10 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 4166717440 (3973MB) avail mem = 4047704064 (3860MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (74 entries) bios0: vendor LENOVO version "7UET66WW (2.16 )" date 04/22/2009 bios0: LENOVO 2768HJ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 798.15 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 266MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS: resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "92P1137" serial25 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 798 MHz: speeds: 2534, 2533, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1440x900 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel GM45 PT IDER" rev 0x07: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel GM45 KT" rev 0x07: ports: 1 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 15 bytes em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:22:68:12:2d:ef uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 bash-4.2$ dmesg OpenBSD 5.4-current (GENERIC) #126: Tue Nov 12 16:30:10 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 4166717440 (3973MB) avail mem = 4047704064 (3860MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (74 entries) bios0: vendor LENOVO version "7UET66WW (2.16 )" date 04/22/2009 bios0: LENOVO 2768HJ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 798.15 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 ca
Re: GM45 gpu hung error
On Wed, Nov 13, 2013 at 03:06:08PM +0200, Alexey Suslikov wrote: > On Wed, Nov 13, 2013 at 2:30 PM, Claudio wrote: > > On Wed, Nov 13, 2013 at 12:12:47PM +, Alexey E. Suslikov wrote: > >> Tomas Bodzar gmail.com> writes: > >> > >> > Right, my fault. Missed complete path in output. Those are for Haswell > >> > >> Looking at mentioned commits, at least cursor update diffs aren't > >> strictly Haswell related. So Mesa update. > >> > > I've tried with the latst snapshot but there are still issues: > > > > dmesg: > > > > OpenBSD 5.4-current (GENERIC) #126: Tue Nov 12 16:30:10 MST 2013 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > real mem = 4166717440 (3973MB) > > avail mem = 4047704064 (3860MB) > > > > > cpu0: Enhanced SpeedStep 798 MHz: speeds: 2534, 2533, 1600, 800 MHz > > (maybe) not related to GPU hangs, but having CPU run at 798 MHz is strange. > > have you tried to put > > hw.setperf=100 > > to /etc/sysctl.conf > > ? I've tried but there was no change, the reason it was running that low I think was apmd.
Re: GM45 gpu hung error
On Wed, Nov 13, 2013 at 03:20:58PM +0200, Alexey Suslikov wrote: > On Wed, Nov 13, 2013 at 3:18 PM, Claudio wrote: > > On Wed, Nov 13, 2013 at 03:06:08PM +0200, Alexey Suslikov wrote: > >> On Wed, Nov 13, 2013 at 2:30 PM, Claudio wrote: > >> > On Wed, Nov 13, 2013 at 12:12:47PM +, Alexey E. Suslikov wrote: > >> >> Tomas Bodzar gmail.com> writes: > >> >> > >> >> > Right, my fault. Missed complete path in output. Those are for Haswell > >> >> > >> >> Looking at mentioned commits, at least cursor update diffs aren't > >> >> strictly Haswell related. So Mesa update. > >> >> > >> > I've tried with the latst snapshot but there are still issues: > >> > > >> > dmesg: > >> > > >> > OpenBSD 5.4-current (GENERIC) #126: Tue Nov 12 16:30:10 MST 2013 > >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > >> > real mem = 4166717440 (3973MB) > >> > avail mem = 4047704064 (3860MB) > >> > >> > >> > >> > cpu0: Enhanced SpeedStep 798 MHz: speeds: 2534, 2533, 1600, 800 MHz > >> > >> (maybe) not related to GPU hangs, but having CPU run at 798 MHz is strange. > >> > >> have you tried to put > >> > >> hw.setperf=100 > >> > >> to /etc/sysctl.conf > >> > >> ? > > > > I've tried but there was no change, the reason it was running that low I > > think was apmd. > > I think you should disable apmd, cold boot and retest. Still no luck and the cpu still seems to run at a super low frequency? dmesg: OpenBSD 5.4-current (GENERIC) #126: Tue Nov 12 16:30:10 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 4166717440 (3973MB) avail mem = 4047704064 (3860MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (74 entries) bios0: vendor LENOVO version "7UET66WW (2.16 )" date 04/22/2009 bios0: LENOVO 2768HJ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 798.14 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 266MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS: resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "92P1137" serial25 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 798 MHz: speeds: 2534, 2533, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1440x900 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel GM45 PT IDER" rev 0x07: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev
Firefox 100% cpu usage html5 videos
Hello, On my laptop firefox cpu usage spikes to 100% when trying to play an html5 video on youtube, the situation is slightly better on other sites but still the load never goes under 80%, this is on -current on a GM45 intel chipset if it matters. Generally speaking it has the worst performance when playing html5 videos, I've tried chromium , xombrero and midori and they all work fine while firefox playback is choppy when it's at his best else it just saturates the cpu and freezes the browser. No output or errors are disaplyed when unsing firefox started from a terminal. Claudio
Re: Firefox 100% cpu usage html5 videos
On Thu, Nov 14, 2013 at 10:20:01PM +0100, ropers wrote: > You need to provide a lot more information to get a meaningful response: > > What exact Firefox version/build/package are you running? On what > hardware? dmesg? On what precise version of OpenBSD? -current? If not, > is it reproducible in -current? > > Good luck. > > On 14 November 2013 22:07, Claudio wrote: > > Hello, > > > > On my laptop firefox cpu usage spikes to 100% when trying to play an html5 > > video on youtube, the situation is slightly better on other sites but still > > the load never goes under 80%, this is on -current on a GM45 intel chipset > > if it matters. > > > > Generally speaking it has the worst performance when playing html5 videos, > > I've tried chromium , xombrero and midori and they all work fine while > > firefox playback is choppy when it's at his best else it just saturates the > > cpu and freezes the browser. > > > > No output or errors are disaplyed when unsing firefox started from a > > terminal. > > > > Claudio > > Firefox version is 25.0 and I'm running the latest -current snapshot, here's my dmesg: OpenBSD 5.4-current (GENERIC.MP) #147: Tue Nov 12 16:37:15 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4166717440 (3973MB) avail mem = 4047663104 (3860MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 2768HJ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.40 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS: resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "92P1137" serial25 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2527 MHz: speeds: 2534, 2533, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1440x900 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured puc0 at pci0 dev 3 function 3 "Intel GM45 KT" rev 0x07: ports: 1 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 15 bytes em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:22:68:12:2d:ef uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pc
kernel panic radeon HD 8570D
Hello, When startig X on the latest snapshot the kernel paniced, I was stupid enough not to run the suggested command at the ddb prompt because I forgot. Here's the error it reported: uvm_fault(0xfe823cb0c468, 0x278, 0, 1) -> e kernel: page fault trap, code=0 Stopped at radeon_vm_bo_add+0xaa: movq 0x278(%r15), %rax I can confirm that the card used to work fine with a snapshot from around halloween. On a related note I know that fan control has been enabled on linux 3.13 for this and other radeon cards, would it be possible to eventually port it ? Here's the dmesg: OpenBSD 5.4-current (GENERIC.MP) #150: Thu Nov 14 00:30:57 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7992832000 (7622MB) avail mem = 7771926528 (7411MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9550 (52 entries) bios0: vendor American Megatrends Inc. version "F3" date 09/28/2012 bios0: Gigabyte Technology Co., Ltd. F2A55M-DS2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG MSDM HPET MSDM IFEU SSDT SSDT IVRS CRAT BGRT acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) PE20(S4) PE21(S4) PE22(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A8-6600K APU with Radeon(tm) HD Graphics , 3893.42 MHz 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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A8-6600K APU with Radeon(tm) HD Graphics , 1930.84 MHz 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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A8-6600K APU with Radeon(tm) HD Graphics , 1930.80 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A8-6600K APU with Radeon(tm) HD Graphics , 1930.84 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0PC) acpiprt2 at acpi0: bus -1 (PE20) acpiprt3 at acpi0: bus -1 (PE21) acpiprt4 at acpi0: bus -1 (PE22) acpiprt5 at acpi0: bus -1 (PE23) acpiprt6 at acpi0: bus 1 (BR12) acpiprt7 at acpi0: bus -1 (BR13) acpiprt8 at acpi0: bus 2 (BR14) acpiprt9 at acpi0: bus 3 (BR15) acpiprt10 at acpi0: bus -1 (BR16) acpiprt11 at acpi0: bus -1 (BR17) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpicpu2 at acpi0: C2, PSS acpicpu3 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB cpu0: 3893 MHz: speeds: 3900 36
speex can't find /usr/lib/libsndio.so.5.0
Hello, On the latest snapshot when trying to install speex (it's brought in by firefox) it fails since it can't find /usr/lib/libsndio.so.5.0 , libsndio.so.6.0 is present instead. It needs rebuilding.
Gnome 3.10 on current
Hello I've decided to give gnome 3.10 a shot in the latest current snapshot. Here are some of the issues big and small I've encountered: 1- gdm fails to start, or better it starts but the frowny face comes up saying that there's been an error and to logout. After that it either goes to a black s creen with a pointer or cycles some more times before going to a blacks creen. 2- when running gnome session ps | aux reports apmd not running anymore even if started at boot, trying to start it with apmd -d shows that /dev/apmctl is alre ady in use (I assume it's been used by the instance started at boot), sysctl hw.setperf is always =100 while gnome is running. After gnome-session closed I cou ld then see apmd running but I had to restart it since setperf was stuck to 100. 3-gnome-session crashes randomly 4-I could not get video thumbnails to work (but really this didn't matter much given the other issues). Here are my dmesg and part of /var/log/messages. OpenBSD 5.4-current (GENERIC.MP) #155: Wed Nov 20 12:24:39 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7993376768 (7623MB) avail mem = 7772450816 (7412MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9550 (52 entries) bios0: vendor American Megatrends Inc. version "F3" date 09/28/2012 bios0: Gigabyte Technology Co., Ltd. F2A55M-DS2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG MSDM HPET MSDM IFEU SSDT SSDT IVRS CRAT BGRT acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) PE20(S4) PE21(S4) PE22(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A8-6600K APU with Radeon(tm) HD Graphics , 3893.46 MHz 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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A8-6600K APU with Radeon(tm) HD Graphics , 1930.85 MHz 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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A8-6600K APU with Radeon(tm) HD Graphics , 1930.80 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A8-6600K APU with Radeon(tm) HD Graphics , 1930.83 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0PC) acpiprt2 at acpi0: bus -1 (PE20) acpiprt3 at acpi0: bus -1 (PE21) acpiprt4 at acpi0: bus -1 (PE22) acpip
Re: Problme parsing the BGP UPDATE file
On Tue, May 16, 2017 at 11:53:22AM +, Stuart Henderson wrote:
> On 2017-05-16, Nagarjun G wrote:
> > Hi Team,
> >
> > We are running an OpenBGPD router inside an AS we own. We are collecting
> > BGP RIB files every 2 hours and UPDATE files every 5 mins. I tried parsing
> > these files using some well known parses like bgpstream and mabo. I am able
> > to parse RIB files successfully but I am unable to parse UPDATE files. I
> > see that files are getting truncated. Developers of mabo are saying that
> > files may be corrupted, mabo will not parse MRT headers are corrupted.
> >
> > *Commands used to dump files:*
> >
> > dump table-v2 "/tmp/rib-dump-v2-%Y%m%d%H%M" 7200
> > dump updates in "/tmp/updates-%Y%m%d%H%M" 300
> >
> > *Error while parsing UPDATE file using mabo:*
> >
> > $ ./mabo dump updates-in-1223.gz
> > {"type":"update","timestamp":1493880788.0,"peer_as":4755.0,"peer_ip":"121.244.206.224","as_path":"4755
> > 6453 7575 38022 55702","announce":["49.0.31.0/24"],"withdraw":[]}
> > [..]
> > MRT parsing error: MRT dump is truncated: 1493880791 16/4 138
> >
> > It starts parsing the file, then throws error.
> >
> > Could someone help me to fix the problem.
> > Thanks in Advance
> >
> > Regards,
> > Nagarjun
> >
>
> I've just tried mabo on a mrt updates dump on an OpenBSD -current
> system and it works here.
>
> Is bgpdump able to read the file? (just "pkg_add libbgpdump" and
> "bgpdump $file"). If so, if you lookup the last entry that mabo was
> able to parse, and look at the next entry in bgpdump (presumably the
> one triggering the failure), does that give any clues about what
> the problem might be?
>
I guess this is the same bug reported in Dec last year and fixed in rev
1.356 of session.c. So this is fixed in 6.1 and -current but not in 6.0.
--
:wq Claudio
Re: OpenBSD 6.1 current relayd TLS error "cannot load certificates"
On Fri, Jun 02, 2017 at 08:38:50PM -0700, Dillon Jay Pena wrote:
> I'm not understanding why I'm getting a relayd error. Thanks in advance.
>
> According to
> http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/relayd.conf.5#listen_on,
> I just need address.crt and private/address.key to use tls with
> relayd, which you can see I do below.
> So why am I getting the relayd error "cannot load certificates for relay www"?
>
> I have included how I got the key and crt files from acme-client/lets
> encrypt in case it's relevant.
>
>
> $ uname -prsv
> OpenBSD 6.1 GENERIC#88 amd64
>
> $ cat /etc/acme-client.conf
> #
> # $OpenBSD: acme-client.conf,v 1.4 2017/03/22 11:14:14 benno Exp $
> #
> authority letsencrypt {
> agreement url
> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf";
> api url "https://acme-v01.api.letsencrypt.org/directory";
> account key "/etc/acme/letsencrypt-privkey.pem"
> }
>
> authority letsencrypt-staging {
> agreement url
> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf";
> api url "https://acme-staging.api.letsencrypt.org/directory";
> account key "/etc/acme/letsencrypt-staging-privkey.pem"
> }
>
> domain thelang.space {
> alternative names { mail.thelang.space www.thelang.space }
> domain key "/etc/ssl/private/thelang.space.key"
> domain certificate "/etc/ssl/thelang.space.crt"
> domain full chain certificate "/etc/ssl/thelang.space.fullchain.pem"
> sign with letsencrypt
> challengedir "/var/www/htdocs/.well-known/acme-challenge"
> }
>
> $ doas acme-client -vAD thelang.space
> acme-client: /etc/ssl/private/thelang.space.key: domain key exists
> (not creating)
> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists
> (not creating)
> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
> acme-client: acme-v01.api.letsencrypt.org: DNS: 104.68.109.156
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: thelang.space
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: mail.thelang.space
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: www.thelang.space
> acme-client:
> /var/www/htdocs/.well-known/acme-challenge/hALHIbtLAX4k274bN4AFBV0W-T08pKTqD6lBw0-CplM:
> created
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/mempVpv498Gw4d7Wr24qcinn5ZUfX_6IO2kQOeskf40/1271082083:
> challenge
> acme-client:
> /var/www/htdocs/.well-known/acme-challenge/SMwY0p1ma9ZDQrlyM6h9BbZkEnMCKx2lW69__zcmCgI:
> created
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/bwNrTgnJmUIH-XqInRMDmRNgRMnXQKBUZngPi3wuHt4/1271082087:
> challenge
> acme-client:
> /var/www/htdocs/.well-known/acme-challenge/wu3Zhef8NA8b9wmxHeMjXBZCg3EKGHgnM30Tx_qn1Ws:
> created
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/fHeHrAzF9RAXO-eJMZxfWElhkf4duUw934pUWy2gWyM/1271082092:
> challenge
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/mempVpv498Gw4d7Wr24qcinn5ZUfX_6IO2kQOeskf40/1271082083:
> status
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/bwNrTgnJmUIH-XqInRMDmRNgRMnXQKBUZngPi3wuHt4/1271082087:
> status
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/fHeHrAzF9RAXO-eJMZxfWElhkf4duUw934pUWy2gWyM/1271082092:
> status
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
> acme-client: http://cert.int-x3.letsencrypt.org/: full chain
> acme-client: cert.int-x3.letsencrypt.org: DNS: 165.254.42.42
> acme-client: /etc/ssl/thelang.space.crt: created
> acme-client: /etc/ssl/thelang.space.fullchain.pem: created
>
> $ cat /etc/relayd.conf
> table { 127.0.0.1 }
>
> relay www {
> listen on thelang.space port 443 tls
>
> forward to check tcp port 8080
> }
>
> $ doas relayd -d
> startup
> /etc/relayd.conf:7: cannot load certificates for relay www
> no actions, nothing to do
> hce exiting, pid 2324
> pfe exiting, pid 21204
> ca exiting, pid 18722
> ca exiting, pid 45718
> ca exiting, pid 79639
> relay exiting, pid 31292
> relay exiting, pid 32940
> relay exiting, pid 75225
>
> $ ls /etc/ssl/thelang.space.crt
> /etc/ssl/thelang.space.crt
> $ doas ls /etc/ssl/private/thelang.space.key
> /etc/ssl/private/thelang.space.key
>
You need to use IP addresses not domain names for the cert name.
e.g. /etc/ssl/127.0.0.1.crt ect
--
:wq Claudio
Re: What's changing the default route?
On Sat, Jul 01, 2017 at 04:48:05PM +0200, tonypon...@mail.com wrote: > I use an ssh tunnel for a VPN on OpenBSD 6.1. To initiate the VPN > connection, I type the following on the local machine > > # ssh -f -w 0:1 R true > # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 > # route add R G > # route change default 10.1.1.2 > > where R is the IP address of the remote server, and where G is the IP > address of the local gateway. > > Usually, this works well. But I occasionally have a problem where the > default address in the routing table will spontaneously change from > 10.1.1.2 to G. What could be causing the routing table to spontaneously > change in this manner without my intervention? > Most probably dhclient(8). -- :wq Claudio
Re: What's changing the default route?
On Sun, Jul 02, 2017 at 08:27:36AM +, Stuart Henderson wrote: > On 2017-07-01, Claudio Jeker wrote: > > On Sat, Jul 01, 2017 at 04:48:05PM +0200, tonypon...@mail.com wrote: > >> I use an ssh tunnel for a VPN on OpenBSD 6.1. To initiate the VPN > >> connection, I type the following on the local machine > >> > >> # ssh -f -w 0:1 R true > >> # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 > >> # route add R G > >> # route change default 10.1.1.2 > >> > >> where R is the IP address of the remote server, and where G is the IP > >> address of the local gateway. > >> > >> Usually, this works well. But I occasionally have a problem where the > >> default address in the routing table will spontaneously change from > >> 10.1.1.2 to G. What could be causing the routing table to spontaneously > >> change in this manner without my intervention? > >> > > > > Most probably dhclient(8). > > A hackish workaround to this would be to add routes for 0.0.0.0/1 > and 128.0.0.0/1 instead of changing the default route. > Or even better use the -priority and add it with a lower prio (e.g. 2). -- :wq Claudio
Re: Gbit performance parameters
On Wed, Jul 12, 2017 at 06:07:28PM +0200, Per-Olov Sjöholm wrote: > Hi > > I have seen net.inet.ip.ifq.drops on my firewall after upgrading the internet > connection and therefor try to tweak it a little. The FW has 4 (but only two > used) physical Intel Gig interfaces. The internal interface has a bunch of > VLANs on it. IPv6 is enabled. > > > I have a linux 8 core Intel atom (C2758 @ 2.40GHz) sitting behind my NAT > OpenBSD 6.0 firewall (CPU N2930 @ 1.83GHz). After increasing > net.inet.ip.ifq.maxlen from default 256 in two steps up to 768 on the > firewall the drops have been less, but still occurs. The performance of the > CentOS 7.3 sitting behind the firewall also have gained approx 150Mbit more > performance in network test against the internet by the > net.inet.ip.ifq.maxlen increase on the OpenBSD firewall. I have now the linux > server sitting behind the fw that gives me the following performance (I have > an 1/1 Gbit fiber in to the house)??? > > [root@server2 tmp]# bbk_cli --live > Start: 2017-07-12 17:35:20 > ISP: Bahnhof Internet AB > Support ID: sth66db38ee9 > Latency: 4.255 ms > Download:803.603 Mbit/s > Upload: 949.265 Mbit/s > Subscription: 500-1000 Mbit/s fiber > [root@server2 tmp]# > > > And "sysctl -a|grep net.inet.ip.ifq??? now shows... > net.inet.ip.ifq.len=0 > net.inet.ip.ifq.maxlen=768 > net.inet.ip.ifq.drops=1292657 > > > The performance was pretty good even without tweaks :), but is now, as shown > above, 100-150 Mbit better???. But I do have a few questions to you pro:s??? > > # Question > Can I have bad drawbacks by the net.inet.ip.ifq.maxlen increase I have done, > and in what way do I notice it if problem occurs? Or can/should the > net.inet.ip.ifq.maxlen be increased more as I still have drops? Or should I > decrease the value to 512 or to default 256 again do avoid any type of > problem? > Could the net.inet.ip.ifq.drops ideally be zero? Or is that just an ideal > wish that never is true? > Any other parameter to look at at these speeds if I want a well behaved fw > without packet drops and with low latency capable of filling my 1/1 Gbit pipe? > The size of net.inet.ip.ifq.maxlen should be sized by lookin at your drops pattern. In general if you have bursty traffic you want a bit more. The goal is that the amount of drops are minimal. On our busy firewalls pushing 500Mbps I set maxlen to 4096 and even 8192. Drawback is of a big queue is an increased latency. At the moment having long queues helps when multiple CPUs compete for the big lock since it reduces the packet loss and so TCP suffers less. The latency increase is something we decided to accept since we're not that latency sensitive. The long term plan is actually to get rid of this queue and knob but we're not right there yet. -- :wq Claudio
Re: Choice of sis(4) versus vr(4) ?
On Mon, Jul 17, 2017 at 09:07:04PM +0300, Lars Noodén wrote: > I'm looking to refurbish an old device and will probably add a network > card to it. Are there any reasons based on the current drivers or the > hardware itself to choose sis(4) or vr(4) over one or the other on > i386 -curren? > They are both similarly bad. I think it would not matter which one you use. -- :wq Claudio
Re: relayd l7 loadbalancing
On Wed, Aug 16, 2017 at 10:27:58AM +0200, Maxim Bourmistrov wrote:
>
> Once connection is established, state is created in PF. Subsequent requests
> will be ???pipelined???.
> It is possible to influence this behavior by manipulating tcp.established in
> pf.conf,
> but I don???t think this is what you want.
>
This is not correct. The problem is keep-alive and the fact the once a
backend is selected by relayd it sticks to it until the session is closed.
This is a bug and something benno@ and I have on our radar to fix.
The workaround for now is to disable keep-alive this can be done by
adding:
match header set "Connection" value "close"
to your config. The solution is not ideal and will make page load times
slower.
> > 16 aug. 2017 kl. 10:05 skrev Mischa Peters :
> >
> > Hi All,
> >
> > I have somewhat the following config for relayd running on 6.1.
> > And I am trying to forward certain request paths to different hosts.
> >
> > table { xx.xx.xx.131 }
> > table { xx.xx.xx.31 }
> > http protocol httpsfilter {
> > match request header remove "Proxy"
> > match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
> > match request header append "X-Forwarded-By" value
> > "$SERVER_ADDR:$SERVER_PORT"
> >
> > match response header set "Server" value "Sever"
> > match response header set "X-Powered-By" value "Power"
> > match response header set "X-Frame-Options" value "SAMEORIGIN"
> > match response header set "X-Xss-Protection" value "1; mode=block"
> > match response header set "X-Content-Type-Options" value "nosniff"
> >
> > match request quick path "/crm/" forward to
> >
> > tcp { no splice }
> > }
> > relay host_tls {
> > listen on $ext_addr_v4 port 443 tls
> > listen on $ext_addr_v6 port 443 tls
> > protocol httpsfilter
> > forward to port 80 check http "/" host example.com code 200
> > forward to port 80
> > }
> >
> > I have tried both "match request quick path" and "match request quick url"
> > but what I noticed is that as soon as you have visited one of the URLs that
> > needs forwarding to a different host you end up at the for all
> > subsequent requests.
> > With "match request quick url" this is to be expected as it checks
> > everything up to /.
> >
> > For example:
> >
> > http://example.com/ -> wwwhost
> > http://example.com/crm/ -> otherhost
> > http://exmaple.com/folder/ -> otherhost
> >
> > Is this expected behaviour for "match request quick path" as well?
> > Is there any way to do this type of load balancing?
> >
> > Thanx!!
> >
> > Mischa
> >
>
--
:wq Claudio
Re: bgpd.conf invalidated on 6.2
On Mon, Oct 16, 2017 at 12:13:14PM +0200, Marko Cupa?? wrote: > Hi, > > I've just upgraded one of my firewalls to 6.2, but bgpd won't start > with bgpd.conf which worked for 5 releases or so. > > Here's error message: > /etc/bgpd.conf:11: duplicate prefix in network statement > config file /etc/bgpd.conf has errors, not reloading > > The problem appears to be with the two following lines in bgpd.conf > (redacted): > network NE.TW.OR.K/24 set nexthop IP.ADD.RE.SS1 > network NE.TW.OR.K/24 set nexthop IP.ADD.RE.SS2 > > Any idea how to make this work on 6.2? > Remove one of the two lines. -- :wq Claudio
Re: Dell PowerEdge R430/R440 support
On Wed, Apr 25, 2018 at 12:22:43PM +0200, Jan Vlach wrote: > Hello misc, > > has anybody Dell PowerEdge R430 or E440 running with OpenBSD? Is the > hardware supported? > > I can't really get the exact chipsets from vendor to cross check with > drivers in OpenBSD and I can't find dmesg or mention anywhere. (Checked > dmesgd.nycbug.org, archives and google generally) > > I would like to have OpenBSD softraid RAID1 with 3 SSD drives, but I'm > not sure what controllers are supported. > > > Vendor states these storage controllers for R440: > PERC H330, H730p, H740p, HBA330, Software RAID (SWRAID) S140 > > R430: > HBA330/H330/H730/H730P > > The chipset is should be C620 for R440 and C610 for R430. > > I have no idea what the chip for ethernet is. > > Any hints, please, what should/would work? I intend to share dmesg to dmesg@ > and nycbug's dmesgd. > The R440 need IIRC at least 6.3 to support the H740p RAID controller. Apart from that they work. -- :wq Claudio
Re: relayd for TLS termination
On Sat, Apr 28, 2018 at 09:39:56AM -0400, David Higgs wrote:
> I run several services on the same host and would like to consolidate
> certificate management with the help of relayd.
>
> Before:
> - acme-client generates certificates via LE
> - kibana running https on port 5601
> - unifi running https on port 8443
> - httpd running http+https on port 80
> - daily.local script to install new certs and restart all services
> when LE updates
>
> After:
> - register new LE domains for kibana and unifi
> - switch kibana and unifi back to running http on localhost
> - relayd transparently terminates all https and demuxes to http
> service based on Host header
> - daily.local has much fewer services to manage
>
> First off, is this even possible with relayd?
More or less. relayd does not do SNI so you need to have per hostname or
actually per certificate a different IP. Doing complicated rule based
relays is not working all that well. So try to keep it simple one port one
service.
> Second, I am having difficulty grokking how to structure my
> relayd.conf. Will I need one relay and protocol block for EACH
> service? Do I need a pf.conf anchor if I am only using relay
> behavior?
Depends. You may be able to just use one 'http protocol' block that is
referenced by multiple relays. It depends on the config.
I think the pf.conf anchor is required even if you are not using
redirects (I assume that relayd would even refuse to start without the
anchor).
> Lastly and perhaps indicative of my difficulties, I am having
> difficulty building (or debugging) even a single host as
> proof-of-concept using the config below. The relayd daemon starts
> just fine, loading symlinked .crt and .key files. (Should
> I be using the fullchain.pem instead?)
Yes, you should use a full chain certificate else there is no trust anchor
for the clients.
> Behavior seems to vary based on client / environment - I have seen
> both wget and curl complain about certificate verification (relaying
> to :80), while curl on a different box reported an empty reply from
> the server after timeout (relaying to 127.0.0.1:80).
>
> Hints or clue sticks would be most appreciated.
>
> --david
>
> ### relayd.conf
>
> http protocol wwwproto {
> tcp { nodelay, sack, socket buffer 65536, backlog 128 }
Honestly most of this tuning is not helpful. sack and backlog may be OK
but esp. changing the socket buffer will disable the automatic socket
buffer scaling and leave you with a much smaller buffer then the default.
> # seen in example, not sure of purpose
> match request header set "Connection" value "close"
This tells the server to close the connection after each request and so no
keep-alive is happening. In some cases this is needed. Especially when
mutliple backends are used in match or pass rules.
> # notify client if relay failed
> return error
> # reject unknown hosts by default
> block
> # traffic for httpd, forward
> pass request header "Host" value "example.com"
> pass request header "Host" value "www.example.com"
I'm not sure why you do this. In general I leave the Host parsing to the
backend servers. Also I think Host may include the port number if it is
not a default port.
> }
>
> relay wwwrelay {
> listen on em1 port 443 tls
> protocol wwwproto
> transparent forward to lo port http
On hig volume servers I would not use transparent forwading but instead
set the X-Forwarded-For header. Also transparent needs help from pf.
> }
>
--
:wq Claudio
Re: attach chroot-jail to switchd(8) ?
On Thu, May 24, 2018 at 09:22:32AM -0400, trondd wrote: > On Wed, May 23, 2018 4:35 am, Thomas Huber wrote: > > Hi all, > > > > I´m just tinkering a little bit and try to mimic some "containerization" > > on > > OpenBSD with chroot. Is it somehow possible to attach a chrooted > > envirionment to swtichd(8) ? > > > > Thanks > > Thomas > > > > OpenBSD's chroot is not like a Linux contianer or FreeBSD jail. There is > no network isolation. Inside the chroot, you get all the same interfaces, > IP's, routes, ports as on the "host" or in another chroot. So doing > anything with the network in the chroot is exactly as same as doing it > normally. > > If you want to isolate, you probably need vether or tap or the like to > make virtual interfaces and manually tie them to whatever you have running > in the chroots and muanully set up proxies or whatever you need to make > services accessible. > This is only partially true. If you use alternate routing tables or rdomain, route -T exec will get you network isolation. Processes can not change the rtable unless they run as superuser. It is not perfect but neither is the linux or freebsd solution when it comes to networking. -- :wq Claudio
Re: edgerouter 6 / rdomain at boot
UI > 0x0001c1, model 0x0027 > /dev/ksyms: Symbol table not valid. > umass0 at uhub0 port 2 configuration 1 interface 0 "Generic USB3.0 Card > Reader" rev 3.00/15.32 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: SCSI4 0/direct > removable serial.05e307491532 > sd0: 61056MB, 512 bytes/sector, 125042688 sectors > sdmmc1: can't enable card > scsibus1 at sdmmc0: 2 targets, initiator 0 > sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct > removable > sd1: 3776MB, 512 bytes/sector, 7733248 sectors > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > boot device: sd0 > root on sd0a (1e8c6ddb499f7a0a.a) swap on sd0b dump on sd0b > WARNING: No TOD clock, believing file system. > WARNING: CHECK AND RESET THE DATE! > > Automatic boot in progress: starting file system checks. > /dev/sd0a (1e8c6ddb499f7a0a.a): file system is clean; not checking > /dev/sd0l (1e8c6ddb499f7a0a.l): file system is clean; not checking > /dev/sd0d (1e8c6ddb499f7a0a.d): file system is clean; not checking > /dev/sd0f (1e8c6ddb499f7a0a.f): file system is clean; not checking > /dev/sd0g (1e8c6ddb499f7a0a.g): file system is clean; not checking > /dev/sd0h (1e8c6ddb499f7a0a.h): file system is clean; not checking > /dev/sd0k (1e8c6ddb499f7a0a.k): file system is clean; not checking > /dev/sd0j (1e8c6ddb499f7a0a.j): file system is clean; not checking > /dev/sd0e (1e8c6ddb499f7a0a.e): file system is clean; not checking > setting tty flags > pf enabled > net.inet.ip.forwarding: 0 -> 1 > net.inet6.ip6.forwarding: 0 -> 1 > net.inet6.icmp6.nd6_debug: 0 -> 0 > net.inet.ipcomp.enable: 0 -> 1 > net.pipex.enable: 0 -> 1 > net.inet.gre.allow: 0 -> 1 > net.inet.ip.ifq.maxlen: 2048 -> 2048 > net.inet6.ip6.ifq.maxlen: 2048 -> 4096 > net.inet.gre.wccp: 0 -> 1 > net.inet.udp.recvspace: 41600 -> 262144 > net.inet.udp.sendspace: 9216 -> 262144 > starting network > ifconfig: SIOCSIFRDOMAIN: File exists > ifconfig: SIOCSIFRDOMAIN: File exists > ifconfig: SIOCSIFRDOMAIN: File exists > add net default: gateway 127.0.0.1 > add net default: gateway 127.0.0.1 > add net default: gateway 127.0.0.1 > reordering libraries: done. > starting early daemons: syslogd pflogd unbound ntpd. > starting RPC daemons:. > savecore: /bsd: kvm_read: version misread > checking quotas: done. > kvm_mkdb: can't open /dev/ksyms > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd dhcpd smtpd. > starting package daemons: siproxd dhcpd2(failed). > starting local daemons: cron. > Sun Jul 1 06:15:17 CEST 2018 > > > > > -- :wq Claudio
Re: clearing the disk cache
On Tue, Jul 03, 2018 at 09:42:46AM +0200, Maximilian Pichler wrote: > I'm doing some performance tests that include reading files from disk > and want to make sure that each test takes place under similar > conditions. > > In particular, how can one clear the disk cache? (I want to make sure > that the second test isn't faster than the first one, just because > some files they both use are still in cache.) > > Right now I'm doing: > $ cat some_file_the_size_of_RAM > /dev/null > > Does this indeed clear the cache? Is there a better way? > > Also, are there several level of file/disk caches or just one? > > As always, thanks for your advice! > This will not clear the cache. Either run the test multiple times and remove the first run or reboot the system after every run. The buffer cache is implemented as two 2-queue and therefor a simple cat bigfile will not fill the cache. You would need to read the file multiple times and even then you may not manage. -- :wq Claudio
Re: clearing the disk cache
On Tue, Jul 03, 2018 at 01:30:20PM +0200, Maximilian Pichler wrote: > On Tue, Jul 3, 2018 at 11:47 AM, Janne Johansson wrote: > > https://www.tedunangst.com/flak/post/2Q-buffer-cache-algorithm > > Thanks. If I'm reading this correctly upon access (read or write), an > action is performed depending on what queue a buffer is in: > - none: Take a buffer from the tail of the cold queue and insert it at > the front of the hot queue. > - hot: Keep it there, but move to the front. > - cold: Move it to the front of the warm queue. > - warm: Keep it there, but move to the front. > > If a buffer reaches the tail of a queue it moves on like this: > hot -> cold > cold -> (delete) > warm -> cold > > Based on this understanding, let me describe my (failed) attempt to > remove a file from cache. > > First, let's use 90%: > $ doas sysctl kern.bufcachepercent > kern.bufcachepercent=90 > > My machine has 16GB of RAM, but the end of the blog post says > something about himem, so maybe this means only 0.9*4GB=3.6GB are > used. > > Now let's create a new file t1, of size 512MB: > $ dd bs=1m count=512 if=/dev/zero of=t1 > 536870912 bytes transferred in 3.458 secs (155210354 bytes/sec) > > t1 should be in the hot queue now. It can be read at 2GB/s (way faster > than disk), so at least we can be sure it is in *some* queue: > $ dd bs=1m if=t1 of=/dev/null > 536870912 bytes transferred in 0.263 secs (2036532935 bytes/sec) > > Now let's fill the hot and cold queues with something else: > $ dd bs=1m count=16384 if=/dev/zero of=t2 > 17179869184 bytes transferred in 57.210 secs (300290968 bytes/sec) > > This should have moved t1 first from the warm to the cold queue and > then removed it from the cold queue. But strangely it can still be > read at 2GB/s: > $ dd bs=1m if=t1 of=/dev/null > 536870912 bytes transferred in 0.251 secs (2135681199 bytes/sec) > > Why is this? How come t1 is still in the cache? > Because it is more complicated. Because buffers are flipped from DMA mem high mem in some situations. IIRC if the DMA hot queue is full the tail buffers are flipped. Also just doing one dd is not enough to move buffers between queues. For that they need to be read multiple times. Also write buffers are never put in high mem or actually flipped down when written. In short the buffer cache is a complex beast and the few statistic numbers systat are not enough to correctly understand the various states buffers can be in. -- :wq Claudio
Re: cannot get re(4) to use 1000baseT
On Wed, Jul 18, 2018 at 04:27:45PM +0200, Jan Stary wrote: > This is 6.3-current on and amd64 PC (dmesg below), using > > re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E-VL > (0x2c80), msi, address 50:e5:49:36:ec:0d > > as the NIC. With a hostname.re0 that says > > inet 192.168.11.3 255.255.255.0 > > it gets configured fine, but only uses 100baseTX. > Now that I got me this 1000Mbps switch, I would like to have 1000baseT. > > Why is it that the autoselect chooses 100baseT > when both the NIC and the switch it is connected to > are capable of 1000Mbps? > > When I change the hostname.re0 to > > inet 192.168.11.3 255.255.255.0 192.168.11.255 media 1000baseT > > (and run 'doas sh /etc/netstart re0'), it becomes > > re0: flags=8843 mtu 1500 > lladdr 50:e5:49:36:ec:0d > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet 1000baseT (none) > status: no carrier > inet 192.168.11.3 netmask 0xff00 broadcast 192.168.11.255 > > and indeed, I lose all conectivity. > > Is anyone seeing the same? > Is there something obvious I am missing? Did you check the cable? Also did it work before? Or is this a new install? -- :wq Claudio > All I found on this was this old thread: > http://openbsd-archive.7691.n7.nabble.com/Forcing-re-driver-to-1000baseT-no-connection-4-4-release-td79375.html > > Jan > > > OpenBSD 6.3-current (GENERIC.MP) #38: Wed Jun 20 13:27:09 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8486780928 (8093MB) > avail mem = 8151605248 (7773MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > acpi0 at bios0: rev 0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) > PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) PCI0(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 addr 0xf400, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.63 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.08 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.08 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.08 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.08 MHz > cpu4: > FPU,VME,DE,PSE,TSC,M
Re: Intel i350 Offloading not working
On Sat, Jul 21, 2018 at 07:02:08PM +, Stuart Henderson wrote: > On 2018-07-21, Adonis Peralta wrote: > > Is there a reason why the offloading features shouldn???t work correctly > > on OpenBSD? > > If you can figure out why it doesn't work, you'll be well on the way to > fixing it. > > > i350 supports offloading just fine via the igb driver on FreeBSD. Is > > it more work on the driver thats needed? > > Different OS, different driver.. > > No idea if it's the case with i350 too, but checksum offload has been > rather underwhelming when supported on some other NICs. We had to turn of many of the HW features used by other OS becuase of HW bugs. em(4) is not an exception. Lately it has become more obvious that most of those offload features are either bad for you or the gain does not really justify the effort. The amount of bugs we hit because of such features are countless. NFS and multicast packets are just two things to mention which broke on Intel cards when enabling some of the offloading features. I lost interest in offloading since CPUs are now fast enough. -- :wq Claudio
Re: how to switch to a snapshot?
On Wed, Jul 25, 2018 at 12:57:33PM +0200, Rudolf Sykora wrote: > Hello, > > I'd perhaps like to switch to a recent snapshot. > I read > https://www.openbsd.org/faq/current.html > but do not quite understand it. > > If I download the snapshot (ie bsd.rd), boot from it, choose Upgrade > at the prompt, and upgrade any installed packages (??using pkg_add -u where > available, otherwise from updated ports??), do I still have to follow > those points described further down on the page, such as > > 2018/04/04 - PF_TRANS_ALTQ removed > > etc.? > > I'd expect I should watch for changes of syntax for configuration > files, right? > Yes. In general installing a snapshot will just work. Most of the config adjustments will happen automatically with sysmerge (but some you need to do by hand). Also it can be required to remove files or users, again this needs to be done by hand but often does not hurt (until it does and then it causes strange issues). In general if you install from snapshots most of current.html does not apply and this is why it is the prefered way to stay -current. -- :wq Claudio
Re: openBGPd crashes in 6.2 and 6.3: "a politician in the decision process"
eer be the cause? Has anybody > dealt with a similar problem? > > I can provide bgpd.conf and full logs of both incidents if necessary. > Are you using templates (aka neighbors with a netmask in the config)? The peer id seems to suggest that... If so can you add 'announce restart no' to the template and recheck? I think the issue is that a clone of a previous neighbor is created on reconnect and then the stale routes (from graceful reload) and the new routes of this clone are identical. I need to look into this a bit more (just returned from vacation). -- :wq Claudio
Re: netstat - process names
On Sun, Aug 26, 2018 at 01:19:05PM +0100, he...@ezaquarii.com wrote: > Hi, > > I'm looking for a way to see which processes are listening > on incoming tcp/udp connections. > > So, here is my output of netstat -f inet -p udp -l > > Proto Recv-Q Send-Q Local Address Foreign Address(state) > udp 0 0 core.5022 lithium.constant.ntp > udp 0 0 core.8806 hydrogen.constan.ntp > udp 0 0 core.21164 helium.constant..ntp > udp 0 0 *.**.* > udp 0 0 *.**.* > > First, what does it mean *.* *.* in last 2 entries. Those sockets are not bound or connected. This is possible with UDP sockets since you can use for example sendto(2) without doing a bind(2) or connect(2) call beforehands. There are some daemons that do this (dhclient, slaacd). > Second, how can I verify what process is listening on ports > 5022,8806 and 21164? > This is not possible since more than one process can be listening on a socket (since file descriptors can be shared). You need to use fstat(1) for this. What linux offers is at best best-effort and sometimes wrong. -- :wq Claudio
Re: "Transit" BGPD not announcing learnt routes to neighbors
On Sun, Sep 09, 2018 at 01:17:40PM +, Tim Jones wrote:
> Hi,
>
> I'm working with something in a lab environment at the moment, testing out
> OpenBGPD to see if it can replace "something else" on an internal network.
>
> I have three OpenBSD instances (A <->B<->C), and whilst B is learning routes
> from C, it is not pushing them out to A, no matter how relaxed I make my
> filters.
>
> On the other hand, going in the other direction, C is learning the default
> route sent by A without problems.
>
> This is on OpenBSD 6.3.
>
> $bgpctl sho nei A-1
> Update statistics:
> Sent Received
> Updates 0 1
> Withdraws 0 0
> End-of-Rib 1 1
>
> $bgpctl sho nei C-1
> Update statistics:
>
> Sent Received
>
> Updates 1 1
>
> Withdraws 0 0
>
> End-of-Rib 1 1
>
>
> $ bgpctl sho ri nei C-1
> *> 198.51.100.164/32 198.51.100.164 100 0 64555 i
>
> AS 64515
> router-id 192.0.2.97
> socket "/var/www/run/bgpd.rsock" restricted
> rde med compare always
>
> # network inet connected # I have tried both with and without this line
>
> group "A_NETS" {
> neighbor 192.0.2.122 {
> descr "A-1"
> remote-as 64500
> local-address 192.0.2.121
"announce all" is probably missing here, since the default in 6.3 was
"announce self" and so transit routes would be filtered.
> }
> }
> group "C_NETS" {
> neighbor 198.51.100.164 {
> descr "C-1"
> remote-as 64555
> local-address 198.51.100.252
> announce default-route
> }
> }
> match from any set { origin igp }
> allow from any
> deny to any
> allow to any prefix 198.51.100.164/32
> allow to any prefix 203.0.113.0/24 prefixlen >= 24
> allow to group "C_NETS"
>
--
:wq Claudio
Re: Minimum Holdtime for BGP OpenBGPd in Production
On Tue, Sep 18, 2018 at 05:11:24AM +0100, Tom Smyth wrote: > Hello all, > I was wondering what is the lowest values of BGP holdtime that you > recommend running in production ? I recomend using the default especially against ebgp peers. > I would like to set them to a lower value to detect an issue with > peers that dont support BFD quicker, > but I dont want to set it to a value that would overly tax the system > resources, > > If you are running approx 60 Peers on one and 30 Peers on another router, > > Im also running Arista 7050 Switches with BGP sessions to the OpenBGPd > Routers. > > I would really apprecate any one elses real world experience on this > matter before I go lowering the default values in our production > enviornment > bgpd should be able to handle the minimal hold time with 30 or 60 peers just fine but I'm not so sure about any other system. Also flaping sessions because of too aggressive holdtime is counterproductive the session flap dampening will kick in and will keep session longer down than needed. In the end, like with most tuning, you need to check for yourself with what you are comfortable with. -- :wq Claudio
Re: PF possibly causing weird SSL issues ?
On Wed, Sep 19, 2018 at 10:00:28AM +, Tim Jones wrote:
>
> > This feels like it might be an MTU related problem, especially likely
> > if the connection is going via pppoe or a tunnel - you may need "scrub
> > (max-mss ##)".
> >
> > The way Google's TLS server handshake is setup, it fits in pppoe without
> > fragmentation, most other sites do not this.
> >
> > Otherwise try simplifying pf.conf (one change at a time and test):
> > disable syncookies and change "modulate state" to "keep state", maybe
> > also the random-id scrub. ("syncookies always" in PF doesn't make a
> > lot of sense to me except for testing, especially if only allowing
> > inside->outside traffic, I think "adaptive" would be more usual if
> > using this feature).
>
>
>
> Thanks Stuart. These sound possibly more likely than some of the other
> suggestions (e.g. wrong date/time or bad pf rules ... I'm not that
> silly).
>
> The connection is not going via PPPoE or tunnel. The immediate next hop
> is an OpenBSD based BGP router (where, incidentally I can't replicate
> this SSL issue, but the router is not (yet) running 6.3 either). The
> OpenBSD router box is then plugged into large carrier routers. So it
> all this is not hanging off the end of some random DSL line !
>
> The reason I've got "syncookies always" is because there are various
> internet exposed services (e.g. webservers) sitting behind this PF
> instance, and as far as I can gather syncookies is recommended as a good
> thing (tm) for these sort of applications ? This PF instance is very
> much a majority out->in instance.
This is a very bad advise you got. Syncookies should only be used in
exterme situations because the they do lose some of the additional
information that is part of the SYN packet. "syncookies always" is only
there for testing but should not be used in production.
Syncookies are a way to preserve resources on the firewalls and servers
when they are attacked by simple SYN floods. This works because the
syncookie allows to respond to SYN packets without creating any kind of
internal state (which is normally required to finish the 3-way handshake).
All the data that would normally be stored in the state has to be
compressed into a few bits of the syncookie and so especially data like the
MSS is not stored at full precision.
> But at the same time I'm also unclear as to what the impact of
> syncookies is on states ? The man page talks of "continue the
> connection with synproxy in place", which in my mind implies "synproxy
> state" ?
Syncookies are similar to synproxy but unlike synproxy they don't create
state on the initial SYN (only on the ACK sent back as repsonse to the
syncookie). It does similar to synproxy only open the backend connection
once the 3-way handshake is finished.
--
:wq Claudio
Re: Adding interfaces to ospf
On Wed, Sep 26, 2018 at 11:31:21PM +0200, Simen Stavdal wrote:
> Hello,
>
> I am setting up an ospf lab, and have a quick question.
> The answer is probably right in front of me, but I just can't seem to find
> it.
>
> I have a basic ospfd.conf including some active and some passive interfaces.
> Working just fine.
>
> usg2# cat /etc/ospfd.conf | grep -v "^#"
> password="secret"
> redistribute connected
> area 0.0.0.0 {
> interface lo2 { passive }
> interface lo11 { passive }
> interface lo10 { passive }
> interface cnmac0 {
> auth-type simple
> auth-key $password
> }
> }
>
>
> I have a neighbour that sees all the routes advertised from usg2.
>
> Then, I would like to add a loopback interface on one of the routers, give
> it a /32 and advertise it (like i already do for some other loopback
> interfaces).
>
> Next, how do I get ospf to advertise the new host address?
>
> I have tried :
> ospfctl reload
> Obviously I have not yet changed ospfd.conf, so I add the new loopback
> interface as passive.
> ospfctl reload again, no luck.
>
> usg2# ifconfig lo12 inet 192.168.5.111 netmask 255.255.255.255 up
>usg2# ifconfig lo12
> lo12: flags=8049 mtu 32768
> index 19 priority 0 llprio 3
> groups: lo
> inet 192.168.5.111 netmask 0x
>
>
> usg2# ospfctl show fib
> flags: * = valid, O = OSPF, C = Connected, S = Static
> Flags Prio Destination Nexthop
> *C4 10.10.100.0/24 link#1
> *C0 127.0.0.0/8 link#0
> *S8 127.0.0.0/8 127.0.0.1
> * 1 127.0.0.1/32 127.0.0.1
> *O 32 192.168.1.1/32 10.10.100.2
> * 1 192.168.5.9/32 192.168.5.9
> * 1 192.168.5.10/32 192.168.5.10
> * 1 192.168.5.99/32 192.168.5.99
> * 1 192.168.5.111/32 192.168.5.111
> *S8 224.0.0.0/4 127.0.0.1
>
> So, it is seen in the fib.
>
> usg2# ospfctl fib couple
> couple request sent.
>
>
> On one of the neighbours, I can see all the locally connected from
> usg2, but not lo12 (which is the new one I just added).
>
>
> The only way I have found so far, is to restart the ospfd daemon, but
> that seems a bit excessive - recalculations and all that. By the way,
> I am running ospfd with "-d" - do not daemonize. Any suggestions?
>
> Running OpenBSD 6.3, tried on octeon and amd64, same behaviour.
>
> I will be happy to supply any information requested.
>
This smells like a bug - unsure if it is fixed in -current.
What does `ospfctl show int` show?
--
:wq Claudio
Re: Routing stops after ipsec/gre tunnel activates
On Mon, Oct 01, 2018 at 04:16:48PM +0100, Kaya Saman wrote: > > On 10/1/18 4:12 PM, Janne Johansson wrote: > > > > > > Den mån 1 okt. 2018 kl 16:56 skrev Kaya Saman > <mailto:kayasa...@gmail.com>>: > > > > Hi, > > I've got an issue where something strange is happening with the > > routing > > table after establishing an ipsec connection it's quite hard to > > describe but what happens is that the tunnel establishes then routing > > goes down completely. The netstat -r command when run on the > > router just > > hangs and doesn't complete (show any routes). > > > > > > Perhaps you can't reach your resolver, try running "netstat -rn" to > > prevent netstat > > from trying to resolve all ips and networks it lists. > > -- > > May the most significant bit of your life be positive. > > > The resolver is local. However, the issue is deeper as inter-subnet > communications go down and these are ipv4 -> ipv4 > > > If I kill the isakmpd process then communication resumes, as in all layer3+ > services start functioning again: icmp, nfs, ssh etc > Since your policy is from 0.0.0.0/0 to 0.0.0.0/0 all traffic will end up in the ipsec tunnel. I doubt this is what you want. IPsec flows steal the traffic before routing happens. I think you need to refine your policy also check with tcpdump what happens on enc0, etc. pp. -- :wq Claudio
Re: Redistributing between bgpd and ospfd
On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > On 15.10.18 12:58, Sebastian Benoit wrote: > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > Hello, > > > > > > I am trying to get bgpd and ospfd play nicely with route redistribution. > > > > > > So far the only way I have found that suits my need is to use > > > bgpd.conf network statements and rtlabels. > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf: > > > match from set rtlabel from_bgpd > > > > > > And in ospfd.conf: > > > redistribute rtlabel from_bgpd > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > ospfd it becomes a bit more tedious. The only way I have found to make > > > bgpd announce ospf originated routes (to its bgp peers) is via network > > > statements in bgpd.conf. These network statements are not conditional > > > on the availability of such a route in ospf though so they are not > > > very dynamic anymore. > > > > > > I understand that it according to standard > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > explicit for type 1 and 2 LSAs. > > > > > > What is the recommended way to achieve dynamic explicit route > > > redistribution in both directions? > > Network statements are the correct way. > > > > You can use > > > > network (inet|inet6) priority ... > > network (inet|inet6) rtlabel ... > > > > So with > > > >network inet priority 32 > > > > you should be able to redistribute all ospf routes into bgp. > > > > If this does not help, please explain your problem further (and include your > > config). > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) for > > this as there was at least a bugfix for route-labels.) > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > setting them per area, or per interface where a route was learned. > just wondering why is it not implemented yet. is that too complex change? or > just not necessary? > Until now there has not been a need for this. In general and probably best common practice is to not mix BGP and OSPF. Instead OSPF is building the underlaying network to run BGP on top of. This is why benno@ was asking for the use case. By the way, because of the nature of OSPF it does not make sense to tag routes by interface, doing it by area could be an option but that comes with some edge cases that need further inspection. -- :wq Claudio
Re: Redistributing between bgpd and ospfd
On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > Hello, > > Only relying on OSPF hellos effectively makes it mimic BGP with its > keepalives. I will ponder the value of transporting the underlay in > OSPF, effectively transporting loopback peering addresses for BGP in > OSPF. I am not sure that it will make my life easier but will consider > it. OSPF is generally faster at converging after reroute and it is possible to set the router-dead-time to minimal which will give you a 1 second timeout. Also the default of 40sec is lower than the 90sec of BGP. Additionally OSPF may give you multipath routes so the failover for BGP may be not noticable. Also GRE has a way to emulate link state but to be honest if I use OSPF on a GRE link I will not turn it on (unless requested). > Thanks for the quick replies everyone. You confirmed that I am not > entirely a moron. > > Still, having the ability to set rtlabels in ospfd would be nice. > On Mon, Oct 15, 2018 at 5:59 PM Stuart Henderson wrote: > > > > On 2018-10-15, open...@kene.nu wrote: > > > in theory. But when WAN links are composed of IPSEC and GRE (which > > > does not have link state) OSPF falls to pieces as the core idea of is > > > link-state. > > > > OSPF primarily uses hellos. Link-state is also used to speed up failover > > up but is not required. > > > > There was a bug in ospfd with DR selection that results in problems > > (specifically multiple routers thinking they were all DR) after a > > netsplit if there was no link-state change. This was already fixed > > though so if you are running 6.3+ and still seeing problems, please > > send a bug report with some information. > > > > > -- :wq Claudio
Re: Redistributing between bgpd and ospfd
On Wed, Oct 17, 2018 at 01:07:32PM +0200, Sebastian Benoit wrote:
> open...@kene.nu(open...@kene.nu) on 2018.10.17 12:44:02 +0200:
> > Hello,
> >
> > On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit
> > wrote:
> > >
> > > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200:
> > > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote:
> > > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its
> > > > > > keepalives. I will ponder the value of transporting the underlay in
> > > > > > OSPF, effectively transporting loopback peering addresses for BGP in
> > > > > > OSPF. I am not sure that it will make my life easier but will
> > > > > > consider
> > > > > > it.
> > > > >
> > > > > OSPF is generally faster at converging after reroute and it is
> > > > > possible to
> > > > > set the router-dead-time to minimal which will give you a 1 second
> > > > > timeout. Also the default of 40sec is lower than the 90sec of BGP.
> > > > > Additionally OSPF may give you multipath routes so the failover for
> > > > > BGP
> > > > > may be not noticable. Also GRE has a way to emulate link state but to
> > > > > be
> > > > > honest if I use OSPF on a GRE link I will not turn it on (unless
> > > > > requested).
> > > >
> > > > I guess the brewing BFD support would speed this up for BGP when it
> > > > arrives
> > > > and make OSPF less useful if speed is the thing that needs to be solved.
> > > >
> > > > Also I've been thinking about the following config in ospfd
> > > >
> > > > rtlabel label external-tag number
> > > > Map route labels to external route tags and vice versa.
> > > > The
> > > >external route tag is a non-negative 32-bit number
> > > >attached to AS-external OSPF LSAs.
> > > >
> > > > What exactly does this mean? As I understand it is to map rtlabels to
> > > > LSA
> > > > Type 5 tags. But what do you do with it then? Could this be used for
> > > > what
> > > > this thread is talking about or is it totally off?
> > >
> > > If you do this on two (or more routers) you distribute the routes and they
> > > end up in the fib with that rtlabel (note the "and vice versa").
> > >
> > > You can do all the things you can do with route labels, for example use
> > > them in pf filters.
> > >
> > > And yes, you could also use it to redistribute them into bgp (although
> > > that
> > > needs to happen on another router i think):
> > >
> > > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ...
> > > hostA hostB hostBhostB
> > >
> > > /Benno
> >
> > I might be wrong here but in prder to have ospfd generate type 5 LSAs
> > one needs both a BGP speaker that announces the prefix in question
> > into ospf and two different ospf areas in your network?
>
> No need for a bgp speaker: a route in the routing table with the label is
> enough.
>
> So here is a rough description of how ospfd and bgpd announce new prefixes
> (i.e. the ones not learned from other routers).
>
> ospfd looks at whats in the kernel routing table (FIB), and depending on its
> configuration (the interface statements _and_ redistribute commands) it adds
> routes into its ospfd internal RIB. That RIB is then propagated into the
> ospf network (skip ospf protocol details here).
>
> ospfd needs routes in the FIB to inject new routes into OSPF.
>
> By inject, i mean "add a new network to the routes in the RIB".
>
> BGPD on the other hand has the "network " statement.
>
> It adds the prefix given there to its RIB ("injects it into BGP") without
> the need for a route in the FIB.
>
> The additional options (network priority ..., network rtlabel ...) are
> only there for convinience and special cases, they are not really needed
> for standard bgp setups.
>
> > Or can I make ospfd generate type5 LSAs in some other way? I see that
> > rtlabels would do it but that implies I have an already existing route
> > in the fib which preemptively I tag in some way. In my case the routes
> > are generated by interface statements in ospfd.conf (so type1 and 2
> > LSAs).
>
> If you use interface statements, those interfaces have IPs on them, which you
> will find have routes in the routing table.
>
> Also, there is "ifconfig rtlabel ..."
>
> I don't know if ospfd will pick those route-labels up (with the rtlabel
> statement). I think it should, but havent used that or looked at the code.
>
The rtlabel / external-tag mapping only works for Type-5 LSA which are
prefixes ospfd picked up via any of the redistribute statements. Any prefix
covered by interface statements end up as non Type-5 LSA and so will not
use the mapping. This includes stub networks.
I have not tried to use "ifconfig rtlabel ..." with ospfd together
but I see no reason why it should not work if used with redistribute
connected for example.
--
:wq Claudio
Re: bgp match to $neighbor set nexthop $carp_ip on 6.4
On Mon, Oct 22, 2018 at 01:17:30PM +0200, Marko Cupa? wrote:
> Hi,
>
> I am struggling to announce nexthop to my bgp peers after default
> ruleset change in 6.4's bgpd.conf.
>
> On 6.3, I used to have:
>
> match to $ISP1 set nexthop $CARP_TO_ISP1
> match to $ISP2 set nexthop $CARP_TO_ISP2
> deny from ebgp
> deny to ebgp
> allow to { $ISP1 $ISP2 }
> allow from ibgp
> allow to ibgp
> (...defaults...)
>
>
> I like the idea of having my simple ruleset done with minimal override
> to defaults. Moreover, I see that slapping above ruleset to 6.4 does
> not work the same as on 6.3 (I think I'm sending garbage upstream).
You can check with 'bgpctl show rib out nei $ISP1 detail' what you are
sending. Also tcpdump is able to show you what you are sending.
> Any good soul out there to tell me what to put above:
>
> ### for simple BGP setups, no editing below this line is required ###
>
> ...in order to set nexthop per upstream neighbor, if possible?
The new ruleset has a few deny quick rules in it. Make sure you don't hit
one of those.
It would be helpful to see the full ruleset as shown with 'bgpd -nv'
--
:wq Claudio
Re: bgpctl not showing rib entries, pftables empty
On Mon, Oct 29, 2018 at 09:30:44AM +0100, Peter Hessler wrote:
> Hi Ashe
>
> Sorry about that, I forgot a part of the config file.
>
> You'll need to add "nexthop qualify via default" to the global part of
> the configuration. Since the routers sending you the information are
> not on your local link, there isn't a valid nexthop so the routes are
> not selected. Once the nexthops are accepted, the prefixes will be
> processed and will be used.
Also don't forget the default deny policy of 6.4. Looking at the config it
seems there is no 'allow from group "spam-bgp"' and so nothing is put into
the RIB.
> -peter
>
>
> On 2018 Oct 29 (Mon) at 03:37:23 + (+), Ashe Connor wrote:
> :Hi all,
> :
> :I’ve set up bgpd for use with bgp-spamd.net’s servers. As far as I can
> tell, the BGP connection and transfer is working fine:
> :
> :--8<--
> :elisheva:~$ cat /etc/bgpd.conf
> :spam_rs1="64.142.121.62"
> :spam_rs2="217.31.80.170"
> :spam_asn="65066"
> :
> :AS 65500
> :fib-update no
> :
> :group "spam-bgp" {
> :remote-as $spam_asn
> :multihop 64
> :export none
> :neighbor $spam_rs1
> :neighbor $spam_rs2
> :}
> :
> :match from group "spam-bgp" community $spam_asn:42 set pftable
> "bgp_spamd_bypass"
> :match from group "spam-bgp" community $spam_asn:666 set pftable "bgp_spamd"
> :elisheva:~$ bgpctl show
> :Neighbor ASMsgRcvdMsgSent OutQ Up/Down
> State/PrfRcvd
> :217.31.80.170 65066410322 0 02:39:41 37096
> :64.142.121.62 65066460318 0 01:25:30 37096
> :elisheva:~$ bgpctl show rib memory
> :RDE memory statistics
> : 37096 IPv4 unicast network entries using 1.4M of memory
> : 37096 rib entries using 2.3M of memory
> : 74192 prefix entries using 6.8M of memory
> :10 BGP path attribute entries using 1.1K of memory
> : 2 BGP AS-PATH attribute entries using 82B of memory,
> : and holding 10 references
> : 7 BGP attributes entries using 280B of memory
> : and holding 10 references
> : 7 BGP attributes using 48B of memory
> :RIB using 10.5M of memory
> :
> :RDE hash statistics
> :path hash: size 131072, 10 entires
> :min 0 max 2 avg/std-dev = 0.000/0.000
> :aspath hash: size 131072, 2 entires
> :min 0 max 1 avg/std-dev = 0.000/0.000
> :attr hash: size 16384, 7 entires
> :min 0 max 1 avg/std-dev = 0.000/0.000
> :--8<--
> :
> :However, despite the entry counts being shown by `bgpctl show rib memory`,
> no other command lists entries as one might expect, and the pf tables are
> empty:
> :
> :--8<--
> :elisheva:~$ bgpctl show rib
> :flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> : S = Stale, E = Error
> :origin validation state: N = not-found, V = valid, ! = invalid
> :origin: i = IGP, e = EGP, ? = Incomplete
> :
> :flags ovs destination gateway lpref med aspath origin
> :elisheva:~$ bgpctl show rib community 65066:42
> :flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> : S = Stale, E = Error
> :origin validation state: N = not-found, V = valid, ! = invalid
> :origin: i = IGP, e = EGP, ? = Incomplete
> :
> :flags ovs destination gateway lpref med aspath origin
> :elisheva:~$ doas pfctl -Ts -t bgp_spamd
> :elisheva:~$ doas pfctl -Ts -t bgp_spamd_bypass
> :elisheva:~$
> :--8<--
> :
> :Any hints as to how to further diagnose? I’ve tried most conceivable
> additional arguments to `bgpctl show rib` and I haven’t found a way to list
> entries yet. Log entries are benign ((re)configuration success messages).
> :
> :Thanks,
> :
> :Ashe
> :
>
> --
> For those who like this sort of thing, this is the sort of thing they like.
> -- Abraham Lincoln
>
--
:wq Claudio
Re: bgpd: announce loopback / local prefix
On Mon, Oct 29, 2018 at 09:51:46PM +0100, Pierre Emeriaud wrote: > Le lun. 29 oct. 2018 à 14:43, Pierre Emeriaud > a écrit : > > > > Is there a good way to redistribute those local prefixes? like what > > "network local" would do. > > denis@ informed me about the recently introduced "network inet6 > priority 1", I guess that could fit with some appropriate filtering. > Thanks! Another option is to set the rtlabel on the interface and then use network rtlabel to redistribute it. -- :wq Claudio
Re: bgpd: announce loopback / local prefix
On Mon, Oct 29, 2018 at 10:26:40PM +0100, Pierre Emeriaud wrote: > Le lun. 29 oct. 2018 à 22:04, Claudio Jeker a > écrit : > > > > Another option is to set the rtlabel on the interface and then use network > > rtlabel to redistribute it. > > I tried that, but it's refused by bgpd parser: > > $ doas bgpd -n > /etc/bgpd.conf:39: syntax error > $ doas nl -ba -nln /etc/bgpd.conf | grep ^39 > 39 network inet6 rtlabel 42 > > I do have routes with this label: > $ route -n show -label 42 > Internet6: > DestinationGateway > Flags Refs Use Mtu Prio Iface > 2001:db8:3cc:10:1000::12001:db8:3cc:10:1000::1UHl > 00 32768 1 lo0 > > I wanted to upgrade to 6.4 before re-trying that, this is done, but no > luck. Am I missing something obvious? This is a problem of the parser. Use "42" with the quotes to make the number a string. Or use a non-digit label (as you figured out already). -- :wq Claudio
Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?
On Tue, Nov 06, 2018 at 05:42:08PM -0500, Daniel Ouellet wrote: > The source ID does default yes, but I have a tunnel gateway for multiple > VPN and I HAD to specify the dstid on the passive side as well or ONLY > the last rule was picked up for the 0.0.0.0/0 of some of them as an > example for all the traffic flowing via the VPN. > > Any overlapping routes where not going as one might think if not dstid > specified. > > example: > > ikev2 "test1-flow" passive from 0.0.0.0/0 to 1.2.3.4/28 peer any dstid > test1.example.com > > ikev2 "test2-flow" passive from 0.0.0.0/0 to 1.3.3.4/28 peer any dstid > test2.example.com > > ikev2 "test3-flow" passive from 0.0.0.0/0 to 1.4.3.4/28 peer any dstid > test3.example.com > > ..etc > > If no dstid was specified, then you didn't have all 3 above as an > example working. > > May be it is suppose to, that I can't say for sure as the idea of it, > but it sure wasn't and isn't if I remove the dstid with everything else > staying the same. > > So what he suggested to you was valid and true. > > But it is your setup and you sure can do as you see fit. This only works if the rules are the same. The problem is that part of the lookups during the handshake are done without dstid and so at start the last rule will match and is used but later on the real rule (with correct dstid) matches. In general you can not mix different auth types because the missmatch happens during auth exchange. Fixing this is not trivial and maybe not even possible. > On 11/6/18 3:16 PM, 雷致强 wrote: > > Thanks for the input, however, I think srcid defaults to the hostname when > > it’s omitted. Explicitly setting it didn’t give me any luck. > > > >> On Nov 7, 2018, at 2:33 AM, J Evans <3...@startmail.com> wrote: > >> > >> I am by no means an expert, but for my setup, in order to get multiple > >> policies working, I had to specify both srcid and dstid for each policy on > >> the passive peer. And then I set srcid and dstid for the policies on the > >> active peers. > >> > > -- :wq Claudio
Re: performance of intel multithreading
On Wed, Nov 07, 2018 at 07:34:57PM +0300, Kihaguru Gathura wrote: > Hi, > > > On Wednesday, November 7, 2018, Nick Holland > wrote: > > On 11/05/18 23:51, Kihaguru Gathura wrote: > >> Hi, > >> > >> From a security standpoint, > >> which platform will offer better performance > > > > huh? What's your priority, security or performance? > > > > Security is the Priority. > > > If you have one and no budget to buy something ...um... modern, use it. > > I have the PrimePower 250 > > > UltraSPARC will probably give them a bigger surprise. > > Please explain further if possible. > > But if you are > > running web services, you are probably running apps written by someone > > without any idea what they are doing in an interpreted language like > > PHP, and the exact same exploits will take out either platform, because > > the exploits will be at a much higher level than the processor. > > Self written services in C language. > SPARC64 has thanks to stackghost a good defence against ROP attacks. It is big endian and strict aligned. The IOMMU also give some protection of driver bugs. SUN4U would be able to do execute only pages but SUN4V no longer supports that. In general OpenBSD/sparc64 is a good arch when it comes to being secure. The problem is that there is less and less good hardware around which is beefy enough and so more and more packages fail to build -- there is general less interest in the HW (esp outside OpenBSD). Now OpenBSD/amd64 is also not bad either, fairly important changes were made to make attacks less successful (e.g. Todd Mortimer's LLVM ret-protector). The big benefit of amd64 is that this is the common arch every developer has access to. In the end running OpenBSD gives you as many security features turned on by default as nowhere else. -- :wq Claudio
Re: BGPlooking glass in 1 RDOMAIN BGPD in another RDomain
On Sun, Nov 18, 2018 at 10:57:01PM +, Tom Smyth wrote: > Hello, > > I have a Looking glass that I want to run on a management interface > that is in a separate rdomain to the BGP router ... > > is there away we can have the the bgprocess in one RDomain (main Rdomain) > and the the bgp looking glass in another rdomain... > > so currently i have httpd in Rdomain 240 > slowcgi is running in rdomain 0 > > ping works but not the bgp commands... > > > I tried setting slowcgi flags but they just didn't take > > > do I need to run slowcgi with route -T240 exec slowcgi ? > (which would put the entire bgplg and the bgp collector on the same Rdomain.. > any suggestions are welcome ...thanks > I would check that the restricted socket is in /var/www/run and is called bgpd.rsock. After that I do not really see why bgpctl should not work. If there are no errors logged in the httpd error log then you could try to ktrace -di the slowcgi process and see why bgplg and bgpctl fails. -- :wq Claudio
Re: routing with DMZ between internal and external firewall
On Mon, Mar 16, 2020 at 09:49:30AM +0100, pebwindkraft wrote:
> Hi,
>
> I have a question concerning static routes and default gateways for a DMZ
> setup, with internal and external firewall.
> A DNS in the DMZ shall be used from internal machines, and later a http
> proxy from internal and external machines.
> The setup is within a network of a bigger data centre with it's own edge
> router. I cannot change anything on this edge router.
> I am using OpenBSD 6.6, and ip forwarding is activated on both firewalls.
> Here an ASCII pic (for better viewing also here:
> https://ln2.sync.com/dl/9da92f730/wrzi9rse-xh9sqzed-cst55auv-y39rkrwj):
>
> || |-| |-| /-\
> | int_pc |---| int_fw |---| ext_fw |---| Data Center |---> Internet
> || |em0 em1| | |em0 em1| | Edge Router |
> |-| | |-| \-/
> |
> ||
> | DNS & http |
> ||
>
> Setup of default routes:
> int_pc -> IP address of em0 on int_fw
> int_fw -> IP address of em0 on ext_fw
> DNS -> IP address of em0 on ext_fw
> ext_fw -> IP address of external interface
>
> Without any firewall rules (pfctl -d), I observe:
>
> 1.) I cannot ping from int_pc to DNS, and vice versa.
> 2.) I cannot ping from int_pc to em0 on ext_fw
>
> I can observe with tcpdump, that ping echo request leaves int_pc, goes
> through int_fw and reaches the network card of DNS or em0 on ext_fw. As the
> default route of DNS is pointing to ext_fw, the ping echo reply is sent to
> ext_fw, which doesn't know what to do with the IP address of int_pc, and
> ignores the package. I get this.
> So I can set a static route on the DNS or on the external firewall, like
> this
>
> route add -inet {network of int_pc} {IP address of em1 on int_fw}
>
> and then pinging back and forth works.
> But setting static routes on all DMZ machines and ext_fw seems doesn't seem
> right to me(?).
>
> What would be the correct design?
> Can I use "only" the ext_fw with a static route, so that packages from DNS
> would travel twice through DMZ net (from DNS to ext_fw, and then from ext_fw
> via int_fw back to int_pc)?
>
> The information I found on misc@ and internet is usually talking about "home
> router" with NAT and three network cards, where one leg supplies the DMZ...
> Mine is different, and I think I do not need NAT here?
>
You need to add routes for your internal network on ext_fw and on the DNS
box. They need to know that those networks are reachable via int_fw. These
routes are more specific and will make sure that the traffic has a path
back to int_pc.
--
:wq Claudio
Re: BGP and carp slaves
On Thu, Apr 02, 2020 at 11:34:21AM +0200, Luca Bodini wrote:
> Hi folks,
>
> I’m just having a strange issue using OpenBSD 6.6 and BGP .
> I have two OpenBSD firewalls with a carp configuration, let’s suppose the
> shared IP is 10.10.10.100, and I am able to announce 10.10.10.100/32 via BGP.
> Now, here is my /etc/bgpd.conf configuration:
>
> # define our own ASN as a macro
> ASN=“65000"
> rde med compare always
>
> # global configuration
> AS $ASN
> router-id 172.10.10.3
>
> # list of networks that may be originated by our ASN
> prefix-set mynetworks { \
> 10.10.10.100/32\
> }
>
> # Generate routes for the networks our ASN will originate.
> # The communities (read 'tags') are later used to match on what
> # is announced to EBGP neighbors
> network prefix-set mynetworks set { community $ASN:1 med 10 }
>
> # upstream providers
> group "upstreams" {
> remote-as 20746
> neighbor 172.10.10.1 {
> descr “provider router 01"
> }
> neighbor 172.10.10.2 {
> descr “provider router 02"
> }
> }
>
> ## rules section
> allow from group upstreams prefix 0.0.0.0/0
>
> # IBGP: allow all updates to and from our IBGP neighbors
> allow from ibgp
> allow to ibgp
> allow to ebgp prefix-set mynetworks
>
> The problem I’m facing is due to (i guess) provider router misconfiguration,
> in fact, routers are forwarding traffic to carp slave and unexpectedly
> everything is working fine: firewall is accepting connections and forwarding
> traffic, for example if I try to SSH:
> ~# ssh -l root 10.10.10.100
> [root@fw-02 root]# ifconfig | grep vhid
> carp: BACKUP carpdev vlan100 vhid 10 advbase 1 advskew 10
>
> I’ve asked provider to change BGP configuration and everything now is stetted
> up correctly, now, the question is:
> Is the carp slave accepting and forwarding connections by design or is it un
> “unintended" feature?
>
By default bgpd will just announce mynetworks without checking if
something is up or not.
You may have more luck with 'network inet connected' or even better use a
rtlabel. In that case bgpd should respect the status of the route.
I normally use carp on both sides and use 'network X/Y set nexthop $CARPIP'
Where $CARPIP is the external carp IP shared between the two routers. In
this case both systems announce the same network with the same nexthop
(the carp IP) to the next routers and so no rerouting happens if the
master dies. This only works if the systems share a lan segement for ebgp
sessions.
--
:wq Claudio
Re: OSPF seems to stops processing updates
On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote: > On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote: > > Thanks. Please see my comments below. > > > > On Mon, 13 Apr 2020, 10:18 Remi Locherer, wrote: > > > > > Hi Richard, > > > > > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote: > > > > We have been having a strange issue, whereby OSPF stops updating > > > properly. > > > > > > > > We can see an entry for an ip route in the database but it is not in the > > > > kernel routing table, and when it is the DR, other routers then do not > > > have > > > > the route at all. > > > > > > > > We are seeing this across multiple boxes. We have 10+ ospf speakers, and > > > > seem to see the issue at different times. > > > > > > > > The problem starts with: > > > > > > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch, > > > > bad flags > > > > > > The neighbor sent a db desc with the master flag set differently than what > > > this ospfd instance recorded before for that particular neighbor. > > > > > > See 2nd last item on page 100 of RFC 2328: > > > https://tools.ietf.org/html/rfc2328#page-100 > > > > > > Thanks, should the routers just recover then from this scenario even if it > > was happening due to lost packets, CPU pause etc. > > I think so. But it may take quite a while. It might also be an bug in ospfd > or in another implementation. Since this issues happen with 5.8 and 6.4 ospfd I would suggest to update to at least 6.6 (especially the 5.8). IIRC there was some issue with ospfd neighbor selection that caused troubles when sessions flapped. This was fixed some time ago but I doubt 5.8 has that fix in. -- :wq Claudio
Re: MultiPath / ADD_PATH for bgpd
On Wed, Apr 15, 2020 at 08:16:14PM +0100, Richard Chivers wrote: > Hi, > > Just wondering if anyone can help. > > I saw back in late 2018 that there were some initial plans for ADD_PATH and > Multipath in bgpd, it was in a list on a slide right after the portable > version. https://youtu.be/4gOoPxGKKjA?t=1500 > > Does anyone know if there are still plans in this area, or if there has > been any progress, we are really interested to explore using this in a > project we are working on, and just keen to understand if it may be coming? > The plan still holds but the timeline got a bit mixed up. Unless someone steps up ADD_PATH will not show up in the 6.8 release but probably in 6.9. -- :wq Claudio
Re: BGPD announce deprecation query
On Sun, Apr 19, 2020 at 08:07:48AM +0100, Richard Chivers wrote:
> Hi,
>
> Just been building a copy of our production system in vagrant to test
> upgrading to the latest version, in order to resolve an issue we were
> having.
>
> In our current config we have:
>
> group "core" {
> local-address $localaddr
> remote-as xx
> announce all
> neighbor x.x.x.x {
> descr "router-a"
> }
> neighbor x.x.x.x {
> descr "router-b"
> }
> }
>
> From the upgrade guide it says: In OpenBSD 6.4, the announce keyword was
> deprecated in bgpd.conf(5). It has now been removed and must be replaced
> with export.
>
> We also have another group with announce none
>
> Is it fair to suggest that removing the announce all will be the same as
> not having it in >= 6.4, and that we replace announce none with export none.
>
> Probably a stupid question, but I only touch BGP occasionally, and was just
> hoping to understand in more detail.
>
> The group core is our own internal bgp speakers, each of these also have
> transit connections too.
>
> All our config is templated using ansible, so we can easily adjust the
> config based on the actual version.
>
> Probably worth saying we are running on 6.6 with patches applied, in the
> test environment.
Yes, you can just remove announce all from your config. I guess you
already have the needed input and output filters in place to ensure only
the right thing is accepted and announced. Actually since the core group
is ibgp even in the old config announce all is not needed since that was
the default for ibgp sessions.
announce none can just be replaced with export none. The result is the
same and no prefix will be announced to these peers even if the filters
would allow them.
As mentioned the important change was that the filter switched from a
default allow rule to a default deny rule both for incoming and outgoing
filters. So you need to check your ruleset and maybe add some additional
filters. Something like
allow from ibgp
allow to ibgp
may do the trick.
--
:wq Claudio
Re: socket I/O on openbsd
On Tue, Apr 21, 2020 at 10:48:46PM -0300, Gustavo Rios wrote: > Dear gentleman, > > i have the an ANSI C code that do the following: > > 0. open a socket > 1. write data to the socket > 2. close the writing end of the socket > 3. read data from the socket > 4. close the read end of the socket > > The the step number 4 returns an error, why ? > > Here it is (Only the relevant part of the code ) > > if (!r) r = apx_connect(s, &sa); > if (!r) r = pmp_set(&ap, 1ul, &bp); > if (!r) r = pmpsend(s, &ap); > if (!r) r = apx_shutdown(s, shut_wr); > if (!r) r = pmprecv(&ap, s, &l); > if (!r) r = apx_shutdown(s, shut_rd); > This is not helpful. What kind of errno is returned? What kind of socket used? There are many more questions... The best way to report this is to use ktrace and show its output. >From that we can see what the syscalls are issued and if there is indeed an error on shutdown(). -- :wq Claudio
Re: Ospfd default route query
On Sun, Apr 26, 2020 at 08:44:42PM +0100, Richard Chivers wrote: > Not sure how I missed the clear information in the man page... > > "If set to default, a default route pointing to this router will be > announced over OSPF" > > It seems I am just having an issue and it should work as I expected. > > I will do some more diagnosis in the morning... > I think the man page is not optimal here. ospfd(8) and ospf6d(8) will only redistribute networks that are in the FIB. So in case of redistribute default the router needs to have a default route 0/0 or ::/0 in the routing table. Also that route's priority needs to be less than 32 to be picked up. This is different from bgpd where the network statements and export default-route statement work even if there is no matching route in the FIB. > On Sun, 26 Apr 2020, 17:09 Richard Chivers, wrote: > > > Hi, > > > > Hope someone can help, I am having a strange issue and can't seem to > > isolate the problem. > > > > We have "redistribute default" set globally on our bgp/ibgp speakers > > in the ospfd.conf. The bsd boxes are all 6.6. > > > > These routers are connected via ibgp to some other routers and have > > external bgp sessions taking at present a couple of basic network > > announcements from their egbp peers. e.g. 2.2.2.0/24 ( we have faked our > > transit provider) > > > > Connected to these routers we have a pair of firewalls, which previously > > received a default route from the bgp/ibgp speakers. > > > > I am trying to understand exactly what the redistribute default in the > > ospfd.conf does. I assume it is saying if i have a static default route or > > another default route from an upstream then tell other routers about it? Or > > is it saying tell others to use me as a default route. I can't seem to find > > anything specific in the docs to clarify this, and would like to understand > > it clearly if pos. > > > > In our case our previous configuration on 5.8 and this configuration has a > > static route on the bgp speakers of 0.0.0.0/24 -> 127.0.0.1. > > > > If I do a ospfctl sh rib or ospfctl sh data on the firewalls i just don't > > see any default route being provided by the bgp speakers. > > > > Hope this makes sense. I am sure I am missing something obvious... > > > > Effectively I want the bgp speakers to announce themselves as the default > > route for their neighbor firewalls over ospf. > > > > Thanks > > -- :wq Claudio
Re: Ospfd default route query
On Mon, Apr 27, 2020 at 07:26:08PM +0100, Richard Chivers wrote: > Hi, > > That makes a lot of sense thanks, and appears to have solved the problem, > we had a route added through our loopback interface in production" > "!/sbin/route add -reject default 127.0.0.1" > > Is that the best/general practise in general? I would use a -blackhole route (no need to send out ICMP messages) but yes, that is what I normally use in such a case (at least for the DFZ). > Cheers > > Richard > > On Mon, Apr 27, 2020 at 8:25 AM Claudio Jeker > wrote: > > > On Sun, Apr 26, 2020 at 08:44:42PM +0100, Richard Chivers wrote: > > > Not sure how I missed the clear information in the man page... > > > > > > "If set to default, a default route pointing to this router will be > > > announced over OSPF" > > > > > > It seems I am just having an issue and it should work as I expected. > > > > > > I will do some more diagnosis in the morning... > > > > > > > I think the man page is not optimal here. ospfd(8) and ospf6d(8) will only > > redistribute networks that are in the FIB. So in case of redistribute > > default the router needs to have a default route 0/0 or ::/0 in the > > routing table. Also that route's priority needs to be less than 32 > > to be picked up. > > > > This is different from bgpd where the network statements and export > > default-route statement work even if there is no matching route in the > > FIB. > > > > > On Sun, 26 Apr 2020, 17:09 Richard Chivers, > > wrote: > > > > > > > Hi, > > > > > > > > Hope someone can help, I am having a strange issue and can't seem to > > > > isolate the problem. > > > > > > > > We have "redistribute default" set globally on our bgp/ibgp speakers > > > > in the ospfd.conf. The bsd boxes are all 6.6. > > > > > > > > These routers are connected via ibgp to some other routers and have > > > > external bgp sessions taking at present a couple of basic network > > > > announcements from their egbp peers. e.g. 2.2.2.0/24 ( we have faked > > our > > > > transit provider) > > > > > > > > Connected to these routers we have a pair of firewalls, which > > previously > > > > received a default route from the bgp/ibgp speakers. > > > > > > > > I am trying to understand exactly what the redistribute default in the > > > > ospfd.conf does. I assume it is saying if i have a static default > > route or > > > > another default route from an upstream then tell other routers about > > it? Or > > > > is it saying tell others to use me as a default route. I can't seem to > > find > > > > anything specific in the docs to clarify this, and would like to > > understand > > > > it clearly if pos. > > > > > > > > In our case our previous configuration on 5.8 and this configuration > > has a > > > > static route on the bgp speakers of 0.0.0.0/24 -> 127.0.0.1. > > > > > > > > If I do a ospfctl sh rib or ospfctl sh data on the firewalls i just > > don't > > > > see any default route being provided by the bgp speakers. > > > > > > > > Hope this makes sense. I am sure I am missing something obvious... > > > > > > > > Effectively I want the bgp speakers to announce themselves as the > > default > > > > route for their neighbor firewalls over ospf. > > > > > > > > Thanks > > > > > > > > -- > > :wq Claudio > > -- :wq Claudio
Re: bad AGGREGATOR, AS 0 not allowed
On Wed, Apr 29, 2020 at 05:45:30PM +0200, Marko Cupać wrote: > Hi, > > on 6.6-RELEASE amd64, (sys)patched up to 019_smtpd_exec, I am noticing > these: > > Apr 29 17:23:33 bgp1 bgpd[42338]: neighbor IP.ADD.RE.SS (desc): bad > AGGREGATOR, AS 0 not allowed, attribute discarded > > My bgpd.conf is almost default, announcing my AS to two upstream peers. > > I wrote to my peer, they said they are not sending me AS 0, and to clear my > session. > > After 'bgpctl neighbor desc clear' I'm still getting these messages. > > Is this related to: > [https://marc.info/?l=openbsd-tech&m=156510627921885&w=2] > > Can I safely disregard this, and wait for next release for these messages to > disappear? At the moment this warning as not been removed, so you will see it even in the next release. It has indeed todo with the fact that AS 0 is not allowed even in the AGGREGATOR attribute. Now your neighbor is sending you such an attribute which indicates that their routers do not handle RFC7607 correctly. At the moment there are a handful of prefixes in the DFZ that are sent with an AGGREGATOR attribute that has AS 0 and this is what triggers. You normally get the error on the initial sync. I wanted to make the error better an include ASPATH / prefix but at the time this problem happens this information is not available. Time to look at this again so that the finger pointing is more helpful. -- :wq Claudio
Re: OSPF lsa_check issue
On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote:
> After some more work this morning we have managed to extract the
> information from tcpdump of the full LS-Update packet, we couldn't see it
> on bsd, but running:
>
> tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick.
>
> What we are seeing is that a pair of firewalls are both sending updates
> like this:
>
> 07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+], proto
> OSPF (89), length 1500)
> x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480 [len 1672]
> Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1)
> Simple text password: dslkfjld, 1 LSA
> LSA #1
> Advertising Router x.x.x.x, seq 0x806e, age 0s, length 1624
>Router LSA (1), LSA-ID: x.x.x.x
>Options: [External]
>Router LSA Options: [ASBR]
> Stub Network: 10.128.32.128, Mask: 255.255.255.128
> topology default (0), metric 10
> Stub Network: 10.128.9.0, Mask: 255.255.255.128
> *{ another 50 or so networks here}*
>
> Each time we get one of these updates the DR logs the lsa_check: bad age.
>
> Another 5 or so seconds later the same LS-Update comes in with the same seq
> number. This appears to continue indefinitely. Our only fix appears to be
> restarting ospfd on the routers.
>
> Does anyone have an idea what is going wrong here?
>
> Something we have considered being a problem is that we do have many
> interfaces, we have 90 or so, so the LS-Update packets are quite large and
> do get fragmented, as we are using a 1500mtu.
>
> The fact that ospfd sees the age and complains though makes us think this
> is not a problem.
>
Looking at the tcpdump output there is something strange with the various
reported length fields. Is it possible to get the raw packet dumps?
--
:wq Claudio
Re: OSPF lsa_check issue
On Tue, May 05, 2020 at 10:51:40AM +0200, Claudio Jeker wrote:
> On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote:
> > After some more work this morning we have managed to extract the
> > information from tcpdump of the full LS-Update packet, we couldn't see it
> > on bsd, but running:
> >
> > tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick.
> >
> > What we are seeing is that a pair of firewalls are both sending updates
> > like this:
> >
> > 07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+], proto
> > OSPF (89), length 1500)
> > x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480 [len 1672]
> > Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1)
> > Simple text password: dslkfjld, 1 LSA
> > LSA #1
> > Advertising Router x.x.x.x, seq 0x806e, age 0s, length 1624
> >Router LSA (1), LSA-ID: x.x.x.x
> >Options: [External]
> >Router LSA Options: [ASBR]
> > Stub Network: 10.128.32.128, Mask: 255.255.255.128
> > topology default (0), metric 10
> > Stub Network: 10.128.9.0, Mask: 255.255.255.128
> > *{ another 50 or so networks here}*
> >
> > Each time we get one of these updates the DR logs the lsa_check: bad age.
> >
> > Another 5 or so seconds later the same LS-Update comes in with the same seq
> > number. This appears to continue indefinitely. Our only fix appears to be
> > restarting ospfd on the routers.
> >
> > Does anyone have an idea what is going wrong here?
> >
> > Something we have considered being a problem is that we do have many
> > interfaces, we have 90 or so, so the LS-Update packets are quite large and
> > do get fragmented, as we are using a 1500mtu.
> >
> > The fact that ospfd sees the age and complains though makes us think this
> > is not a problem.
> >
>
> Looking at the tcpdump output there is something strange with the various
> reported length fields. Is it possible to get the raw packet dumps?
>
Can you try the following diff and see if it fixes the issue?
--
:wq Claudio
Index: lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.47
diff -u -p -r1.47 lsupdate.c
--- lsupdate.c 19 Nov 2019 09:55:55 - 1.47
+++ lsupdate.c 5 May 2020 09:20:50 -
@@ -186,7 +186,7 @@ add_ls_update(struct ibuf *buf, struct i
return (0);
}
- lsage = ibuf_reserve(buf, 0);
+ lsage = ibuf_reserve(buf, len);
if (ibuf_add(buf, data, len)) {
log_warn("add_ls_update");
return (0);
Re: OSPF lsa_check issue
On Wed, May 06, 2020 at 09:33:11AM +0100, Richard Chivers wrote:
> Hi,
>
> Some progress has been made, we can now replicate this consistently and it
> appears that whenever a LS update exceeds the mtu (1500) we get this issue
> of lsa_check bad age.
>
> When running with the diff Claudio sent we start getting a bunch of errors
> complaining about:
>
> recv_ls_update: bad packet size, neighbor ID x.x.x.x
> lsa_check: bad packet size
>
> We don't ever move to a state of FULL/DR or similar.
>
> Does anyone have any suggestions? We are just starting to look at the wider
> code to see if we can comprehend what may be occurring, but it will
> likely be a steep learning curve :)
>
Just realized that my diff was wrong since ibuf_reserve() would change the
write position of the buffer and so you end up with some empty space in
the buffer.
Here is a better diff. This is using ibuf_size to get the current write
position and then ibuf_seek() to write the age back into the right spot.
Using the position instead of the pointer has the benefit that a realloc()
in ibuf_add() will not result in the stale pointer to lsage that the
current code has.
I have currently no ospf setup so my testing is limited.
--
:wq Claudio
Index: lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.47
diff -u -p -r1.47 lsupdate.c
--- lsupdate.c 19 Nov 2019 09:55:55 - 1.47
+++ lsupdate.c 6 May 2020 08:48:19 -
@@ -175,8 +175,8 @@ int
add_ls_update(struct ibuf *buf, struct iface *iface, void *data, u_int16_t len,
u_int16_t older)
{
- void*lsage;
- u_int16_tage;
+ size_t ageoff;
+ u_int16_t age;
if ((size_t)iface->mtu < sizeof(struct ip) + sizeof(struct ospf_hdr) +
sizeof(u_int32_t) + ibuf_size(buf) + len + MD5_DIGEST_LENGTH) {
@@ -186,7 +186,7 @@ add_ls_update(struct ibuf *buf, struct i
return (0);
}
- lsage = ibuf_reserve(buf, 0);
+ ageoff = ibuf_size(buf);
if (ibuf_add(buf, data, len)) {
log_warn("add_ls_update");
return (0);
@@ -198,7 +198,7 @@ add_ls_update(struct ibuf *buf, struct i
if ((age += older + iface->transmit_delay) >= MAX_AGE)
age = MAX_AGE;
age = htons(age);
- memcpy(lsage, &age, sizeof(age));
+ memcpy(ibuf_seek(buf, ageoff, sizeof(age)), &age, sizeof(age));
return (1);
}
Re: OSPF lsa_check issue
On Wed, May 06, 2020 at 03:23:06PM +0100, Richard Chivers wrote: > Hi, > > Thanks so much for the diff, it appears to have resolved the issue. > > We are now trying to establish whether we need the fix widely deployed or > only on the box that originates with the large LSA updates, pushing it over > the 1500mtu. > > We are going to run some tests, but our expectation is that when the DR > sends the message from the originating router on to its neighbors that they > will then see the same issue. > > Out of interest is there any way of just announcing a single network. > > In this particular case the large LS-Update is caused because we have many > interfaces, but these are all carp so will failover in one hit anyway. We > have allocated 10.128.0.0/16 to this firewall so there are many networks, > but anything in our network with a destination of 10.128.0.0/16 can end up > here. > > We tried something like *redistribute 10.128.0.0/16 <http://10.128.0.0/16> > depend on carp0*, but what that appears to do is limit advertisements to > the subnets that fall within that range, so we still have a very large LSA > update anyway. > > Just wondering if there was any workaround, as it would just simplify > processing etc. > > It is probably a non issue anyway now, with the fix, but just interested if > anyone has done anything similar. Without the exact config it is hard to judge but you are advertising a lot of stub networks in the router lsa. stub networks are from interface rules that are passive or have no active peers. So to reduce the size of the router LSA an option is to remove some of the interfaces and change them to redistribute connected which uses Type-5 LSA instead. -- :wq Claudio
Re: RT_TABLEID_MAX behavior changed?
On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote: > it seems the things work just when i rebuild userland completely (im pretty > sure i did it only with compiling kernel in past, correct me if i wrong?). > > btw, questions for the Devs. > Looking at the cvs history, i really worried that you do not expand > rt_tableid_max limit for the years, moreover now its actually 8 bits > shorter than it was before loopback to rdomain map. There are many people > with more than such a number of vpns, for example if they setup centralized > vpns setup, or border inter AS router role on the box. Sorry your mail is incredibly inprecise and unclear. There is no rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max returned nothing). So I have no idea what you are talking about and am therefor not able to give you a better answer. > вс, 17 мая 2020 г., 10:25 Bars Bars : > > > Hey, guys. > > > > I always used the rt_tableid_max expanded to 16 bit range in past releases > > 5.x and after rebuilding the kernel it worked immediately. > > But now I installed 6.6 on the new system, and after changing > > rt_tableid_max (and new rt_tableid_mask and bits values too), my whole > > userland throw an rtable / rdomain too large error. > > Is there behaviour change? > > The only thing changed (as i know) it is news net/trable.c struct to map > > loopback to domain, where there is only 8 unused bits to which i can expand > > tableid value. > > > > -- :wq Claudio
Re: RT_TABLEID_MAX behavior changed?
On Tue, May 19, 2020 at 11:21:13AM +0300, Bars Bars wrote:
> it seems i figured out why userland was 'broken' on recompiled kernel
> with changed RT_TABLEID_MAX.
> I dont think things are really broken, may be i dont them right way, please
> advice.
>
> I could reproduce the issue (all steps are done exactly as in openbsd.org
> faq).
> I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and change
> didnt work on userland.
> Then i rebuilt userland, rebooted, all works now.
> Now if i apply some patch from errata, there is kernel re-linking done, and
> just after that kernel change doesnt work.
> Is it expected behavior? How can i fix it? syspacth -r doesnt help.
>
You can not syspatch a system with a custom kernel. You need to do apply
the patches yourself. syspatch only works for non-modified kernels.
It should actually check this by making sure that the kernel signature is
correct so not sure what exactly happend but I guess you never properly
installed your kernel including the relink directory and so syspatch
relinked a default kernel over your modified one.
> пн, 18 мая 2020 г. в 13:31, Bars Bars :
>
> > To be more convinient, when i said about that its limit became shorter its
> > relevant to sys/net/rtable.c struct dommp.
> > struct dommp {
> > unsigned int limit;
> > /*
> > * Array to get the routing domain and loopback interface related
> > to
> > * a routing table. Format:
> > *
> > * 8 unused bits | 16 bits for loopback index | 8 bits for rdomain
> > */
> > unsigned int *value;
> > };
> >
> > In past the maxumum value was limited to u_int16_t in some deep places,
> > but nowadays there is only 8 bits allocated to it based on the struct + 8
> > unused bits which i hop i can safely add to allocation.
> > I worried these unused bits are not guaranteed to users, so actually the
> > limit is 8 bits instead of 16 in earlier releases.
> >
> >
> >
> > пн, 18 мая 2020 г. в 11:51, Bars Bars :
> >
> >> Hi, Claudio
> >>
> >> I mean these in sys/socket.h
> >> /*
> >> * Maximum number of alternate routing tables
> >> */
> >> #define RT_TABLEID_MAX 8000
> >> #define RT_TABLEID_BITS 16
> >> #define RT_TABLEID_MASK 0x
> >>
> >>
> >> пн, 18 мая 2020 г. в 10:18, Claudio Jeker :
> >>
> >>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
> >>> > it seems the things work just when i rebuild userland completely (im
> >>> pretty
> >>> > sure i did it only with compiling kernel in past, correct me if i
> >>> wrong?).
> >>> >
> >>> > btw, questions for the Devs.
> >>> > Looking at the cvs history, i really worried that you do not expand
> >>> > rt_tableid_max limit for the years, moreover now its actually 8 bits
> >>> > shorter than it was before loopback to rdomain map. There are many
> >>> people
> >>> > with more than such a number of vpns, for example if they setup
> >>> centralized
> >>> > vpns setup, or border inter AS router role on the box.
> >>>
> >>> Sorry your mail is incredibly inprecise and unclear. There is no
> >>> rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max
> >>> returned nothing). So I have no idea what you are talking about and am
> >>> therefor not able to give you a better answer.
> >>>
> >>> > вс, 17 мая 2020 г., 10:25 Bars Bars :
> >>> >
> >>> > > Hey, guys.
> >>> > >
> >>> > > I always used the rt_tableid_max expanded to 16 bit range in past
> >>> releases
> >>> > > 5.x and after rebuilding the kernel it worked immediately.
> >>> > > But now I installed 6.6 on the new system, and after changing
> >>> > > rt_tableid_max (and new rt_tableid_mask and bits values too), my
> >>> whole
> >>> > > userland throw an rtable / rdomain too large error.
> >>> > > Is there behaviour change?
> >>> > > The only thing changed (as i know) it is news net/trable.c struct to
> >>> map
> >>> > > loopback to domain, where there is only 8 unused bits to which i can
> >>> expand
> >>> > > tableid value.
> >>> > >
> >>> > >
> >>>
> >>> --
> >>> :wq Claudio
> >>>
> >>
--
:wq Claudio
Re: Convert ffs1 to ffs2?
On Wed, May 20, 2020 at 11:30:00AM +0300, Михаил Попов wrote: > > "Possible" is irrelevant. Lots of things are _possible_ but not done. > > Then only rsyncing? There is also dump and restore. > Why not adding at least one of a well tested journaled FS like XFS to OpenBSD? > Is XFS too fat and complex to be secure? There is a lot of talk but nobody ever did the work. It is hard work and will take a lot of time. Also the license needs to be compatible with OpenBSD. > Does OpenBSD work well if system root is stored via NFS, say on a Linux ZFS? OpenBSD can run diskless but not sure if it works well, that depends on your workload and opinion. -- :wq Claudio
video: kernel panic
Hello, any of the list members came across a kernel panic caused by running /usr/X11R6/bin/video ? $ video fatal protection fault in supervisor mode http://155.138.134.219/videokernelcrash.jpg OpenBSD 6.7-current (GENERIC.MP) #204: Thu May 21 11:44:48 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8334811136 (7948MB) avail mem = 8069582848 (7695MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeac50 (96 entries) bios0: vendor Dell Inc. version "1.13.0" date 11/18/2019 bios0: Dell Inc. Vostro 5471 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT HPET SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT SSDT TPM2 SSDT ASF! DMAR BGRT acpi0: wakeup devices RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) RP01(S4) PEGP(S4) PEGA(S4) RP02(S4) PXSX(S4) RP03(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) Core(TM) i7-8550U CPU @ 1.80GHz, 1896.21 MHz, 06-8e-0a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1895.59 MHz, 06-8e-0a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1895.59 MHz, 06-8e-0a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1895.59 MHz, 06-8e-0a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus 1 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus 2 (RP05) acpiprt14 at acpi0: bus 3 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP21) acpiprt22 at acpi0: bus -1 (RP22) acpiprt23 at acpi0: bus -1 (RP23) acpiprt24 at acpi0
Re: OpenBGPD fatal in RDE: rde_dispatch_imsg_session: imsg_get error: Cannot allocate memory
On Tue, Jun 30, 2020 at 10:23:07AM +0200, Laurent CARON wrote: > Hi, > > > I'm running a pretty busy OpenBGPd router (~250 bgp sessions) with 4 IPv4 > and 4 IPv6 full views, plus a few IX sessions. > > > # bgpctl show rib mem > RDE memory statistics > 820983 IPv4 unicast network entries using 31.3M of memory > 203228 IPv6 unicast network entries using 10.9M of memory > 1935802 rib entries using 118M of memory > 6348318 prefix entries using 775M of memory > 728103 BGP path attribute entries using 50.0M of memory > and holding 6348318 references > 464633 BGP AS-PATH attribute entries using 22.3M of memory > and holding 728103 references > 29055 entries for 371905 BGP communities using 8.6M of memory > and holding 6348318 references > 18541 BGP attributes entries using 724K of memory > and holding 1618379 references > 18540 BGP attributes using 145K of memory > 0 as-set elements in 0 tables using 0B of memory > 64 prefix-set elements using 3.0K of memory > RIB using 1008M of memory > Sets using 3.0K of memory > > RDE hash statistics > path hash: size 131072, 728103 entries > min 0 max 19 avg/std-dev = 5.555/2.268 > aspath hash: size 131072, 464633 entries > min 0 max 17 avg/std-dev = 3.545/1.853 > comm hash: size 16384, 29055 entries > min 0 max 8 avg/std-dev = 1.773/0.925 > attr hash: size 16384, 18541 entries > min 0 max 8 avg/std-dev = 1.132/0.848 > > > More often than not the BGPd daemon is crashing (although having plenty of > RAM (80G) on the server) with: /var/log/messages > > fatal in RDE: rde_dispatch_imsg_session: imsg_get error: Cannot allocate > memory > > fatal in RDE: prefix_alloc: Cannot allocate memory > > fatal in RDE: communities_copy: Cannot allocate memory > > peer closed imsg connection > main: Lost connection to RDE > peer closed imsg connection > SE: Lost connection to RDE > peer closed imsg connection > SE: Lost connection to RDE control > Can't send message 57 to RDE, pipe closed > last message repeated 12 times > peer closed imsg connection > SE: Lost connection to parent > neighbor A.B.C.D (sas-v4-001): sending notification: Cease, administratively > down > > > :/etc/login.conf: > > default:\ > :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin > /usr/local/sbin:\ > :umask=022:\ > :datasize-max=768M:\ > :datasize-cur=768M:\ > :maxproc-max=256:\ > :maxproc-cur=128:\ > :openfiles-max=1024:\ > :openfiles-cur=512:\ > :stacksize-cur=4M:\ > :localcipher=blowfish,a:\ > :tc=auth-defaults:\ > :tc=auth-ftp-defaults: > > daemon:\ > :ignorenologin:\ > :datasize=infinity:\ > :maxproc=infinity:\ > :openfiles-max=1024:\ > :openfiles-cur=128:\ > :stacksize-cur=8M:\ > :localcipher=blowfish,a:\ > :tc=default: > > bgpd:\ > :openfiles=512:\ > :tc=daemon: > > How can I pinpoint the source of the problem ? > Can you check and monitor with ps aux | grep bgpd and or top the VSZ and RSS of the RDE process. What is the maximum you notice. Also how do you start bgpd? Make sure the limits from login.conf are actually applied (using rcctl start should do that while doas bgpd would not). Cheers -- :wq Claudio
Re: CPU usage of httpd+slowcgi
On Mon, Jul 27, 2020 at 02:54:25PM +0100, Stuart Henderson wrote: > Replying back on-list, I don't do support-type mails off-list, and other > people know more about sparc64 hardware than me. > > On 2020/07/26 22:38, Kihaguru Gathura wrote: > > Hi Stuart, > > > > For legacy, single-core CPU's such as Sparc64 V. > > Would OpenBSD cope well with more number of CPU's or less as in previous > > case? > > > > Example. > > > > 2 CPU's (primepower 250) -> 4 CPU's (PrimePower 450) -> 8 CPU's(PrimePower > > 650) -> 16 CPU's > > (PrimePower 850) -> 32 CPU's (Primepower 1500) > > It depends on the workload. I'd have thought for most things the max > really usable at the moment is probably somewhere in the region of 4-8 > cpu cores before kernel locking gets in the way too much. > > FWIW sparc64 ports builds are now done on T4 and they're really fast. > I think (but am not 100% sure) that this is carved into ldoms so the > number of cores visible to each OpenBSD instance is limited (so > contention between cores in the kernel is also limited). The primepower 250 are decent and IIRC you can get dual core SPARC64-VI CPUs for those. They use a fair amount of power. The bigger irons are fun but honestly the weight and power consumption is just not worth it. A primepower 250 is compareable with a fast v215. At least that is my experience. Better to look for an M3000 or M4000 or as suggested for a T4-1. Also make sure you get good CPUs in them (esp. the M4000 comes with a few options). -- :wq Claudio
Re: rtables and kernel routes
On Fri, Aug 21, 2020 at 08:45:36AM +0200, open...@kene.nu wrote: > Hello, > > I am seeing rather strange, or maybe expected, behaviour. I utilise > rtables to send internal traffic towards the internet via a default > route in rtable 2. The traffic is punted to rtable 2 with pf. The > strangeness I am seeing is that unless there is a matching dummy route > in rtable 0 the traffic gets dropped on ingress hence the pf ruleset > that moves it into rtable 2 is never evalutated. > > Is this expected? The man pages for rdomain seems to suggest so but it > is not explicitly stated. I guess with internal traffic you mean traffic on the local LAN that is forwarded by the router. Not traffic local to the machine. pf(4) runs twice in your box. Once on packet reception (in rules) and once before sending out a packet (out rules). In between these two checkpoints packet forwarding happens (if forwarding is enabled and traffic is not for the local system). During forwarding a route lookup is made and based on that lookup the packet is sent out on the right interface. If this lookup fails the packet can't be forwarded and is dropped. Now the pf hook for out rules happens after this point and so a valid route is required to get there. In your case you either need a (default) route in rtable 0 so that traffic makes it to the out rule that then changes the rtable to 2 and sends out the packet towards the internet or you need to change the rtable on input (match in ... rtable 2) so that the forwarding lookup is done on rtable 2 (where there is a valid route to the destination). It seems most people prefer to write pf rulesets like yours with out rules and so a dummy default route in rtable 0 is needed but from a technical perspective it is better to do the rtable change on input. By doing so you actually save an extra route lookup (the one on rtable 0 hitting the dummy route). -- :wq Claudio
Re: bgpd config advice needed
On Mon, Aug 24, 2020 at 04:36:10PM +, Laura Smith wrote: > Hi, > > Let's say I've got a scenario where I've got transit ISPs and peering > connections. > > My general config rule is that I use med to prioritise peering over transit > (because localpref is too high up in the BGP selection algorithm, so > localpref is a sledgehammer to crack a nut). > > That setup has served me well. But now with increasing peering connections, > I'm seeing the wrong peer being selected for a route, e.g. (IPs and ASNs > obfuscated to protect the innocent) > > *> N 2001:db8:::/29 2001:db8::::1 100 100 64512 > 65500 i > * N 2001:db8:::/29 2001:db8::::2 100 100 65500 > 65500 i > > In this example, both 64512 and 65500 are peers (med=100) but obviously 65500 > 65500 should be the preferred route. > > What options do I have to resolve this sort of tie-break ? Ideally I'd > like to find something that would resolve all such instances rather than > have to introduce config hacks on a per-peer basis. > A possible option is to prefer announcements from the neighbor which is the originator. To do this you can use a rule like: match from ebgp source-as neighbor-as set med +100 Now it is a bit strange that an AS is prepending on peering. I wonder why they do that (is their connection to the IX undersized?). -- :wq Claudio
Re: pf, send(2) and EACCES
On Fri, Aug 28, 2020 at 11:40:17AM -0400, Daniel Jakots wrote: > On Fri, 28 Aug 2020 16:06:48 +0200, Sebastien Marie > wrote: > > > - generate lot of postgresql access. from postgresql thread, the > > statement seems to be a SELECT, so it would be fine to ran in loop > > (hopping no cache and real traffic generated). > > > > - run pfctl -Treplace in a loop (with a set of different files as the > > kernel code takes care if host are added, changed, deleted) > > I ran the select on one machine and the pfctl -Treplace on db1 both in > a `while :` for about two hours and it didn't happen. > > I'll try again if the problem happens genuinely again. Have a look at the pf(4) stats. especially check if the congestion counter increases when you see the error. If pf(4) detects a network congestion then ruleset evaluation is skipped and only state matching happens. In that case you can get EACCESS for connections that would normally be allowed by pf(4). -- :wq Claudio
Re: webcam fixes and changes in -current
Thank you very much, you made a difference in a teacher's life. Regards Laurence Tratt wrote: > Lots of us have to use webcams more than we used to. There have been > some recent changes in OpenBSD support for webcams that some might > find useful. Most of the hard work was done by Marcus Glocker, with > input from Ingo Feinerer, sc.dying, and myself. > > The first change is that MJPEG in cameras now works reliably. In > essence, most webcams can deliver uncompressed video at a low frame > rate or compressed (MJPEG) at a high frame rate. The latter tickled a > limitation in the USB stack, which led to the picture breaking up -- > and which is now fixed! If you want to know what your camera is > capable of, my suggestion is to install ffmpeg and then run: > > $ ffplay -f v4l2 -list_formats all -i /dev/video0 > > which will output lots of stuff, but at the end has the important > bits: > > [video4linux2,v4l2 @ 0x914fbbb6000] Raw : yuyv422 : > YUYV : 640x480 160x90 160x120 176x144 320x180 320x240 > 352x288 432x240 640x360 800x448 800x600 864x480 960x720 1024x576 > 1280x720 1600x896 1920x1080 2304x1296 2304x1536 [video4linux2,v4l2 @ > 0x914fbbb6000] Compressed: mjpeg :MJPEG : > 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 > 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 > 1920x1080 > > This shows that my C920s webcam has a maximum MJPEG resolution of > 1920x1080. The "raw" options (yuyv422) might look tempting as they > have a max resolution of 2304x1536, but "video -q" shows they can > only achieve low frame rates: > > $ video -q > video device /dev/video: > encodings: yuy2 > frame sizes (width x height, in pixels) and rates (in frames per > second): 160x90: 30, 24, 20, 15, 10, 7, 5 > 160x120: 30, 24, 20, 15, 10, 7, 5 > 176x144: 30, 24, 20, 15, 10, 7, 5 > 320x180: 30, 24, 20, 15, 10, 7, 5 > 320x240: 30, 24, 20, 15, 10, 7, 5 > 352x288: 30, 24, 20, 15, 10, 7, 5 > 432x240: 30, 24, 20, 15, 10, 7, 5 > 640x360: 30, 24, 20, 15, 10, 7, 5 > 640x480: 30, 24, 20, 15, 10, 7, 5 > 800x448: 30, 24, 20, 15, 10, 7, 5 > 800x600: 24, 20, 15, 10, 7, 5 > 864x480: 24, 20, 15, 10, 7, 5 > 960x720: 15, 10, 7, 5 > 1024x576: 15, 10, 7, 5 > 1280x720: 10, 7, 5 > 1600x896: 7, 5 > 1920x1080: 5 > 2304x1296: 2 > 2304x1536: 2 > controls: brightness, contrast, saturation, gain, sharpness, > white_balance_temperature > > As that suggests, video(1) only easily supports YUY2/YUYV422. The > easiest way to see higher frame rates I know of is to use ffmpeg. > Most cameras can sustain 30fps (or sometimes 60fps) at high > resolutions as can be seen with: > > $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i > /dev/video0 > > If you use video chat in a browser, you should find that it can now > reliably support higher resolutions without problems. > > video(1) has also been extended to allow altering webcam controls > from the command-line. In order to do this, nothing else can be using > the webcam; however, the settings are "sticky" so they effect > subsequent programs which use the webcam. I can see the current > settings with: > > $ video -c > brightness=128 > contrast=128 > saturation=128 > gain=0 > sharpness=128 > white_balance_temperature=auto > > and I can reset things back to a known state with: > > $ video -d > > I can change e.g. brightness with: > > $ video brightness=200 > brightness: 128 -> 200 > > Some, though not all, controls have automatic adjustment. If your > webcam has the white_balance_temperature control, it probably > defaults to "auto", meaning that it tries to adjust based on how > yellow/white it thinks the light is. In my experience, the automatic > adjustment ends up making everything look like a Smurfs homage (i.e. > too blue). video(1) allows us to override the automatic setting and > specify a temperature manually (in Kelvin). During the day I might > use: > > $ video white_balance_temperature=5000 > white_balance_temperature: auto -> 5000 > > If you really want, you can use "auto" as a value for such controls > instead of a numeric value. Note further that if you're used to other > operating systems webcam support, you might expect there to be two > white balance temperature controls (one for the manual temperature > and a separate auto boolean): video(1) unifies them. > > You can specify multiple controls at once e.g.: > > $ video brightness=50 white_balance_temperature=3000 > brightness: 128 -> 50 > white_balance_temperature: auto -> 3000 > > Be aware that uvideo doesn't yet support the "camera terminal control > requests" part of the UVC spec so some controls (e.g. zoom, pan, and > exposure) cannot be altered. If and when uvideo gains such support, > the necessary changes to video(1) will be trivial. > > Overall, I think this makes webcams mu
Re: Primepower 250 vs Sunfire v215
On Sun, Sep 20, 2020 at 09:02:55AM +0300, Kihaguru Gathura wrote: > Hi, > > For those who have experience with older Sparc machines, Which hardware > offers better reliability/stability? > > Fujitsu Primepower 250 or Sun fire V215. > Depends mostly on how well they were handled. Also if they are equipped with all the PSUs. I used both for a long time, neither caused me issues. The Primepower is bigger and needs more power but if you find a box with good CPUs and memory it should run faster than a V215. On the other hand the V215 has PCIe slots and so NVMe disks are an option. -- :wq Claudio
Re: Primepower 250 vs Sunfire v215
On Sun, Sep 20, 2020 at 08:00:45PM +0300, Kihaguru Gathura wrote: > > The Primepower is bigger and needs more power but if you find a box with > > good CPUs and memory it should run faster than a V215 > > How did the performance of the PrimePower 250 SCSI drives compare to Sun > Fire V215 SAS drives? Any spinning rust is slow compared to SSD disks. I run my Fire V215 with a NVME disk for the busy partitions (but boot from the SAS drives). This is not really possible with the primepower 250 (hard to find any kind of SSD for that system). -- :wq Claudio
Re: Moving from Bird to OpenBGPD
On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote: > > > On 7/14/19 12:52 AM, Denis Fondras wrote: > > On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote: > > > Hello, > > > > > > My apologies for sending this email multiple times. > > > > > > I was so mortified by Tutanota's awful text formatting that I > > > created a new mail account that supported IMAP so that I could load > > > it up in Thunderbird with text only mode enabled. > > > > > > Once again, my apologies for my rookie mistake choosing Tutanota for > > > use on an international mailing list such as this one. I hope you > > > guys will give me one more chance. > > > > > > My (hopefully) unmangled message is below. > > > > > > > You did not include which version you are running, I'll assume this is > > 6.5. It seems you do not have any filter, OpenBGPD denies everything > > by default. > > > > Thanks for the reply Denis. You were right, I was missing my allow > rules. After setting "allow from any AS 64515" and "allow to any" rules, > everything started working. I was able to get IPv6 working as well > without a hitch. > > Are there any other filter rules I should be setting to secure my BGP > deployment? I'm on a private ASN assigned to me by Vultr. This is my > first forray into BGP land, so any advice or tips would be much > appreciated. Ideally you want to limit the filters to only announce what you really need to announce to prevent leaking of prefixes because of a missconfiguration. Also what is Vultr sending you via BGP? Depending on that you may be able to limit the input as well. I guess in this simple setup it does not matter to have simple allow filters since this bgpd instance is not connected to the default free zone and so there is less risk of leaking or receiving leaked routes. In general if your BGP setup has more than one external neighbor you need to take care of your filters to make sure that you don't leak updates from one neighbor to the other. -- :wq Claudio
Re: Moving from Bird to OpenBGPD
On Mon, Jul 15, 2019 at 11:33:45PM -0700, BSD user wrote:
>
>
> On 7/14/19 11:24 PM, Claudio Jeker wrote:
> > On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote:
> > >
> > >
> > > On 7/14/19 12:52 AM, Denis Fondras wrote:
> > > > On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
> > > > > Hello,
> > > > >
> > > > > My apologies for sending this email multiple times.
> > > > >
> > > > > I was so mortified by Tutanota's awful text formatting that I
> > > > > created a new mail account that supported IMAP so that I could load
> > > > > it up in Thunderbird with text only mode enabled.
> > > > >
> > > > > Once again, my apologies for my rookie mistake choosing Tutanota for
> > > > > use on an international mailing list such as this one. I hope you
> > > > > guys will give me one more chance.
> > > > >
> > > > > My (hopefully) unmangled message is below.
> > > > >
> > > >
> > > > You did not include which version you are running, I'll assume this is
> > > > 6.5. It seems you do not have any filter, OpenBGPD denies everything
> > > > by default.
> > > >
> > >
> > > Thanks for the reply Denis. You were right, I was missing my allow
> > > rules. After setting "allow from any AS 64515" and "allow to any" rules,
> > > everything started working. I was able to get IPv6 working as well
> > > without a hitch.
> > >
> > > Are there any other filter rules I should be setting to secure my BGP
> > > deployment? I'm on a private ASN assigned to me by Vultr. This is my
> > > first forray into BGP land, so any advice or tips would be much
> > > appreciated.
> >
> > Ideally you want to limit the filters to only announce what you really
> > need to announce to prevent leaking of prefixes because of a
> > missconfiguration. Also what is Vultr sending you via BGP? Depending on
> > that you may be able to limit the input as well.
> >
> > I guess in this simple setup it does not matter to have simple allow
> > filters since this bgpd instance is not connected to the default free zone
> > and so there is less risk of leaking or receiving leaked routes. In
> > general if your BGP setup has more than one external neighbor you need to
> > take care of your filters to make sure that you don't leak updates from
> > one neighbor to the other.
> >
>
> Thanks for the reply Claudio!
>
> You were right, my "allow from" rule was unnecessary, Vultr doesn't
> appear to be sending me anything.
>
> I managed to get my "allow to" rule tightened up to look like this:
>
> allow to any prefix {xxx.xxx.xxx.141/32 2001:::::/64}
This rule is perfectly fine.
> I tried tightening the rule down further to restrict to Vultr's upstream
> AS and IP addresses like so:
>
> 'allow to 169.254.169.254 AS 64515 prefix 140.82.0.141/32'
The problem here is that AS 64515 wants to match any part of the ASPATH
for AS 64515. Which is not there and so this rule never matches.
You can write this rule either as:
'allow to 169.254.169.254 prefix xxx.xxx.xxx.141/32'
or
'allow to AS 64515 prefix xxx.xxx.xxx.141/32'
> Unfortunately the rule doesn't work properly as my prefixes immediately
> become unpingable after loading that rule. I'm probably missing
> something obvious. Any suggestions on how to tighten down the rule further?
Normally it is enought to limit the rule to the prefixes you want to
announce. So the first rule is just fine.
> My final question is concerning assigning prefixes to interfaces. Is it
> best practice to assign the addresses to something like 'lo1' loopback
> interface, or should assigning it as an alias on an egress interface
> suffice? I tried and they both seem to work.
That is a bit of a style question. In some cases using lo1 has benefits
(the IP will always be UP which can matter when you have multiple
interfaces). Using it on the only interface out would have the benefit
that you could use a default route that uses the public IP as source IP
for outgoing packets by default. (using 'route add default gateway
-ifa xxx.xxx.xxx.141')
In your case I guess neither matters so you can decide what you like
better.
--
:wq Claudio
Re: Best 1Gbe NIC
On Fri, Aug 02, 2019 at 12:28:58PM +0100, Andy Lemin wrote: > Ahhh, thank you! > > I didn’t realise this had changed and now the drivers are written with > full knowledge of the interface. That is an overstatement but we know for sure a lot more about these cards then many other less open ones. > So that would make Intel Server NICs (i350 for example) some of the best > 1Gbe cards nowadays then? They are well supported by OpenBSD as are many other server nics like bge and bnx. I would not call them best, when it comes to network cards it seems to be a race to the bottom. All chips have stuff in them that is just not great. em(4) for example needs a major workaround because the buffersize is specified by a bitfield. My view is more pessimistic, all network cards are shit there are just some that are less shitty. Also I prefer to use em(4) over most other gigabit cards. -- :wq Claudio > > Sent from a teeny tiny keyboard, so please excuse typos > > > On 2 Aug 2019, at 09:52, Jonathan Gray wrote: > > > >> On Fri, Aug 02, 2019 at 09:19:09AM +0100, Andy Lemin wrote: > >> Hi list, > >> > >> I know this is a rather classic question, but I have searched a lot on > >> this again recently, and I just cannot find any conclusive up to date > >> information? > >> > >> I am looking to buy the best 1Gbe NIC possible for OpenBSD and the only > >> official comments I can find relate to 3COM for ISA, or community > >> consensus towards Chelsio for 10Gbe. > >> > >> I know Intel works ok and I???ve used the i350???s before, but my > >> understanding is that Intel still doesn???t provide the documentation for > >> their NICs and so the emX driver is reverse engineered. > > > > This is incorrect. Intel provides datasheets for Ethernet parts. > > em(4) is derived from Intel authored code for FreeBSD supplied under a > > permissive license. > > > >> > >> And if I remember correctly some offload features were also disabled in > >> the emX driver a while back as some functions where found to be insecure > >> on die and so it was deemed safer to bring the logic back on CPU. > >> > >> So I???m looking for the best 1Gbe NIC that supports the most > >> offloading/best driver support/performance etc. > >> > >> Thanks, Andy. > >> > >> PS; could we update the official supported hardware lists? ;) > >> All the best. > >> > >> > >> Sent from a teeny tiny keyboard, so please excuse typos > >> >
Re: Building Unbound with Python module support
ck example > >>> python plugin as per the source built sphinx docs. > >>> > >>> I’m not at my computer at the moment so can’t share the exact errors, but > >>> thought I’d ask as it feels like I’m missing something obvious! > >>> > >>> Maybe I need some extra build options or static library references to > >>> make it as smooth as the built in Unbound? Or maybe I should be using a > >>> different source? > >>> > >>> Any initial thoughts? I’ll post exact errors as soon as I can. > >> > >> Initial thoughts are "did you use the same configure flags as much as > >> possible > >> as the build in base". Really need to see the errors to be able to make any > >> more detailed suggestions. > >> > >> The default install can't include Python support, because the default > >> install > >> of Unbound is in the base OS, and Python isn't. > >> > >> -- :wq Claudio
Re: missing SYN_RECV in netstat
On Tue, Aug 20, 2019 at 07:36:11PM +0200, Peter J. Philipp wrote: > Hi, > > On the NANOG list there is a thread about something synflooding: > https://mailman.nanog.org/pipermail/nanog/2019-August/102713.html > > Most of my hosts are synflooded, and I was wondering why my OpenBSD > hosts don't show any SYN_RECV states in a netstat -nafinet. I had to tcpdump > to see a synflood happening on port 53 on one of my hosts, have to > still check the other one. Could there be a bad pf rule I'm > using? I suspect this is a worm of sorts or something. > > While not an emergency, it is inconvenient to pick out the synflooders > with tcpdump. Is there any better tools? netstat does not show SYN_RECV states because those are hold in the syncache and need to finish the 3-way handshake before showing up in netstat. I normally use tcpdump to identify synfloods but pfctl -ss will probably show them as well (up to the moment where pf decides to switch to syncookies). -- :wq Claudio
Re: ldapd hangs/stalls
On Wed, Aug 28, 2019 at 03:17:05PM -0400, Allan Streib wrote: > Allan Streib writes: > > > Running a rather busy ldapd host, and seeing some hangs in responses to > > queries. > > > I see that fstat -u _ldapd always ends at FD 119 when the hang occurs: > > [...] > _ldapd ldapd 42641 112* internet stream tcp 0x0 172.16.0.169:389 <-- > 172.16.0.38:44708 > _ldapd ldapd 42641 113* internet stream tcp 0x0 172.16.0.169:389 <-- > 172.16.0.45:43392 > _ldapd ldapd 42641 114* internet stream tcp 0x0 172.16.0.169:389 <-- > 172.16.0.26:54300 > _ldapd ldapd 42641 115* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.100:36250 > _ldapd ldapd 42641 116* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.109:45362 > _ldapd ldapd 42641 117* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.108:47864 > _ldapd ldapd 42641 118* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.104:56746 > _ldapd ldapd 42641 119* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.106:40436 > > > I tried the following: > > Gave _ldapd a login class of "ldap" > > Added to login.conf: > > ldap:\ > :openfiles=512:\ > :tc=daemon: > > restart ldapd. > > Still hangs with fstat output the same. > I guess the problem is in the error handling of one of the filter codes which leaks an fd. At least I suspect that the error message about filter type is suggesting that. -- :wq Claudio
Re: Prometheus node_exporter on OpenBSD - anyone managed ?
On Thu, Sep 19, 2019 at 10:13:23PM +, Travis Cole wrote: > > Looks like they are assuming GNU make. > > > Try doing the build with 'gmake'. > > > If you don't already have gmake installed: > > > # pkg_add gmake > Or just do `pkg_add node_exporter`. While prometheus does not provide a pre-compiled binary OpenBSD does. > On Thu, Sep 19, 2019 at 11:49:20PM +0200, Rachel Roch wrote: > > Hi, > > > > The official Prometheus github repo > > (https://github.com/prometheus/node_exporter) > > <https://github.com/prometheus/node_exporter> appears to suggest in > > multiple places that node_exporter is capable of working on OpenBSD. > > > > But although they provide pre-compiled binaries for multiple platforms > > including NetBSD (https://github.com/prometheus/node_exporter/releases) > > <https://github.com/prometheus/node_exporter/releases> they seemingly don't > > provide a binary for OpenBSD. > > > > So I tried downloading the source and compiling it, but I get a screenful > > of nasty sounding messages, e.g.: > > Bad modifier: , ,$(shell $(GO) env GOPATH))) > > > > Bad modifier: , ,$(shell $(GO) env GOPATH))) > > > > No closing parenthesis in archive specification > > > > *** Parse error: Error in archive specification: "(, \.'))" > > (Makefile.common:41) > > > > *** Parse error: Need an operator in 'else' (Makefile.common:51) > > > > *** Parse error: Need an operator in '' (Makefile.common:54) > > > > *** Parse error: Need an operator in '' (Makefile.common:55) > > > > *** Parse error: Need an operator in 'endif' (Makefile.common:61) > > > > Bad modifier: , ,$(shell go env GOPATH))) > > > > Bad modifier: , ,$(shell go env GOPATH))) > > > > > > Given the popularity of Prometheus, I'm sure someone on-list must be > > actively running it ? > > > > Thanks ! > > > > Rachel > > > -- :wq Claudio
Re: What is the 3rd column in the learned mac address list in ifconfig
On Fri, Sep 20, 2019 at 07:16:15AM +0100, Tom Smyth wrote: > Hi all, hope those of you at eurobsdcon are enjoying your selves > wish I was there > I waswondering what is the 3rd column in the learned mac address list in > the column is a number 0 or 1 after the interface name in > ifconfig bridge x > > ihave highlighted with ** the value i'm interested in > Addresses (max cache: 100, timeout: 240): > 00:17:c8:3e:08:22 em2 *0* flags=0<> This would be the age of the entry. > > ifconfig bridge x > > > bridge0: flags=41 > index 7 llprio 3 > groups: bridge > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto > rstp > em2 flags=3 > port 4 ifpriority 0 ifcost 0 > em1 flags=3 > port 3 ifpriority 0 ifcost 0 > vether0 flags=3 > port 10 ifpriority 0 ifcost 0 > Addresses (max cache: 100, timeout: 240): > 00:17:c8:3e:08:22 em2 0 flags=0<> > 1c:c3:eb:68:05:29 em1 0 flags=0<> > b8:bc:1b:1e:9d:9f em1 0 flags=0<> > 38:f9:d3:47:db:54 em1 1 flags=0<> > 48:bf:6b:e6:27:c2 em1 0 flags=0<> > 74:d4:35:80:51:91 em2 1 flags=0<> > 74:44:01:81:9b:7e em1 0 flags=0<> > > -- > Kindest regards, > Tom Smyth. -- :wq Claudio
Re: Prometheus node_exporter on OpenBSD - anyone managed ?
On Fri, Sep 20, 2019 at 10:36:11AM +0200, Rachel Roch wrote: > Claudio, > > pkg_add node_exporter ? > > I already had a good look at the package list on the FTP mirror and > can't see any node_exporter there ? pkg_add seems to agree with me, it > says "can't find node_exporter" ? > > Certainly pkg_add would be my preferred option, but it seems someone has > forgot poor old node_exporter for recent releases ? node_exporter-0.18.0 is in -current since May. So yes, it has not been in 6.5 or any earlier release. > Regarding the other gmake suggestion, that possibility occurred to me > after sending yesterday's email, but I guess I would have to edit > various source files to make sure its calling the right command. Not > rocket science I guess, but equally could be time consuming to make sure > I've caught all the right spots in the code. -- :wq Claudio > Sep 20, 2019, 05:29 by cje...@diehard.n-r-g.com: > > > On Thu, Sep 19, 2019 at 10:13:23PM +, Travis Cole wrote: > > > >> > >> Looks like they are assuming GNU make. > >> > >> > >> Try doing the build with 'gmake'. > >> > >> > >> If you don't already have gmake installed: > >> > >> > >> # pkg_add gmake > >> > > > > Or just do `pkg_add node_exporter`. While prometheus does not provide > > a pre-compiled binary OpenBSD does. > > > >> On Thu, Sep 19, 2019 at 11:49:20PM +0200, Rachel Roch wrote: > >> > Hi, > >> > > >> > The official Prometheus github repo > >> > (https://github.com/prometheus/node_exporter) > >> > <https://github.com/prometheus/node_exporter> appears to suggest in > >> > multiple places that node_exporter is capable of working on OpenBSD. > >> > > >> > But although they provide pre-compiled binaries for multiple platforms > >> > including NetBSD (https://github.com/prometheus/node_exporter/releases) > >> > <https://github.com/prometheus/node_exporter/releases> they seemingly > >> > don't provide a binary for OpenBSD. > >> > > >> > So I tried downloading the source and compiling it, but I get a > >> > screenful of nasty sounding messages, e.g.: > >> > Bad modifier: , ,$(shell $(GO) env GOPATH))) > >> > > >> > Bad modifier: , ,$(shell $(GO) env GOPATH))) > >> > > >> > No closing parenthesis in archive specification > >> > > >> > *** Parse error: Error in archive specification: "(, \.'))" > >> > (Makefile.common:41) > >> > > >> > *** Parse error: Need an operator in 'else' (Makefile.common:51) > >> > > >> > *** Parse error: Need an operator in '' (Makefile.common:54) > >> > > >> > *** Parse error: Need an operator in '' (Makefile.common:55) > >> > > >> > *** Parse error: Need an operator in 'endif' (Makefile.common:61) > >> > > >> > Bad modifier: , ,$(shell go env GOPATH))) > >> > > >> > Bad modifier: , ,$(shell go env GOPATH))) > >> > > >> > > >> > Given the popularity of Prometheus, I'm sure someone on-list must be > >> > actively running it ? > >> > > >> > Thanks ! > >> > > >> > Rachel > >> > > >> > > > > -- > > :wq Claudio > > >
Re: bgpctl sho ri nei terse output vs man page discrepancy
On Sun, Sep 22, 2019 at 04:48:18PM -, Stuart Henderson wrote: > On 2019-09-22, Rachel Roch wrote: > > Hi, > > > > Hopefully I'm not missing something silly here but I've read the paragraph > > in the man page and it only lists 15 variables: > > > > "The printed numbers are the sent and received open, > > sent and received notifications, sent and received > > updates, sent and received keepalives, and sent and > > received route refresh messages plus the current and > > maximum prefix count, the number of sent and received > > updates, and withdraws." > > > > But bgpctl sho ri nei outputs 16 numbers, not 15 ? > > Sent and recevied updates, sent and received withdraws. > > Unfortunately the peer's name/address is missing, which makes it a bit > tricky to use with "group", though it's not very convenient to change the > output format now .. Better now than later. You could add the name/ip to the end. -- :wq Claudio
Re: bgplg ping/traceroute failed
On Thu, Oct 03, 2019 at 02:07:58PM -0400, Henry Bonath wrote: > Hello Misc, > > I had thought that I had configured the looking glass correctly per the man > page, > I have everything else working correctly, with custom header and footer > with CSS and all works great. > Whenever I attempt to ping/traceroute from the webpage, it simlpy reports: > "failed." > > Here is what permissions look like: (set to 4555, per the man page) > # ls -l /var/www/bin > total 3584 > -r-xr-xr-x 1 root bin 336016 Apr 13 16:35 bgpctl > -r-sr-xr-x 2 www bin 366536 Apr 13 16:35 ping > -r-sr-xr-x 2 www bin 366536 Apr 13 16:35 ping6 > -r-sr-xr-x 2 www bin 325320 Apr 13 16:35 traceroute > -r-sr-xr-x 2 www bin 325320 Apr 13 16:35 traceroute6 The ping* and traceroute* binaries need to be setuid root not setuid www. The root privs are needed to open the raw socket after that privs are dropped. Also check the mail from Theo about nosuid mount option on /var > OpenBSD version is 6.5 amd64. > > Is there anything I am missing that I would need to do in order to make > this work? > Thanks in advance! > -Henry -- :wq Claudio
Re: bgpctl(8) community question
On Mon, Oct 07, 2019 at 04:48:34PM -0500, Adam Thompson wrote: > [OpenBSD 6.5-STABLE, up to date] > > When using bgpctl(8), I'm able to do almost everything I need, but I'm > having trouble figuring out how to do one thing: > > How do I show routes that do NOT have a community (or ext-community, or > large-community) attribute? > > The best I can come up with so far is a fairly ugly AWK script that buffers > the detailed route output, then emits it if it doesn't see a Communities: > line. Am I missing a better way? > > Thanks, > -Adam > > N.B. manually looking through N sets of DFZ route tables isn't going to > happen, I need a mostly-automatic solution. Currently there is no other way to filter on prefixes which don't have a community. You can use the ssv output to make the filtering easier or you tag the prefixes with a different community (first set community on all routes and then delete community again from those where you set the other community). Adding a 'not' option to community matching should be possible. I will look into that after 6.6 is out. -- :wq Claudio
Re: Strong Host Model in OpenBSD network stack
On Fri, Oct 18, 2019 at 07:21:42AM +0200, Remi Locherer wrote: > On Thu, Oct 17, 2019 at 10:33:41PM -0600, Theo de Raadt wrote: > > > Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo > > > replies immediately. > > > > > > On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same > > > behaviour like FreeBSD. No replies anymore, whenever the "wrong" > > > interface was contacted. > > > > How many users set those variables? > > > > A global seems this is a misguided place to establish such a policy. > > > > If it was good and neccessary for everyone on all interfaces and had no > > downsides, they would have turned it on. But they didn't. > > > > A similar feature "urpf-failed" which is more nuanced is available in > > pf.conf, and you can properly use it on a per-interface basis, also > > selecting to do so based un other per-rule options, rather than having > > a 'global rule'. > > > > Something blocked FreeBSD or NetBSD from turning this into the default. > > What was that reason -- was it too damaging? > > > > (I'm going to assume the people with so-called 'strong' views didn't win > > the battle, and the so-called 'weak' view pervailed, probably because > > the 'strong' option created breakage and prevents the dominant > > operational model of Getting-Shit-Done. That's why I ask how many > > people in real life subscribe the 'strong' view by turning on this > > option in FreeBSD/NetBSD. 3 people or is it 2? In my experience, > > everyone is so busy getting on about their lives they don't flip any > > knobs which don't provide an immediately confirmable and neccessary > > value). > > > > from source port source os source to dest port dest > > This rule applies only to packets with the specified source and > > destination addresses and ports. > > > > Addresses can be specified in CIDR notation (matching > > netblocks), > > as symbolic host names, interface names or interface group > > names, > > or as any of the following keywords: > > > > any Any address. > > no-route Any address which is not currently routable. > > route label Any address matching the given route(8) label. > > self Expands to all addresses assigned to all > > interfaces. > >Any address matching the given table. > > urpf-failed Any source address that fails a unicast reverse > > path > > forwarding (URPF) check, i.e. packets coming in on > > an interface other than that which holds the route > > back to the packet's source address. > > > > Convince us we should change to the strong model, and I'll embrace it. > > > > You won't convince us to make a global which people don't understand... > > > > This "strong" model is a bad fit for routers. > > When this model is needed we have pf (antispoof or urpf-failed). > Alternatively rdomains can be used (put a network interface with management > services on it in a separate rdomain). > The BSD systems and IIRC most unix systems have been following the weak host model. As mentioned the weak model has a lot of benefits. I see no point in changing this. -- :wq Claudio
Re: Strong Host Model in OpenBSD network stack
On Thu, Oct 17, 2019 at 09:50:28PM +0200, Bastian Kanbach wrote:
> Hello,
>
> recently I was performing some checks that relate to the "Strong Host
> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
> different than I expected. I always assumed that the network stack of
> OpenBSD was following the "Strong Host Model", but I might be wrong with
> that:
OpenBSD does follow the "Weak Host Model". Has always been like that.
> Basically the Strong Host Model means that the network stack "accepts
> locally destined packets if the destination IP address in the packet
> matches an IP address assigned to the network interface on which the
> packet was received."
>
> FreeBSD and NetBSD have a sysctl property for this, called
> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
> However for OpenBSD I haven't seen such a property at all.
>
>
> Basically my setup consisted of the following virtual machines and
> network interfaces (IP-Forwarding disabled):
>
>
> VM 1 (OpenBSD 6.5):
>
> em0: 192.168.100.1/24 ("Internal Network")
>
> em1: 10.0.0.97/24 ("NAT")
>
>
> VM 2 (Ubuntu Server 18.10):
>
> ens33: 192.168.100.2/24 ("Internal Network")
>
>
>
>
>
> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
> interfaces are associated with the same Virtualbox network, and both IP
> addresses are part of the same /24 subnet.
>
> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
> addresses are part of different subnets and no routes were configured.
>
>
> Then I performed 2 tests:
>
>
> Test 1:
>
> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
> packet was NOT answered by VM1.
>
This is a Layer 2 ARP test. Since 10.0.0.97 is not on that interface arp
will not answer. The host model only matters for Layer 3.
>
> Test 2:
>
> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
> MAC address of interface em0).
>
>
> While the behaviour of Test 1 indicates that the Strong Host Model is
> followed, Test 2 shows the behaviour of a "Weak Host Model".
No, Test 1 is not the right test for the host model.
> What of both is actually supposed to be the default for OpenBSD? Is
> there any kernel parameter to control these behaviours, like
> net.inet.ip.check_interface for FreeBSD or NetBSD?
We don't have a button and just follow the "Weak Host Model".
You can enforce a strong model per interface with pf(4):
block in on !em0 inet to (em0)
or
block in
pass in on em0 to (em0)
pass in on em1 to (em1)
--
:wq Claudio
Re: Requesting vi tips
On Fri, Oct 18, 2019 at 03:12:37PM +0100, cho...@jtan.com wrote:
> OK this has started to get on my nerves now.
>
> I use vi to enter emails despite using evil emacs for development and
> other general editing. Rather than linking them together (they're on
> seperate machines) to enter emails in emacs I'd rather figure out
> something interesting about vi.
>
> At the moment I limit lines to 72 characters through a laborious process
> of finding the appropriate space character myself and replacing it with
> a ^M. Obviously nonsense which is why I sometimes don't bother. (Sorry).
>
> I know about fmt and could easily concoct the pipeline to format each
> paragraph but I wonder if there's something that can correctly parse the
> whole email and format the entire thing en masse without me writing what
> would undoubtedly be Yet Another Poor Implementation.
>
> Alternatively is there something that would make vi do it on the fly, or
> something akin to emacs' C-q or vim's gq. Although I appreciate the fact
> that vi doesn't try to be clever.
>
set wl=72 will limit the line lenght to around 72. Additionally you
can use !fmt with movement chars to reformat sections. I use !{fmt
or {!}fmt frequently to reformat the paragraph I'm in.
--
:wq Claudio
Re: Does net.mpls.maxloop_inkernel do anything?
On Thu, Oct 24, 2019 at 12:01:35PM +0100, Thomas Habets wrote: > $ cd /usr/src/sys > $ grep mpls_inkloop -r . > ./netmpls/mpls.h: &mpls_inkloop, \ > ./netmpls/mpls.h:extern int mpls_inkloop; > ./netmpls/mpls_raw.c:int mpls_inkloop = MPLS_INKERNEL_LOOP_MAX; > $ grep -r MPLSCTL_MAXINKLOOP . > ./netmpls/mpls.h:#defineMPLSCTL_MAXINKLOOP 4 > > Looks like last users of this variable were removed in 2015: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/netmpls/mpls_input.c.diff?r1=1.51&r2=1.52&f=h > > So should this sysctl be retired, or is there an indirect accessor path I > did not find? Yes, I agree this is dead and could be GC-ed. -- :wq Claudio
Re: LDAP tls: handshake failure
On Thu, Oct 24, 2019 at 02:06:47PM +0200, Martijn van Duren wrote:
> On 10/24/19 1:50 PM, Robert Klein wrote:
> > Hi,
> >
> >
> >
> > On Thu, 24 Oct 2019 05:26:49 +0200,
> > Predrag Punosevac wrote:
> >>
> >> Kapetanakis Giannis wrote:
> >>
> >>> On 23/10/2019 19:14, Predrag Punosevac wrote:
> >>>> Hi Misc,
> >>>>
> >>>> I just upgraded a LDAP server from 6.5 to 6.6 running authorization and
> >>>> authentication services for a 100 some member university research group.
> >>>> It appears TLS handshake is broken. This worked perfectly on 6.5 and
> >>>> earlier.
> >>>>
> >
> > [ rest deleted ]
> >
> >> I am out of fuel to look more this tonight but I am 99% sure something
> >> have changed on 6.6 which broke the things. Maybe my configuration was
> >> wrong all along and in 6.6 few screws got tighten up which bit me for my
> >> rear end. I would appreciate any further commend or suggestions how to
> >> debug this. I would also appreciate any reports of fully working ldapd
> >> on 6.6 release
> >>
> >> Best,
> >> Predrag
> >>
> >
> > This is related to commit “Make sure that ber in ber_scanf_elements is
> > not NULL before parsing format” (martijn@) and caused by the scan string
> > used by ber_scanf_elements on line 310 in ldape.c
>
> Thanks for looking into this. I didn't found the time yet.
> >
> > Regarding the commit, see also emails with subject “ber.c: Don't
> > continue on nonexistent ber” to tech@ on August, 13.
> >
> > When you set scan string for ber_scanf_elements in line 310 of ldape.c
> > from "{se" to "{s" it works again. Patch below.
> >
> > When you look at the ldap_extended function on ldape.c, you see ext_val
> > is assigned to req_op in line 314. The only use could happen in the
> > extended_ops[i]fn(req) call in line 318. This currently can only be a
> > call to ldap_starttls (beginning at line 285, same file) which doesn't
> > use req_op either. So it the `e' shouldn't matter.
> >
> > At a guess, this also conforms to RFC4511, section 4.14.1.
>
> Glancing over the RFC seems that you are correct.
> >
> > If ldap_extended is extended to handle other operations than starttls,
> > care must be taken for an optional additional octet string in the
> > request (see definition of extended request in RFC4511, section 4.12).
>
> Diff below should handle this. Also, you forgot to remove the ext_val.
> >
> >
> > Best regards
> > Robert
> >
> martijn@
>
> Index: ldape.c
> ===
> RCS file: /cvs/src/usr.sbin/ldapd/ldape.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 ldape.c
> --- ldape.c 28 Jun 2019 13:32:48 - 1.31
> +++ ldape.c 24 Oct 2019 12:05:19 -
> @@ -298,7 +298,6 @@ ldap_extended(struct request *req)
> {
> int i, rc = LDAP_PROTOCOL_ERROR;
> char*oid = NULL;
> - struct ber_element *ext_val = NULL;
> struct {
> const char *oid;
> int (*fn)(struct request *);
> @@ -307,11 +306,11 @@ ldap_extended(struct request *req)
> { NULL }
> };
>
> - if (ber_scanf_elements(req->op, "{se", &oid, &ext_val) != 0)
> + if (ber_scanf_elements(req->op, "{s", &oid) != 0)
> goto done;
>
> log_debug("got extended operation %s", oid);
> - req->op = ext_val;
> + req->op = req->op->be_sub->be_next;
>
> for (i = 0; extended_ops[i].oid != NULL; i++) {
> if (strcmp(oid, extended_ops[i].oid) == 0) {
OK claudio@
--
:wq Claudio
Re: random packet drops with syncookies/synproxy
On Sat, Nov 09, 2019 at 01:30:32PM +0100, Markus Wernig wrote: > Hm, also no replies to that one :-) > > On 11/6/19 8:15 PM, Markus Wernig wrote: > > > So just to make sure: Is anybody using syncookies and/or synproxy in > > production in a similar setup? > > So nobody is using syncookies/synproxy at all? I guess that is a reasonably safe assumption. syncookies are rather new and probably need more battle testing. synproxy never helped me much in case of a SYN attack since it will cause pf(4) to hit the state limit no matter what you do and then stuff starts to break. -- :wq Claudio
Re: route an IPv4 /32 to a different interface
On Sun, Dec 15, 2019 at 08:57:48PM +0100, Denis Fondras wrote: > Hi, > > I have this setup : > > em3: flags=8843 mtu 1500 > lladdr > index 4 priority 0 llprio 3 > media: Ethernet autoselect (1000baseSX full-duplex) > status: active > inet6 fe80::aa9:b803:8a7a:ca72%em3 prefixlen 64 scopeid 0x4 > inet 172.16.0.254 netmask 0xff00 broadcast 172.16.0.255 > em4: flags=8843 mtu 1500 > lladdr > index 5 priority 0 llprio 3 > media: Ethernet autoselect (1000baseSX full-duplex) > status: active > inet 172.16.0.249 netmask 0xfffc broadcast 172.16.0.251 > inet6 fe80::29ae:98d:f238:fd68%em4 prefixlen 64 scopeid 0x5 > > I have a computer with IPv4 address 172.16.0.248 connected to em3. > When I try to ping it, obviously it goes to em4. > > How can I route 172.16.0.248 through em3 ? > > I tried with : > * route add 172.16.0.248/32 172.16.0.254 -iface em3 > * route add 172.16.0.248/32 -llinfo -link -static -iface em3 > but without luck. > You have overlapping networks and you try to add an IP from the more specific into the less specific block. That is going to be tricky and it will most probably not work in all cases (e.g. hosts on the more specific network would not be able to talk to that IP). While it may be possible to coerce the routing table into doing the right thing it will probably not work well. One way to work around this is using rdomains another is renumbering the network. -- :wq Claudio
Re: Readv and writev failing across ethernet
On Mon, Dec 23, 2019 at 08:17:37AM -0800, Philip Guenther wrote: > On Mon, Dec 23, 2019 at 5:04 AM Raymond, David > wrote: > > > The "timeout" error was numerically 60. Curiously, boards with RTL > > 8111GR chips did not produce these errors, but those with RTL 8111H > > chips did. Unfortunately, this chipset seems to be in a lot of newer > > motherboards. > > > > I didn't use ktrace/kdump. The openmpi software returned the error > > presented by readv/writev. > > > > It sounds like the simplest solution at this point is to try > > non-Realtek pcie network cards. Any suggestions? How are Intel or > > Broadcom cards? > > > > At this point I think you're clearly in the "device driver is buggy" > situation. If this device has an in-tree driver (and not something you're > compiling locally into your kernel) then you should start a new thread > starting with a dmesg and a clear description of the involved hardware. I don't know what OpenMP uses for communication but re(4) does not return errno 60 (ETIMEDOUT). So it seems like it is something else. Also 8111G and 8111H are treated the same way in our re(4) driver. -- :wq Claudio
Re: The OpenBSD talk at 36c3
On Sun, Dec 29, 2019 at 01:29:12PM +0100, Henry Jensen wrote:
> Greetings,
>
> for those who didn't watched it, there is an accompanied site at
> https://isopenbsdsecu.re/
>
> Summary: There are a lot of claims. The speaker basically said, that
> some mitigations are "cool", but other, more or less, useless.
>
> Further accusations are, that OpenBSD still uses e-mail and cvs and not
> more advanced CI tools.
>
> I can't say anything to the more technical claims about useless
> mitigations, since I am not a OS developer. Is there going to be a
> response from the OpenBSD team?
>
One thing that everyone can check is the claim that 50% of our commit
messages are less than 10 chars long and 75% are less than 20 chars.
Using the git repo you can run something like this and get the numbers
yourself.
openbsd-git> git log --log-size --format="%B" | grep '^log size ' | cut -f
3 -d ' ' | awk '{ t++; if ($1 <= 10) s++; if ($1 <= 20) m++; else l++; }
END { print s " <= 10 char"; print m " <= 20 char"; print l " rest"; print
t " total" }'
12386 <= 10 char
25894 <= 20 char
176304 rest
202198 total
Sorry but 25k is no where close to 75% of 202198.
Seems he did count words not characters.
--
:wq Claudio
Re: tap(4) performance tuning on (amd64)
On Fri, Jan 10, 2020 at 01:00:49PM +, Tom Smyth wrote:
> Hi lads,
>
> I have been doing some testing with tap(4) and openvpn (standard ssl )
> I have been using openvpn with tap and I have been trying with null
> encryption. null authentication,
> the performance of the tap interface seems to be about 100-150Mb/s on a
> system
> which can give 3Gb/s-5Gb/s on ix(4) interfaces in Bridge mode and
> 4-8Gb/s on tpmr mode
> I was wondering is there a sysctl setting that if modified would
> improve the tap interface performance.
> I have tried with tpmr(4) and bridge(4)
>
> is there a simple way testing a tap(4) interface throughput /
> performance without Openvpn process
>
> I can try mlvpn and wireguard
> but I would love if there was a trick where I can just test the tap(4)
> interface with something like pair(4)...
>
> ix0---bridge0--tap0---someprocess--tap1-bridge1--ix1
> or
> ix0--tpmr0--tap0--someprocess--tap1-tpmr1-ix1
>
> is there a simple "someprocess" that would provide forwarding packets
> between tap0 and tap1 in userland
> so that any performance testing on tap(4) interfaces does not have the
> distractions of complex userland programs with encryption /
> encapsulation overheads
>
I just wrote a simple tun/tap bridge for testing so here you go.
Compile it with 'cc -Wall -o tbridge tbridge.c -lpthread' and run it
with 'tbridge -k /dev/tun0 /dev/tun1' to wire tun0 and tun1 together.
You can select between, select(2), poll(2), kqueue(2) and pthreads as the
way on how to multiplex the reads.
For me the code triggers scheduler inefficencies and causes packets drops
on the output queue when there are multiple packet producers.
--
:wq Claudio
/*
* Copyright (c) 2020 Claudio Jeker
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
volatile sig_atomic_tquit;
static void
do_read(int in, int out)
{
char buf[2048];
ssize_t n, o;
n = read(in, buf, sizeof(buf));
if (n == -1)
err(1, "read");
o = write(out, buf, n);
if (o == -1)
err(1, "read");
if (o != n)
errx(1, "short write");
}
static void
do_poll(int fd[2])
{
struct pollfd pfd[2];
int n, i;
while (quit == 0) {
memset(pfd, 0, sizeof(pfd));
pfd[0].fd = fd[0];
pfd[0].events = POLLIN;
pfd[1].fd = fd[1];
pfd[1].events = POLLIN;
n = poll(pfd, 2, INFTIM);
if (n == -1)
err(1, "poll");
if (n == 0)
errx(1, "poll: timeout");
for (i = 0; i < 2; i++) {
if (pfd[i].revents & POLLIN)
do_read(fd[i], fd[(i + 1) & 0x1]);
else if (pfd[i].revents & (POLLHUP | POLLERR))
errx(1, "fd %d revents %x", i, pfd[i].revents);
}
}
}
static void
do_select(int fd[2])
{
fd_set readfds;
int n, i, maxfd = -1;
while (quit == 0) {
FD_ZERO(&readfds);
for (i = 0; i < 2; i++) {
if (fd[i] > maxfd)
maxfd = fd[i];
FD_SET(fd[i], &readfds);
}
n = select(maxfd + 1, &readfds, NULL, NULL, NULL);
if (n == -1)
err(1, "select");
if (n == 0)
errx(1, "select: timeout");
for (i = 0; i < 2; i++) {
if (FD_ISSET(fd[i], &readfds))
do_read(fd[i], fd[(i + 1) & 0x1]);
}
}
}
static void
do_kqueue(int fd[2])
{
struct kevent kev[2];
int kq, i, n;
if ((kq = kqueue()) == -1)
err(1, "kqueue");
mem
Re: tap(4) performance tuning on (amd64)
On Tue, Jan 21, 2020 at 02:44:35AM +, Tom Smyth wrote:
> Claudio,
> Thanks for this,
> I compiled it on Openbsd 6.6 (stable) amd64
>
> it compiled without error
>
> the binary seems to run fine but,
> ./tbridge -k /dev/tap0 /dev/tap1
>
> runs and displays the usage message and gives an errorlevel of 1
> every time use the -k or -t or -s or -p arguments see terminal
> conversation below
>
Shit, I added a last minute check and as usual introduced a bug.
Line 189 change if (ch != 0) to if (mode != 0)
--
:wq Claudio
/*
* Copyright (c) 2020 Claudio Jeker
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
volatile sig_atomic_tquit;
static void
do_read(int in, int out)
{
char buf[2048];
ssize_t n, o;
n = read(in, buf, sizeof(buf));
if (n == -1)
err(1, "read");
o = write(out, buf, n);
if (o == -1)
err(1, "read");
if (o != n)
errx(1, "short write");
}
static void
do_poll(int fd[2])
{
struct pollfd pfd[2];
int n, i;
while (quit == 0) {
memset(pfd, 0, sizeof(pfd));
pfd[0].fd = fd[0];
pfd[0].events = POLLIN;
pfd[1].fd = fd[1];
pfd[1].events = POLLIN;
n = poll(pfd, 2, INFTIM);
if (n == -1)
err(1, "poll");
if (n == 0)
errx(1, "poll: timeout");
for (i = 0; i < 2; i++) {
if (pfd[i].revents & POLLIN)
do_read(fd[i], fd[(i + 1) & 0x1]);
else if (pfd[i].revents & (POLLHUP | POLLERR))
errx(1, "fd %d revents %x", i, pfd[i].revents);
}
}
}
static void
do_select(int fd[2])
{
fd_set readfds;
int n, i, maxfd = -1;
while (quit == 0) {
FD_ZERO(&readfds);
for (i = 0; i < 2; i++) {
if (fd[i] > maxfd)
maxfd = fd[i];
FD_SET(fd[i], &readfds);
}
n = select(maxfd + 1, &readfds, NULL, NULL, NULL);
if (n == -1)
err(1, "select");
if (n == 0)
errx(1, "select: timeout");
for (i = 0; i < 2; i++) {
if (FD_ISSET(fd[i], &readfds))
do_read(fd[i], fd[(i + 1) & 0x1]);
}
}
}
static void
do_kqueue(int fd[2])
{
struct kevent kev[2];
int kq, i, n;
if ((kq = kqueue()) == -1)
err(1, "kqueue");
memset(kev, 0, sizeof(kev));
for (i = 0; i < 2; i++) {
EV_SET(&kev[i], fd[i], EVFILT_READ, EV_ADD | EV_ENABLE,
0, 0, (void *)(intptr_t)i);
}
if (kevent(kq, kev, 2, NULL, 0, NULL) == -1)
err(1, "kevent register");
while (quit == 0) {
n = kevent(kq, NULL, 0, kev, 2, NULL);
if (n == -1)
err(1, "kevent");
if (n == 0)
errx(1, "kevent: timeout");
for (i = 0; i < n; i++) {
if (kev[i].flags & EV_ERROR)
errc(1, kev[i].data, "kevent EV_ERROR");
if (kev[i].filter == EVFILT_READ) {
int r = (int)kev[i].udata;
do_read(fd[r], fd[(r + 1) & 0x1]);
}
}
}
}
static void *
run_thread(void *arg)
{
int *fd = arg;
while (quit == 0)
do_read(fd[0], fd[1]);
return NULL;
}
static void
do_thread(int fd[2])
{
pthread_t tid;
int ret;
ret
Re: Fwd: tap(4) performance tuning on (amd64)
On Tue, Jan 21, 2020 at 09:17:20PM +, Tom Smyth wrote: > in testing tap(4) performance on the same box with the following config > using claudios userlandbridge (tbridge) in between two tap interfaces > each tap was also added their own standard bridge(4) along with 1 physical > interface. > > iperf3client--ix0--bridge0--tap0--tbridge--tap1--bridge1--ix1---iperf3svr > > with a 1socket 2 core system that gives 3Gb/s we got the following > performance > > tbridge -t gave 557Mb/s TCP throughput > > btw (tbridge -t did not stop after using ^C or kill > but did respond to kill -s SIGKILL ) I forgot to mark the signals to interrupt read instead of restart. So you need another packet to arrive to exit the loop. You can add siginterrupt(SIGTERM, 1); siginterrupt(SIGINT, 1); siginterrupt(SIGHUP, 1); before the signal() calls to install the signal handler and then ^C will work. > tbridge -s gave 455Mb/s TCP throughput > > tbridge -p gave 448Mb/s TCP throughput > > tbridge -k gave 458mb/s TCP througput > > im going to try this again with more CPUs as the workload of forwarding in > this box involves 3 bridges in series. > > I will also try with the tpmr(4) driver > so something about OpenVPN has a bottleneck that reduces performance > by a factor of 3 -4x > Surprised by the 20% better performance of the threaded version. I wonder if the single threaded version max out the performance of a single CPU. My tests running tcpbench just between two interfaces show no measurable performance difference between the different modes (for either tun or tap). -- :wq Claudio
Re: ahci issue corebooted X220 does not recognise usb or stata
On Wed, Feb 19, 2020 at 02:34:40PM +0100, Thomas Meulendijks wrote: > Hi OpenBSD Mailing list, > > I am trying to install Openbsd via the install66.fs on a Thinkpad X220 > [amd64] with coreboot. > I have the problem that it does not recognize any USB or SATA device may it > be storage or peripherals like a keyboard, except for the boot USB. > I tried with external USB storage, multiple different internal SSD's, > multiple USB keyboards, but sysctl does not show anything and dmesg does not > give a message when plugged in or out. > I also tried with the grub and seabios payloads but it did not make a > difference. > Coreboot and payloads are compiled at master and agenst the latest stable > version but it did not make a difference. > coreboot Master version is 4.11-1189. > > When I look at dmesg I see ahci failed, I know you guys will need to see my > dmesg but since I can't save it to a drive [read problem above] > and the installation fs only has ftp to communicate to the web as far as I > can see and I don't know how to set up a ftp server, I am at a loss of how to > get it out. > Maybe I am missing something? The Thinkpad X220 works with its original BIOS so the problem is with your coreboot and not with OpenBSD. coreboot fails to properly report something (most probably some of the ACPI or SMBIOS information is wrong) and because of that every PCI access seems to fail. Most probably pci0 is not setup correctly. We can't help you here, you changed your BIOS with something that is not quite right. You should reach out to coreboot. > A part of dmesg I think may be helpful that I typed over: > > > em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msiem0: The EEPROM > Checksum Is Not Valid > em0: Unable to initialize the hardware > ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apci 2 int 19 > ehci0: reset timeout > ehci0 init failed, error=13 > > ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apci 2 int 18 > ehci1: reset timeout > ehci1 init failed, error=13 > "Intel QM67 LPC" rev 0x05 at pci0 dev 31 function 0 not configured > ahci0 at pci0 dev 31 function 2 "Intel 6 Series AHCI" rev 0x05: msi, unable > to reset controller > "Intel 6 Series SMBus" rev 0x05 at pci0 dev 31 function 3 not configured > "Intel 6 Series Thermal" rev 0x05 at pci0 dev 31 function 6 not configured > > > I hope this is enough info and would greatly appreciate it if anyone could > help me out! > > Greetings, > > Thomas > -- :wq Claudio
Re: size of size_t (diff angle)
This has not much to do with OpenBSD.
As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
Any other type of machine that is not covered by these two types will
not run OpenBSD.
In both cases size_t is defined as unsigned long which is the same as
uintptr_t and the same size as pointer.
Now if SIZE_MAX is the highest address is a different thing.
On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
it covers actually more then what is possible). The highest valid
address is in most cases less than SIZE_MAX.
--
:wq Claudio
On Thu, Feb 27, 2020 at 01:36:39AM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Marc Espie" wrote:
> >>> You're looking at the wrong type. size_t is very good for what it does.
> >>
> >> Yes; meproblem is with the 'what it does' part.
> >
> > It represents memory sizes. It works on anything with a sane
> > memory model.
>
> The way meunderstands it, it's just an offset, plain and simple. Which
> on a sane machine is indeed of the same type as an address[0].
>
> Unfortunately, C99 does not appear to reflect that. Now, to what degree
> (if!) we should respect C99, or take it much seriously at all, is
> another matter...
>
> >>> Try uintptr_t
> >>
> >> Are you proposing a change to struct iovec?
> >
> > Why should I ? readv works with sizes, so size_t is adequate.
>
> Yes, why should you? That was me implied question. You told me to use
> uintptr_t, but that will hardly solve things on the exact problem mewas
> working on (medidn't specify what it was, and you didn't ask), unless we
> change struct iovec (cue an 'over my dead body' response from theo, and
> with respect to compat, he'd be damn right).
>
> > You were mentionning caddr_t earlier. intptr_t and uintptr_t are
> > the adequate types for working with addresses. size_t is the adequate
> > family for working with sizes.
>
> Me's found that such statements emerge from a shallow understanding of
> the nature of C. C doesn't know sizes: indeed, it barely knows indices
> and offsets. If sizeof() would have been defined to return the index
> of the final byte, instead of the count of bytes, then the C99
> definition for size_t would've been pre-empted.
>
> > POSIX kind-of implies readv, which means that both realms tend of
> > mesh.
>
> Yes, that's an obvious layer error. C as a language should not be
> confused with libc, or UNIX in general. In fact, C and UNIX appear to
> only have two concrete things in common: ASCII, and the byte as the
> fundamental type. That's it.
>
> > If you're on something where they don't, you're fucked.
>
> Me's never been the type to play it safe. The path forward is not blind
> obedience to the ravings of committees, especially those that pretend to
> set a universal standard.
>
> > Good luck.
>
> Thanks. Me's decided to ditch the {read,write}v compat wrappers and take
> the performance hit. It's all preperation for a real OS, after all:
> me'll do it right in there.
>
> > What are you doing asking questions on an OpenBSD list, btw ?
>
> nnx runs on OpenBSD. You must be confusing it with NetNIX, which is the
> OS that will eventually emerge.
>
> NetNIX will not have size_t.
>
> Baai,
>
> --zeurkous.
>
> [0] Except, of course, it's an 'offset + 1'. Oops. But that's the least
> of the problems if SIZE_MAX is not guaranteed to be the highest
> address...
>
> --
> Friggin' Machines!
>
Re: size of size_t (diff angle)
On Thu, Feb 27, 2020 at 02:07:36PM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Claudio Jeker" wrote:
> > This has not much to do with OpenBSD.
>
> On the contrary: these issues touch the fundaments of UNIX programming.
>
> > As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
> > Any other type of machine that is not covered by these two types will
> > not run OpenBSD.
>
> Oh yes, this is not NetBSD, me's well aware... And yet, metries hard to
> satisfy basic portability when feasible. This is consistent with OpenBSD
> practice, at least if the manual pages are anything to go by.
>
> > In both cases size_t is defined as unsigned long which is the same as
> > uintptr_t and the same size as pointer.
>
> Of course, in practice that's the case. You'll really get no argument
> from me there.
>
> > Now if SIZE_MAX is the highest address is a different thing.
> > On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
> > it covers actually more then what is possible). The highest valid
> > address is in most cases less than SIZE_MAX.
>
> Yes, the {,in}famous halfway split... for calculations involving
> already valid {addresse,offset,size}s that hardly matters, however.
>
> What *does* matter, is the potential lack of equivalence of the types.
> Which, as you pointed out, does not affect OpenBSD (at this time), yet
> might be a portability issue. Hence me raising it.
The times of non ILP32 or I32LP64 UNIX systems is over (at least when it
comes to userland processes). If you want a UNIX-like OS where code will
work then those are your only options. The ecosystem is not able to handle
anything else anymore. All the other discussions are theortical and will
not result in anything that is usable to run UNIX software.
--
:wq Claudio
Re: rdomain 0 and dafault route
On Tue, Oct 06, 2015 at 06:49:29AM +0200, Holger Glaess wrote: > hi > > just a simple question > > how can i setup an kind of "default route" in rdomain 0 > to , for example , rdomain 2. > > i have 3 rdomain > > the default one > one with the internet connection ( rdomain 1 ) > one for my wlan ( rdomain 2 ) > > the routing between wlan to internet is still working( test "route -n -T 2 > exec ping 8.8.8.8" ), > but if use the wlan client my local ( forward ) dns server in rdomain 0 > he diden't got an anser as result that the dns server can not reach > any externel dns server. You need to use pf to move packets between rdomains. Look for the rtable keyword. -- :wq Claudio
Re: rdomain 0 and dafault route
On Tue, Oct 06, 2015 at 08:58:24AM +0200, Holger Glaess wrote: > hi > > > On Tue, Oct 06, 2015 at 06:49:29AM +0200, Holger Glaess wrote: > >> hi > >> > >> just a simple question > >> > >> how can i setup an kind of "default route" in rdomain 0 > >> to , for example , rdomain 2. > >> > >> i have 3 rdomain > >> > >> the default one > >> one with the internet connection ( rdomain 1 ) > >> one for my wlan ( rdomain 2 ) > >> > >> the routing between wlan to internet is still working( test "route -n -T > >> 2 > >> exec ping 8.8.8.8" ), > >> but if use the wlan client my local ( forward ) dns server in rdomain 0 > >> he diden't got an anser as result that the dns server can not reach > >> any externel dns server. > > > > You need to use pf to move packets between rdomains. Look for the rtable > > keyword. > > > > i try somthing like that for rdomain 0 ( lan_if ) > > pass out on lan_if from any to any rtable 2 ( internet ) nat-to (pppoe0) > or > pass out rdomain from any to any rtable 2 nat-to (pppoe0) > > same with "in" because an simple ping to 8.8.8.8 in ( or on ? ) rdomain 0 > ( direct on the router ) is no working. > > there is no default route at rdomain 0 > You going to need a default route (can point to loopback) because routing decisions are done before pf can move the packet. -- :wq Claudio
Re: bgpd+ospfd configuration question
On Tue, Oct 20, 2015 at 11:07:12AM -0400, John E.P. Hynes wrote:
> Hi list,
>
> I've read through the docs and Claudio's guide, but something isn't
> clear to me I'm hoping to get some direction on:
>
> I am about to multihome. My uplinks to my ISPs terminate on different
> OpenBSD routers. The class C network behind them includes one internal
> OpenBSD gateway performing NAT for connections leaving the internal
> private network.
>
> My understanding is that I would configure OpenBGPD on the two border
> routers with iBGP between them, like this:
>
> /etc/bgpd.conf
>
> # Global Config
> AS MyASN
> router-id 1.2.3.4
>
> # Announce Our Network Space
> network 1.2.3/24
>
> # Neighbor Config
> neighbor 9.8.7.6 {
> descr "My ISP 1"
> remote-as TheirASN
> }
>
> # iBGP
> group IBGP {
> remote-as MyASN
> neighbor 1.2.3.5 {
> descr "MyOtherBorderGateway"
> }
> }
>
> ...Essentially, since no host in my public network would be aware of
> which border gateway to leave through, I need an IGP such as OpenOSPFd
> as well. Something like this on the border gateways:
>
> /etc/ospfd.conf
>
> # Global Config
> router-id 0.0.0.1
> redistribute connected
>
> # Areas
> area 0.0.0.0 {
> auth-type crypt
> auth-md 1 "SomePW"
> auth-md 2 "SomeDifferentPW"
> auth-md-keyid 1
>
> # Main Link (DMZ)
> interface em1
> }
>
> ...and then something like this on all hosts on my public network,
> including the NAT firewall:
>
> /etc/ospfd.conf
>
> # Global Config
> router-id 0.0.0.3
>
> # Areas
> area 0.0.0.0 {
> auth-type crypt
> auth-md 1 "SomePW"
> auth-md 2 "SomeDifferentPW"
> auth-md-keyid 1
>
> # Main Link (DMZ)
> interface em1
> }
>
>
> My questions are:
>
> 1) Claudio's guide suggests to me that iBGP needs to be run on the NAT
> firewall as well, but I don't understand *why* that would be necessary
> and I think I'm mis-reading it. Clarification please?
By running BGP on the internal FW allows you to send out the traffic to
the correct broder router and so you get better control over which path
you reach the internet.
> 2) Do I really want "redistribute connected" in the ospfd.conf on the
> border routers, or "redistribute default"?
>
If you feed the BGP table to your FW than you most probably need
redistribute connected. In such a simple setup as yours you can also skip
using OSPF and just use "set nexthop self" in bgpd since all your routers
& firewalls are directly connected.
In short the IGP (OSPF) is required for incoming traffic to find its
destination in your network whereas iBGP is required to take the optimal
way out of your network.
--
:wq Claudio
Re: apache 2.4 - Missing mod_cgid.so?
On Fri, Oct 23, 2015 at 07:20:43PM +0200, Alessandro DE LAURENZIS wrote:
> Dear misc@ reader,
>
> I've just upgraded my home server to 5.8, so I switched to apache 2.4
> (from 2.2); the problem is that my git server no longer works and the
> root cause seems to be that httpd2 with my current configuration (see [0])
> isn't able to run any cgi scripts.
>
> I noticed that the module mod_cgid.so (which, in my very limited
> understanding, should supersede the old mod_cgi.so when threaded MPM is
> used) is missing in /usr/local/lib/apache2 - Could it be the culprit?
>
> Any hints? Am I doing something very stupid?
>
> I would be glad to give further details, but please point me in the
> right direction, because I'm a bit lost.
>
You may try to build your own version with adding --enable-cgi in the
Makefile configure flags. It seems that even configure tells that
--enable-cgi is the default it seems it is not. Go figure...
Also mod_cgid.so should be built but seems to be missing. mod_cgid.so is
the module that should be used with the worker or event MPM.
So maybe try something like this diff.
--
:wq Claudio
Index: Makefile
===
RCS file: /cvs/ports/www/apache-httpd/Makefile,v
retrieving revision 1.67
diff -u -p -r1.67 Makefile
--- Makefile13 Sep 2015 12:37:49 - 1.67
+++ Makefile23 Oct 2015 20:15:37 -
@@ -65,6 +65,7 @@ CONFIGURE_ARGS= --enable-layout=OpenBSD
--enable-disk-cache \
--enable-proxy=shared \
--enable-mods-shared=all \
+ --enable-cgi \
--enable-suexec \
--with-suexec-caller=www \
--with-suexec-bin=${TRUEPREFIX}/sbin/suexec2 \
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/www/apache-httpd/pkg/PLIST-main,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST-main
--- pkg/PLIST-main 13 Sep 2015 12:37:49 - 1.6
+++ pkg/PLIST-main 23 Oct 2015 20:33:37 -
@@ -98,7 +98,8 @@ lib/apache2/mod_buffer.so
lib/apache2/mod_cache.so
lib/apache2/mod_cache_disk.so
lib/apache2/mod_cache_socache.so
-@comment lib/apache2/mod_cgid.so
+lib/apache2/mod_cgi.so
+lib/apache2/mod_cgid.so
lib/apache2/mod_charset_lite.so
lib/apache2/mod_data.so
lib/apache2/mod_dav.so
Re: OpenBGPd on OpenBSD 5.8 crashing during startup
On Wed, Nov 25, 2015 at 05:08:27PM +0100, Thorleif Wiik [BCIX] wrote:
> Hi,
>
> OpenBGPd on OpenBSD 5.8 (with all patches applied) is crashing during
> startup.
>
> On a second box with 5.7 and the same hardware/configuration there are no
> problems.
> OpenBGPd is configured as route-server with 118 v4/v6 peers and about 35300
> IPv4
> and 14800 IPv6 routes.
>
>
> Any tips for configuration changes to prevent this on 5.8?
Something in the session engine corrupted some memory, now the question is
what. Is it possible to get a backtrace of the session engine?
See sysctl(8) at the bottom on how to use kern.nosuidcoredump=3 to get a
core file.
Wonder if the SE is printing something before it explodes. Is it possible
to get more of the log?
The poll fd errors are a red herring because this is a case where errno is
not previously set and so it should not print it. See diff at the end of
this mail.
> Nov 25 13:41:41 route-server bgpd[22856]: startup
> Nov 25 13:41:41 route-server bgpd[22856]: rereading config
> Nov 25 13:41:41 route-server bgpd[30006]: route decision engine ready
> Nov 25 13:43:34 route-server bgpd[30006]: RDE reconfigured
>
> .. many many prefixes
>
> Nov 25 13:45:45 route-server bgpd[30006]: handle_pollfd: poll fd: No buffer
> space available
> Nov 25 13:45:45 route-server bgpd[30006]: RDE: Lost connection to SE
> Nov 25 13:45:46 route-server bgpd[30006]: handle_pollfd: poll fd: No buffer
> space available
> Nov 25 13:45:46 route-server bgpd[30006]: RDE: Lost connection to SE control
> Nov 25 13:45:46 route-server bgpd[22856]: handle_pollfd: poll fd: Invalid
> argument
> Nov 25 13:45:46 route-server bgpd[22856]: main: Lost connection to SE
> Nov 25 13:45:46 route-server bgpd[22856]: Lost child: session engine
> terminated; signal 11
> Nov 25 13:45:46 route-server bgpd[30006]: route decision engine exiting
>
>
>
> Thanks, Thorleif
>
>
> --
> Thorleif Wiik, CTO
> thorleif.w...@bcix.de
>
> Tel: +49 160 90378641
>
> BCIX Management GmbH / BCIX e.V.
> Stromstrasse 5
> 10555 Berlin - Germany
>
> http://www.bcix.de/
> https://twitter.com/bcix <http://twitter.com/bcix>
> https://www.facebook.com/BCIX.Internet.Exchange
>
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.182
diff -u -p -r1.182 bgpd.c
--- bgpd.c 20 Nov 2015 23:26:08 - 1.182
+++ bgpd.c 25 Nov 2015 20:47:34 -
@@ -903,21 +903,21 @@ handle_pollfd(struct pollfd *pfd, struct
if (pfd->revents & POLLOUT)
if (msgbuf_write(&i->w) <= 0 && errno != EAGAIN) {
- log_warn("handle_pollfd: msgbuf_write error");
+ log_warn("imsg write error");
close(i->fd);
i->fd = -1;
return (-1);
}
if (pfd->revents & POLLIN) {
- if ((n = imsg_read(i)) == -1) {
- log_warn("handle_pollfd: imsg_read error");
+ if ((n = imsg_read(i)) == -1 && errno != EAGAIN) {
+ log_warn("imsg read error");
close(i->fd);
i->fd = -1;
return (-1);
}
- if (n == 0) { /* connection closed */
- log_warn("handle_pollfd: poll fd");
+ if (n == 0) {
+ log_warnx("peer closed imsg connection");
close(i->fd);
i->fd = -1;
return (-1);
