Add Crucial P5Plus NVMe to pcidevs
This adds Crucial to the PCI vendors list and the P5Plus NVMe. ok? --Kurt Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2044 diff -u -p -r1.2044 pcidevs --- pcidevs 6 Aug 2023 14:40:25 - 1.2044 +++ pcidevs 7 Aug 2023 00:44:02 - @@ -386,6 +386,7 @@ vendor ATRONICS0x907f Atronics vendor NETMOS 0x9710 NetMos vendor 3COM2 0xa727 3Com vendor PARALLELS 0x Parallels +vendor CRUCIAL 0xc0a9 Crucial vendor TIGERJET0xe159 TigerJet Network vendor ENDACE 0xeace Endace vendor BELKIN 0xec80 Belkin Components @@ -2874,6 +2875,9 @@ product CREATIVELABS SBJOY2 0x7004 PCI G product CREATIVELABS SBJOY30x7005 PCI Gameport Joystick product CREATIVELABS PPB 0x7006 PCIE-PCI product CREATIVELABS EV19380x8938 Ectiva 1938 + +/* Crucial products */ +product CRUCIAL P5PLUS 0x5407 P5 Plus NVMe /* Cyclades products */ product CYCLADES CYCLOMY_1 0x0100 Cyclom-Y below 1M
Re: Add T490 Thunderbolt 3 controller to pcidevs
On Thu, Sep 15, 2022 at 10:36:40AM +1000, Jonathan Gray wrote: > On Wed, Sep 14, 2022 at 12:49:48PM -0400, Kurt Mosiejczuk wrote: > > This adds the IDs for the thunderbolt 3 controller parts in my T490 > > ok? > Shouldn't this be JHL6240 not JHL6420? > https://downloadmirror.intel.com/28658/eng/tbt_release_notes_17.4.77.400.txt > JHL6240 Series - "Alpine Ridge LP" > https://ark.intel.com/content/www/us/en/ark/products/94030/intel-jhl6240-thunderbolt-3-controller.html I mean, sure, if you want to be a hidebound "put the digits in the correct order" kind of person. :D Corrected diff below. --Kurt Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2004 diff -u -p -r1.2004 pcidevs --- pcidevs 2 Sep 2022 10:34:07 - 1.2004 +++ pcidevs 15 Sep 2022 00:50:17 - @@ -4008,6 +4008,9 @@ product INTEL I219_LM70x15bb I219-LM product INTEL I219_V7 0x15bc I219-V product INTEL I219_LM6 0x15bd I219-LM product INTEL I219_V6 0x15be I219-V +product INTEL JHL6240 0x15bf JHL6240 Thunderbolt 3 +product INTEL JHL6240_PCIE 0x15c0 JHL6240 Thunderbolt 3 +product INTEL JHL6240_XHCI 0x15c1 JHL6240 Thunderbolt 3 product INTEL X550EM_A_KR 0x15c2 X553 Backplane product INTEL X550EM_A_KR_L0x15c3 X553 Backplane product INTEL X550EM_A_SFP_N 0x15c4 X553 SFP+
Add T490 Thunderbolt 3 controller to pcidevs
This adds the IDs for the thunderbolt 3 controller parts in my T490 ok? --Kurt Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.2004 diff -u -p -r1.2004 pcidevs --- pcidevs 2 Sep 2022 10:34:07 - 1.2004 +++ pcidevs 14 Sep 2022 16:47:36 - @@ -4008,6 +4008,9 @@ product INTEL I219_LM70x15bb I219-LM product INTEL I219_V7 0x15bc I219-V product INTEL I219_LM6 0x15bd I219-LM product INTEL I219_V6 0x15be I219-V +product INTEL JHL6420 0x15bf JHL6420 Thunderbolt 3 +product INTEL JHL6420_PCIE 0x15c0 JHL6420 Thunderbolt 3 +product INTEL JHL6420_XHCI 0x15c1 JHL6420 Thunderbolt 3 product INTEL X550EM_A_KR 0x15c2 X553 Backplane product INTEL X550EM_A_KR_L0x15c3 X553 Backplane product INTEL X550EM_A_SFP_N 0x15c4 X553 SFP+
Re: initial 11ac support for iwm(4)
On Wed, Mar 16, 2022 at 04:11:41PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwm(4) driver.
> It allows use of 80 MHz channels and VHT MCS.
> In net80211 I added a new rate control module to support VHT rates, as
> a new file called ieee80211_ra_vht.c, derived from ieee80211_ra.c which
> we use in 11n mode. The task of this code is to determine the fastest
> VHT rate that is usable. (This was not needed to add 11ac support to
> iwx(4) because iwx(4) devices perform this task in firmware.)
> Retries at lower rates must be handled by the driver. iwm(4) does this via
> the "LQ" command which sends a table of Tx rates the firmware should use.
> So far, I have tested this successfully on iwm(4) 8265.
> In my testing performance peaks at around 250Mbit/s.
> There is no device-specific code involved so I would expect this to
> work on all cards supported by the driver.
> I will test a few more devices I have here soon, but I don't have
> access to all iwm(4) hardware variants at the moment. Testing on any
> iwm(4) device would be appreciated. Please be precise about which model
> of iwm(4) you are testing on when reporting results.
Working great so far on the 9560 in my T490.
I've been seeing VHT-MCS5 and VHT-MCS6.
--Kurt
> diff refs/heads/master refs/heads/11ac
> blob - 7df604d4b6e3913ffeef8c16e7e47637c84af881
> blob + 8ed3356b0144a014bece57fa7dcf734624be9fbb
> --- sys/conf/files
> +++ sys/conf/files
> @@ -847,6 +847,7 @@ file net80211/ieee80211_pae_input.c wlan
> file net80211/ieee80211_pae_output.c wlan
> file net80211/ieee80211_proto.c wlan
> file net80211/ieee80211_ra.c wlan
> +file net80211/ieee80211_ra_vht.c wlan
> file net80211/ieee80211_rssadapt.c wlan
> file net80211/ieee80211_regdomain.c wlan
> file netinet/if_ether.c ether
> blob - 7e0e0f4841d3ba61fcf8335bc21c0df2fb416801
> blob + ddb2d586ed0ed8c43da2c38d982d47685db940b3
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -143,6 +143,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include /* for SEQ_LT */
> #undef DPRINTF /* defined in ieee80211_priv.h */
> @@ -222,7 +223,7 @@ const struct iwm_rate {
> #define IWM_RVAL_IS_OFDM(_i_) ((_i_) >= 12 && (_i_) != 22)
>
> /* Convert an MCS index into an iwm_rates[] index. */
> -const int iwm_mcs2ridx[] = {
> +const int iwm_ht_mcs2ridx[] = {
> IWM_RATE_MCS_0_INDEX,
> IWM_RATE_MCS_1_INDEX,
> IWM_RATE_MCS_2_INDEX,
> @@ -247,7 +248,7 @@ struct iwm_nvm_section {
> };
>
> int iwm_is_mimo_ht_plcp(uint8_t);
> -int iwm_is_mimo_mcs(int);
> +int iwm_is_mimo_ht_mcs(int);
> int iwm_store_cscheme(struct iwm_softc *, uint8_t *, size_t);
> int iwm_firmware_store_section(struct iwm_softc *, enum iwm_ucode_type,
> uint8_t *, size_t);
> @@ -334,6 +335,7 @@ void iwm_init_channel_map(struct iwm_softc *, const
> ui
> const uint8_t *nvm_channels, int nchan);
> int iwm_mimo_enabled(struct iwm_softc *);
> void iwm_setup_ht_rates(struct iwm_softc *);
> +void iwm_setup_vht_rates(struct iwm_softc *);
> void iwm_mac_ctxt_task(void *);
> void iwm_phy_ctxt_task(void *);
> void iwm_updateprot(struct ieee80211com *);
> @@ -396,6 +398,8 @@ void iwm_rx_frame(struct iwm_softc *, struct mbuf *,
> i
> uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *);
> void iwm_ht_single_rate_control(struct iwm_softc *, struct ieee80211_node *,
> int, uint8_t, int);
> +void iwm_vht_single_rate_control(struct iwm_softc *, struct ieee80211_node *,
> + int, int, uint8_t, int);
> void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_node *, int, int);
> void iwm_txd_done(struct iwm_softc *, struct iwm_tx_data *);
> @@ -409,14 +413,15 @@ voidiwm_rx_compressed_ba(struct iwm_softc *, struct
> i
> void iwm_rx_bmiss(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_rx_data *);
> int iwm_binding_cmd(struct iwm_softc *, struct iwm_node *, uint32_t);
> +uint8_t iwm_get_vht_ctrl_pos(struct ieee80211com *, struct
> ieee80211_channel *);
> int iwm_phy_ctxt_cmd_uhb(struct iwm_softc *, struct iwm_phy_ctxt *, uint8_t,
> - uint8_t, uint32_t, uint32_t, uint8_t);
> + uint8_t, uint32_t, uint32_t, uint8_t, uint8_t);
> void iwm_phy_ctxt_cmd_hdr(struct iwm_softc *, struct iwm_phy_ctxt *,
> struct iwm_phy_context_cmd *, uint32_t, uint32_t);
> void iwm_phy_ctxt_cmd_data(struct iwm_softc *, struct iwm_phy_context_cmd *,
> - struct ieee80211_channel *, uint8_t, uint8_t, uint8_t);
> + struct ieee80211_channel *, uint8_t, uint8_t, uint8_t, uint8_t);
> int iwm_phy_ctxt_cmd(struct iwm_softc *, struct iwm_phy_ctxt *, uint8_t,
> - uint8_t, uint32_t, uint32_t, uint8_t);
> + uint8_t, uint32_t, uint32_t, uint8_t, uint8_t);
> int iwm_send_cmd(struct iwm_softc *, struct iwm_host_cmd *);
> int iwm_send_cmd_pdu(struct
Re: services(5): more cleanup
On Wed, May 12, 2021 at 01:13:55AM +0200, Jeremie Courreges-Anglas wrote: > I'd like to drop SWAT, unofficial and dropped by the samba project > around the switch to samba4. > > - moved smtps/465 to the standards section (rfc8314) > The new service was named "submissions". I guess we should use both > that and the "smtps" alias. > https://datatracker.ietf.org/doc/html/rfc8314#section-7.3 > ok? ok kmos --Kurt > > Index: services > === > RCS file: /d/cvs/src/etc/services,v > retrieving revision 1.100 > diff -u -p -p -u -r1.100 services > --- services 5 May 2021 11:49:17 - 1.100 > +++ services 11 May 2021 23:03:12 - > @@ -123,7 +123,7 @@ microsoft-ds 445/tcp # > Microsoft-DS > microsoft-ds 445/udp # Microsoft-DS > kpasswd 464/tcp # Kerberos 5 password > changing > kpasswd 464/udp # Kerberos 5 password > changing > -smtps465/tcp # mail message > submission (TLS) > +submissions 465/tcp smtps # mail message submission (TLS) > photuris 468/tcp # Photuris Key Management > photuris 468/udp > isakmp 500/udp # ISAKMP key management > @@ -296,7 +296,6 @@ kerberos_master 751/udp # > Kerberos 4 > kerberos_master 751/tcp # Kerberos 4 kadmin > krb_prop 754/tcp hprop # Kerberos slave propagation > krbupdate760/tcp kreg# BSD Kerberos registration > -swat 901/tcp # Samba Web Administration Tool > datametrics 1645/udp > ekshell2 2106/tcp# Encrypted kshell - UColorado, > Boulder > webster 2627/tcp# Network dictionary > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
Re: Unlock top part of uvm_fault()
On Thu, Apr 22, 2021 at 03:38:53PM +0200, Martin Pieuchot wrote:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
> I'd be interested to have this tested and see how much does that impact
> the build time of packages.
> We should be able to do the switch on an arch-by-arch basis. It's
> easier for me to develop & debug on these two architectures so I started
> with them. If you want to unlock another architecture and report back,
> I'd be glad.
Sorry for the delay on starting such a build, but one just finished for me
overnight. I don't know that it made much difference in time to build, but
it completed the full build just fine.
(It was 3 hours quicker, but it also built less packages, in particular
because all the ruby 2.6 packages are gone)
--Kurt
> Thanks,
> Martin
>
> Index: arch/amd64/amd64/trap.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/trap.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 trap.c
> --- arch/amd64/amd64/trap.c 22 Oct 2020 13:41:51 - 1.87
> +++ arch/amd64/amd64/trap.c 22 Apr 2021 13:06:54 -
> @@ -176,10 +176,7 @@ upageflttrap(struct trapframe *frame, ui
> union sigval sv;
> int signal, sicode, error;
>
> - KERNEL_LOCK();
> error = uvm_fault(>p_vmspace->vm_map, va, 0, access_type);
> - KERNEL_UNLOCK();
> -
> if (error == 0) {
> uvm_grow(p, va);
> return 1;
> @@ -261,9 +258,7 @@ kpageflttrap(struct trapframe *frame, ui
> if (curcpu()->ci_inatomic == 0 || map == kernel_map) {
> onfault = pcb->pcb_onfault;
> pcb->pcb_onfault = NULL;
> - KERNEL_LOCK();
> error = uvm_fault(map, va, 0, access_type);
> - KERNEL_UNLOCK();
> pcb->pcb_onfault = onfault;
>
> if (error == 0 && map != kernel_map)
> Index: arch/sparc64/sparc64/trap.c
> ===
> RCS file: /cvs/src/sys/arch/sparc64/sparc64/trap.c,v
> retrieving revision 1.108
> diff -u -p -r1.108 trap.c
> --- arch/sparc64/sparc64/trap.c 11 Mar 2021 11:17:00 - 1.108
> +++ arch/sparc64/sparc64/trap.c 22 Apr 2021 13:06:54 -
> @@ -773,10 +773,7 @@ data_access_fault(struct trapframe64 *tf
> if (!(addr & TLB_TAG_ACCESS_CTX)) {
> /* CTXT == NUCLEUS */
>
> - KERNEL_LOCK();
> error = uvm_fault(kernel_map, va, 0, access_type);
> - KERNEL_UNLOCK();
> -
> if (error == 0)
> return;
> goto kfault;
> @@ -792,9 +789,7 @@ data_access_fault(struct trapframe64 *tf
>
> onfault = (vaddr_t)p->p_addr->u_pcb.pcb_onfault;
> p->p_addr->u_pcb.pcb_onfault = NULL;
> - KERNEL_LOCK();
> error = uvm_fault(>p_vmspace->vm_map, (vaddr_t)va, 0, access_type);
> - KERNEL_UNLOCK();
> p->p_addr->u_pcb.pcb_onfault = (void *)onfault;
>
> /*
> @@ -959,9 +954,7 @@ text_access_fault(struct trapframe64 *tf
> uvm_map_inentry_sp, p->p_vmspace->vm_map.sserial))
> goto out;
>
> - KERNEL_LOCK();
> error = uvm_fault(>p_vmspace->vm_map, va, 0, access_type);
> - KERNEL_UNLOCK();
>
> /*
>* If this was a stack access we keep track of the maximum
> @@ -1055,9 +1048,7 @@ text_access_error(struct trapframe64 *tf
> uvm_map_inentry_sp, p->p_vmspace->vm_map.sserial))
> goto out;
>
> - KERNEL_LOCK();
> error = uvm_fault(>p_vmspace->vm_map, va, 0, access_type);
> - KERNEL_UNLOCK();
>
> /*
>* If this was a stack access we keep track of the maximum
Re: cwm: keep pointer within window on maximize/fullscreen toggle
On Thu, Apr 08, 2021 at 03:35:33AM +0200, Klemens Nanni wrote: > This scratch has been itching me for far too long and concerns the > funcionality behind those cwm(1) default bindings: This fixes one of the few problems I have with cwm. Works well for me. ok kmos --Kurt >CM-fToggle full-screen mode of current window. >CM-mToggle maximization of current window. >CM-equalToggle vertical maximization of current window. >CMS-equal Toggle horizontal maximization of current window. > > Spawn a window, maximize it in any way, move the cursor to a window > border that is not on the screen's edge and unmaximize again... > > While the window goes back the cursor stays at the screen's edge, i.e. > focus is lost to the underlaying window. > > Moving, resizing, tiling or snapping windows in any way always moves the > cursor along iff needed, e.g. using > >MS-[hjkl] Move window by a large amount; see cwmrc(5). > > to move a small window from the center to the edge keeps the cursor > within window borders -- no matter what you do with the keyboard, focus > stays on that window. > > Diff below does the same when toggling maximize/fullscreen. > > Feedback? OK? > > > > Index: client.c > === > RCS file: /cvs/xenocara/app/cwm/client.c,v > retrieving revision 1.263 > diff -u -p -r1.263 client.c > --- client.c 16 Apr 2020 13:32:35 - 1.263 > +++ client.c 8 Apr 2021 01:18:56 - > @@ -336,6 +336,7 @@ client_toggle_fullscreen(struct client_c > resize: > client_resize(cc, 0); > xu_ewmh_set_net_wm_state(cc); > + client_ptr_inbound(cc, 1); > } > > void > @@ -376,6 +377,7 @@ client_toggle_maximize(struct client_ctx > resize: > client_resize(cc, 0); > xu_ewmh_set_net_wm_state(cc); > + client_ptr_inbound(cc, 1); > } > > void > @@ -408,6 +410,7 @@ client_toggle_vmaximize(struct client_ct > resize: > client_resize(cc, 0); > xu_ewmh_set_net_wm_state(cc); > + client_ptr_inbound(cc, 1); > } > > void > @@ -440,6 +443,7 @@ client_toggle_hmaximize(struct client_ct > resize: > client_resize(cc, 0); > xu_ewmh_set_net_wm_state(cc); > + client_ptr_inbound(cc, 1); > } > > void >
Re: compress sparc64 bsd.rd
On Sun, Jan 03, 2021 at 07:19:51PM +, Miod Vallat wrote: > > Since this change went in, bsd.rd doesn't boot unless I uncompress it first. > > upgrade detected: switching to /bsd.upgrade > > Trying /bsd.upgrade... > > NOTE: random seed is being reused. > > Booting /pci@400/pci@2/pci@0/pci@c/nvme@0/disk@1:a/bsd.upgrade > > 4246528@0x100+5120@0x140cc00+3248796@0x1c0+945508@0x1f1929c > > OF_map_phys(ff84,8192,fee5,-1) failed > > no space for symbol table > > Program terminated > What machine and OpenBoot version are you using? > gzipped kernels work here (as they used to) on: > Sun Ultra 1 UPA/SBus (UltraSPARC 167MHz), No Keyboard > OpenBoot 3.1, 128 MB memory installed, Serial #8592590. > Ethernet address 8:0:20:83:1c:ce, Host ID: 80831cce. T4-1 LDOM. One of the build cluster. SPARC T4-1, No Keyboard Copyright (c) 1998, 2017, Oracle and/or its affiliates. All rights reserved. OpenBoot 4.38.9, 7.5000 GB memory available, Serial #83498844. Ethernet address 0:14:4f:fa:17:5c, Host ID: 84fa175c. Boot device: /pci@400/pci@1/pci@0/pci@0/nvme@0/disk@1 File and args: OpenBSD IEEE 1275 Bootblock 2.1 ..>> OpenBSD BOOT 1.21 ERROR: /iscsi-hba: No iscsi-network-bootpath property upgrade detected: switching to /bsd.upgrade Trying /bsd.upgrade... NOTE: random seed is being reused. Booting /pci@400/pci@1/pci@0/pci@0/nvme@0/disk@1:a/bsd.upgrade 4246528@0x100+5120@0x140cc00+3248796@0x1c0+945508@0x1f1929c OF_map_phys(3f842000,8192,fee52000,-1) failed no space for symbol table Program terminated > Rebooting with command: boot bsd.rd.gz This is interesting. The change has it just being named bsd.rd, without the .gz. --Kurt > Boot device: /sbus/SUNW,fas@e,880/sd@0,0 File and args: bsd.rd.gz > OpenBSD IEEE 1275 Bootblock 2.1 > ..>> OpenBSD BOOT 1.21 > Booting /sbus@1f,0/SUNW,fas@e,880/sd@0,0:a/bsd.rd.gz > 4249968@0x100+1680@0x140d970+3249820@0x1c0+944484@0x1f1969c > symbols @ 0xffe88400 249148+165+369384+224195 start=0x100 > console is /sbus@1f,0/zs@f,110:a > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org > (etc, etc)
Re: compress sparc64 bsd.rd
On Wed, Dec 30, 2020 at 08:37:49PM +, Miod Vallat wrote:
> Up until 6.5, sparc64 bsd.rd were gzipped kernels. This got lost during
> the Great Installation Media Unification of the 6.6 release cycle, and
> since then bsd.rd are uncompressed.
> The following diff ought to fix this and bring back sparc64 netboot
> times down to acceptable times.
Since this change went in, bsd.rd doesn't boot unless I uncompress it first.
upgrade detected: switching to /bsd.upgrade
Trying /bsd.upgrade...
NOTE: random seed is being reused.
Booting /pci@400/pci@2/pci@0/pci@c/nvme@0/disk@1:a/bsd.upgrade
4246528@0x100+5120@0x140cc00+3248796@0x1c0+945508@0x1f1929c
OF_map_phys(ff84,8192,fee5,-1) failed
no space for symbol table
Program terminated
--Kurt
> Index: miniroot/Makefile
> ===
> RCS file: /OpenBSD/src/distrib/sparc64/miniroot/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- miniroot/Makefile 18 May 2020 06:20:44 - 1.23
> +++ miniroot/Makefile 30 Dec 2020 20:35:55 -
> @@ -100,7 +100,7 @@ unconfig:
>
> .ifdef RELEASEDIR
> install:
> - cp bsd.rd ${RELEASEDIR}/bsd.rd
> + cp bsd.gz ${RELEASEDIR}/bsd.rd
> chmod a+r ${RELEASEDIR}/bsd.rd
> cp ${FS} ${RELEASEDIR}
> cp ${CDROM} ${RELEASEDIR}
>
Re: net80211: fix announced RSN (WPA2) capabilities
On Tue, Dec 08, 2020 at 12:11:07AM -0500, Kurt Mosiejczuk wrote:
> > With this patch we only echo the RSN capalibities which we actually support.
> > I am handling MFP and PBAR bits here as done elsewhere, but note that
> > neither of these features is enabled yet at run-time.
> > (We do have code for MFP; but it is untested, and disabled in all of our
> > wifi drivers. That's for another day...)
> > ok?
> I've been running this with my iwn wireless all night with no regression.
> (AP is a Unifi AC Lite).
> ok kmos
I should add that I have the BA agreement and the gapwait accounting patches
too. I ran those for a bit with no regressions before adding this one to
the mix.
--Kurt
>
> > diff 18e888c6238d4d2767f9b9d181633c8a9b33b1a3 /usr/src
> > blob - 1610fbf508ab3f6fb12721ee5c1ba7f56c0a94b3
> > file + sys/net80211/ieee80211_output.c
> > --- sys/net80211/ieee80211_output.c
> > +++ sys/net80211/ieee80211_output.c
> > @@ -941,7 +941,7 @@ ieee80211_add_rsn_body(u_int8_t *frm, struct ieee80211
> > {
> > const u_int8_t *oui = wpa ? MICROSOFT_OUI : IEEE80211_OUI;
> > u_int8_t *pcount;
> > - u_int16_t count;
> > + u_int16_t count, rsncaps;
> >
> > /* write Version field */
> > LE_WRITE_2(frm, 1); frm += 2;
> > @@ -1017,7 +1017,16 @@ ieee80211_add_rsn_body(u_int8_t *frm, struct
> > ieee80211
> > return frm;
> >
> > /* write RSN Capabilities field */
> > - LE_WRITE_2(frm, ni->ni_rsncaps); frm += 2;
> > + rsncaps = (ni->ni_rsncaps & (IEEE80211_RSNCAP_PTKSA_RCNT_MASK |
> > + IEEE80211_RSNCAP_GTKSA_RCNT_MASK));
> > + if (ic->ic_caps & IEEE80211_C_MFP) {
> > + rsncaps |= IEEE80211_RSNCAP_MFPC;
> > + if (ic->ic_flags & IEEE80211_F_MFPR)
> > + rsncaps |= IEEE80211_RSNCAP_MFPR;
> > + }
> > + if (ic->ic_flags & IEEE80211_F_PBAR)
> > + rsncaps |= IEEE80211_RSNCAP_PBAC;
> > + LE_WRITE_2(frm, rsncaps); frm += 2;
> >
> > if (ni->ni_flags & IEEE80211_NODE_PMKID) {
> > /* write PMKID Count field */
> >
> >
>
Re: net80211: fix announced RSN (WPA2) capabilities
On Mon, Dec 07, 2020 at 10:55:29PM +0100, Stefan Sperling wrote:
> When announcing RSN (WPA2) capabilities in management frames such as
> association requests, we currently echo back all RSN (i.e. WPA2)
> capabilities which were announced by our peer.
> This is bad in case the peer announces features we don't support.
> One such feature is Management Frame Protection (MFP). If we announce this
> capability then the peer sends us encrypted management frames which won't be
> processed. One symptom of this is that we fail to negotiate 11n block ack
> with APs that enable MFP if the client announces support for MFP (problem
> found by sthen@).
> With this patch we only echo the RSN capalibities which we actually support.
> I am handling MFP and PBAR bits here as done elsewhere, but note that
> neither of these features is enabled yet at run-time.
> (We do have code for MFP; but it is untested, and disabled in all of our
> wifi drivers. That's for another day...)
> ok?
I've been running this with my iwn wireless all night with no regression.
(AP is a Unifi AC Lite).
ok kmos
> diff 18e888c6238d4d2767f9b9d181633c8a9b33b1a3 /usr/src
> blob - 1610fbf508ab3f6fb12721ee5c1ba7f56c0a94b3
> file + sys/net80211/ieee80211_output.c
> --- sys/net80211/ieee80211_output.c
> +++ sys/net80211/ieee80211_output.c
> @@ -941,7 +941,7 @@ ieee80211_add_rsn_body(u_int8_t *frm, struct ieee80211
> {
> const u_int8_t *oui = wpa ? MICROSOFT_OUI : IEEE80211_OUI;
> u_int8_t *pcount;
> - u_int16_t count;
> + u_int16_t count, rsncaps;
>
> /* write Version field */
> LE_WRITE_2(frm, 1); frm += 2;
> @@ -1017,7 +1017,16 @@ ieee80211_add_rsn_body(u_int8_t *frm, struct ieee80211
> return frm;
>
> /* write RSN Capabilities field */
> - LE_WRITE_2(frm, ni->ni_rsncaps); frm += 2;
> + rsncaps = (ni->ni_rsncaps & (IEEE80211_RSNCAP_PTKSA_RCNT_MASK |
> + IEEE80211_RSNCAP_GTKSA_RCNT_MASK));
> + if (ic->ic_caps & IEEE80211_C_MFP) {
> + rsncaps |= IEEE80211_RSNCAP_MFPC;
> + if (ic->ic_flags & IEEE80211_F_MFPR)
> + rsncaps |= IEEE80211_RSNCAP_MFPR;
> + }
> + if (ic->ic_flags & IEEE80211_F_PBAR)
> + rsncaps |= IEEE80211_RSNCAP_PBAC;
> + LE_WRITE_2(frm, rsncaps); frm += 2;
>
> if (ni->ni_flags & IEEE80211_NODE_PMKID) {
> /* write PMKID Count field */
>
>
Re: [s...@spacehopper.org: Re: Remove useless line from daemon class in login.conf]
On Wed, Oct 14, 2020 at 02:41:51PM +0100, Stuart Henderson wrote:
> Just found this in my local tree still, iirc danj liked it but there
> wasn't much other enthusiasm. Any other comments? Should I just drop
> the diff? Change 'a' to use 2^10 minimum? Change to fixed 2^10 with
> no auto measurement?
I think this makes sense. I like it.
ok kmos
--Kurt
> - Forwarded message from Stuart Henderson -
>
> From: Stuart Henderson
> Date: Sat, 23 May 2020 22:08:11 +0100
> Subject: Re: Remove useless line from daemon class in login.conf
>
> On 2020/05/22 16:04, Theo de Raadt wrote:
> > Stuart Henderson wrote:
> >
> > > On 2020/05/22 17:06, Daniel Jakots wrote:
> > > > Hi,
> > > >
> > > > We used to have different numbers of blowfish rounds between the
> > > > default and daemon classes in login.conf. On Jun 26, 2016, tedu
> > > > committed "upgrade selected login.conf to use auto rounds for bcrypt"
> > > > for amd64, sparc64, i386, and maccpc [1].
> > > >
> > > > Since the class daemon inherits from the default class, the
> > > > :localcipher=blowfish,a:\
> > > > is a duplicate.
> > > >
> > > > Here's a diff to remove them.
> > >
> > > I'm OK with unifying these settings, but FWIW I never switched to auto
> > > for these, it doesn't seem all that sensible for somebody with the ability
> > > to generate enough load on the machine to be able to reduce the strength
> > > of bcrypt down to the 64 (2^6) rounds minimum.
> >
> > Yes, that is problematic.
> >
> > The minimum should be probably be raised, we should consider if auto
> > should even exist anymore.
> >
>
> As long as it doesn't allow weakening things I think auto should still
> exist so that machines can have a stronger bcrypt where it's cheap.
>
> When this was introduced, login.conf for amd64/i386/macppc/sparc64
> changed from 8 (normal users) and 9 (daemon class i.e. root) to auto.
> Since other, mainly slower, arches stayed with hardcoded 8/9 I don't
> think the current minimum reachable in the code makes sense at all.
>
> I've gone to a few machines and done:
>
> - 50 runs of "encrypt -b a" to see what setting was chosen by auto
>
> for i in `jot 50`; do echo foo | encrypt -b a; sleep .1; done | cut -d'$' -f3
> | sort | uniq -c
>
> - 50 runs of "encrypt -b 9" or "encrypt -b 10" and averaged, to see
> how long those two settings take
>
> time for i in `jot 50`; do echo foo | encrypt -b 10; done
> (divided by 50)
>
> Chosen -b 9-b 10
> Cortex-A53 1.4GHz (pi3) all 8 0.220.40
> GX-412TC 1GHz (APU2) all 8 0.160.31
> Cortex-A72 1.5GHz (pi4) all 9 0.070.14
> L5520 2.27GHz all 9 0.080.16
> E3-1225v3 3.2GHz 12x8 3x9 35x10 0.050.10
> E3-1240v5 3.5GHz all 10 0.040.08
> E3-1270v6 3.8GHz all 11 0.030.05
>
> I think bumping the minimum to 2^9 would be reasonable, there's a more
> noticeable delay on some machines but I think that's fair enough (any
> cracking is likely to be done on a fast machine, and the user can force
> it lower themselves if they want to take the risk).
>
> With a higher minimum than that the delay starts to get very noticeable
> in some cases, so I'm not sure we're ready for that yet.
>
> I think it also makes sense to use blowfish,a in login.conf on all
> arches, replacing the old 8/9. Actually -b a is already used in the
> installer for both root and the standard user on all archs, whatever
> they have in login.conf. Resulting in the situation that on some
> archs, the bcrypt created during install for root's password is
> weaker than it would be if reset after boot.
>
> So maybe this or something like it?
>
> Index: lib/libc/crypt/bcrypt.c
> ===
> RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 bcrypt.c
> --- lib/libc/crypt/bcrypt.c 26 Aug 2016 08:25:02 - 1.57
> +++ lib/libc/crypt/bcrypt.c 23 May 2020 20:16:46 -
> @@ -237,14 +237,15 @@ bcrypt_checkpass(const char *pass, const
> DEF_WEAK(bcrypt_checkpass);
>
> /*
> - * Measure this system's performance by measuring the time for 8 rounds.
> - * We are aiming for something that takes around 0.1s, but not too much over.
> + * Measure this system's performance by measuring the time for 2^9 rounds.
> + * We are aiming for something that takes around 0.1s, not too much over,
> + * but without allowing it to be too weak.
> */
> int
> _bcrypt_autorounds(void)
> {
> struct timespec before, after;
> - int r = 8;
> + int r = 9;
> char buf[_PASSWORD_LEN];
> int duration;
>
> @@ -257,12 +258,12 @@ _bcrypt_autorounds(void)
> duration += (after.tv_nsec - before.tv_nsec) / 1000;
>
> /* too quick? slow it down. */
> - while (r < 16 && duration <= 6) {
> + while (r < 16 && duration <= 75000) {
> r += 1;
>
Re: Make df output more human friendly in daily(8)
On Fri, Oct 02, 2020 at 07:55:53PM +0200, Ingo Schwarze wrote: > Daniel Jakots wrote on Thu, Oct 01, 2020 at 10:32:31PM -0400: > > Currently daily(8) runs `df -ikl`. > By default, it does not. It only does that if you set VERBOSESTATUS. Actually, it does do it by default. One needs to set VERBOSESTATUS=0 in order to stop it from doing so. --Kurt
Provide ldomctl(8) better error messages when parsing ldom.conf
Currently ldomctl init-system will error out in many situations. A number of
them involve requesting more resources than there are available. Right now
onw just gets error messages like:
resource_id larger than max_mblocks
resource_id larger than max_guests
not enough VCPU resources available
not enough memory available
With this diff, we put out numbers for most of these.
ldomctl: requested vcpus (256) > vcpu resources (64)
ldomctl: requested memory (213674622976) > memory resources (137428467712)
The other change in here is moving max_cpus to uint64_t. max_cpus was an
int but is only compared to uint_64t. So I moved max_cpus to uint64_t.
I suppose I could have gone the other way. I don't know if anyone has
strong feelings on it.
Thoughts? Comments? ok?
--Kurt
Index: config.c
===
RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v
retrieving revision 1.40
diff -u -p -r1.40 config.c
--- config.c24 May 2020 22:08:54 - 1.40
+++ config.c24 May 2020 22:10:56 -
@@ -122,7 +122,7 @@ void guest_fixup_phys_io(struct guest *)
TAILQ_HEAD(, frag) free_frags = TAILQ_HEAD_INITIALIZER(free_frags);
TAILQ_HEAD(, cpu) free_cpus = TAILQ_HEAD_INITIALIZER(free_cpus);
-int total_cpus;
+uint64_t total_cpus;
TAILQ_HEAD(, mblock) free_memory = TAILQ_HEAD_INITIALIZER(free_memory);
uint64_t total_memory;
@@ -601,7 +601,8 @@ hvmd_init_mblock(struct md *md, struct m
errx(1, "missing resource_id property in mblock node");
if (resource_id >= max_mblocks)
- errx(1, "resource_id larger than max_mblocks");
+ errx(1, "resource_id %lld larger than max_mblocks %lld", \
+ resource_id, max_mblocks);
mblock = xzalloc(sizeof(*mblock));
md_get_prop_val(md, node, "membase", >membase);
@@ -632,7 +633,8 @@ hvmd_init_console(struct md *md, struct
errx(1, "missing resource_id property in console node");
if (resource_id >= max_guests)
- errx(1, "resource_id larger than max_guests");
+ errx(1, "resource_id %lld larger than max_guests %lld", \
+ resource_id, max_guests);
console = xzalloc(sizeof(*console));
md_get_prop_val(md, node, "ino", >ino);
@@ -655,7 +657,8 @@ hvmd_init_cpu(struct md *md, struct md_n
errx(1, "missing resource_id property in cpu node");
if (resource_id >= max_cpus)
- errx(1, "resource_id larger than max-cpus");
+ errx(1, "resource_id %lld larger than max-cpus %lld", \
+ resource_id, max_cpus);
if (!md_get_prop_val(md, node, "pid", ))
errx(1, "missing pid property in cpu node");
@@ -698,7 +701,8 @@ hvmd_init_device(struct md *md, struct m
errx(1, "missing resource_id property in ldc_endpoint node");
if (resource_id >= max_devices)
- errx(1, "resource_id larger than max_devices");
+ errx(1, "resource_id %lld larger than max_devices %lld", \
+ resource_id, max_devices);
device = xzalloc(sizeof(*device));
md_get_prop_val(md, node, "gid", >gid);
@@ -754,7 +758,8 @@ hvmd_init_endpoint(struct md *md, struct
errx(1, "missing resource_id property in ldc_endpoint node");
if (resource_id >= max_guest_ldcs)
- errx(1, "resource_id larger than max_guest_ldcs");
+ errx(1, "resource_id %lld larger than max_guest_ldcs %lld", \
+ resource_id, max_guest_ldcs);
if (ldc_endpoints[resource_id]) {
/*
@@ -800,7 +805,8 @@ hvmd_init_guest(struct md *md, struct md
errx(1, "missing resource_id property in guest node");
if (resource_id >= max_guests)
- errx(1, "resource_id larger than max_guests");
+ errx(1, "resource_id %lld larger than max_guests %lld", \
+ resource_id, max_guests);
guest = xzalloc(sizeof(*guest));
TAILQ_INIT(>cpu_list);
@@ -2816,10 +2822,19 @@ build_config(const char *filename, int n
primary_num_cpus = total_cpus - num_cpus;
if (primary_memory == 0 && total_memory > memory)
primary_memory = total_memory - memory;
- if (num_cpus > total_cpus || primary_num_cpus == 0)
- errx(1, "not enough VCPU resources available");
- if (memory > total_memory || primary_memory == 0)
- errx(1, "not enough memory available");
+ if (num_cpus > total_cpus)
+ errx(1, "requested vcpus (%lld) > vcpu resources (%lld)", \
+ num_cpus, total_cpus);
+ if (primary_num_cpus == 0)
+ errx(1, "No vcpus left for primary domain");
+ if (memory > total_memory)
+ errx(1, "requested memory (%lld) > memory resources (%lld)", \
+ memory, total_memory);
+ if
Re: ldomctl: Make init-sytem -n check vcpu and memory constraints
On Fri, May 22, 2020 at 04:39:03PM -0600, Theo de Raadt wrote: > Why is VCPU upper case? > I don't see any other place it is upper case. I don't know. It was that way before the change. It's in the file twice as uppercase, both times when using errx(3). It's not used as lowercase when using errx. It has been that way for 7+ years. It can easily be changed though. --Kurt
Re: ldomctl: Make init-sytem -n check vcpu and memory constraints
On Fri, May 22, 2020 at 11:05:21PM +0200, Klemens Nanni wrote:
> kmos noted that `-n' wouldn't bark at overallocation.
> Hoisting PRI reading and moving the `-n' check after constraint checking
> makes it bail on invalid configs just as expected:
> $ cat ldom.conf
> domain guest {
> vdisk "/dev/null"
> vcpu 128
> memory 1G
> }
> $ ldomctl init-sytem -n ldom.conf ; echo $?
> 0
> $ ./obj/ldomctl init-sytem -n ldom.conf
> ldomctl: not enough VCPU resources available
> OK?
Tested and works for me.
ok kmos
--Kurt
>
> Index: config.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 config.c
> --- config.c 17 Mar 2020 21:24:22 - 1.36
> +++ config.c 22 May 2020 21:01:17 -
> @@ -2792,18 +2798,6 @@ build_config(const char *filename, int n
> SIMPLEQ_INIT(_list);
> if (parse_config(filename, ) < 0)
> exit(1);
> - if (noaction)
> - exit(0);
> -
> - pri = md_read("pri");
> - if (pri == NULL)
> - err(1, "unable to get PRI");
> - hvmd = md_read("hv.md");
> - if (hvmd == NULL)
> - err(1, "unable to get Hypervisor MD");
> -
> - pri_init(pri);
> - pri_alloc_memory(hv_membase, hv_memsize);
>
> SIMPLEQ_FOREACH(domain, _list, entry) {
> if (strcmp(domain->name, "primary") == 0) {
> @@ -2822,6 +2816,19 @@ build_config(const char *filename, int n
> errx(1, "not enough VCPU resources available");
> if (memory > total_memory || primary_memory == 0)
> errx(1, "not enough memory available");
> +
> + if (noaction)
> + exit(0);
> +
> + pri = md_read("pri");
> + if (pri == NULL)
> + err(1, "unable to get PRI");
> + hvmd = md_read("hv.md");
> + if (hvmd == NULL)
> + err(1, "unable to get Hypervisor MD");
> +
> + pri_init(pri);
> + pri_alloc_memory(hv_membase, hv_memsize);
>
> hvmd_init(hvmd);
> primary = primary_init();
>
Re: Add CAVEATS to ldom.conf(5) man page
On Wed, May 20, 2020 at 09:35:39AM -0600, Theo de Raadt wrote: > Kurt Mosiejczuk wrote: > > I suppose we could look at having ldomctl throw a warning if there are not > > enough ldom and ttyV devices for the configuration file presented. > Maybe it can test access to the required resources as it starts up. Probably wise for both ldomd on startup and ldomctl when processing ldom.conf. --Kurt
Re: Add CAVEATS to ldom.conf(5) man page
On Wed, May 20, 2020 at 09:24:20AM -0600, Theo de Raadt wrote: > Kurt Mosiejczuk wrote: > > > Seems reasonable, what about adopting vmd(8) CAVEATS for ldomd(8)? > > > Running out of devices with more guests can be nasty do debug. > > Here's an attempt at doing that. There isn't a man page for the ldom > > devices nor is there one specifically for the ttyV* devices, so I left > > the ".Xr" off of those. > Let's step back. Why is it nasty to debug? > What errors are shown? What errors are not shown? Is there an error > reporting missing? Should the code *inspect* for that condition, and > report a warning or error, on stderr or via logging? > If it did, would that make the proposed manual page change redundant? Yeah. The code definitely needs improvement on that front. I've seen parts where it isn't checking return codes on operations on the devices. Part of this started because rcctl reports ldomd starting just fine but ldomd dies if it cannot access a device. I suppose we could look at having ldomctl throw a warning if there are not enough ldom and ttyV devices for the configuration file presented. --Kurt
Add CAVEATS to ldom.conf(5) man page
On Mon, May 18, 2020 at 08:12:00PM +0200, Klemens Nanni wrote: > On Mon, May 18, 2020 at 01:20:07PM -0400, Kurt Mosiejczuk wrote: > > Learning how LDOMs work on this T4-1 and we only create 8 devices > > (each /dev/ldom* and /dev/ttyV*) by default. The now-commonly-available > > T4-1 machines can do far more than that pretty easily, so bump up the > > number created by default from 8 to 16. > Seems reasonable, what about adopting vmd(8) CAVEATS for ldomd(8)? > Running out of devices with more guests can be nasty do debug. Here's an attempt at doing that. There isn't a man page for the ldom devices nor is there one specifically for the ttyV* devices, so I left the ".Xr" off of those. ok? --Kurt Index: ldom.conf.5 === RCS file: /cvs/src/usr.sbin/ldomctl/ldom.conf.5,v retrieving revision 1.13 diff -u -p -r1.13 ldom.conf.5 --- ldom.conf.5 21 Feb 2020 19:39:28 - 1.13 +++ ldom.conf.5 19 May 2020 23:48:22 - @@ -131,3 +131,10 @@ upon resetting the machine. .Pp If in doubt, leave enough memory unused for the hypervisor to reserve. On bigger T4 based machines, 1024 megabytes has proven to suffice. +.Sh CAVEATS +Each guest requires one ldom device and one ttyV device per configured logical +domain. Administrators may need to create additional devices using +.Xr MAKEDEV 8 +if more than 16 logical domains are configured. + +
Re: Increase default number of devices created for LDOMs on sparc64
On Mon, May 18, 2020 at 08:43:25PM +0200, Otto Moerbeek wrote: > On Mon, May 18, 2020 at 06:27:04PM -, Miod Vallat wrote: > > > Learning how LDOMs work on this T4-1 and we only create 8 devices > > > (each /dev/ldom* and /dev/ttyV*) by default. The now-commonly-available > > > T4-1 machines can do far more than that pretty easily, so bump up the > > > number created by default from 8 to 16. > > > ok? > > MAKEDEV is a generated file. Edit the second-to-last line of MAKEDEV.md > > to add the extra 8 nodes. > After edit MAKEDEV.md, commit MAKEDEV.md, run make and commit the resulting > MAKEDEV file. Thank you. This should be the right way. ok? --Kurt Index: MAKEDEV.md === RCS file: /cvs/src/etc/etc.sparc64/MAKEDEV.md,v retrieving revision 1.91 diff -u -p -r1.91 MAKEDEV.md --- MAKEDEV.md 23 Jan 2020 02:47:29 - 1.91 +++ MAKEDEV.md 19 May 2020 23:41:32 - @@ -177,8 +177,8 @@ target(all, drm, 0, 1, 2, 3)dnl target(all, switch, 0, 1, 2, 3)dnl twrget(all, s64_tzs, tty, a, b, c, d)dnl twrget(all, s64_czs, cua, a, b, c, d)dnl -twrget(all, vcc, ttyV, 0, 1, 2, 3, 4, 5, 6, 7)dnl +twrget(all, vcc, ttyV, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f)dnl twrget(all, vldc_hvctl, hvctl)dnl twrget(all, vldc_spds, spds)dnl -twrget(all, vldc_ldom, ldom, 0, 1, 2, 3, 4, 5, 6, 7)dnl +twrget(all, vldc_ldom, ldom, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)dnl target(all, vdsp, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)dnl
Increase default number of devices created for LDOMs on sparc64
Learning how LDOMs work on this T4-1 and we only create 8 devices (each /dev/ldom* and /dev/ttyV*) by default. The now-commonly-available T4-1 machines can do far more than that pretty easily, so bump up the number created by default from 8 to 16. ok? --Kurt Index: MAKEDEV === RCS file: /cvs/src/etc/etc.sparc64/MAKEDEV,v retrieving revision 1.204 diff -u -p -r1.204 MAKEDEV --- MAKEDEV 18 Apr 2020 21:29:57 - 1.204 +++ MAKEDEV 18 May 2020 14:33:34 - @@ -634,19 +634,21 @@ local) all) R vdsp0 vdsp1 vdsp2 vdsp3 vdsp4 vdsp5 vdsp6 vdsp7 vdsp8 vdsp9 R vdsp10 vdsp11 vdsp12 vdsp13 vdsp14 vdsp15 ldom0 ldom1 ldom2 - R ldom3 ldom4 ldom5 ldom6 ldom7 spds hvctl ttyV0 ttyV1 ttyV2 - R ttyV3 ttyV4 ttyV5 ttyV6 ttyV7 cuaa cuab cuac cuad ttya ttyb - R ttyc ttyd switch0 switch1 switch2 switch3 drm0 drm1 drm2 - R drm3 bpp0 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 - R sd7 sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 - R tun3 bio pty0 fd1 fd1B fd1C fd1D fd1E fd1F fd1G fd1H fd0 - R fd0B fd0C fd0D fd0E fd0F fd0G fd0H diskmap vscsi0 ch0 audio0 - R audio1 audio2 dt bpf fuse pppac pppx hotplug ptm local - R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 - R rmidi4 rmidi5 rmidi6 rmidi7 video0 video1 uk0 random lpa0 - R lpa1 lpa2 lpt0 lpt1 lpt2 tty00 tty01 tty02 tty03 tty04 tty05 - R tty06 tty07 tty08 tty09 tty0a tty0b ttyh0 ttyh1 pf wd0 wd1 - R wd2 wd3 std st0 st1 fd + R ldom3 ldom4 ldom5 ldom6 ldom7 ldom8 ldom9 ldom10 ldom11 + R ldom12 ldom13 ldom14 ldom15 spds hvctl ttyV0 ttyV1 ttyV2 + R ttyV3 ttyV4 ttyV5 ttyV6 ttyV7 ttyV8 ttyV9 ttyVa ttyVb ttyVc + R ttyVd ttyVe ttyVf cuaa cuab cuac cuad ttya ttyb ttyc ttyd + R switch0 switch1 switch2 switch3 drm0 drm1 drm2 drm3 bpp0 + R vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 + R cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3 bio pty0 + R fd1 fd1B fd1C fd1D fd1E fd1F fd1G fd1H fd0 fd0B fd0C fd0D + R fd0E fd0F fd0G fd0H diskmap vscsi0 ch0 audio0 audio1 audio2 + R dt bpf fuse pppac pppx hotplug ptm local wscons pci0 pci1 + R pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4 rmidi5 + R rmidi6 rmidi7 video0 video1 uk0 random lpa0 lpa1 lpa2 lpt0 + R lpt1 lpt2 tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 + R tty08 tty09 tty0a tty0b ttyh0 ttyh1 pf wd0 wd1 wd2 wd3 std + R st0 st1 fd ;; wd*|sd*)
FYI - ftp.usa.openbsd.org outage today (Thursday March 12th)
RIT is shutting down power to the building ftp.usa.openbsd.org resides in today at 4pm. Accordingly, I will be shutting the mirror down at 3pm. This will be a short outage, and I will be turning things back on by 9pm tonight. (All times are EDT) FYI --Kurt Mosiejczuk
Re: Add -R alias to -r for scp(1)
On Wed, Jan 01, 2020 at 09:31:29PM -0500, Kurt Mosiejczuk wrote: > On Wed, Jan 01, 2020 at 09:15:14PM -0500, Ted Unangst wrote: > > Kurt Mosiejczuk wrote: > > > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an > > > alias for -r to scp(1) for those assuming consistency with cp(1). > > But it doesn't implement cp -R semantics. It does the copy the way cp -r > > does. > > (For symlinks, etc.) > According to cp(1), there *isn't* a -r. That's the whole reason I found it > odd we use the opposite flag for scp(1). I see, I had to be grubbing around in the STANDARDS section of the man page to know it exists. It also says I shouldn't use it. --Kurt
Re: Add -R alias to -r for scp(1)
On Wed, Jan 01, 2020 at 09:15:14PM -0500, Ted Unangst wrote: > Kurt Mosiejczuk wrote: > > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an > > alias for -r to scp(1) for those assuming consistency with cp(1). > But it doesn't implement cp -R semantics. It does the copy the way cp -r does. > (For symlinks, etc.) According to cp(1), there *isn't* a -r. That's the whole reason I found it odd we use the opposite flag for scp(1). --Kurt
Add -R alias to -r for scp(1)
cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an
alias for -r to scp(1) for those assuming consistency with cp(1).
--Kurt
Index: scp.1
===
RCS file: /cvs/src/usr.bin/ssh/scp.1,v
retrieving revision 1.87
diff -u -p -r1.87 scp.1
--- scp.1 30 Nov 2019 07:07:59 - 1.87
+++ scp.1 2 Jan 2020 01:08:01 -
@@ -215,6 +215,12 @@ Recursively copy entire directories.
Note that
.Nm
follows symbolic links encountered in the tree traversal.
+.It Fl R
+A synonym for
+.Fl r .
+(To mimic the
+.Xr cp 1
+flag for recursive copy).
.It Fl S Ar program
Name of
.Ar program
Index: scp.c
===
RCS file: /cvs/src/usr.bin/ssh/scp.c,v
retrieving revision 1.206
diff -u -p -r1.206 scp.c
--- scp.c 9 Sep 2019 02:31:19 - 1.206
+++ scp.c 2 Jan 2020 01:08:01 -
@@ -404,7 +404,7 @@ main(int argc, char **argv)
fflag = Tflag = tflag = 0;
while ((ch = getopt(argc, argv,
- "dfl:prtTvBCc:i:P:q12346S:o:F:J:")) != -1) {
+ "dfl:pRrtTvBCc:i:P:q12346S:o:F:J:")) != -1) {
switch (ch) {
/* User-visible flags. */
case '1':
@@ -452,6 +452,7 @@ main(int argc, char **argv)
case 'p':
pflag = 1;
break;
+ case 'R':
case 'r':
iamrecursive = 1;
break;
Re: [Patch]: check-lib-depends(1) fix typo in manpage
On Sun, Dec 22, 2019 at 05:34:40PM -0800, Lev Lazinskiy wrote: > Hi everyone, > This is my first patch, so I apologize in advance if there are any > errors. I have been reading every man page for my own benefit and I came > across a typo in check-lib-depends(1). This patch fixes it. > I plan on sending any other fixes that I find, out of curiosity is it > better to send a new email for every man page, or to batch these up? > Index: share/man/man1/check-lib-depends.1 > === > RCS file: /cvs/src/share/man/man1/check-lib-depends.1,v > retrieving revision 1.3 > diff -u -p -u -r1.3 check-lib-depends.1 > --- share/man/man1/check-lib-depends.14 Mar 2019 15:25:16 - > 1.3 > +++ share/man/man1/check-lib-depends.123 Dec 2019 01:11:41 - > @@ -44,7 +44,7 @@ from the > directory, or look directly inside a > .Ar package . > .Pp > -Likewise, it can also verify dependencies off installed packages, > +Likewise, it can also verify dependencies of installed packages, > or figure them out directly from the port directory. > .Pp > .Nm Committed. Thanks! --Kurt
Re: [PATCH] portgen(1) man page: Add py type
On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> As far as plists go, unless the port only supports py2 or only
> supports py3, it ought to generate the plist with FLAVOR=python3
> and then prefix any lines ending in ${MODPY_PYCACHE}/ with
> ${MODPY_COMMENT}.
Yes. I was describing that to afresh1 at one point. Someone else brought
up setting REVISION while doing so. I had seen that danj's aliases for
regenerating the plist set REVISION to 999, although I had a problem
related to have done that at one point. Is setting the REVISION while
doing so still necessary? If it is, what does it do? (It'd probably be
nice to know the reasoning before making a tool incorporate it :) ).
--Kurt
ftp.usa.openbsd.org mirror unavailable Monday afternoon through Wednesday morning
RIT is doing two overnight power outages again starting 5pm (EDT) Monday May 13th. Accordingly, ftp5.usa.openbsd.org (which is also ftp3.usa.openbsd.org and ftp.usa.openbsd.org) will be down from Monday Afternoon until the power comes back on Wednesday morning on May 15th. --Kurt Mosiejczuk
ftp5 outages today and tomorrow (May 14th and 15th)
RIT is turning off the power for electrical maintenance today and tomorrow. ftp5 will be out 4pm EST until 1am EST. This dance will happen again tomorrow, but the outage will last until 7am EST the following morning. FYI --Kurt Mosiejczuk
Re: Patch to add 2 words to share/dict/web2
On Mon, Mar 05, 2018 at 08:07:53PM -0700, Theo de Raadt wrote: > If we added the complete english language, /usr would be full. > (Already a few people having trouble with multiple upgrades + the > new kernel/library link kits) If we had definitions, I might agree with you that it might fill /usr. The file is 2.4M though, and even if we got super-studious and doubled its size, we'd be less than 5M. It's also not like a library where we keep the old version around. That said, this isn't a hill to die on. It bothered me how much we (tech industry in general) will spend so much space on stupid crap but we have spellcheckers that only carry a subset of words in use. I bitched about it online and someone pointed out I could help do something about it. So, (eventually) I did. --Kurt
Patch to add 2 words to share/dict/web2
It was annoying me that "aspirational" wasn't in common spellcheck dictionaries and afresh@ suggested I submit a patch to at least get the situation corrected for OpenBSD. Before getting around to this, I noticed "supremacist" wasn't there either so added that. Index: share/dict/web2 === RCS file: /cvs/src/share/dict/web2,v retrieving revision 1.8 diff -u -p -r1.8 web2 --- share/dict/web2 16 Dec 2017 13:01:22 - 1.8 +++ share/dict/web2 5 Mar 2018 22:02:55 - @@ -14387,6 +14387,7 @@ aspirant aspirata aspirate aspiration +aspirational aspirator aspiratory aspire @@ -195461,6 +195462,7 @@ supraventricular supraversion supravital supraworld +supremacist supremacy suprematism supreme
Removing dead unused cruft from /usr/src/lib/libssl/test
I was out hunting for unused cruft in the source tree and found a bunch of stuff in /usr/src/libssl/test that is unused. (Reference to ULTRIX in bctest brought me there). Each of the following files are not only ancient, but I can find no other reference to them in the rest of the source tree, not even the other files in /usr/src/libssl/test : CAssdh.cnf CAssdsa.cnf CAssrsa.cnf Sssdsa.cnf Sssrsa.cnf VMSca-response.1 VMSca-response.2 bctest testreq2.pem v3-cert1.pem v3-cert2.pem Below is a diff to send them all to the attic. Index: lib/libssl/test/CAssdh.cnf === RCS file: lib/libssl/test/CAssdh.cnf diff -N lib/libssl/test/CAssdh.cnf --- lib/libssl/test/CAssdh.cnf 5 Oct 1998 20:13:05 - 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,24 +0,0 @@ -# -# SSLeay example configuration file. -# This is mostly being used for generation of certificate requests. -# -# hacked by iang to do DH certs - CA - -RANDFILE = ./.rnd - - -[ req ] -distinguished_name= req_distinguished_name -encrypt_rsa_key = no - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = CU -countryName_value = CU - -organizationName = Organization Name (eg, company) -organizationName_value= La Junta de la Revolucion - -commonName= Common Name (eg, YOUR name) -commonName_value = Junta - Index: lib/libssl/test/CAssdsa.cnf === RCS file: lib/libssl/test/CAssdsa.cnf diff -N lib/libssl/test/CAssdsa.cnf --- lib/libssl/test/CAssdsa.cnf 5 Oct 1998 20:13:06 - 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,23 +0,0 @@ -# -# SSLeay example configuration file. -# This is mostly being used for generation of certificate requests. -# -# hacked by iang to do DSA certs - CA - -RANDFILE = ./.rnd - - -[ req ] -distinguished_name= req_distinguished_name -encrypt_rsa_key = no - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = ES -countryName_value = ES - -organizationName = Organization Name (eg, company) -organizationName_value= Hermanos Locos - -commonName= Common Name (eg, YOUR name) -commonName_value = Hermanos Locos CA Index: lib/libssl/test/CAssrsa.cnf === RCS file: lib/libssl/test/CAssrsa.cnf diff -N lib/libssl/test/CAssrsa.cnf --- lib/libssl/test/CAssrsa.cnf 5 Oct 1998 20:13:06 - 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,24 +0,0 @@ -# -# SSLeay example configuration file. -# This is mostly being used for generation of certificate requests. -# -# create RSA certs - CA - -RANDFILE = ./.rnd - - -[ req ] -distinguished_name= req_distinguished_name -encrypt_key = no - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = ES -countryName_value = ES - -organizationName = Organization Name (eg, company) -organizationName_value= Hermanos Locos - -commonName= Common Name (eg, YOUR name) -commonName_value = Hermanos Locos CA - Index: lib/libssl/test/Sssdsa.cnf === RCS file: lib/libssl/test/Sssdsa.cnf diff -N lib/libssl/test/Sssdsa.cnf --- lib/libssl/test/Sssdsa.cnf 5 Oct 1998 20:13:06 - 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,27 +0,0 @@ -# -# SSLeay example configuration file. -# This is mostly being used for generation of certificate requests. -# -# hacked by iang to do DSA certs - Server - -RANDFILE = ./.rnd - - -[ req ] -distinguished_name= req_distinguished_name -encrypt_rsa_key = no - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = ES -countryName_value = ES - -organizationName= Organization Name (eg, company) -organizationName_value = Tortilleras S.A. - -0.commonName = Common Name (eg, YOUR name) -0.commonName_value= Torti - -1.commonName = Common Name (eg, YOUR name) -1.commonName_value= Gordita - Index: lib/libssl/test/Sssrsa.cnf === RCS file: lib/libssl/test/Sssrsa.cnf diff -N
Remove BUGS reference to SunOS <3.0 from rpcinfo.8
While reading up on portmap and rpcinfo, I noticed the BUGS section of rpcinfo.8 talked about problems interacting with NFS on SunOS versions < 3.0. While I suppose that fact might win a UNIX trivia contest for someone some day, I'd think we can do without it. Index: rpcinfo.8 === RCS file: /cvs/src/usr.bin/rpcinfo/rpcinfo.8,v retrieving revision 1.14 diff -u -p -u -p -r1.14 rpcinfo.8 --- rpcinfo.8 1 Sep 2010 14:43:34 - 1.14 +++ rpcinfo.8 20 Jul 2017 14:26:24 - @@ -195,12 +195,3 @@ service use: .Rs .%T "RPC Programming Guide" .Re -.Sh BUGS -In releases prior to SunOS 3.0, the Network File System (NFS) did not -register itself with the portmapper; -.Nm -cannot be used to make -.Tn RPC -calls to the -.Tn NFS -server on hosts running such releases.
Correction for www/faq/faq10.html - yptest is dead
Was looking over the YP section of the FAQ and was intrigued to learn of yptest(8). Except it was sent to the attic years ago. So this eliminates its mention as a useful YP debugging tool. Index: faq/faq10.html === RCS file: /cvs/www/faq/faq10.html,v retrieving revision 1.267 diff -u -p -r1.267 faq10.html --- faq/faq10.html 16 Apr 2017 16:04:47 - 1.267 +++ faq/faq10.html 2 Jun 2017 18:01:33 - @@ -623,9 +623,8 @@ from the YP server, but that data will n ... -Other useful tools for debugging your YP setup include -http://man.openbsd.org/ypmatch;>ypmatch(1) and -http://man.openbsd.org/yptest;>yptest(8). +Another useful tool for debugging your YP setup is +http://man.openbsd.org/ypmatch;>ypmatch(1). The second part of configuring a YP client involves editing local configuration
Re: Question on getcwd(3) behavior on OpenBSD
On Fri, Jun 02, 2017 at 04:37:08PM +0200, Alexander Bochmann wrote: > > to OpenBSD 6.1. I've found out that git will abort in one scenario > > where there is a directory in the tree where the user has execute > > permissions but not read permissions. > Did you use the git version from ports (2.12.2)? Between that and > git 2.13 they added a patch "for FreeBSD", which ignores the EACCES: > https://github.com/git/git/commit/49a8fe8e962ed929cf5bed5520e581025f5bfe9a > Since I don't see any conditionals around that, I assume it should > solve the problem on OpenBSD too? (Didn't try though.) I did use the package. I saw that link and was going to look at it, wondering if it was compiled in for OpenBSD or not. Although it wasn't clear it ignored the result from the release notes. I'll take a look at that and see if it helps. Thanks! --Kurt
Question on getcwd(3) behavior on OpenBSD
Just recently converted the main user machines students and faculty use to OpenBSD 6.1. I've found out that git will abort in one scenario where there is a directory in the tree where the user has execute permissions but not read permissions. I traced down this abort to a getcwd(3) call where git gets EACCES, and decides the world is ending. On the Linux server that was retired, the getcwd(3) call just works. Some folks suggested to me that getcwd(3) should work just fine in this scenario, so I installed a FreeBSD VM to see what happens there. git is perfectly happy there. That getcwd(3) works just fine. Ok, since it's not just Linux behaving this way, I'm now wondering if this is a bug in OpenBSD's getcwd(3). I realize this may also be a POSIX corner case. You can duplicate this scenario like this: $ mkdir -p test/foo $ chmod 111 test $ git init --bare test/foo fatal: unable to get current working directory: Permission denied $ So, is this a case where OpenBSD interprets POSIX differently? Is it a bug? Is git being stupid here? (This last one is probably yes). Thanks, --Kurt
FYI - ftp5.usa.openbsd.org down overnight May 24th, 25th, and 26th
RIT (where ftp5 is hosted) is doing electrical substation work overnight for three nights starting Wednesday May 24th. Power will be out from 5pm-7am each time so I will be shutting everything down starting at 4pm and bringing it all back up by 8am the following morning. All times are EDT. FYI --Kurt Mosiejczuk
ftp5.usa.openbsd.org going down Saturday September 24th at 10pm - Back Sunday morning
Due to a power outage happening this Sunday morning, ftp5.usa.openbsd.org will be going down around 10pm EDT (UTC-4) on Saturday September 24th. I will bring it back up when the power comes back at 9:30am EDT on Sunday September 25th, so it should be back up by 11am EDT. FYI --Kurt Mosiejczuk
ftp5.usa.openbsd.org going down 7pm-1am Sunday September 18th
Due to a just-announced power outage happening this Sunday night, ftp5.usa.openbsd.org will be going down around 7pm EDT (UTC-4) on Sunday September 14th. I will bring it back up when the power comes back at midnight EDT, so it should be back up by 1am EDT. FYI --Kurt Mosiejczuk
ftp5.usa.openbsd.org mirror up for the day, going down again overnight
I brought ftp5 back up this morning around 7:15am EDT and checked it was working, it will be going down again around 4pm EDT since RIT is doing the second half of their electrical substation work tonight from 5pm until 7am. I'll bring it back up tomorrow morning shortly after 7am. --Kurt Mosiejczuk
FYI - ftp5.usa.openbsd.org down tonight and tomorrow night
ftp5 is hosted here at RIT and they are doing work on the substation that supplies our electricity tonight (May 25th) and tomorrow night (May 26th). The power goes out at 5pm EDT so I'm shutting everything down starting at 4pm. Power comes back at 7am EDT tomorrow and Friday so it will be back up by 8am EDT on Thursday and Friday. Sorry for the late notice, I sent it to mirrors-discuss first and someone pointed out I should send it here, but I've been running around getting ready for the shutdown. --Kurt Mosiejczuk
[PATCH] Add note about tty/cua devices in tip change
I have a console server that was using tip and pre-emptively switched to cu now since tip is on its way out, and some of my connections didn't work because I was using /dev/ttyXX entries instead of /dev/cuaXX entries. I figure adding a mention of that might save some grief. Here's a patch for faq/current.html --Kurt Index: current.html === RCS file: /cvs/www/faq/current.html,v retrieving revision 1.597 diff -u -p -r1.597 current.html --- current.html27 Apr 2015 14:59:54 - 1.597 +++ current.html27 Apr 2015 19:28:48 - @@ -511,6 +511,9 @@ tip(1) has been removed in favour of cu( rm /usr/bin/tip /usr/share/man/man1/tip.1 /pre +(You may need to switch from using tty(4) devices to cua(4) devices +in /etc/remote.) + h3 id =201504272015/04/27 - _file user added/h3 A new em_file/em user and group have been added to support privilege separation in file(1). sysmerge(8) should be run to ensure it is added.
Cleanup of dead code in pr(1)
Inspired by the work I saw bcallah@ doing in cleaning up vi I started
hunting ifdefs for other operating systems and dead code that was ifdef'd
out.
First up is a cleanout of dead code in /usr/bin/pr. The patch kills code
that is ifdef'd out. Resulting binary is identical.
--Kurt
Index: pr.c
===
RCS file: /cvs/src/usr.bin/pr/pr.c,v
retrieving revision 1.35
diff -u -p -r1.35 pr.c
--- pr.c8 Feb 2015 23:40:34 - 1.35
+++ pr.c7 Apr 2015 16:49:20 -
@@ -1396,36 +1396,6 @@ otln(char *buf, int cnt, int *svips, int
return(0);
}
-#ifdef notused
-/*
- * inskip():skip over pgcnt pages with lncnt lines per page
- *file is closed at EOF (if not stdin).
- *
- *infFILE * to read from
- *pgcntnumber of pages to skip
- *lncntnumber of lines per page
- */
-int
-inskip(FILE *inf, int pgcnt, int lncnt)
-{
-int c;
-int cnt;
-
-while(--pgcnt 0) {
- cnt = lncnt;
- while ((c = getc(inf)) != EOF) {
- if ((c == '\n') (--cnt == 0))
- break;
- }
- if (c == EOF) {
- if (inf != stdin)
- (void)fclose(inf);
- return(1);
- }
-}
-return(0);
-}
-#endif
/*
* nxtfile:returns a FILE * to next file in arg list and sets the
@@ -1927,9 +1897,6 @@ setup(int argc, char *argv[])
if (merge) {
if ((clcnt = argc - eoptind) = 1) {
clcnt = CLCNT;
-#ifdef stupid
- merge = 0;
-#endif
}
} else
clcnt = CLCNT;
Cleanup of PAM and other gunk in /usr/sbin/pppd
Here is some more ifdef cleanup. This patch kills all the gunk for PAM
which we don't need. Also gone is some stuff for other operating systems
like ultrix and NeXT.
--Kurt
Index: auth.c
===
RCS file: /cvs/src/usr.sbin/pppd/auth.c,v
retrieving revision 1.34
diff -u -p -r1.34 auth.c
--- auth.c 16 Jan 2015 06:40:19 - 1.34
+++ auth.c 7 Apr 2015 17:10:14 -
@@ -86,18 +86,11 @@
#include sys/socket.h
#include utmp.h
#include fcntl.h
-#if defined(_PATH_LASTLOG) defined(_linux_)
-#include lastlog.h
-#endif
#include netdb.h
#include netinet/in.h
#include arpa/inet.h
-#ifdef USE_PAM
-#include security/pam_appl.h
-#endif
-
#ifdef HAS_SHADOW
#include shadow.h
#ifndef PW_PPP
@@ -733,74 +726,6 @@ check_passwd(unit, auser, userlen, apass
return ret;
}
-/*
- * This function is needed for PAM.
- */
-
-#ifdef USE_PAM
-static char *PAM_username = ;
-static char *PAM_password = ;
-
-#ifdef PAM_ESTABLISH_CRED /* new PAM defines :(^ */
-#define MY_PAM_STRERROR(err_code) (char *) pam_strerror(pamh,err_code)
-#else
-#define MY_PAM_STRERROR(err_code) (char *) pam_strerror(err_code)
-#endif
-
-static int pam_conv (int num_msg,
- const struct pam_message **msg,
- struct pam_response **resp,
- void *appdata_ptr)
-{
-int count = 0, replies = 0;
-struct pam_response *reply = NULL;
-int size = 0;
-
-for (count = 0; count num_msg; count++)
- {
- struct pam_response *newreply;
- int newsize = size + sizeof (struct pam_response);
- newreply = realloc (reply, newsize); /* ANSI: is malloc() if
reply==NULL */
- if (!newreply) {
- free(reply);
- reply = NULL;
- return PAM_CONV_ERR;
- }
- reply = newreply;
- size = newsize;
-
- switch (msg[count]-msg_style)
- {
- case PAM_PROMPT_ECHO_ON:
- reply[replies].resp_retcode = PAM_SUCCESS;
- reply[replies++].resp = strdup(PAM_username); /* never NULL */
- break;
-
- case PAM_PROMPT_ECHO_OFF:
- reply[replies].resp_retcode = PAM_SUCCESS;
- reply[replies++].resp = strdup(PAM_password); /* never NULL */
- break;
-
- case PAM_TEXT_INFO:
- reply[replies].resp_retcode = PAM_SUCCESS;
- reply[replies++].resp = NULL;
- break;
-
- case PAM_ERROR_MSG:
- default:
- free (reply);
- return PAM_CONV_ERR;
- }
- }
-
-if (resp)
-*resp = reply;
-else
-free (reply);
-
-return PAM_SUCCESS;
-}
-#endif
/*
* plogin - Check the user name and password against the system
@@ -820,56 +745,6 @@ plogin(user, passwd, msg, msglen)
int *msglen;
{
-#ifdef USE_PAM
-
-struct pam_conv pam_conversation;
-pam_handle_t *pamh;
-int pam_error;
-/*
- * Fill the pam_conversion structure
- */
-memset (pam_conversation, '\0', sizeof (struct pam_conv));
-pam_conversation.conv = pam_conv;
-
-pam_error = pam_start (ppp, user, pam_conversation, pamh);
-
-if (pam_error != PAM_SUCCESS) {
- *msg = MY_PAM_STRERROR (pam_error);
- return UPAP_AUTHNAK;
-}
-/*
- * Define the fields for the credential validation
- */
-(void) pam_set_item (pamh, PAM_TTY, devnam);
-PAM_username = user;
-PAM_password = passwd;
-/*
- * Validate the user
- */
-pam_error = pam_authenticate (pamh, PAM_SILENT);
-if (pam_error == PAM_SUCCESS) {
-pam_error = pam_acct_mgmt (pamh, PAM_SILENT);
-
- /* start a session for this user. Session closed when link ends. */
- if (pam_error == PAM_SUCCESS)
- (void) pam_open_session (pamh, PAM_SILENT);
-}
-
-*msg = MY_PAM_STRERROR (pam_error);
-
-PAM_username =
-PAM_password = ;
-/*
- * Clean up the mess
- */
-(void) pam_end (pamh, pam_error);
-
-if (pam_error != PAM_SUCCESS)
-return UPAP_AUTHNAK;
-/*
- * Use the non-PAM methods directly
- */
-#else /* #ifdef USE_PAM */
struct passwd *pw;
char *tty;
@@ -910,12 +785,6 @@ plogin(user, passwd, msg, msglen)
|| strcmp(crypt(passwd, pw-pw_passwd), pw-pw_passwd) != 0)
return (UPAP_AUTHNAK);
-/* These functions are not enabled for PAM. The reason for this is that */
-/* there is not necessarily a passwd entry for this user. That is */
-/* real purpose of 'PAM' -- to virtualize the account data from the */
-/* application. If you want to do the same thing, write the entry in*/
-/* the 'session' hook. */
-
/*
* Write a wtmp entry for this user.
*/
@@ -941,8 +810,6 @@ plogin(user, passwd, msg, msglen)
}
#endif
-#endif /* #ifdef USE_PAM */
-
syslog(LOG_INFO, user %s logged in, user);
logged_in = TRUE;
@@ -955,33 +822,12 @@ plogin(user, passwd, msg, msglen)
static
Re: Tweak to daily df to use human output
On Mon, Apr 13, 2015 at 02:02:26PM -0400, Kenneth Gober wrote: easier to read, but less useful may not be an improvement. for people with large filesystems they will start seeing output like: /dev/sd0e 3.6T 2.3T 1.3T 66% (followed by inode info) that's all well and good, but it's then possible to add 40 GB of data to the filesystem, and have this output: /dev/sd0e 3.6T 2.3T 1.3T 66% (inode info, perhaps with more inodes used) in other words, the -h flag causes df to treat large changes in disk usage as not worth reporting (assuming you consider 40GB a large change). when a change in utilization of 40GB becomes invisible, the output of df arguably becomes much less useful (especially if you keep a history of daily emails so that you can track changes over time). In my own .kshrc file I have an alias df=df -h which I find very useful, but for the daily emails I would prefer the output to stay as it is. if df had a -m option akin to the -k option I wouldn't mind switching to that, but I think -h swings the pendulum too far from more detail than I need all the way into too little. That's an excellent point. I had originally looked for a -m option for df, but saw only -k or -h (It seems that -m is a GNUism). I briefly thought about using BLOCKSIZE, but df puts the blocksize into that column, eliminating the desired benefit. It seems this would require more thought. --Kurt
Cleanup of tset(1) - Part 1 of 2
More ifdef trimming. This time tset is up. Binary is still identical after this diff. --Kurt Index: tset.c === RCS file: /cvs/src/usr.bin/tset/tset.c,v retrieving revision 1.36 diff -u -p -r1.36 tset.c --- tset.c 18 Sep 2013 16:21:30 - 1.36 +++ tset.c 13 Apr 2015 20:45:25 - @@ -83,9 +83,6 @@ #if HAVE_GETTTYNAM HAVE_TTYENT_H #include ttyent.h #endif -#ifdef NeXT -char *ttyname(int fd); -#endif #if HAVE_SIZECHANGE # if !defined(sun) || !TERMIOS @@ -95,29 +92,11 @@ char *ttyname(int fd); # endif #endif -#if NEED_PTEM_H -/* they neglected to define struct winsize in termios.h -- it's only - in termio.h */ -#include sys/stream.h -#include sys/ptem.h -#endif - #include dump_entry.h #include transform.h MODULE_ID($Id: tset.c,v 1.36 2013/09/18 16:21:30 millert Exp $) -/* - * SCO defines TIOCGSIZE and the corresponding struct. Other systems (SunOS, - * Solaris, IRIX) define TIOCGWINSZ and struct winsize. - */ -#ifdef TIOCGSIZE -# define IOCTL_GET_WINSIZE TIOCGSIZE -# define IOCTL_SET_WINSIZE TIOCSSIZE -# define STRUCT_WINSIZE struct ttysize -# define WINSIZE_ROWS(n) n.ts_lines -# define WINSIZE_COLS(n) n.ts_cols -#else # ifdef TIOCGWINSZ # define IOCTL_GET_WINSIZE TIOCGWINSZ # define IOCTL_SET_WINSIZE TIOCSWINSZ @@ -125,7 +104,6 @@ MODULE_ID($Id: tset.c,v 1.36 2013/09/18 # define WINSIZE_ROWS(n) n.ws_row # define WINSIZE_COLS(n) n.ws_col # endif -#endif extern char **environ;
Cleanup of tset(1) - Part 2 of 2
This is cleaning up completely redundant #defines housed in #ifdefs in
tset.c
This does not provide an identical binary, since it trims out redundant
information from speeds[]. The diff is fairly straightforward though.
I avoided trimming out the potentially redundant defines that use EXTA and
EXTB since they are defined in /usr/include/termios.h. I'm not sure of the
point of those in the code, but I held off for now.
Are there reasons/scenarios where all the ifdefs around the baud rates of
19200 and up are used/needed? Would it be worth cleaning them up for easier
to read code?
--Kurt
? processed-tset.c
? termsort.c
? tset
Index: tset.c
===
RCS file: /cvs/src/usr.bin/tset/tset.c,v
retrieving revision 1.36
diff -u -p -r1.36 tset.c
--- tset.c 18 Sep 2013 16:21:30 - 1.36
+++ tset.c 13 Apr 2015 19:47:43 -
@@ -299,18 +299,6 @@ static const SPEEDS speeds[] =
/* sgttyb may define up to this point */
#ifdef B19200
{19200, B19200},
-#endif
-#ifdef B38400
-{38400, B38400},
-#endif
-#ifdef B19200
-{19200, B19200},
-#endif
-#ifdef B38400
-{38400, B38400},
-#endif
-#ifdef B19200
-{19200, B19200},
#else
#ifdef EXTA
{19200, EXTA},
Tweak to daily df to use human output
I came up with the following tweak to get the filesystem status in the daily emails back into 80 columns. I liked the addition of the inodes in the emails, but that addition started pushing many of the filesystems past the 80 column mark, making them hard to read. --Kurt Index: daily === RCS file: /cvs/src/etc/daily,v retrieving revision 1.82 diff -u -p -r1.82 daily --- daily 17 Nov 2014 18:19:08 - 1.82 +++ daily 7 Apr 2015 02:07:07 - @@ -130,7 +130,7 @@ next_part Checking subsystem status: if [ X$VERBOSESTATUS != X0 ]; then echo echo disks: - df -ikl + df -ihl echo dump W fi
Re: SIIG 4S PCIe 4-port Serial Card
William Ahern wrote: The puc(4) man page lists the SIIG Cyber 4S PCI as supported. I just inserted a SIIG Cyber 4S PCIe. I figured it would look the same as the PCI card, considering that the new chip is named OXPCIe954, similar to the old OXPCI954. But obviously that was hopelessly naive. Instead I get: vendor Oxford, unknown product 0xc208 (class communications subclass serial, rev 0x00) at pci13 dev 0 function 0 not configured It looks like the vendor id is PCI_VENDOR_OXFORD2, and not PCI_VENDOR_SIIG. Any pointers on what data structure and defines I should try adding? It looks like the actual PUC driver is simple enough, I just need the card to be recognized. I'm running stock OpenBSD 5.1/amd64 on a Soekris net6501. When I put a variant in, I looked at the following files: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pucdata.c?annotate=1.51 Search for henning and the section starting on line 551 is the patch in this file you want. This was the other (which didn't go in right away since I mangled the patch in email): http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pcidevs?annotate=1.1434 Look for miod or 1.1434 to find that one line change. Now, mine mostly worked, except communication was garbled. Mine was one of the cards with a faster crystal. Assuming your just isn't recognized, some work with something like lspci would get the exact identifiers for you. It's been 4-5 years since then, and I had to look up these files, but I suspect this is the areas you are looking for. --Kurt Mosiejczuk
Re: smtpd require auth
Bob Beck wrote: On Tue, Oct 9, 2012 at 11:04 AM, Bob Beck b...@obtuse.com wrote: I think Bob's point is that then you use 587 (with auth) for yourselves and 25 (without auth) for mail from the rest of the intertubes. Yes, that's my point :) Along with the fact that this is probably the 99% use case out there. Keeping with an OpenBSD type phliosophy says that the config should be geared towards that with a minimum of knobs, especially knobs you need to turn to be in the 99% use case. That's all I'm saying :) How about auth being authentication required and an optional auth (or optional-auth) to allow the flexibility for setups like the one Gilles was talking about? Giving you the lack of surprise for turning on auth, without locking out the case where you don't want to require it. --Kurt
