Re: Questions to the snapshot from January 9 2016 ?

[Stefan Sperling]

On Thu, Jan 14, 2016 at 04:07:42PM +0100, Christoph R. Murauer wrote:
> I tried the patch with the snapshot from yesterday but the result was
> the same - no link ... sleeping in a, b and g mode.
> 
> 

Can you please capture a beacon from this AP for me?
That is, one line from the output of:

  tcpdump -n -i iwm0 -y IEEE802_11_RADIO -s 1500 -vvv subtype beacon

where the SSID of the beacon matches your AP, and while the iwm0
interface is associated in 11b mode or while it is scanning.

Thanks.

Re: Questions to the snapshot from January 9 2016 ?

[Christoph R. Murauer]

Thanks for your answer.

> See the apmd(8) manual about /etc/apm/resume.

I will have a look at it, thanks.

> Use a different one. anoncvs.fr.openbsd.org and
> anoncvs.spacehopper.org
> update fairly fast.

I used your mirror which was really fast (the initial checkout for
src, ports and xenocara needs less then 15 minuts).

Re: unbound(8) generating too many log messages

[Mike]

On 1/14/2016 2:26 AM, Philippe Meunier wrote:
>[snip]
> The problem is that unbound(8) generates such a pair of messages up to
> 20 times for each root server!  That's 2 lines * 20 times * 13 root
> servers = 520 lines that end up going to syslog.  Then 15 seconds
> later ntpd(8) tries again and you get another 520 lines, and so on.
> This continues until a network interface is configured.  The result is
> that I've accumulated over 16000 lines of log messages like the ones
> above over just the past three days...
>[snip]

That's a big improvement over the way unbound used to be.

I have experienced unbound generating 20,000 log records PER SECOND.
http://marc.info/?l=unbound-users=137166462329717=2

What you're seeing is the fixed version which, imo, is still excessive
logging.

Re: Questions to the snapshot from January 9 2016 ?

[Christoph R. Murauer]

> Can you please capture a beacon from this AP for me?
> That is, one line from the output of:
>
>   tcpdump -n -i iwm0 -y IEEE802_11_RADIO -s 1500 -vvv subtype beacon
>
> where the SSID of the beacon matches your AP, and while the iwm0
> interface is associated in 11b mode or while it is scanning.
>
> Thanks.
>

Yep, needs a littlebit to find the device.

The ssid is correct and checked based on the MAC adress of the device.

# ifconfig iwm0 scan
iwm0: flags=8943 mtu 1500
lladdr cc:3d:82:52:2b:5a
priority: 4
groups: wlan
media: IEEE802.11 autoselect mode 11b
status: no network
ieee80211: nwid TP-LINK_M7350_6D1625 wpakey
0x15e08e2fd1fb0c86efe13dd3878a80395bb91315a49ff70fb9cdfbab7d4d5f14
wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp
wpagroupcipher tkip
nwid 0x chan 6
bssid 3c:46:d8:6d:16:25 100% 54M
privacy,short_preamble,short_slottime,wpa2
nwid AND SO ON ...

The beacon :

17:03:22.158084 802.11 flags=0<>: beacon, timestamp 4390707584,
interval 100, caps=2061,
ssid 0x, rates 1M 2M 5M 6M 9M
11M 12M 18M, ds (chan 6), tim 0x0102, erp 0x00, xrates 24M 36M 48M
54M, htcaps=<20/40MHz,SGI@20MHz,SGI@40MHz,A-MSDU
3839,DSSS/CCK@40MHz,A-MPDU max 8191,RxMCS 0x>,
htop=<40MHz chan 6:5,protect non-HT,basic MCS set 0x>,
vendor 0x0050f2010150f2020250f2040050f2020150f202, rsn
0x010fac02020fac04000fac02010fac020c00, vendor
0x0050f202010183a427a442435e0062322f00, 74:14
0x14000a002c01c800140005001900, 127:1 0x01, vendor
0x0050f204104a0001101044000102, 
17:03:22.352092 802.11 flags=0<>: beacon, timestamp 1802032436154,
interval 100, caps=2021, ssid
(PBS-445EF9), rates 1M 2M 5M 11M 18M 24M 36M 54M, ds (chan 11), tim
0x0102, country 'EU ', erp 0x00, 47:1 0x00, xrates 6M 9M 12M 48M,
htcaps=<20MHz,greenfield,SGI@20MHz,SGI@40MHz,A-MSDU
7935,DSSS/CCK@40MHz,A-MPDU max 65535,A-MPDU spacing 8.00us,RxMCS
0x>, htop=<20MHz chan 11,STA chanw
20MHz,RIFS,non-greenfield STA,basic MCS set 0x>,
vendor 0x0010180201f02c, vendor
0x0050f2010150f2020250f2040050f2020150f2020c00, vendor
0x0050f202010103a427a442435e0062322f00, 

Re: athn causes crash when bringing interface up

[Stefan Sperling]

On Wed, Jan 13, 2016 at 03:31:57PM -0500, Brendan Van Hook wrote:
> Hello,
> 
> After upgrading to the most recent snapshot, a simple 'ifconfig athn0 up' 
> sends
> me to ddb:
> 
> kernel: integer divide fault trap, code=0
> Stopped at:   ar5008_set_delta_slope+0x40:idiv1   %ecx,%eax
> 
> Trace:
> 
> ar5008_set_delta_slop() at ar5008_set_delta_slope+0x40
> athn_hw_reset() at athn_hw_reset+0x20e
> athn_init() at athn_init+0x11c
> athn_ioctl() at athn_ioctl+0x1de
> ifioctl() at ifioctl+0x90c
> sys_ioctl() at sys_ioctl+0x196
> syscall() at syscall+0x368
> --- syscall (number 54) ---
> end of kernel
> end trace frame:0x7f7d2490, count: -7
> 0x1ca1142212ca:

Should be fixed in -current.

Dell XPS 9343 and OpenBSD

[Remi Locherer]

Hi,

I read tedu@'s post about OpenBSD on laptops and thought a little report
about running -current on Dell XPS 13 might be interest.

http://www.tedunangst.com/flak/post/openbsd-laptops

I'm running -current on this and use it daily.

o Graphics:
 Works ok with the modsetting driver (now default).

o Battery:
I don't have exact measures. It runs about a day with one charge. I mainly
use a bunch of xterms and browsers.

o WLAN
The notebook shipped with a unsupported broadcom wlan adpater. I replaced
it with an iwm0 card. The notebook can be opened with a torx screwdriver.

o LAN
There is no built in Ethernet device. I use an USB3 to Gig. Ethernet
adapter from Edimax (axen).

o Audio
Only works with a patched kernel:
http://marc.info/?l=openbsd-misc=144270531711263=2

o Touchpad
Works more or less. Sometimes a click is not recognized or the pointer
makes unexpected jumps and dmesg fills with:
pms0: not in sync yet, discard input (state 0)
It got a little bit better with BIOS updates. On CentOS 7 it's the same
behaviour.

o Camera
video(4) says: video: could not find a usable encoding

o Suspend, resume and hibernate
Works reliable. Only when suspended by closing the lid it behaves strange:
after opening the lid it resumes and then supends again. Then pressing the
power button finaly resumes the device.

o EFI
Booting with EFI works. Sometimes after efiboot loaded the kernel  it reboots.
Then I either have to shutdown the notebook for some hours or boot into the
BIOS or another OS. Then it boots again. I didn't figure out how to willingly
reproduce this.

Remi


OpenBSD 5.9-beta (GENERIC.MP) #3: Wed Jan 13 21:41:17 CET 2016
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8473636864 (8081MB)
avail mem = 8212652032 (7832MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
bios0: vendor Dell Inc. version "A07" date 11/11/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT 
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.64 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
acpimadt0: bogus nmi for apid 1

Re: unbound(8) generating too many log messages

[Raf Czlonka]

On Thu, Jan 14, 2016 at 07:26:32AM GMT, Philippe Meunier wrote:
> Hello,
> 
> I have a laptop computer configured to use unbound(8) and ntpd(8) but
> which does not have any network interface configured by default
> (except lo0, obviously) since which interface needs to be configured
> and how depends on where I'm using the computer.
> 
> After booting, unbound(8) and ntpd(8) both start without problem.
> Then ntpd(8) automatically starts trying to contact NTP servers from
> pool.ntp.org, which triggers DNS queries.  In turn unbound(8) tries to
> contact root DNS servers and fails since no network interface is
> configured.  Unbound(8) then logs messages to syslog:
> 
> Jan 14 10:07:58 mycomputer unbound: [2824:0] notice: sendto failed: Can't 
> assign requested address
> Jan 14 10:07:58 mycomputer unbound: [2824:0] notice: remote address is 
> 192.5.5.241 port 53
> 
> The problem is that unbound(8) generates such a pair of messages up to
> 20 times for each root server!  That's 2 lines * 20 times * 13 root
> servers = 520 lines that end up going to syslog.  Then 15 seconds
> later ntpd(8) tries again and you get another 520 lines, and so on.
> This continues until a network interface is configured.  The result is
> that I've accumulated over 16000 lines of log messages like the ones
> above over just the past three days...
> 
> So is there a way to make unbound(8) more quiet (short of sending the
> log messages to /dev/null)?

Hi Philippe,

How about simply disabling unbound at boot:

# rcctl disable unbound

and then have something like this in your /etc/hostname.if:

rcctl -f start unbound

> For info, this is the unbound(8) version 1.5.4 from OpenBSD
> 5.8-release.
> 
> Thank you,
> 
> Philippe

Regards,

Raf

Re: PF: can't make queueing and priority work as expected

[Mihai Popescu]

> Ok, let's start insult each other.

No insult intended from my side and no one commited.

> I've setup my first PF on OpenBSD in 2006.

As Master Fu said once, if you can't setup it by yourself, maybe you
should not use it.

> Stuck your advice up your ass and fuck off.

I'm curious who will dear to answer your question on this forum anymore.

Bye.

Important SSH patch coming soon

[Theo de Raadt]

Important SSH patch coming soon.  For now, every on all operating
systems, please do the following:

Add undocumented "UseRoaming no" to ssh_config or use "-oUseRoaming=no"
to prevent upcoming #openssh client bug CVE-2016-0777. More later.

Installer exits after selecting root disk

[Marko Cupać]

Hi,

I am trying to install OpenBSD 5.8 release on sdcard of PC Engines
apu1d, but installer exits after selecting root disk, leaving me in
prompt:

---cut-here---
Available disks are: sd0 sd1.
Which disk is the root disk? ('?' for details) [sd0] sd1
Disk: sd1   geometry: 1911/255/63 [30703616 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [

#
---cut-here---

I changed sdcard, tried to install both from usb thumb drive (fs) and
usb optical drive (iso), with the same result. I tried both i386 and
amd64. Needless to say, checksums of downloaded iso/fs are correct.

Strangely enough, I've recently installed a few apu1d's the same way
without problem. The only difference is power adapter - I am not using
the one from PC Engines now, but generic one with same specification
instead.

Could power adapter cause such behaviour? If not, what could?

Thank you in advance.
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Dell XPS 9343 and OpenBSD

[Scott Bonds]

Thanks for sharing Remi! I've been thinking about getting one of
those, I'm glad to hear it runs OpenBSD ok. Now if Dell would just add
an internal WWAN option. :)

On 01/14, Remi Locherer wrote:
> Hi,
> 
> I read tedu@'s post about OpenBSD on laptops and thought a little report
> about running -current on Dell XPS 13 might be interest.
> 
> http://www.tedunangst.com/flak/post/openbsd-laptops
> 
> I'm running -current on this and use it daily.
> 
> o Graphics:
>  Works ok with the modsetting driver (now default).
> 
> o Battery:
> I don't have exact measures. It runs about a day with one charge. I mainly
> use a bunch of xterms and browsers.
> 
> o WLAN
> The notebook shipped with a unsupported broadcom wlan adpater. I replaced
> it with an iwm0 card. The notebook can be opened with a torx screwdriver.
> 
> o LAN
> There is no built in Ethernet device. I use an USB3 to Gig. Ethernet
> adapter from Edimax (axen).
> 
> o Audio
> Only works with a patched kernel:
> http://marc.info/?l=openbsd-misc=144270531711263=2
> 
> o Touchpad
> Works more or less. Sometimes a click is not recognized or the pointer
> makes unexpected jumps and dmesg fills with:
> pms0: not in sync yet, discard input (state 0)
> It got a little bit better with BIOS updates. On CentOS 7 it's the same
> behaviour.
> 
> o Camera
> video(4) says: video: could not find a usable encoding
> 
> o Suspend, resume and hibernate
> Works reliable. Only when suspended by closing the lid it behaves strange:
> after opening the lid it resumes and then supends again. Then pressing the
> power button finaly resumes the device.
> 
> o EFI
> Booting with EFI works. Sometimes after efiboot loaded the kernel  it reboots.
> Then I either have to shutdown the notebook for some hours or boot into the
> BIOS or another OS. Then it boots again. I didn't figure out how to willingly
> reproduce this.
> 
> Remi
> 
> 
> OpenBSD 5.9-beta (GENERIC.MP) #3: Wed Jan 13 21:41:17 CET 2016
> r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8473636864 (8081MB)
> avail mem = 8212652032 (7832MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
> bios0: vendor Dell Inc. version "A07" date 11/11/2015
> bios0: Dell Inc. XPS 13 9343
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT 
> SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
> PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
> PXSX(S4) RP05(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.64 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz
> cpu3: 
> 

FAQ 10.4.2 why días(1)? typo

[Halim Srama]

In the first sentence of this FAQ:
http://www.openbsd.org/faq/faq10.html#doas

I think there is a word missing:
"passwords should not shared"
should be:
"passwords should not be shared"

I have searched the archives and didn't find any report about this.

Re: iwm0: could not initiate 2 GHz scan

[Chris Wojo]

  On Wed, 13 Jan 2016 01:58:14 -0700 Stefan Sperling 
wrote 
 > So it's clear we still have an issue here. This could be a problem
 > with frame protection settings, which if wrongly configured would
 > cause Tx failures and frames damaged while in flight. Protection
 > settings for the network are advertised by the AP and we must apply
 > them correctly or many things won't work.
 > (cf.
http://www.testequipmentdepot.com/flukenetworks/pdf/802.11n-compatibility.pdf
)
 >
 > One issue I'm already aware of is that we currently don't update
 > protection settings in case the AP decides to change them while
 > we're associated. But your problem indicates that perhaps we're
 > not configuring frame protection correctly in the first place.
 >
 > Can you please send one line showing a beacon for your AP at home,
 > and a few lines showing beacons from the various APs at your office?
 >
 > You can print beacons as a line of text like this:
 >
 >   tcpdump -n -i iwm0 -s 1500 -vvv -y IEEE802_11_RADIO subtype beacon
 >
 > Note that if you run this command while associated to an AP (i.e. while
 > ifconfig iwm0 shows status: active) it will only show beacons for that AP.
 >
 > Could you also compile and run a kernel with the follwing diff applied,
 > and show me what this prints while you're tyring to associate and DHCP
 > to the APs?
 >
 > Thanks.
 >
 > Index: if_iwm.c
 > ===
 > RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
 > retrieving revision 1.75
 > diff -u -p -r1.75 if_iwm.c
 > --- if_iwm.c7 Jan 2016 23:08:38 -1.75
 > +++ if_iwm.c13 Jan 2016 08:55:33 -
 > @@ -145,6 +145,7 @@
 >  #define le16_to_cpup(_a_) (le16toh(*(const uint16_t *)(_a_)))
 >  #define le32_to_cpup(_a_) (le32toh(*(const uint32_t *)(_a_)))
 >
 > +#define IWM_DEBUG
 >  #ifdef IWM_DEBUG
 >  #define DPRINTF(x)do { if (iwm_debug > 0) printf x; } while (0)
 >  #define DPRINTFN(n, x)do { if (iwm_debug >= (n)) printf x; } while
(0)
 > @@ -4948,6 +4949,7 @@ iwm_mvm_mac_ctxt_cmd_common(struct iwm_s
 >  if (ni->ni_flags & IEEE80211_NODE_HT) {
 >  enum ieee80211_htprot htprot =
 >  (ni->ni_htop1 & IEEE80211_HTOP1_PROT_MASK);
 > +DPRINTF(("%s: htprot = %d\n", __func__, htprot));
 >  switch (htprot) {
 >  case IEEE80211_HTPROT_NONE:
 >  break;
 >
 >
 >

Here is a one liner from the beacons at home:
19:19:02.891580 802.11 flags=42: QoS data: 30:85:a9:8b:27:2c >
18:5e:0f:6e:57:44 sap 00 I (s=18,r=0,C) len=98, 

This is a selection of my home dmesg output approximately when connecting:
iwm apm stop
iwm apm start
iwm apm start
Radio type=0x0-0x2-0x1
loading ring 0 descriptors (0xff0001c04000) at 1c040
loading ring 1 descriptors (0xff0001c21000) at 1c210
loading ring 2 descriptors (0xff0001c3e000) at 1c3e0
loading ring 3 descriptors (0xff0001c5b000) at 1c5b0
loading ring 4 descriptors (0xff0001c78000) at 1c780
loading ring 5 descriptors (0xff0001c95000) at 1c950
loading ring 6 descriptors (0xff0001cb2000) at 1cb20
loading ring 7 descriptors (0xff0001ccf000) at 1ccf0
loading ring 8 descriptors (0xff0001cec000) at 1cec0
loading ring 9 descriptors (0xff0001d09000) at 1d090
loading ring 10 descriptors (0xff0001d26000) at 1d260
loading ring 11 descriptors (0xff0001d2e000) at 1d2e0
loading ring 12 descriptors (0xff0001d36000) at 1d360
loading ring 13 descriptors (0xff0001d3e000) at 1d3e0
loading ring 14 descriptors (0xff0001d46000) at 1d460
loading ring 15 descriptors (0xff0001d4e000) at 1d4e0
loading ring 16 descriptors (0xff0001d56000) at 1d560
loading ring 17 descriptors (0xff0001d5e000) at 1d5e0
loading ring 18 descriptors (0xff0001d66000) at 1d660
loading ring 19 descriptors (0xff0001d6e000) at 1d6e0
shadow registers enabled
LOAD FIRMWARE type 1 offset 8388608 len 81920
LOAD FIRMWARE type 1 offset 0 len 183268
LOAD FIRMWARE type 1 offset 4294954188 len 32
enabled txq 9 FIFO 7
sending command 0x98 qid 9, idx 0
Sending phy db data and configuration to runtime image
sending command 0x6c qid 9, idx 1
sending command 0x6c qid 9, idx 2
sending command 0x6c qid 9, idx 3
sending command 0x6c qid 9, idx 4
sending command 0x6c qid 9, idx 5
sending command 0x6c qid 9, idx 6
sending command 0x6c qid 9, idx 7
sending command 0x6c qid 9, idx 8
sending command 0x6c qid 9, idx 9
sending command 0x6c qid 9, idx 10
sending command 0x6c qid 9, idx 11
sending command 0x6c qid 9, idx 12
sending command 0x6c qid 9, idx 13
sending command 0x6c qid 9, idx 14
sending command 0x6c qid 9, idx 15
Finished sending phy db non channel data
sending command 0x6a qid 9, idx 16
sending command 0x18 qid 9, idx 17
Internal station added.
sending command 0x8 qid 9, idx 18
sending command 0x8 qid 9, idx 19
sending command 0x8 qid 9, idx 20
Sending device power command with flags = 0x2001
sending command 0x77 qid 9, idx 21
enabled txq 0 FIFO 0
enabled txq 1 

Re: PF: can't make queueing and priority work as expected

[David Gwynne]

> On 13 Jan 2016, at 19:19, Marko Cupać  wrote:
>
> On Tue, 12 Jan 2016 16:40:58 +0100
> Claudio Jeker  wrote:
>
>> On Tue, Jan 12, 2016 at 05:33:06AM -0700, Daniel Melameth wrote:
>>> On Mon, Jan 11, 2016 at 9:37 PM, David Gwynne 
>>> wrote:
> On 11 Jan 2016, at 22:43, Daniel Melameth 
> wrote: On Sun, Jan 10, 2016 at 7:58 AM, Marko Cupa??
> 
>>> wrote:
>> On Sat, 9 Jan 2016 11:11:27 -0700
>> Daniel Melameth  wrote:
>>> You NEED to set a max on your ROOT queues.
>> I came to this conclusion as well. But not only on root queues.
>> For example, when max is set on root queue but only bandwidth
>> on child queues, no shaping takes place...
> This works for me.
>> Or, to cut the long story short, if someone can paste queue
>> definition which accomplishes 'give both queues max bandwidth,
>> but throttle traffic from first queue when traffic from the
>> second one arrives', I will be more than happy to quit
>> bothering misc@ list readers with my rants and observations.
> I would expect this to be possible with prio alone, but I've
> never been able to get it to work.  Perhaps I'm misunderstanding
> how prio works.
 prio is basically an array of lists of packets to be transmitted.
 high
>>> priority packets go on a different list to low priority packets.

 the problem is the way packets go on and off these lists.
 basically as soon
>>> as a packet is queued on one of these lists for transmission, we
>>> call the driver immediately to send it. generally as soon as a
>>> packet is queued on the interface, it immediately gets dequeued by
>>> the driver and transmitted on the hardware.

 it is only when you build up a backlog of packets that priq can
 come into
>>> effect. the only way you can build up a backlog of packets is if
>>> your hardware is slower at transmitting packets than the thing that
>>> generates these packets to send.

 in your case you're probably getting packets from a relatively
 slow internet
>>> connection and transmitting them on a high speed local network. the
>>> transmit hardware is almost certainly going to be faster than your
>>> source of packets, so you'll never build up a queue of backlogged
>>> packets, so prio is effectively a nop.

 dlg
>>>
>>> Thanks for taking the time to chime in guys.  Prior to implementing
>>> any queueing, I tested this stuff out on a LAN--so no slower
>>> connectionswere involved--and I was unable to see prio in action, at
>>> least not with any observable similarity to ALTQ's PRIQ.
>>>
>>> A simple rule set:
>>>
>>> match out on egress proto tcp to port 12345 set prio 7
>>> match out on egress proto tcp to port 12346 set prio 0
>>> pass
>>>
>>> Using tcpbench to push packets into both queues, I would have
>>> expected the packets destined for port 12346 to get throttled, but
>>> both flows simply reached an equilibrium, which I would have
>>> expected without prio.  Under PRIQ, I would have seen the flow to
>>> port 12346 get almost completely starved of bandwidth.  When doing
>>> non-prio queuing with a similarly simple ruleset, both flows
>>> properly matched their target bandwidth.
>>
>> This assumes that you manage to fill the TX interface queue to a level
>> that it always fills the tx DMA rings before being empty. On high
>> speed interfaces this most of the time not the case and so both
>> sessions are able to reach the maximum bandwidth.
>> To be honest prio queue only make sense when you have a slow interface
>> (10Mbps) or a shaper in place that causes the queue to fill up.
>> There is currently no shaper you can use together with the prio
>> queues so only option one remains.
>>
>
> Have we come to conclusion that currently prio makes no sense at all?

it wont have the effect you want. that doesn't mean it doesn't make sense
somewhere else.

>
> Can I hope that saying 'currently' means this is not the intended
> design? Or should I come to peace with the fact that with OpenBSD and
> PF I can forget about shaping inbound TCP traffic in a way that
> child queues can expand to max link bandwidth unless there is a
> congestion, while in congestion admin can choose which child queues to
> throttle and in which order?

hfsc might need some work at the code level, it might just suck to configure.

>
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/

Re: FAQ 10.4.2 why días(1)? typo

[Michael McConville]

Halim Srama wrote:
> In the first sentence of this FAQ:
> http://www.openbsd.org/faq/faq10.html#doas
> 
> I think there is a word missing:
> "passwords should not shared"
> should be:
> "passwords should not be shared"
> 
> I have searched the archives and didn't find any report about this.

Committed. Thanks!

That said, the sentence could probably be worded more elegantly...

Asrock Rack C2750D4I -- unsupported watchdog ?

[Brendan Horan]

Hi,

I have an Asrock Rack C2750D4I Atom board.

Most things are working quite well so far.
Some odd sensor readings but I can poll via IPMI anyway.


One thing I would like to get working if I can is the watchdog.

If I enable the watchdog in the BIOS, Openbsd never see's the watchdog.
Watchdog can not be kicked and machine restarts, as expected.

To me it seems the watchdog is not supported by Openbsd yet?
Or am I doing something wrong?


The following outputs where generated when the watchdog was enabled in the
BIOS.


Thanks
brendan

---
# sysctl | grep -i watchdog                                  
                                                 
#
# watchdogd -d  
watchdogd: no watchdog timer available
#
# dmesg
OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
    dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8545411072 (8149MB)
avail mem = 8282529792 (7898MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f538000 (23 entries)
bios0: vendor American Megatrends Inc. version "P2.80" date 12/04/2014
bios0: ASRock C2750D4I
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT HPET AAFT SPMI MCFG WDAT UEFI APIC BDAT SSDT
SPCR
acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.45 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz
cpu4:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu4: 1MB 64b/line 16-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz
cpu5:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu5: 1MB 64b/line 16-way L2 cache
cpu5: smt 0, core 5, package 0
cpu6 at mainbus0: apid 12 (application processor)
cpu6: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz
cpu6:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu6: 1MB 64b/line 16-way L2 cache
cpu6: smt 0, core 6, package 0
cpu7 at mainbus0: apid 14 (application processor)
cpu7: 

VXLAN in version 5.9

[minha-casa]

Hello,



Anybody already test vxlan in version 5.9 I reproduced
the same test with version 5.8 and everything is ok.



My lab is simple:



vxlan0 192.168.1.17 Machine1 em0 200.98.41.17  <->  em1
200.98.44.18 Machine2 vxlan0 192.168.1.19





I can see the packet vxlan arriving in destination but there
is not return. Both directions is the same thing. I do the same test, same
network with version 5.8 and is ok.



machine1

# ifconfig

lo0: flags=8049 mtu 32768

priority: 0

groups: lo

inet6 ::1 prefixlen 128

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4

inet 127.0.0.1 netmask 0xff00

em0:
flags=18b43
mtu 1500

lladdr 00:50:56:bb:59:64

priority: 0

groups: egress

media: Ethernet autoselect (1000baseT full-duplex,master)

status: active

inet 200.98.41.17 netmask 0xff00 broadcast 200.98.41.255

em1: flags=18802 mtu 1500

lladdr 00:50:56:bb:43:9d

priority: 0

media: Ethernet autoselect (1000baseT full-duplex,master)

status: active

enc0: flags=0<>

priority: 0

groups: enc

status: active

vxlan0: flags=8843 mtu 1500

lladdr fe:e1:ba:d0:f0:53

priority: 0

groups: vxlan

media: Ethernet autoselect

status: active

tunnel: inet 200.98.41.17 -> 200.98.44.18 vnetid 1

inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255

#

# pfctl -d

pfctl: pf not enabled

#







Machine2

# ifconfig

lo0: flags=8049 mtu 32768

priority: 0

groups: lo

inet6 ::1 prefixlen 128

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4

inet 127.0.0.1 netmask 0xff00

em0: flags=18802 mtu 1500

lladdr 00:50:56:bb:67:e5

priority: 0

media: Ethernet autoselect (1000baseT full-duplex,master)

status: active

em1:
flags=18b43
mtu 1500

lladdr 00:50:56:bb:46:a7

priority: 0

groups: egress

media: Ethernet autoselect (1000baseT full-duplex,master)

status: active

   inet 200.98.44.18 netmask 0xff80 broadcast 200.98.44.127

enc0: flags=0<>

priority: 0

groups: enc

status: active

vxlan0: flags=8843 mtu 1500

lladdr fe:e1:ba:d0:e6:c1

priority: 0

groups: vxlan

media: Ethernet autoselect

status: active

tunnel: inet 200.98.44.18 -> 200.98.41.17 vnetid 1

inet 192.168.1.19 netmask 0xff00 broadcast 192.168.1.255

# pfctl -d

pfctl: pf not enabled

#





TCPDUMP



Machine1

root@200.98.41.17's password:

Last login: Fri Jan 15 01:45:45 2016 from 200.221.130.5

OpenBSD 5.9-beta (GENERIC.MP) #1540: Fri Jan  8 10:48:32 MST 2016



Welcome to OpenBSD: The proactively secure Unix-like operating system.



Please use the sendbug(1) utility to report bugs in the system.

Before reporting a bug, please try to reproduce it with the latest

version of the code.  With bug reports, please try to ensure that

enough information to reproduce the problem is enclosed, and if a

known fix for it exists, include that as well.



# tcpdump -ni em0 port 4789

tcpdump: listening on em0, link-type EN10MB

02:00:23.386424 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:25.274328 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:27.400703 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:29.245143 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:31.393324 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:54.806495 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:56.867895 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

02:00:58.799075 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]







Machine2



# tcpdump -ni em1 port 4789

tcpdump: listening on em1, link-type EN10MB

20:58:20.043878 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:58:35.189082 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:58:37.362855 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:58:39.120386 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:59:46.034194 200.98.44.18.4789 > 200.98.41.17.4789: udp 50 [tos 0x10]

20:59:53.259481 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:59:55.435700 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:59:57.193269 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

20:59:59.341469 200.98.41.17.4789 > 200.98.44.18.4789: udp 50 [tos 0x10]

Re: unbound(8) generating too many log messages

[Stuart Henderson]

Setting 'verbosity: 0' in config will do it, but I don't think it
should be necessary. At the very least putting the 'remote address'
on the same line as the sendto notice would give syslog something of
a chance to reduce the number of lines.

Could you ask for suggestions on unbound-users please?


On 2016-01-14, Philippe Meunier  wrote:
> Hello,
>
> I have a laptop computer configured to use unbound(8) and ntpd(8) but
> which does not have any network interface configured by default
> (except lo0, obviously) since which interface needs to be configured
> and how depends on where I'm using the computer.
>
> After booting, unbound(8) and ntpd(8) both start without problem.
> Then ntpd(8) automatically starts trying to contact NTP servers from
> pool.ntp.org, which triggers DNS queries.  In turn unbound(8) tries to
> contact root DNS servers and fails since no network interface is
> configured.  Unbound(8) then logs messages to syslog:
>
> Jan 14 10:07:58 mycomputer unbound: [2824:0] notice: sendto failed: Can't 
> assign requested address
> Jan 14 10:07:58 mycomputer unbound: [2824:0] notice: remote address is 
> 192.5.5.241 port 53
>
> The problem is that unbound(8) generates such a pair of messages up to
> 20 times for each root server!  That's 2 lines * 20 times * 13 root
> servers = 520 lines that end up going to syslog.  Then 15 seconds
> later ntpd(8) tries again and you get another 520 lines, and so on.
> This continues until a network interface is configured.  The result is
> that I've accumulated over 16000 lines of log messages like the ones
> above over just the past three days...
>
> So is there a way to make unbound(8) more quiet (short of sending the
> log messages to /dev/null)?
>
> For info, this is the unbound(8) version 1.5.4 from OpenBSD
> 5.8-release.
>
> Thank you,
>
> Philippe

Re: Questions to the snapshot from January 9 2016 ?

[Christoph R. Murauer]

> Please try this diff.
> I suspect this bug is causing all sorts of problems.
>
> Index: ieee80211.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 ieee80211.c
> --- ieee80211.c   12 Jan 2016 09:28:09 -  1.57
> +++ ieee80211.c   13 Jan 2016 14:19:26 -
> @@ -749,8 +749,10 @@ ieee80211_setmode(struct ieee80211com *i
>   modeflags = chanflags[mode];
>   for (i = 0; i <= IEEE80211_CHAN_MAX; i++) {
>   c = >ic_channels[i];
> - if (mode == IEEE80211_MODE_AUTO ||
> - (c->ic_flags & modeflags) == modeflags)
> + if (mode == IEEE80211_MODE_AUTO) {
> + if (c->ic_flags != 0)
> + break;
> + } else if ((c->ic_flags & modeflags) == modeflags)
>   break;
>   }
>   if (i > IEEE80211_CHAN_MAX) {
> @@ -764,8 +766,10 @@ ieee80211_setmode(struct ieee80211com *i
>   memset(ic->ic_chan_active, 0, sizeof(ic->ic_chan_active));
>   for (i = 0; i <= IEEE80211_CHAN_MAX; i++) {
>   c = >ic_channels[i];
> - if (mode == IEEE80211_MODE_AUTO ||
> - (c->ic_flags & modeflags) == modeflags)
> + if (mode == IEEE80211_MODE_AUTO) {
> + if (c->ic_flags != 0)
> + setbit(ic->ic_chan_active, i);
> + } else if ((c->ic_flags & modeflags) == modeflags)
>   setbit(ic->ic_chan_active, i);
>   }
>   /*
>

Hello !

I tried the patch with the snapshot from yesterday but the result was
the same - no link ... sleeping in a, b and g mode.