Re: S-nail, ssh, and vi

[Predrag Punosevac]

mar...@martinbrandenburg.com wrote:

> > From owner-misc+M164041=martin=martinbrandenburg@openbsd.org Sat Apr 22 
> > 21:43:17 2017
> > Date: Sat, 22 Apr 2017 21:42:55 -0400
> > From: Predrag Punosevac 
> > To: misc@openbsd.org
> > Subject: S-nail, ssh, and vi
> >
> > Can anybody help me understand what am I seeing. Namely I am trying to 
> > send an e-mail using S-nail 14.8.12 (the last one which cleanly compiles
> > on OpenBSD). Actual package is 14.8.9. Ever since I upgraded to 6.1 I
> > noticed that if I try to use ~v in order to load my e-mail into vi from
> > the base for editing I have normal behaviour if the existing message is
> > empty but if I had started typing I see
> >
> >
> > ~v [LogLevel VERBOSE]
> > ~v [LogLevel DEBUG]
> 
> You never saw this before 6.1?  It's been this way for years.
> 
> It's coming from ssh.  If you type an escape sequence immediately after
> a newline ssh might recognize it.  Type return followed by ~? in ssh for
> more information.
> 
> ~v/~V won't be of much use unless you're debugging ssh, but you'll wonder
> how you ever lived without some of them.
> 
> ~. will kill a stuck session.
> ~C will let you set up and tear down -L/-R/-D forwardings
> ~^Z will send ssh to the background
> and ~~ will let you type ~ which is most useful for typing this list
> 
> In short, type ~~v for vi when running mail in ssh.
> 
> Martin

Works for me! I only run mail in ssh when I am away from my home to
bypass worning messages from my mail providers. I have never seen this
before. 

Best,
Predrag

Re: understanding ldapd log error messages

[Predrag Punosevac]

Predrag Punosevac write:
> Hi misc,
> 
> ldapd on one of my two ldap servers stop working overnight
> 

ldapd died again overnight. I noticed that this started happening not
right after the upgrade to 6.1 but less than 24h  after I added a
person to my LDAP database. How do I go about debugging a daemon? I am
reading

http://man.openbsd.org/rc.d

and I have used option -d when a daemon fails to start but I really need
to catch what happens when ldapd dies and redirect to the log file. 

Best,
Predrag



> # uname -a  
> OpenBSD atlas.int.autonlab.org 6.1 GENERIC.MP#20 amd64
> 
> I manually restarted it and it appears to work OK.  I started digging
> little bit through the log files and I see the following in my
> /var/log/message file before and after the upgrade. Can somebody help me
> understand what I see and point me to some kind reading? Is my database
> corrupted for some reason? The LDAP server overall has being working
> really well for the past 3.5 years with Red Hat, FreeBSD, and OpenBSD
> clients. I have being upgrading this server since the last database
> format change (I think OpenBSD 5.3 or 5.4).
> 
> Best,
> Predrag

Re: S-nail, ssh, and vi

[martin]

> From owner-misc+M164041=martin=martinbrandenburg@openbsd.org Sat Apr 22 
> 21:43:17 2017
> Date: Sat, 22 Apr 2017 21:42:55 -0400
> From: Predrag Punosevac 
> To: misc@openbsd.org
> Subject: S-nail, ssh, and vi
>
> Can anybody help me understand what am I seeing. Namely I am trying to 
> send an e-mail using S-nail 14.8.12 (the last one which cleanly compiles
> on OpenBSD). Actual package is 14.8.9. Ever since I upgraded to 6.1 I
> noticed that if I try to use ~v in order to load my e-mail into vi from
> the base for editing I have normal behaviour if the existing message is
> empty but if I had started typing I see
>
>
> ~v [LogLevel VERBOSE]
> ~v [LogLevel DEBUG]

You never saw this before 6.1?  It's been this way for years.

It's coming from ssh.  If you type an escape sequence immediately after
a newline ssh might recognize it.  Type return followed by ~? in ssh for
more information.

~v/~V won't be of much use unless you're debugging ssh, but you'll wonder
how you ever lived without some of them.

~. will kill a stuck session.
~C will let you set up and tear down -L/-R/-D forwardings
~^Z will send ssh to the background
and ~~ will let you type ~ which is most useful for typing this list

In short, type ~~v for vi when running mail in ssh.

Martin

S-nail, ssh, and vi

[Predrag Punosevac]

Can anybody help me understand what am I seeing. Namely I am trying to 
send an e-mail using S-nail 14.8.12 (the last one which cleanly compiles
on OpenBSD). Actual package is 14.8.9. Ever since I upgraded to 6.1 I
noticed that if I try to use ~v in order to load my e-mail into vi from
the base for editing I have normal behaviour if the existing message is
empty but if I had started typing I see


~v [LogLevel VERBOSE]
~v [LogLevel DEBUG]


oo


Best,
Predrag

Intel Corporation 82576 Virtual Function not recognized

[Jiri B]

Hi,

I'm playing a little bit with KVM and SR-IOV and OpenBSD doesn't
recognize 'Intel Corporation 82576 Virtual Function'[1], ie. VF on
my Intel 82756 dual-port network card activated on a Linux box.


...
vendor "Intel", unknown product 0x10ca (class network subclass ethernet, rev 
0x01) at pci0 dev 8 function 0 not configured
^^ sr-iov vfio
...

# pcidump - 0:8:0 
 0:8:0: Intel unknown
0x: Vendor ID: 8086 Product ID: 10ca
0x0004: Command: 0002 Status: 0010
0x0008: Class: 02 Subclass: 00 Interface: 00 Revision: 01
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR mem 64bit addr: 0xfebe4000/0x4000
0x0018: BAR empty ()
0x001c: BAR mem 64bit addr: 0xfebe8000/0x4000
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 8086 Product ID: a04c
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0x0070: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
0x00a0: Capability 0x10: PCI Express
Link Speed: unknown (0) / 2.5 GT/s Link Width: x0 / x4


Steps to reproduce:

- boot a Linux box with supported HW with kernel param intel_iommu=on
- echo 1 > /sys/module/vfio_iommu_type1/parameters/allow_unsafe_interrupts
- Linux kernel module vfio_pci should be loaded
- Linux kernel module igb should be loaded
- find SR-IOV device via lspci
- enable 1 VF, eg.: echo 1 > /sys/bus/pci/devices/:02:00.1/sriov_numvfs
- check what's pci address of new VF, eg:
  virsh nodedev-dumpxml pci__02_00_1 | grep -A1 'virt_function'
- attached VF as 'hostdev' device into OpenBSD KVM VM[2]

j.

[1] http://cateee.net/lkddb/web-lkddb/IGBVF.html
[2] 
https://www.suse.com/documentation/sles-12/book_virt/data/sec_libvirt_config_io.html
 or

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/chap-Guest_virtual_machine_device_configuration.html#sect-PCI_devices-PCI_passthrough


OpenBSD 6.1-current (GENERIC) #10: Fri Apr 21 18:39:14 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 519933952 (495MB)
avail mem = 499625984 (476MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6a00 (9 entries)
bios0: vendor SeaBIOS version "rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org" 
date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel Core i7 9xx (Nehalem Class Core i7), 1866.88 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,HV,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"PNP0A06" at acpi0 not configured
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
em0 at pci0 dev 2 function 0 "Intel 82574L" rev 0x00: apic 0 int 10, address 
00:25:90:3c:66:01
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio0
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 5120MB, 512 bytes/sector, 10485760 sectors
virtio0: msix shared
uhci0 at pci0 dev 4 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 11
uhci1 at pci0 dev 4 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 10
uhci2 at pci0 dev 4 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 10
ehci0 at pci0 dev 4 function 

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Jeff]

On Fri, 21 Apr 2017, Jeff wrote:

> On Fri, 21 Apr 2017, Stefan Sperling wrote:
>
> > On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote:
> > > Hi,
> > >
> > > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> > > I attempted to update to OpenBSD 6.1 using the files first from:
> > >
> > > http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64
> > >
> > > Then from:
> > >
> > > https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64
> > >
> > > First I tried to copy bsd.rd to / and boot from it.  When I boot
> > > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> > > OpenBSD 6.0.
> >
> > Did you actually type '/boot bsd.rd'?
> > When booting from softraid you need to pass the virtual 'sr' drive
> > as part of the boot path. Try again with: boot sr0a:/bsd.rd
> >
> > >From the boot_sparc64(8) man page:
> >
> >  To boot from a softraid(4) volume by default, boot-device must be set 
> > to
> >  a disk device hosting a chunk of the softraid volume:
> >
> >ok setenv boot-device disk0
> >
> >  and boot-file must contain the (sr) device name of the softraid volume
> >  and optionally a partition letter and/or kernel:
> >
> >ok setenv boot-file sr0a:/bsd
> >
>
> Hi Stefan,
>
> Thanks!
>
> I must have missed that man page when I originally installed 6.0.
> Booting with sr0a:/bsd* did work but it took a much longer time
> loading the symbols with both bsd & bsd.rd.  I'll be sure to read
> that man page and try again later today after I'm done working (in
> case I muck it up again).
>
> Using a non-standard name for the bsd.rd file seems to help clarify
> things.
>
> ok printenv boot-device
> boot-device = disk1:a /pci@1f,0/pci@1/scsi@8/disk@1,0:a
>
> ok boot disk1:a /bsd.rd.61
> ...
> Executing last command: boot disk1:a /bsd.rd.61
> Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
> /bsd.rd.61
> OpenBSD IEEE 1275 Bootblock 1.4
> ..>> OpenBSD BOOT 1.7
> Can't read disk label.
> Can't open disk label package
> Drive not ready
> Can't read disk label.
> Can't open disk label package
> sr0*
> open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/etc/random.seed: No such file or 
> directory
> open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/bsd.rd.61: No such file or directory
>
> Boot:
>
> lom> reset
>
> ok boot sr0a:/bsd.rd.61
> Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
> sr0a:/bsd.rd.61
> OpenBSD IEEE 1275 Bootblock 1.4
> ..>> OpenBSD BOOT 1.7
> Can't read disk label.
> Can't open disk label package
> Drive not ready
> Can't read disk label.
> Can't open disk label package
> sr0*
> Booting sr0:a/bsd.rd.61
> 4045496@0x100+1352@0x13dbab8+3251904@0x180+942400@0x1b19ec0
> symbols @ 0xfff42300 120 start=0x100
> console is /pci@1f,0/pci@1,1/isa@7/serial@0,3f8
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> OpenBSD 6.1 (RAMDISK) #55: Sat Apr  1 17:41:52 MDT 2017
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
>
>

Hi,

Booting from sr0a seemed to do the trick to get my system upgraded to
6.1.  Unfortunately, it's now panicing frequently with, "panic:
psycho0: uncorrectable DMA error" but on different commands each time.
I know this is old hardware so I'm trying to swap out hardware to see
if it's hardware related but it's been pretty stable until I attempted
to upgrade from 6.0.  Thus far, I've swapped out the DIMMs.  I think
I'm going to try installing 6.1 on a spare V120 partially to see if
I still have issues and partially to have a backup system.

Question: After upgrading to 6.1, it's still booting with "OpenBSD
BOOT 1.7" but I noticed when booting from the burned install61.iso
CD, it reports BOOT 1.9.  I tried running "installboot sd2"  but
there's no change.  Is there another method I'm overlooking to
update the boot image?

Thanks!

-Jeff

Re: tmux fail to start when using if-shell in .tmux.conf

[Erling Westenvik]

On Sat, Apr 22, 2017 at 11:21:17PM +0200, Theo Buehler wrote:
> On Sat, Apr 22, 2017 at 10:35:50PM +0200, Erling Westenvik wrote:
> > Hi!
> >
> > After upgrading to today's snapshot (amd64, April 22) tmux refused to
> > load with exit status 1 and error message 'lost server'. I quickly found the
> > culprit in my .tmux.conf; a left over experimental if-shell statement I
> > used a while ago when I needed nested tmux sessions:
> >
> > if-shell "echo $SSH_TTY | grep /dev/ttyp" "set -g prefix C-r" "set -g 
> > prefix C-Space"
> >
> > After commenting out the if-shell statement tmux loads fine, but – why
> > did this cause tmux not to load in the first place? Running the
> > statement as a command in tmux as soon tmux is running works just fine!?
>
> I ran into this as well; nicm fixed this bug in -current
> (cmd-if-sh.c r1.54).
>
> There was a change (cfg.c r1.56) that causes the commands in the config
> file run outside of any client. A bug in the if-sh implementation led to
> a NULL dereference in that situation, and this segfault killed the tmux
> server (as indicated by the 'lost server' message you saw).
>
> When run inside a tmux client, the pointer that was NULL in the previous
> paragraph points to the client, and now the dereference is valid, so the
> command worked properly.

Indeed. Updated, compiled and installed the sources
(/usr/src/usr.bin/tmux), and that was it. Thanks!

--
Erling Westenvik

Re: tmux fail to start when using if-shell in .tmux.conf

[Theo Buehler]

On Sat, Apr 22, 2017 at 10:35:50PM +0200, Erling Westenvik wrote:
> Hi!
> 
> After upgrading to today's snapshot (amd64, April 22) tmux refused to
> load with exit status 1 and error message 'lost server'. I quickly found the
> culprit in my .tmux.conf; a left over experimental if-shell statement I
> used a while ago when I needed nested tmux sessions:
> 
> if-shell "echo $SSH_TTY | grep /dev/ttyp" "set -g prefix C-r" "set -g prefix 
> C-Space"
> 
> After commenting out the if-shell statement tmux loads fine, but – why
> did this cause tmux not to load in the first place? Running the
> statement as a command in tmux as soon tmux is running works just fine!?

I ran into this as well; nicm fixed this bug in -current
(cmd-if-sh.c r1.54).

There was a change (cfg.c r1.56) that causes the commands in the config
file run outside of any client. A bug in the if-sh implementation led to
a NULL dereference in that situation, and this segfault killed the tmux
server (as indicated by the 'lost server' message you saw).

When run inside a tmux client, the pointer that was NULL in the previous
paragraph points to the client, and now the dereference is valid, so the
command worked properly.

Re: Strange PF behaviour after 6.0 -> 6.1 pgrade

[Sjöholm Per-Olov]

> On 21 Apr 2017, at 14:22, Sjöholm Per-Olov  wrote:
> 
> 
>> On 21 Apr 2017, at 10:34, Stuart Henderson  wrote:
>> 
>> On 2017-04-20, Sjöholm Per-Olov  wrote:
>>> Could it be any buffers that is causing this in 6.1 but not in 6.0 ?
>> 
>> There were changes that would allow larger TCP buffers in 6.1. This
>> would not have made a difference to normal or natted connections from
>> non-OpenBSD going through PF to non-OpenBSD but could possibly affect
>> some configurations with proxies (though only if PF rules were already
>> dodgy - you would have active states in "pfctl -ss|grep -A1 tcp"
>> without wscale values if this was the case).
>> 
>> Might be worth bumping up the pf log level and seeing if system logs
>> give you more clues. Default is "error", you need "notice" to get the
>> ones which might give useful clues (loose state match warnings or
>> state mismatch errors).  (On a busy machine, be ready to back-off on
>> the debug level in case it causes too much load).
>> 
>> 
> 
> Another addition… This is what the problem actually looks like
> 
> ## 1 ## When the problem is ongoing…. Telnet from internet to DMZ server FAIL
> [sjoholmp@dewey ~]$ telnet mail.dyn.incedo.org 25
> Trying 155.4.8.28...
> ^C
> 
> ## 2 ## This looks like this
> Apr 21 14:06:28.751796 rule 573/(match) pass in on em3: 168.235.89.110.42126 
> > 192.168.1.12.25: S 2597688027:2597688027(0) win 29200  1460,sackOK,timestamp 668227520 0,nop,wscale 6> (DF)
> Apr 21 14:06:28.751824 rule 63/(match) block out on em3: 155.4.8.28.25 > 
> 168.235.89.110.42126: R 0:0(0) ack 2597688028 win 0 (DF)
> 
> 
> ## 3 ## Reload PF
> root@xanadu:/var/log#pfctl -f /etc/pf.conf
> root@xanadu:/var/log#
> 
> 
> ## 4 ## Telnet from internet again WORKS
> [sjoholmp@dewey ~]$ telnet mail.dyn.incedo.org 25
> Trying 155.4.8.28...
> Connected to mail.dyn.incedo.org.
> Escape character is '^]'.
> 220 mail.dyn.incedo.org ESMTP Sendmail; Fri, 21 Apr 2017 14:08:16 +0200
> 
> 
> ## 5 ## Looks like this
> Apr 21 14:08:16.239213 rule 573/(match) pass in on em3: 168.235.89.110.42168 
> > 192.168.1.12.25: S 4285065753:4285065753(0) win 29200  1460,sackOK,timestamp 668335004 0,nop,wscale 6> (DF)
> Apr 21 14:08:16.239267 rule 89/(match) pass out on vlan3: 
> 168.235.89.110.42168 > 192.168.1.12.25: S 4285065753:4285065753(0) win 29200 
>  (DF)
> 
> ## 6 ## After a few hours the same problem occurs again which requires a PF 
> reload 
> 
> The dmesg extra output ater pfctl -x notice only shows..
> pf: pf_map_addr: selected address 155.4.8.28
> 
> 
> I have serious problems with 6.1. I will probably go back to 6.0. I will 
> giveit  to the end of this day and check what I can…
> 
> Peo
> 


I downgraded to 6.0 stable again and all problems are gone.

As I cleaned up sysctl and reduced the ruleset to basic and still had the 
problem, I guess there eventually could be a problem with 6.1 kernel. I tried 
both UNI and MP kernel with same problem.

/Peo

Re: flaky network connection after 6.1 upgrade

[Colton Lewis]

On Thu, Apr 20, 2017 at 5:31 AM, Stefan Sperling  wrote:
> On Wed, Apr 19, 2017 at 10:08:01AM +0200, Stefan Sperling wrote:
>> On Tue, Apr 18, 2017 at 11:29:22PM -0500, Colton Lewis wrote:
>> > > Can you show me a dmesg please, specifically the lines which are
>> > > related to your wifi card?
>>
>> > athn0 at pci6 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 8 int 17
>> > athn0: AR9280 rev 2 (1T2R), ROM rev 11, address 00:15:af:cd:f2:4f
>>
>> Thank you! This confirms my suspicion that your wifi card is a weird one.
>> It can receive MIMO but cannot send MIMO (2 Rx chains but only 1 Tx chain).
>>
>> Likely there's a bug in the code which fails to account for this situation.
>> AFAIK this kind of device has not been tested before.
>>
>> I'll take a look.
>
> Please try this patch.
>
> This patch makes unequal numbers of Tx and Rx streams work in 11n mode.
> I have tested this patch by artificially limiting iwm(4) to one Tx stream.
> This works as expected (AP sends with two streams, iwm(4) sends with one).
>
> I still cannot explain why 11g mode became worse for you such that only 11b
> mode works. I cannot recall any change which would make a difference between
> 6.0 and 6.1 in that regard. Are you sure you were testing 11g mode correctly?
> When you switched your athn client to 11g mode, did your AP follow this change
> or did it continue treating your client as 11n capable? A quirk like that
> would explain this discrepancy.
>
> Index: sys/net80211/ieee80211.h
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211.h,v
> retrieving revision 1.58
> diff -u -p -r1.58 ieee80211.h
> --- sys/net80211/ieee80211.h12 May 2016 18:18:48 -  1.58
> +++ sys/net80211/ieee80211.h19 Apr 2017 13:47:13 -
> @@ -612,8 +612,8 @@ enum {
>  /* Bits 96-100: Tx MCS set */
>  #define IEEE80211_TX_MCS_SET_DEFINED   0x01
>  #define IEEE80211_TX_RX_MCS_NOT_EQUAL  0x02
> -#define IEEE80211_TX_SPATIAL_STREAMS   0x18
> -#define IEEE80211_TX_UNEQUAL_MODULATION0x20
> +#define IEEE80211_TX_SPATIAL_STREAMS   0x0c
> +#define IEEE80211_TX_UNEQUAL_MODULATION0x10
>  /* Bits 101-127: Reserved */
>
>  /*
> Index: sys/net80211/ieee80211_mira.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_mira.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 ieee80211_mira.c
> --- sys/net80211/ieee80211_mira.c   28 Jan 2017 16:01:36 -  1.10
> +++ sys/net80211/ieee80211_mira.c   20 Apr 2017 09:37:53 -
> @@ -81,6 +81,7 @@ int   ieee80211_mira_check_probe_timers(st
> struct ieee80211_node *);
>  void   ieee80211_mira_probe_next_rate(struct ieee80211_mira_node *,
> struct ieee80211_node *);
> +intieee80211_mira_valid_tx_mcs(struct ieee80211com *, int);
>  uint32_t ieee80211_mira_valid_rates(struct ieee80211com *,
> struct ieee80211_node *);
>  uint32_t ieee80211_mira_mcs_below(struct ieee80211_mira_node *, int);
> @@ -991,6 +992,21 @@ ieee80211_mira_probe_next_rate(struct ie
> ni->ni_txmcs = ieee80211_mira_next_mcs(mn, ni);
>  }
>
> +int
> +ieee80211_mira_valid_tx_mcs(struct ieee80211com *ic, int mcs)
> +{
> +   uint32_t ntxstreams = 1;
> +   static const int max_mcs[] = { 7, 15, 23, 31 };
> +
> +   if ((ic->ic_tx_mcs_set & IEEE80211_TX_RX_MCS_NOT_EQUAL) == 0)
> +   return isset(ic->ic_sup_mcs, mcs);
> +
> +   ntxstreams += ((ic->ic_tx_mcs_set & IEEE80211_TX_SPATIAL_STREAMS) >> 
> 2);
> +   if (ntxstreams < 1 || ntxstreams > 4)
> +   panic("invalid number of Tx streams: %u", ntxstreams);
> +   return (mcs <= max_mcs[ntxstreams - 1] && isset(ic->ic_sup_mcs, mcs));
> +}
> +
>  uint32_t
>  ieee80211_mira_valid_rates(struct ieee80211com *ic, struct ieee80211_node 
> *ni)
>  {
> @@ -999,8 +1015,11 @@ ieee80211_mira_valid_rates(struct ieee80
>
> for (i = 0;
> i < MIN(IEEE80211_MIRA_NUM_MCS, IEEE80211_HT_NUM_MCS); i++) {
> -   if (isset(ic->ic_sup_mcs, i) && isset(ni->ni_rxmcs, i))
> -   valid_mcs |= (1 << i);
> +   if (!isset(ni->ni_rxmcs, i))
> +   continue;
> +   if (!ieee80211_mira_valid_tx_mcs(ic, i))
> +   continue;
> +   valid_mcs |= (1 << i);
> }
>
> return valid_mcs;

I applied the patch and compiled a new kernel using the stable branch.
11n and 11g both work now,
but with significantly worse performance than 11b. Downloads are about
40% slower.

$ curl http://download.thinkbroadband.com/200MB.zip -O
was my test.

tmux fail to start when using if-shell in .tmux.conf

[Erling Westenvik]

Hi!

After upgrading to today's snapshot (amd64, April 22) tmux refused to
load with exit status 1 and error message 'lost server'. I quickly found the
culprit in my .tmux.conf; a left over experimental if-shell statement I
used a while ago when I needed nested tmux sessions:

if-shell "echo $SSH_TTY | grep /dev/ttyp" "set -g prefix C-r" "set -g prefix 
C-Space"

After commenting out the if-shell statement tmux loads fine, but – why
did this cause tmux not to load in the first place? Running the
statement as a command in tmux as soon tmux is running works just fine!?

Erling

--
Erling Westenvik

BeagleBone Black GPIO

[Byron Klippert]

Hello Misc,

I'm trying to get a BeagleBone Black talking onewire and i2c via GPIO to
several off-board ICs through gpioow(4) and gpioiic(4) respectively.

I've got the following in /etc/rc.securelevel:

# Set GPIO pin directions for USR LEDs and give them names
gpioctl gpio1 21 set out USR0
gpioctl gpio1 22 set out USR1
gpioctl gpio1 23 set out USR2
gpioctl gpio1 24 set out USR3

# Attach a onewire(4) bus on a gpioow(4) device using 1 GPIO pin
gpioctl gpio1 attach gpioow 29 0x1

# Attach a i2c(4) bus on a gpioiic(4) device using 2 GPIO pins
gpioctl gpio2 attach gpioiic 2 0x3


dmesg shows the masters attaching after boot:

beagle:/home/bK $ dmesg
OpenBSD 6.1 (GENERIC) #89: Sat Apr  1 19:14:03 MDT 2017
dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 517754880 (493MB)
mainbus0 at root: TI AM335x BeagleBone Black
cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache
omap0 at mainbus0
prcm0 at omap0 rev 0.2
dmtimer0 at omap0 rev 3.1
dmtimer1 at omap0 rev 3.1
simplebus0 at mainbus0: "ocp"
simplebus1 at simplebus0: "l4_wkup"
simplebus2 at simplebus1: "scm"
ompinmux0 at simplebus2
intc0 at simplebus0 rev 5.0
omgpio0 at simplebus0: rev 0.1
gpio0 at omgpio0: 32 pins
omgpio1 at simplebus0: rev 0.1
gpio1 at omgpio1: 32 pins
omgpio2 at simplebus0: rev 0.1
gpio2 at omgpio2: 32 pins
omgpio3 at simplebus0: rev 0.1
gpio3 at omgpio3: 32 pins
com0 at simplebus0: ti16750, 64 byte fifo
com0: console
tiiic0 at simplebus0 rev 0.11
iic0 at tiiic0
"ti,tps65217" at iic0 addr 0x24 not configured
"at,24c256" at iic0 addr 0x50 not configured
"nxp,tda998x" at iic0 addr 0x70 not configured
tiiic1 at simplebus0 rev 0.11
iic1 at tiiic1
"at,24c256" at iic1 addr 0x54 not configured
"at,24c256" at iic1 addr 0x55 not configured
"at,24c256" at iic1 addr 0x56 not configured
"at,24c256" at iic1 addr 0x57 not configured
ommmc0 at simplebus0
sdmmc0 at ommmc0: 4-bit, sd high-speed, mmc high-speed
ommmc1 at simplebus0
sdmmc1 at ommmc1: 1-bit
omdog0 at simplebus0 rev 0.1
cpsw0 at simplebus0: version 1.12 (0), address 90:59:af:69:cf:7a
ukphy0 at cpsw0 phy 0: Generic IEEE 802.3u media interface, rev. 1: OUI
0x0001f0, model 0x000f
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI2 0/direct
removable
sd0: 7646MB, 512 bytes/sector, 15659008 sectors
scsibus1 at sdmmc1: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0:  SCSI2 0/direct
removable
sd1: 1832MB, 512 bytes/sector, 3751936 sectors
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
boot device: sd0
root on sd0a (f33e524785e13e4d.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!
gpioow0 at gpio1: DATA[29] pull-up
onewire0 at gpioow0
gpioiic0 at gpio2: SDA[2] pull-up, SCL[3]
iic2 at gpioiic0

After boot, I'm able to toggle the USR LEDs no problem but I'm not able
to see the temp sensors on either onewire or i2c.

The slave ICs I'm using are both supported in the manual pages:

DS18S20, man 4 owtemp
DS1631, man 4 maxds


Using the following pinouts as reference:

http://www.toptechboy.com/wp-content/uploads/2015/06/beaglebone-black-pinout.jpg

onewire: DQ on P8 header, pin 26

i2c: SDA on P8 header, pin 7 / SCL on P8 header, pin 8 (tried flipping
SDA/SCL but no change)



Am I assuming correctly that by asserting 5V to the ICs, the master will
auto-poll and the value will be made available through sysctl(8)?

Perhaps I'm missing a step before going to securemode?

Any advice?


Thanks in advance,

-- 
Byron Klippert  
  byronklipp...@ml1.net
  c. 867-336-1306

Re: spamd and outlook.com

[Kevin Chadwick]

On Fri, 21 Apr 2017 13:51:36 -0700
Kurt H Maier  wrote:

> What I don't do it set an outgoing voicemail greeting informing
> correspondents that my time is more valuable than theirs, and if they
> want to contact me I have a list of hoops through which they must
> jump.
> 
> That would make me an asshole.

Hardly but it is a world full of major assholes and being slightly
assholeish would be ok if it helped fight them but greylisting is not
assholeish at all. Major providers making greylisting difficult is
being an asshole. Fast greylisting (couple of minutes) is on the rise
because it works, so they will hopefully change. CDN (content delivery
networks changing IPs and complicating CA trust) are a far more
assholeish hack.

I admit the implementations are more hackish than they could be but if
greylisting which has it's own standards now, is a hack then so are
blacklists which don't work very well and which is why users of the
major providers get a lot more spam than I do (not just greylisting
being the reason). The ability to download entire blacklists can be a
paid for service and also would be more wasteful.

Advertising an MX and refusing delivery is a hack that was never
intended too, when email was designed on expensive wholly trusted
networks?

I guess you don't mind the asshole call centres with noone on the other
end and then hang up or make you say hello again to see if someone
answers before switching to an employee as they rate the time of the
call centre employees doing a job under horrible pressure as more
valuable than the recipient? It works both ways, it would
obviously be better if spammers did not exist.