RE: FOSDEM 2018 - Distributions Devroom Call for Participation
*sigh* I wrote: > Yes, the poster has enlightened me by private e-mail now. There's an > OpenBSD 'track', apparently, woohoo! Correction: it was not the poster, and it was in public. This broken webmail poop is why I din't respond everyday. Be glad! ;) --schaafuit.
Re: Apollo Lake kernel panic
I copied the bsd.mp kernel from a working machine. Here is the dmesg. I also disabled C states in BIOS and was able cleanly to halt machine OpenBSD 6.2 (GENERIC) #132: Tue Oct 3 21:18:21 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 16799846400 (16021MB) avail mem = 16283758592 (15529MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries) bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017 bios0: ASRock J4205-ITX acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP LPIT APIC NPKT PRAM WSMT SSDT SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BERT WDAT NHLT acpi0: wakeup devices SIO1(S4) PS2K(S4) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1497.60 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT cpu0: 1MB 64b/line 16-way L2 cache cpu0: TSC frequency 149760 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP03) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP05) acpiprt4 at acpi0: bus 4 (RP06) acpiec0 at acpi0: not present acpicpu0 at acpi0: C1(@1 halt!), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: PWRB "INT3452" at acpi0 not configured "INT3452" at acpi0 not configured "INT3452" at acpi0 not configured "INT3452" at acpi0 not configured "INT33A1" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 0x0b drm0 at inteldrm0 inteldrm0: msi error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/bxt_dmc_ver1.bin (-22) error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 (ignored) inteldrm0: 1440x900, 32bpp Unclaimed register detected after writing to register 0x68980 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 14 function 0 vendor "Intel", unknown product 0x5a98 rev 0x0b: msi azalia0: codecs: Realtek/0x0892, 0x/0x, using Realtek/0x0892 audio0 at azalia0 vendor "Intel", unknown product 0x5a9a (class communications subclass miscellaneous, rev 0x0b) at pci0 dev 15 function 0 not configured ahci0 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x5ae3 rev 0x0b: msi, AHCI 1.3.1 ahci0: port 0: 6.0Gb/s ahci0: port 1: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.5000c500a20c8afc sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c500a20c72e9 sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors ppb0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x5ad8 rev 0xfb: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G (0x4c00), msi, address 70:85:c2:4a:bf:5b rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 ppb1 at pci0 dev 19 function 1 vendor "Intel", unknown product 0x5ad9 rev 0xfb: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 19 function 2 vendor "Intel", unknown product 0x5ada rev 0xfb: msi pci3 at ppb2 bus 3 ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI 1.2 ahci1: port 0: 1.5Gb/s scsibus2 at ahci1: 32 targets cd0 at scsibus2 targ 0 lun 0: ATAPI 5/cdrom removable ppb3 at pci0 dev 19 function 3 vendor "Intel", unknown product 0x5adb rev 0xfb: msi pci4 at ppb3 bus 4 xhci0 at pci0 dev 21 function 0 vendor "Intel", unknown product 0x5aa8 rev 0x0b: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 ven
Re: Apollo Lake kernel panic
I was able to boot machine which crashed with bsd.sp kernel. Please see message below. That kernel is non-patched kernel as I was running normally bsd.mp kernel. Also I forgot to say in my previous message that I didn't mess with C states (BIOS option). I was also using legacy (not pure UEFI boot) as the the original installation was done on the system which didn't support UEFI boot. OpenBSD 6.2 (GENERIC) #132: Tue Oct 3 21:18:21 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 16799846400 (16021MB) avail mem = 16283758592 (15529MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries) bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017 bios0: ASRock J4205-ITX acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP LPIT APIC NPKT PRAM WSMT SSDT SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BERT WDAT NHLT acpi0: wakeup devices SIO1(S4) PS2K(S4) UAR1(S4) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1497.60 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT cpu0: 1MB 64b/line 16-way L2 cache cpu0: TSC frequency 149760 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP03) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP05) acpiprt4 at acpi0: bus 4 (RP06) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: PWRB "INT3452" at acpi0 not configured "INT3452" at acpi0 not configured "INT3452" at acpi0 not configured "INT3452" at acpi0 not configured "INT33A1" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 0x0b drm0 at inteldrm0 inteldrm0: msi error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/bxt_dmc_ver1.bin (-22) error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 (ignored) inteldrm0: 1440x900, 32bpp Unclaimed register detected after writing to register 0x68980 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 14 function 0 vendor "Intel", unknown product 0x5a98 rev 0x0b: msi azalia0: codecs: Realtek/0x0892, 0x/0x, using Realtek/0x0892 audio0 at azalia0 vendor "Intel", unknown product 0x5a9a (class communications subclass miscellaneous, rev 0x0b) at pci0 dev 15 function 0 not configured ahci0 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x5ae3 rev 0x0b: msi, AHCI 1.3.1 ahci0: port 0: 6.0Gb/s ahci0: port 1: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.5000c500a20c8afc sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c500a20c72e9 sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors ppb0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x5ad8 rev 0xfb: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G (0x4c00), msi, address 70:85:c2:4a:bf:5b rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 ppb1 at pci0 dev 19 function 1 vendor "Intel", unknown product 0x5ad9 rev 0xfb: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 19 function 2 vendor "Intel", unknown product 0x5ada rev 0xfb: msi pci3 at ppb2 bus 3 ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI 1.2 ahci1: port 0: 1.5Gb/s scsibus2 at ahci1: 32 targets cd0 at scsibus2 targ 0 lun 0: ATAPI 5/cdrom removable ppb3 at pci0 dev 19 function 3 vendo
Re: Apollo Lake kernel panic
Pedro Ramos wrote: > Please find attached the dmesg from ASRock J4205-ITX. > > > Best regards, > Pedro Ramos > > > ["asrock.j4205-itx.dmesg.gz" (application/x-gzip)] Unfortunatelly I got one of those few weeks ago and it is nothing but the trouble. The first one died but NewEgg sent me the second one. I don't know where to begin. With the default ACPI configuration options 1. Suspend to RAM enabled 2. ACPI HPET Table enabled one can't clearly shut down 6.2 stable. This is what I got www.devio.us/~ppunosevac/kernel-panic-1.jpg The system was frozen to the point that I could not get crash trace. With suspend to RAM and HPET table disabled I could finally do shutdown -p now without crashing kernel. I see that even on 6.2 current dmesg which was sent bunch of errors in dmesg pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 0x0b drm0 at inteldrm0 inteldrm0: msi error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/bxt_dmc_ver1.bin (-22) error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 (ignored) Unfortunatelly at this point my system is trashed so I can't post dmesg from of 6.2 stable. Namely after trying to start Chrome I got kernel panic again but I was able this time to trace it www.devio.us/~ppunosevac/kernel-panic-2.jpg Now the system hangs on the boot with the message entry point at 0x1000158 My boot device was RAID 1 and I would appreciate if somebody could give me a suggestion if I can recover the system (I do have the backup for data). Few more things. I could not get X running on my DVI-D 4:3 monitor. However both VGA output and HDMI were working. HDMI had no problem using my high definition Panasonic TV. If you attach HDD to ASMedia ASM1061 SATA ports (there are 2 of those and there are two of SATA3 6.0Gb/s Connectors, support NCQ, AHCI and Hot Plug) S.M.A.R.T. daemon will refuse to start. I have not investigated this further. Sound Realtek ALC892 did work as well as Realtek 8111GR Gigabit LAN. I could not make a use of 1 x PCI Express 2.0 x1 Slot. Note also that M.2 is only for WiFi not for storage device. I am not feeling good about this purchase right now. Maybe somebody could give me some pointers. Best, Predrag
Re: Cheap 2x NIC OpenBSD device
Sean Murphy [s.pat.mu...@gmail.com] wrote: > You can install OpenBSD on it. As noted in the thread by techay Ted > Unangst has a good write up on the unit on his blog. > A side note, OpenBSD 6.2-current will take better advantage of the multiple cores using the cnmac interface (or will soon) on this box than the 6.2 release.
Re: Bad network performance on apu2c4
Rupert Gallagher [r...@protonmail.com] wrote: > Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a > windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on > both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec. > This is not a regression. The APU2 has limited CPU power and can handle larger packets much better than typically internet-routable 1500 byte packets. The same traffic level, with 1500 byte packets generates 6 times more packets per second than that traffic level with 9000 bytes packets. There is ongoing work to improve the network stack performance on boxes like the APU2 (which have 4 cores). You will see improvements. If you want it better today, you need a faster box. Chris
Re: FOSDEM 2018 - Distributions Devroom Call for Participation
On Fri, Nov 03, 2017 at 08:57:52PM +0100, leo_...@volny.cz wrote: > "Brian Exelbierd" wrote: > > Online at: > > https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html > > > > The Distributions devroom will take place Sunday 4 February 2018 at > > FOSDEM, in Brussels, Belgium at the Université Libre de Bruxelles. > > Interesting. What does this have to do with OpenBSD? Quite a bit, actually. FOSDEM has had a BSD devroom track for years. > And I'll sign it with my shit. > > Stop spamming us, really. > > --schaafuit. I'd gladly welcome their mail if it means we'll never again receive any of yours. Go away. -Bryan.
Re: FOSDEM 2018 - Distributions Devroom Call for Participation
Hi leo_tck, leo_...@volny.cz wrote on Fri, Nov 03, 2017 at 08:57:52PM +0100: > [I don't normally respond to spam, This is not spam. It is an on-topic posting. Please refrain from insulting people, in particular those posting rarely who may not be very familiar with OpenBSD and might be mislead to think that such insults would be normal or acceptable in an OpenBSD context. > "Brian Exelbierd" wrote: >> Online at: >> https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html >> >> The Distributions devroom will take place Sunday 4 February 2018 at >> FOSDEM, in Brussels, Belgium at the Universite Libre de Bruxelles. > Interesting. What does this have to do with OpenBSD? FOSDEM is a major conference about Free Software, arguably even the major conference in Europe. OpenBSD as a free operating system. OpenBSD developers have presented at FOSDEM in the past. I'm actually considering to propose a presentation myself, and i'm grateful for the heads-up. I consider FOSDEM a major opportunity for communication among free operating systems that rarely talk to each other. The *BSD conferences are no doubt useful too, but less suited to that particular purpose. While some of your questions may be interesting and some of your criticisms might have a point, discussing most of them would be off-topic on this list. A call for proposals for a major free software conference is clearly on topic here; nitpicking on the concept of the conference is not. Yours, Ingo -- Ingo Schwarze
Re: Is there an option switch to lower minimum DH strength in SSH client?
>I was finally able to bring our OpenBSD based Network Management System up >to the current OS release (it was a couple of years out of date) but this >process broke access to a large number of older HP switches on our network. >Thorough analysis of the problem and study of the source code lead me to >believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: > >increase the minimum modulus that we will send or accept in >diffie-hellman-group-exchange to 2048 bits; > >Within the file it further explains that this is mitigation for DH >precomputation attacks. I understand and appreciate strengthening server >code. But this breaks the use of SSH client leaving little recourse other >than perhaps telnet with NO encryption instead of somewhat weak encryption, >as the "server" is outside of our control. (I already checked that we have >the latest firmware, less than one year old.) If your switch management is located on a locked-down intranet, aka 'darknet', you can handle this with configuration, or not update the clients that connect to their legacy servers. But I guess they are not on a darknet, because you worry about telnet. >Is this an oversight or is there a particular logic to intentionally >breaking compatibility with a not-insignificant base of installed equipment? Absolutely the latter. It is intentional. Security and interopability often collide, especially as new research papers get written and computational abilities expand. Circumstances arise where both needs cannot be satisfied and past decisions must be evaluated and upgraded. Decisions like this are not taken lightheartedly. BTW you can contact HP tech support and tell them that the latest Cisco Nexus productline just performed a update to latest (well 6 months ago) OpenSSH. Including ditching SSH1 support. Cisco has shorter lifecycles than HP, but did so even for many EOL products in that line. So HP could get around to this.
RE: FOSDEM 2018 - Distributions Devroom Call for Participation
Hi, [I don't normally respond to spam, but I need to blow off some frustration =)] "Brian Exelbierd" wrote: > Online at: > https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html > > The Distributions devroom will take place Sunday 4 February 2018 at > FOSDEM, in Brussels, Belgium at the Universit=C3=A9 Libre de Bruxelles. Interesting. What does this have to do with OpenBSD? > For this year's distributions devroom, we want to focus on the ways that > distribution technologies can be leveraged to allow for easier > creation of a multi-verse of artifacts from single source trees. Uhm, what does that *mean*, in technical terms? > We also > want to continue to highlight the huge efforts being made in shared > environments around Build/Test/Release cycles. Define 'shared environments'? > We welcome submissions targeted at contributors interested in issues > unique to distributions, especially in the following topics: > > - Distribution and Community collaborations, eg: how does code flow from > developers to end users across communities, ensuring trust and code > audibility ^^ I propose reviving speak(1). > - Automating building software for redistribution to minimize human > involvement, eg: bots that branch and build software, bots that > participate as team members extending human involvement Counterproductive. > - Cross-distribution collaboration on common issues, eg: content > distribution, infrastructure, and documentation What's cross-distribution? Is it like cross-pollination? > - Growing distribution communities, eg: onboarding new users, helping > new contributors learn community values and technology, increasing > contributor technical skills, recognizing and rewarding contribution Sounds like a schoolteacher approach to me. An onboarding school, haha! > - Principals of Rolling Releases, Long Term Supported Releases (LTS), > Feature gated releases, and calendar releases You do know that calendar releases have been obsolete since cal(1), right? Unless you like pretty pictures. > - Distribution construction, installation, deployment, packaging and > content management Ooh yes, when installing OpenBSD I'm very very interested in content management, woohoo! > - Balancing new code and active upstreams verus security updates, back > porting and minimization of user breaking changes {,L}users are broken by design, so we don't need to worry about that =) > - Delivering architecture independent software universally across > architectures within the confines of distribution systems Gibberish. > - Effectively communicating the difference in experience across > architectures for developers, packagers, and users Ever heard of manual pages? They're great! > - Working with vendors and including them in the community What vendors? Most of them ain't interested. > - The future of distributions, emerging trends and evolving user demands > from the idea of a platform I DEMAND WINDOZE 3193179381, AND I DEMAND IT NOW!!!11!!1!! WH!11!!! > Ideal submissions are actionable and opinionated. Submissions may > be in the form of 25 or 50 minute talks, panel sessions, round-table > discussions, or Birds of a Feather (BoF) sessions. Actionable? Prolly. Opinionated? Yup. Write me in! And I'll sign it with my shit. Stop spamming us, really. --schaafuit.
Re: Bad network performance on apu2c4
openbsd "current"... is it 6.1 or 6.2? if 6.2, was it better with 6.1? From a later message of yours, you mention ISP upload, but the OP did not mention it. Are you testing on LAN, WAN or internet? Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec. Sent from ProtonMail Mobile On Wed, Nov 1, 2017 at 09:14, Christer Solskogen wrote: > Hi! I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th > of October) - and according to iperf I'm not getting the speed that I was > expecting. Between the APU and the other machines I have I get: 465 Mbits/sec > - While between two other machines, connected to the same switch I get 939 > Mbits/sec. So I'm pretty sure that APU is to blame. ifconfig: em0: flags=8b43 > mtu 1500 lladdr 00:0d:b9:41:6f:c8 index 1 priority 0 llprio 3 media: > Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.0.2 > netmask 0xff00 broadcast 192.168.0.255 I've tried different MTU sizes as > well, but it does not seem to have any effect. > ,broadcast,running,promisc,allmulti,simplex,multicast>
Re: FAQ14: Growing disk partitions: fdisk
On Fri, Nov 03, 2017 at 05:12:54PM +0100, Alexander Hall wrote: > > > On November 3, 2017 8:41:20 AM GMT+01:00, Otto Moerbeek > wrote: > >On Fri, Nov 03, 2017 at 08:07:37AM +0100, Stephane HUC "PengouinBSD" > >wrote: > > > >> > >> Le 11/03/17 à 07:27, Otto Moerbeek a écrit : > >> (...) > >> > > >> > My guess is that if you use duids in fstab then you should call it > >by > >> > that name withc fsck (which uses fstab). Alternatively, specify the > >> > mount point. > >> > > >> > -Otto > >> > > >> > > >> > >> Interesting point of view, but: > >> > >> 1/ I've not change the writing of the fstab file. It is the fact of > >the > >> installer OpenBSD. > >> > >> 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it > >> seems it not doing it. > >> > >> > # fsck sd0d > >> > fsck: sd0d: unknown special file or file system. > > > >It does use fstab, but it cannot find sd0d in fstab. > > > >> > >> 3/ By using duids, how i call fsck? > > > >fsck ef1ea0f909e0b8d8.d > > > >> > >> # fsck /tmp > >> > >> ??? > > > >That line didn't show properly in my mal client. > > > >> > >> 4/ And, yes, calling fsck as: > >> > >> # fsck /dev/sd0d > >> > >> seems run correctly! > > > >Yes, because if a full path is given, fsck uses that without > >needing to consult fstab. > > Is there some reason why one can it or is not convert fsck to use opendev()? fsck never did interpret short names, so I would be surpised it it did that suddenly. -Otto > > /Alexander > > > > >> > >> => But then why is it written in the FAQ this below, since it doesn't > >> seem to work? (at least with stable amd64 OpenBSD) > >> > >> "Before the partition can be mounted again, its integrity must be > >> checked with fsck(8): > >> > >> # fsck sd0h > >> " > > > >That's an error in the FAQ. It has been fixed now, > > > > -Otto
Re: Is there an option switch to lower minimum DH strength in SSH client?
On Fri, Nov 03, 2017 at 12:06:22AM -0400, Jacob Leifman wrote: > I was finally able to bring our OpenBSD based Network Management System up > to the current OS release (it was a couple of years out of date) but this > process broke access to a large number of older HP switches on our network. > Thorough analysis of the problem and study of the source code lead me to > believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: > > increase the minimum modulus that we will send or accept in > diffie-hellman-group-exchange to 2048 bits; > > Within the file it further explains that this is mitigation for DH > precomputation attacks. I understand and appreciate strengthening server > code. But this breaks the use of SSH client leaving little recourse other > than perhaps telnet with NO encryption instead of somewhat weak encryption, > as the "server" is outside of our control. (I already checked that we have > the latest firmware, less than one year old.) > > Curiously, diffie-hellman-group1-sha1, which is the only one supported by > the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); > I was hoping that I could use it to explicitly request smaller DH but > ultimately it still dies with "Invalid key length" error. > > Is this an oversight or is there a particular logic to intentionally > breaking compatibility with a not-insignificant base of installed equipment? While I agree with all the other posters that ideally all equipment should be kept up-to-date rather than leaning on aging security technology, I do realize that in some areas you simply have to get things done and move on. As such, I recommend this quick fix: # pkg_add putty This will give you the 'plink' command which is a cli putty ssh, and it allows this stuff by default without making you add host entries to ~/.ssh/config. I have noticed it still does warn you when the end point is using older ciphers but at least doesn't bomb out. I started using this for older Cisco gear at $WORKPLACE as I grew tired of editing the ssh config for the OpenSSH version :-) Hope this helps, Cheers! -ryan > > Thank you, > > Jacob Leifman > Educational Technology > > Weymouth Public Schools > > -- > CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is > intended only for the individual or entity to which it is addressed and may > contain confidential and/or privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, or the employee or agent responsible for delivering it > to the intended recipient, please contact the sender by reply e-mail and > destroy all copies of the original message. If you are the intended > recipient but do not wish to receive communication through this medium, > please advise the sender immediately. Please note that any views or > opinions presented in this email are solely those of the author and do not > necessarily represent those of the Weymouth Public Schools. > www.weymouthschools.org/
Re: FAQ14: Growing disk partitions: fdisk
On November 3, 2017 8:41:20 AM GMT+01:00, Otto Moerbeek wrote: >On Fri, Nov 03, 2017 at 08:07:37AM +0100, Stephane HUC "PengouinBSD" >wrote: > >> >> Le 11/03/17 à 07:27, Otto Moerbeek a écrit : >> (...) >> > >> > My guess is that if you use duids in fstab then you should call it >by >> > that name withc fsck (which uses fstab). Alternatively, specify the >> > mount point. >> > >> >-Otto >> > >> > >> >> Interesting point of view, but: >> >> 1/ I've not change the writing of the fstab file. It is the fact of >the >> installer OpenBSD. >> >> 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it >> seems it not doing it. >> >> > # fsck sd0d >> > fsck: sd0d: unknown special file or file system. > >It does use fstab, but it cannot find sd0d in fstab. > >> >> 3/ By using duids, how i call fsck? > >fsck ef1ea0f909e0b8d8.d > >> >> # fsck /tmp >> >> ??? > >That line didn't show properly in my mal client. > >> >> 4/ And, yes, calling fsck as: >> >> # fsck /dev/sd0d >> >> seems run correctly! > >Yes, because if a full path is given, fsck uses that without >needing to consult fstab. Is there some reason why one can it or is not convert fsck to use opendev()? /Alexander > >> >> => But then why is it written in the FAQ this below, since it doesn't >> seem to work? (at least with stable amd64 OpenBSD) >> >> "Before the partition can be mounted again, its integrity must be >> checked with fsck(8): >> >> # fsck sd0h >> " > >That's an error in the FAQ. It has been fixed now, > > -Otto
Re: Is there an option switch to lower minimum DH strength in SSH client?
Chris Turner writes: > Encryption options can be selected by the client so long as they are available Which is the issue. The change to usr.bin/ssh/dh.h was: -#define DH_GRP_MIN 1024 +#define DH_GRP_MIN 2048 So the new DH_GRP_MIN value of 2048 is compiled in. They could try reverting that commit locally and rebuilding. Allan
Re: Is there an option switch to lower minimum DH strength in SSH client?
On 03/11/17 15:27, Jacob Leifman wrote: >> KexAlgorithms +diffie-hellman-group1-sha1 >> Ciphers +aes128-cbc >> >> Regards >> > > Hi, > > Not quite, I have the converse problem -- using the modern ssh client and > being unable to connect to an older embedded ssh server. But your solution > indicates that in the ssh server implementation the explicit compatibility > mode actually works. I find the incongruity between server and client > approaches to backwards compatibility rather odd, since it is generally > much easier to upgrade or replace a client application (end-user software) > than the server application, especially embedded server as in my case. > > -Jacob. The reverse is done on your .ssh/config host old-server Hostname 10.0.0.1 KexAlgorithms diffie-hellman-group-exchange-sha1 Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc choose what works for you ssh -v is a friend here to see where it complains. G
Re: Is there an option switch to lower minimum DH strength in SSH client?
On 11/03/17 08:27, Jacob Leifman wrote: Not quite, I have the converse problem -- using the modern ssh client and being unable to connect to an older embedded ssh server. But your solution indicates that in the ssh server implementation the explicit compatibility mode actually works. Encryption options can be selected by the client so long as they are available e.g.: ssh -X -oHostKeyAlgorithms=+ssh-dss -oPubKeyAcceptedKeyTypes=+dsa or by adding a host-specific option in a ~/.ssh/config entry. See ssh_config(5) and ssh -Q options.
Re: Is there an option switch to lower minimum DH strength in SSH client?
On Fri, Nov 3, 2017 at 9:17 AM, Solène Rapenne wrote: > Je 2017-11-03 05:06, Jacob Leifman skribis: > > I was finally able to bring our OpenBSD based Network Management System up >> to the current OS release (it was a couple of years out of date) but this >> process broke access to a large number of older HP switches on our >> network. >> Thorough analysis of the problem and study of the source code lead me to >> believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: >> >> increase the minimum modulus that we will send or accept in >> diffie-hellman-group-exchange to 2048 bits; >> >> Within the file it further explains that this is mitigation for DH >> precomputation attacks. I understand and appreciate strengthening server >> code. But this breaks the use of SSH client leaving little recourse other >> than perhaps telnet with NO encryption instead of somewhat weak >> encryption, >> as the "server" is outside of our control. (I already checked that we have >> the latest firmware, less than one year old.) >> >> Curiously, diffie-hellman-group1-sha1, which is the only one supported by >> the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); >> I was hoping that I could use it to explicitly request smaller DH but >> ultimately it still dies with "Invalid key length" error. >> >> Is this an oversight or is there a particular logic to intentionally >> breaking compatibility with a not-insignificant base of installed >> equipment? >> >> Thank you, >> >> Jacob Leifman >> Educational Technology >> >> Weymouth Public Schools >> > > Hello, > > I'm not sure if it's what you ask but I had a problem with old ssh clients > not able to connect to a recent ssh server after a system upgrade. I had to > add this to my sshd config (on the server) to allow them to connect : > > > KexAlgorithms +diffie-hellman-group1-sha1 > Ciphers +aes128-cbc > > Regards > Hi, Not quite, I have the converse problem -- using the modern ssh client and being unable to connect to an older embedded ssh server. But your solution indicates that in the ssh server implementation the explicit compatibility mode actually works. I find the incongruity between server and client approaches to backwards compatibility rather odd, since it is generally much easier to upgrade or replace a client application (end-user software) than the server application, especially embedded server as in my case. -Jacob. -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
Re: Is there an option switch to lower minimum DH strength in SSH client?
On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson wrote: > 2017-11-03 5:06 GMT+01:00 Jacob Leifman >: > >> I was finally able to bring our OpenBSD based Network Management System up >> to the current OS release (it was a couple of years out of date) but this >> process broke access to a large number of older HP switches on our >> network. >> > > >> But this breaks the use of SSH client leaving little recourse other >> than perhaps telnet with NO encryption instead of somewhat weak >> encryption, >> as the "server" is outside of our control. (I already checked that we have >> the latest firmware, less than one year old.) >> >> Is this an oversight or is there a particular logic to intentionally >> breaking compatibility with a not-insignificant base of installed >> equipment? >> >> > If your vendor, even with a <1y firmware still only can handle old and > deprecated > keysizes, you should not ask for everyone elses sshs to become worse, but > rather > push the vendor to get up to speed, and since that will not work, you will > have to > resort to building older ssh and use that instead of the safer one that > comes with > the modern OS you upgraded to. > > Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out > in browsers > so that the majority of users are safe, not kept to cater to the lowest > common denominator > of the laziest vendor still alive. > > You should be asking HP how come they can't keep the free sshd code > updated, > if security is your prime concern, not ask openbsd to lower everyone elses > security. > I am not asking to lower anyone else's security or for SSH to "become worse", I appreciate the default behavior being what it is. I am asking about a way to have an explicit compatibility mode -- even if we are successful at lobbying a behemoth like HP for an update, it will take time, probably a lot of time. Nor is a chronically underfunded public school district in the position to outright replace >$500K worth of switches that do their primary duties without fail. Not having some kind of compatibility mode, leaves me with choice of bad and worse. Typical K-12 management neither understands tech nor can afford to divert funds to "frivolous" upgrades. Their inevitable response is either "don't upgrade" or "choose another product", a product that will not have even the basic security level OpenBSD had say three years ago. > > -- > May the most significant bit of your life be positive. > -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
Re: Is there an option switch to lower minimum DH strength in SSH client?
2017-11-03 14:17 GMT+01:00 Jacob Leifman : > On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson > wrote: > >> 2017-11-03 5:06 GMT+01:00 Jacob Leifman > .org>: >> >>> >>> If your vendor, even with a <1y firmware still only can handle old and >> deprecated >> keysizes, you should not ask for everyone elses sshs to become worse, but >> rather >> > push the vendor to get up to speed, and since that will not work, you will >> have to >> resort to building older ssh and use that instead of the safer one that >> comes with >> the modern OS you upgraded to. >> >> I am not asking to lower anyone else's security or for SSH to "become > worse", I appreciate the default behavior being what it is. I am asking > about a way to have an explicit compatibility mode -- even if we are > successful at lobbying a behemoth like HP for an update, it will take time, > probably a lot of time. Nor is a chronically underfunded public school > district in the position to outright replace >$500K worth of switches that > do their primary duties without fail. Not having some kind of compatibility > mode, leaves me with choice of bad and worse. Typical K-12 management > neither understands tech nor can afford to divert funds to "frivolous" > upgrades. Their inevitable response is either "don't upgrade" or "choose > another product", a product that will not have even the basic security > level OpenBSD had say three years ago. > compat => https://www.openssh.com/openbsd.html scroll to the bottom, get one of the old versions and compile that. cost: $0 Probably same amount as HP paid to be able to have a deprecated sshd in their product. -- May the most significant bit of your life be positive.
Re: Is there an option switch to lower minimum DH strength in SSH client?
Je 2017-11-03 05:06, Jacob Leifman skribis: I was finally able to bring our OpenBSD based Network Management System up to the current OS release (it was a couple of years out of date) but this process broke access to a large number of older HP switches on our network. Thorough analysis of the problem and study of the source code lead me to believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: increase the minimum modulus that we will send or accept in diffie-hellman-group-exchange to 2048 bits; Within the file it further explains that this is mitigation for DH precomputation attacks. I understand and appreciate strengthening server code. But this breaks the use of SSH client leaving little recourse other than perhaps telnet with NO encryption instead of somewhat weak encryption, as the "server" is outside of our control. (I already checked that we have the latest firmware, less than one year old.) Curiously, diffie-hellman-group1-sha1, which is the only one supported by the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); I was hoping that I could use it to explicitly request smaller DH but ultimately it still dies with "Invalid key length" error. Is this an oversight or is there a particular logic to intentionally breaking compatibility with a not-insignificant base of installed equipment? Thank you, Jacob Leifman Educational Technology Weymouth Public Schools Hello, I'm not sure if it's what you ask but I had a problem with old ssh clients not able to connect to a recent ssh server after a system upgrade. I had to add this to my sshd config (on the server) to allow them to connect : KexAlgorithms +diffie-hellman-group1-sha1 Ciphers +aes128-cbc Regards
Re: Is there an option switch to lower minimum DH strength in SSH client?
2017-11-03 13:53 GMT+01:00 Gregory Edigarov : > You should be asking HP how come they can't keep the free sshd code >> updated, >> if security is your prime concern, not ask openbsd to lower everyone elses >> security. >> >> I think for most vendors, it is a rather administrative, than technical > question. > Yes, their technical people can update code, yes they can do it quick, but > their management is slow... > > I think you can let them update for decades and they will not update the sshd anyhow. So in the end, the conclusion was true, "since ssh has moved on, if I want to keep using my old hw, I need to resort to insecure ways of administering them", where it may be ancient ssh clients or telnet or serial ports. When it comes to IT security, stuff like "was removed 2 years ago, and deprecated for X years before that, and better versions have been available for X+Y years" actually matters. You can wave your arms and pretend as if this was a big shock for you, but actually there is a lot of diligence being skipped in order for someone to end up in a situation like this. And not just in the customer end, but the vendor also. And everyone else that keep an unpatched admin station around just to make that random old system going even though vendors claim to care for your security. -- May the most significant bit of your life be positive.
Re: Is there an option switch to lower minimum DH strength in SSH client?
On Fri, Nov 03, 2017 at 02:53:53PM +0200, Gregory Edigarov wrote: > I think for most vendors, it is a rather administrative, than technical > question. > Yes, their technical people can update code, yes they can do it quick, but > their management is slow... Often, the same management is telling everybody security is of the highest concern to them, so make them deliver on that. -Otto
FOSDEM 2018 - Distributions Devroom Call for Participation
Online at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html The Distributions devroom will take place Sunday 4 February 2018 at FOSDEM, in Brussels, Belgium at the Université Libre de Bruxelles. For this year's distributions devroom, we want to focus on the ways that distribution technologies can be leveraged to allow for easier creation of a multi-verse of artifacts from single source trees. We also want to continue to highlight the huge efforts being made in shared environments around Build/Test/Release cycles. We welcome submissions targeted at contributors interested in issues unique to distributions, especially in the following topics: - Distribution and Community collaborations, eg: how does code flow from developers to end users across communities, ensuring trust and code audibility - Automating building software for redistribution to minimize human involvement, eg: bots that branch and build software, bots that participate as team members extending human involvement - Cross-distribution collaboration on common issues, eg: content distribution, infrastructure, and documentation - Growing distribution communities, eg: onboarding new users, helping new contributors learn community values and technology, increasing contributor technical skills, recognizing and rewarding contribution - Principals of Rolling Releases, Long Term Supported Releases (LTS), Feature gated releases, and calendar releases - Distribution construction, installation, deployment, packaging and content management - Balancing new code and active upstreams verus security updates, back porting and minimization of user breaking changes - Delivering architecture independent software universally across architectures within the confines of distribution systems - Effectively communicating the difference in experience across architectures for developers, packagers, and users - Working with vendors and including them in the community - The future of distributions, emerging trends and evolving user demands from the idea of a platform Ideal submissions are actionable and opinionated. Submissions may be in the form of 25 or 50 minute talks, panel sessions, round-table discussions, or Birds of a Feather (BoF) sessions. Dates -- Submission Deadline: 03-Dec-2017 @ 2359 GMT Acceptance Notification: 8-Dec-2017 Final Schedule Posted: 15-Dec-2017 How to submit -- Visit https://penta.fosdem.org/submission/FOSDEM18 1.) If you do not have an account, create one here 2.) Click 'Create Event' 3.) Enter your presentation details 4.) Be sure to select the Distributions Devroom track! 5.) Submit What to include --- - The title of your submission - A 1-paragraph Abstract - A longer description including the benefit of your talk to your target audience, including a definition of your target audience. - Approximate length / type of submission (talk, BoF, ...) - Links to related websites/blogs/talk material (if any) Administrative Notes We will be live-streaming and recording the Distributions Devroom. Presenting at FOSDEM implies permission to record your session and distribute the recording afterwards. All videos will be made available under the standard FOSDEM content license (CC-BY). If you have any questions, feel free to contact the devroom organizers: distributions-devr...@lists.fosdem.org (https://lists.fosdem.org/listinfo/distributions-devroom) Cheers! Brian Exelbierd (twitter: @bexelbie) and Brian Stinson (twitter: @bstinsonmhk) for and on behalf of The Distributions Devroom Program Committee
Re: Is there an option switch to lower minimum DH strength in SSH client?
On 03.11.17 14:37, Janne Johansson wrote: 2017-11-03 5:06 GMT+01:00 Jacob Leifman : I was finally able to bring our OpenBSD based Network Management System up to the current OS release (it was a couple of years out of date) but this process broke access to a large number of older HP switches on our network. But this breaks the use of SSH client leaving little recourse other than perhaps telnet with NO encryption instead of somewhat weak encryption, as the "server" is outside of our control. (I already checked that we have the latest firmware, less than one year old.) Is this an oversight or is there a particular logic to intentionally breaking compatibility with a not-insignificant base of installed equipment? If your vendor, even with a <1y firmware still only can handle old and deprecated keysizes, you should not ask for everyone elses sshs to become worse, but rather push the vendor to get up to speed, and since that will not work, you will have to resort to building older ssh and use that instead of the safer one that comes with the modern OS you upgraded to. Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out in browsers so that the majority of users are safe, not kept to cater to the lowest common denominator of the laziest vendor still alive. You should be asking HP how come they can't keep the free sshd code updated, if security is your prime concern, not ask openbsd to lower everyone elses security. I think for most vendors, it is a rather administrative, than technical question. Yes, their technical people can update code, yes they can do it quick, but their management is slow...
Re: Is there an option switch to lower minimum DH strength in SSH client?
2017-11-03 5:06 GMT+01:00 Jacob Leifman : > I was finally able to bring our OpenBSD based Network Management System up > to the current OS release (it was a couple of years out of date) but this > process broke access to a large number of older HP switches on our network. > > But this breaks the use of SSH client leaving little recourse other > than perhaps telnet with NO encryption instead of somewhat weak encryption, > as the "server" is outside of our control. (I already checked that we have > the latest firmware, less than one year old.) > > Is this an oversight or is there a particular logic to intentionally > breaking compatibility with a not-insignificant base of installed > equipment? > > If your vendor, even with a <1y firmware still only can handle old and deprecated keysizes, you should not ask for everyone elses sshs to become worse, but rather push the vendor to get up to speed, and since that will not work, you will have to resort to building older ssh and use that instead of the safer one that comes with the modern OS you upgraded to. Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out in browsers so that the majority of users are safe, not kept to cater to the lowest common denominator of the laziest vendor still alive. You should be asking HP how come they can't keep the free sshd code updated, if security is your prime concern, not ask openbsd to lower everyone elses security. -- May the most significant bit of your life be positive.
Re: Fail2ban alternative for OpenBSD
On 02.11.17 20:19, Stuart Henderson wrote: On 2017-10-30, Gregory Edigarov wrote: On 29.10.17 03:20, x9p wrote: Coming from the Linux world, I wonder if there is a better alternative to fail2ban, already being used in OpenBSD servers by the majority. I suggest you NEVER use such "solutions". It's security by obscurity model, and therefore a bad very very bad thing. You'd be much safer completely turning off password authentication, using keys instead. If someone is pushing a lot of auth attempts, they can be consuming meaningful amounts of cpu. (They're usually too quick to show up in top). So restricting it can be useful from that point of view. Myself, I normally restrict ssh to connecting from a predefined list of IPs though ... And it is a right behavior when you can define such a list. myself, I just turn off password auth, and have my keys on a pen drive.
Is there an option switch to lower minimum DH strength in SSH client?
I was finally able to bring our OpenBSD based Network Management System up to the current OS release (it was a couple of years out of date) but this process broke access to a large number of older HP switches on our network. Thorough analysis of the problem and study of the source code lead me to believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: increase the minimum modulus that we will send or accept in diffie-hellman-group-exchange to 2048 bits; Within the file it further explains that this is mitigation for DH precomputation attacks. I understand and appreciate strengthening server code. But this breaks the use of SSH client leaving little recourse other than perhaps telnet with NO encryption instead of somewhat weak encryption, as the "server" is outside of our control. (I already checked that we have the latest firmware, less than one year old.) Curiously, diffie-hellman-group1-sha1, which is the only one supported by the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); I was hoping that I could use it to explicitly request smaller DH but ultimately it still dies with "Invalid key length" error. Is this an oversight or is there a particular logic to intentionally breaking compatibility with a not-insignificant base of installed equipment? Thank you, Jacob Leifman Educational Technology Weymouth Public Schools -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
Re: Apollo Lake
Às 17:29 de 02/10/2017, Chris Cappuccio escreveu: The Asrock J3710 is supported with inteldrm and ethernet etc... Predrag Punosevac [punoseva...@gmail.com] wrote: Hi Misc, The motherboard on my desktop machine just died. I would like to go fanless embedded. Something like ASRock J3455-ITX. https://www.newegg.com/Product/Product.aspx?Item=N82E16813157728&ignorebbr=1 However I am bit concern about Apollo Lake family of products. Can anyone post a dmesg? I am open for any suggestions. Best, Predrag Please find attached the dmesg from ASRock J4205-ITX. Best regards, Pedro Ramos asrock.j4205-itx.dmesg.gz Description: GNU Zip compressed data
Re: FAQ14: Growing disk partitions: fdisk
On Fri, Nov 03, 2017 at 08:07:37AM +0100, Stephane HUC "PengouinBSD" wrote: > > Le 11/03/17 à 07:27, Otto Moerbeek a écrit : > (...) > > > > My guess is that if you use duids in fstab then you should call it by > > that name withc fsck (which uses fstab). Alternatively, specify the > > mount point. > > > > -Otto > > > > > > Interesting point of view, but: > > 1/ I've not change the writing of the fstab file. It is the fact of the > installer OpenBSD. > > 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it > seems it not doing it. > > > # fsck sd0d > > fsck: sd0d: unknown special file or file system. It does use fstab, but it cannot find sd0d in fstab. > > 3/ By using duids, how i call fsck? fsck ef1ea0f909e0b8d8.d > > # fsck /tmp > > ??? That line didn't show properly in my mal client. > > 4/ And, yes, calling fsck as: > > # fsck /dev/sd0d > > seems run correctly! Yes, because if a full path is given, fsck uses that without needing to consult fstab. > > => But then why is it written in the FAQ this below, since it doesn't > seem to work? (at least with stable amd64 OpenBSD) > > "Before the partition can be mounted again, its integrity must be > checked with fsck(8): > > # fsck sd0h > " That's an error in the FAQ. It has been fixed now, -Otto
Re: Bad network performance on apu2c4
On Fri, Nov 3, 2017 at 2:15 AM, Stuart Henderson wrote: > On 2017/11/03 00:10, Christer Solskogen wrote: > > On Thu, Nov 2, 2017 at 7:24 PM, Stuart Henderson > > wrote: > > > > Forwarding is kernel-only and should be faster than userland > > sending. So if > > you're trying to determine performance when used for forwarding, > > you need to > > have other machine/s sending and receiving packets for the test > > > > > > The thing is the the uplink to my ISP is supposed to be 500Mbit/sec. > > But I only get around 400MB/s, which seems a bit low for a gigabit > > interface. > > Problem is not with the ISP, as I've tested with an old-ish laptop. (I > > even get a bit more than 500Mbit/s!) > > Perhaps current is using some extra debug-stuff that slows things down? > > > > You may get a little more with tweaks, but the real answer is the ongoing > work > to improve SMP in the OpenBSD network stack. I like the APU2 but that's > a rather fast connection and running fairly close to current limits. > Ok, thanks for the explanation ! :-) -- chs
Re: FAQ14: Growing disk partitions: fdisk
> => But then why is it written in the FAQ this below, since it doesn't > seem to work? (at least with stable amd64 OpenBSD) i tested it before giving my ok, but apparently i overlooked this detail. fixed, thanks
Re: FAQ14: Growing disk partitions: fdisk
Le 11/03/17 à 07:27, Otto Moerbeek a écrit : (...) > > My guess is that if you use duids in fstab then you should call it by > that name withc fsck (which uses fstab). Alternatively, specify the > mount point. > > -Otto > > Interesting point of view, but: 1/ I've not change the writing of the fstab file. It is the fact of the installer OpenBSD. 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it seems it not doing it. > # fsck sd0d > fsck: sd0d: unknown special file or file system. 3/ By using duids, how i call fsck? # fsck /tmp ??? 4/ And, yes, calling fsck as: # fsck /dev/sd0d seems run correctly! => But then why is it written in the FAQ this below, since it doesn't seem to work? (at least with stable amd64 OpenBSD) "Before the partition can be mounted again, its integrity must be checked with fsck(8): # fsck sd0h " -- ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< Stephane HUC as PengouinBSD or CIOTBSD b...@stephane-huc.net signature.asc Description: OpenPGP digital signature