Re: Status of mips64el packages for 6.3
On Tue, Jun 05, 2018 at 06:46:08AM +0200, Pierre-Emmanuel André wrote: > On Sun, Jun 03, 2018 at 04:16:30AM -0700, Xiyue Deng wrote: > > On Fri, May 11, 2018 at 06:29:57PM -0700, Xiyue Deng wrote: > > > On Fri, May 11, 2018 at 08:53:18PM +, Stuart Henderson wrote: > > > > On 2018-05-10, Xiyue Deng wrote: > > > > > Hi, > > > > > > > > > > I noticed that a few days ago (maybe around Monday) the 6.3 release > > > > > page[1] has updated mips64el package count: > > > > > > > > > > mips64el: 8254 > > > > > > > > > > A few days have passed however there is still no > > > > > /pub/OpenBSD/6.3/packages/mips64el available[2]. In the meantime, it > > > > > seems the snapshots packages were actually updated[3]. Just wonder > > > > > whether they were actually 6.3 packages, and if not, will 6.3 packages > > > > > be available? > > > > > > > > > > Thanks. > > > > > > > > > > [1] https://www.openbsd.org/63.html > > > > > [2] https://cdn.openbsd.org/pub/OpenBSD/6.3/packages/mips64el > > > > > [3] https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el > > > > > > > > > > > > > > > > > > The files dated 4 May in snapshots/packages/mips64el are 6.3 release > > > > packages. You can use them from there for now (e.g. via "pkg_add -D > > > > snap"); > > > > they're not likely to be superseded before the files are copied to the > > > > proper 6.3 directory. > > > > > > > > > > > > > > Great to know! Hope 6.3 path will also be ready soon. > > > > Hi again, > > > > It's been a month since the availability of mips64el snapshot packages > > and they still have not been copied to 6.3/packages yet. Just hope it > > will be taken care of before new packages are uploaded and overwritten > > the current ones. Not meant to be pushy, but 6.2 currently still > > doesn't have mips64el packages. I just hope 6.3 doesn't follow the same > > fate. > > > > Hi, > > Packages are available now. > Sorry for the delay. > Regards, Thanks a lot on behalf of my Loongson!
Re: NTP client traffic from WAN causing LAN DoS?
On 2018-06-05, Stuart Longland wrote: > On 05/06/18 06:46, Stuart Henderson wrote: >> On 2018-06-04, Stuart Longland wrote: >>> My thinking, since the problem has disappeared, is that the sheer number >>> of clients was overwhelming the router, and as a result, it didn't have >>> enough buffer space to handle the number of separate hosts requesting >>> the time from it. >> >> Oh! It might have been PF state table exhaustion. By default a maximum >> of 1 states are allowed (can be overridden with a different value in >> pf.conf). >> >> Has it been rebooted since the last time you saw the problem? If not, >> pfctl -si might still have some clues in the counters. > > Unfortunately yes, a few times. Is there a maximum limit on the number > of states? I later found that option and bumped it to 4, but I'm > not certain on what the maximum is. > > I'm guessing it'll be a function how big a "state" is, and how much > memory I'm willing to dedicate to `pf`. This machine isn't doing much > else but routing, so I can afford to throw quite a bit of memory (and > CPU) at it. You can check how much memory a state uses, see the pfstate line in "systat pool" (you can cursor-down through the list). You can at least get an idea of what fits in syatem memory. I think there are some limits to kernel memory use beyond the actual amount of memory in the system but am not sure of the details of that (and I think it varies between machine arches). It might not make sense to keep state for this NTP traffic anyway, you could try this near the top of the ruleset: pass in quick proto udp to self port ntp no state pass out quick proto udp from self port ntp no state This would be a cpu vs memory tradeoff. (For each packet it's doing a state lookup first anyway, then passes through the ruleset, so "no state" would increase cpu use a bit - putting it near the top and using "quick" keeps this as low as possible).
Send public IP / Alias / Reported in Round Robin manner
Hi.
Some days ago I received a second public IP address ("B") for my VPS /
OpenBSD system. In order for this ip to be available I added it as an
alias to my first public IP "A" as described in [1].
I am also running an OpenVPN server on this machine.
When I check for the public ip [2] the original IP "A" is constantly
reported.
When I check from a connected VPN client the public IP is returned in
a "Round Robin" manner, switching between "A" and "B" for each check.
As I understand this problem is likely related to my pf.conf.
Before I go into that I'm wondering how this "round robin" behavior is
even possible in the first place.
Thank you for your feedback and comments.
B.W.
---
[1] "Setting up aliases on an interface"
https://www.openbsd.org/faq/faq6.html
[2] for example with `curl ipinfo.io/ip`
OpenBSD on Lenovo m710q running minidlna?
I have a Lenovo m710q foobar2000 appliance under Windows 10. I like the box, it's about 1 1/2 as wide as a Lemote Fuloong Mini and about as deep and tall, but has slots for two, 2.5 inch drives. I thought about buying another one to use as a minidlna host under OpenBSD. Does anybody on the list have any experience with OpenBSD and minidlna on this box? Or any experience in general running minidlna on OpenBSD? Thanks, /jl
Re: Send public IP / Alias / Reported in Round Robin manner
On June 5, 2018 7:22:05 AM AKDT, Berry Wendermouth wrote: >When I check for the public ip [2] the original IP "A" is constantly >reported. This will likely be the case until the ttl on the original dns record expires. >When I check from a connected VPN client the public IP is returned in >a "Round Robin" manner, switching between "A" and "B" for each check. This is perfectly normal load-balancing behavior when you have two A records (or 2 records) for the same host in dns. Put in some A records for ipa.myhost.riseup.net and ipb.myhost.riseup.net or otherwise give the two ip addresses unique (additional) names if you wish to distinguish. -- https://www.colmena.biz/~justina/contacto.php
Re: lock order reversal in dmesg?
Am 06/04/18 um 23:01 schrieb Stuart Henderson: > On 2018-06-02, Jungle Boogie wrote: >> With one of the snapshots from Friday 1 June, I'm seeing more info in my >> dmesg >> than I typically do. Has some extra debugging been turned on? > > Yes. > > Here you go. Best, STEFAN OpenBSD 6.3-current (GENERIC.MP) #75: Mon Jun 4 00:06:10 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17079074816 (16287MB) avail mem = 16420855808 (15660MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries) bios0: vendor American Megatrends Inc. version "1.03.06" date 06/25/2014 bios0: Notebook W65_67SZ acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT SSDT SSDT DMAR acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(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) i5-4210M CPU @ 2.60GHz, 3093.33 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,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 using xsaveopt cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (P0P2) acpiprt5 at acpi0: bus -1 (P0PA) acpiprt6 at acpi0: bus -1 (P0PB) acpiprt7 at acpi0: bus 1 (PEG0) acpiec0 at acpi0 acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 120 degC acpicmos0 at acpi0 "INT3F0D" at acpi0 not configured "MSFT0001" at acpi0 not configured "ETD0403" at acpi0 not configured "PNPC000" at acpi0 not configured acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: LID0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "BAT" serial 0001 type LION oem "Notebook" "PNP0C14" at acpi0 not configured "INT340E" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: LCD0 cpu0: Enhanced SpeedStep 3093 MHz: speeds: 2601, 2600, 2500, 2300, 2200, 2100, 2000, 1800, 1700, 1600, 1400, 1300, 1200, 1100, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06 ppb0 at pci0 dev 1 function 0 "Intel Core 4G P
