Re: Dell Latitude E5570 on current/amd64

[Mike Larkin]

On Tue, Aug 09, 2016 at 07:43:38PM +0200, Jan Stary wrote:
> This is Dell Latitude E5570 running current (full dmesg below).
> Basically works, but I experience problems with resuming the video.
> 

You have Skylake video which does not resume properly yet.

-ml

> This is what /var/log/messages has to say about the suspend/resume.
> 
>   Aug  9 19:05:18 dell apmd: system suspending
>   Aug  9 19:05:19 dell /bsd: ugen0 detached
>   Aug  9 19:05:20 dell /bsd: ugen1 detached
>   Aug  9 19:05:21 dell /bsd: video0 detached
>   Aug  9 19:05:21 dell /bsd: uvideo0 detached
>   Aug  9 19:05:22 dell /bsd: uhub0 detached
>   Aug  9 19:05:45 dell /bsd: uhub0 at usb0 "Intel xHCI root hub" rev 
> 3.00/1.00 addr 1
>   Aug  9 19:05:45 dell apmd: system resumed from sleep
>   Aug  9 19:05:45 dell /bsd: ugen0 at uhub0 port 6 "Intel product 0x0a2b" rev 
> 2.00/0.01 addr 2
>   Aug  9 19:05:46 dell /bsd: usbd_fill_iface_data: bad max packet size
>   Aug  9 19:05:46 dell last message repeated 7 times
>   Aug  9 19:05:46 dell /bsd: ugen1 at uhub0 port 10 "Broadcom Corp 5880" rev 
> 1.10/1.01 addr 3
>   Aug  9 19:05:46 dell /bsd: usbd_fill_iface_data: bad max packet size
>   Aug  9 19:05:46 dell last message repeated 7 times
>   Aug  9 19:05:47 dell /bsd: uvideo0 at uhub0 port 11 configuration 1 
> interface 0 "CN0J8NNP7248765RBBM6A00 Integrated_Webcam_HD" rev 2.00/54.13 
> addr 4
>   Aug  9 19:05:47 dell /bsd: video0 at uvideo0
> 
> The apmd is running as 'apmd -A'.
> The suspend was initiated by 'zzz' (and seems to go fine);
> the resume was initiated by pressing the blinking power button.
> It does not resume fully: the screen stays black. The detached
> usb devices re-attach, the machine is pingable, but I cannot
> connect with ssh.
> 
> Maybe related: there is no vga0, but there is vga1.
> 
>   vga1 at pci0 dev 2 function 0 "Intel HD Graphics 530" rev 0x06
>   wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
>   wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> 
> Maybe also related: on intel graphics, mplayer usually has no problem
> going fullscreen; here, fullscren just means the original size centered
> on an otherwise empty screen. 'xvinfo' says 'no adaptors present'.
> Is that expected?
> 
> Also, there is quite a few devices "not configured".
> See below for pcidump -xxvv.
> 
> How can I help further debug this machine?
> 
>   Thank you
> 
>   Jan
> 
> 
> 
> OpenBSD 6.0-current (GENERIC.MP) #1: Mon Aug  8 19:55:50 CEST 2016
> r...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16810340352 (16031MB)
> avail mem = 16296390656 (15541MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries)
> bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016
> bios0: Dell Inc. Latitude E5570
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT 
> DBGP DBG2 SSDT UEFI SSDT SSDT SLIC DMAR ASF!
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
> UAR1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) 
> RP12(S4) PXSX(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-6440HQ CPU @ 2.60GHz, 2295.51 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,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 23MHz
> 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-6440HQ CPU @ 2.60GHz, 2294.63 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.63 MHz
> cpu2: 
> 

Re: Colour man pages via ssh + tmux on 5.9?

[lists]

Tue, 9 Aug 2016 20:33:43 +0100 skin...@britvault.co.uk (Craig Skinner)
> On 2016-08-09 Tue 07:10 AM |, li...@wrant.com wrote:
> > 
> > I've had this in .Xdefaults for a long time, does this work for you?
> >   
> 
> Aye Anton;- I looked at that FAQ earlier, which is for local man pages.
> 
> On a remote tmux ssh session (which could be from Windows Putty, an
> Android, or some other client), the remote no X machine needs to do it.
> 
> Cheers!

Hi Craig,

You see how OpenBSD has profoundly offloaded my logic model, I've never
for a moment considered connecting from any insecure machine that would
not be running OpenBSD as a "from" station.  Totally missed this option
and not being discriminating in any way.  Indeed, I see your point now.

Here, another option comes to mind, one could run Xterm on Windows too?

Wikipedia: Cygwin - Unix-like environment and CLI for Windows
[https://en.wikipedia.org/wiki/Cygwin]

Cygwin/X: screenshots
[http://x.cygwin.com/screenshots/]

All-bets-off where your primary trusted client machine is compromised..
This'd be the "wrong" approach by all means with bring-your-own-device.
Depends on the local policy of course and personal choices most of all.

I still would consider this a non option for me though, just mentioned.
Better carry around a small sub-notebook running OpenBSD like everyone.

Kind regards,
Anton

Re: PC Engines APU NIC (RTL8111E) performance

[Darren Tucker]

On Tue, Aug 09, 2016 at 12:26:00PM +0200, Momtchil Momtchev wrote:
> I tried this patch (5f22 in the RL_IM register) on 5.9-stable, no
> POOL_DEBUG, 30 pf rules and about 10k states and I got about 8000 IRQ/s (up
> from 6000/s on vanilla) and iperf RX throughput was down to 280 MBit/s.

Are you running iperf on the APU?  I'm running it on separate machines
either side.

> I then tried upping the RXPKTS to 15 and the RXTIME to 4 (100us) - this is
> 5f4f in RL_IM. The IRQs dropped to 5000 IRQ/s and the CPU utilisation went
> down, but RX throughput went further down to 240 MBit/s. Next I tried the
> magic value 5151 and IRQs dropped to 4000 IRQ/s (???), CPU went down and
> throughput went down to 200 MBit/s.
> All these are RX values. On the TX side I get slightly higher throughput
> and a higher IRQ rate.
> There are no public datasheets for the 8111E and I think there is
> something fishy with those values. The original source of the 5151 magic is
> the open-source driver by Realtek. Hopefully they know what they are doing.
> They have a Linux and a FreeBSD driver on their site. The one for FreeBSD
> seems to be based on that same driver by Bill Paul from Windriver and it
> uses this magic value which doesn't make any sense if 1 is the number of
> packets to wait before sending an interrupt.
> 
> Also what I find very puzzling is that lower IRQ rates lead to lower CPU
> utilization but not higher throughput??
> 
> What hardware are you using? This is not an APU? Maybe there is some
> other bottleneck on the APU?

It's an early (2 core) APU.  dmesg below.

> Are you getting higher performance than on vanilla?

It's not consistent and I think there's a variable I haven't controlled
for. I've been fiddling a lot but right now a stock -current kernel
performance is about in the same ballpark as with the diff.  Have you
tested with -current?  I might try 5.9 for comparison.

Things I've tried to control for:
hw.perfpolicy=manual
hw.setperf=0 (also 100)
kern.pool_debug=0

I did find that the results seemed a bit more consistent when disabling
Nagle (iperf -N) which would probably make it less sensitive to latency
or loss during TCP slow start.

OpenBSD 6.0 (GENERIC) #2135: Sun Jul 24 10:30:11 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 2098520064 (2001MB)
avail mem = 2030505984 (1936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40N Processor, 1000.13 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:31:30:74
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:31:30:75
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 "Realtek 

Re: Colour man pages via ssh + tmux on 5.9?

[Craig Skinner]

On 2016-08-09 Tue 07:10 AM |, li...@wrant.com wrote:
> 
> I've had this in .Xdefaults for a long time, does this work for you?
> 

Aye Anton;- I looked at that FAQ earlier, which is for local man pages.

On a remote tmux ssh session (which could be from Windows Putty, an
Android, or some other client), the remote no X machine needs to do it.

Cheers!
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: Colour man pages via ssh + tmux on 5.9?

[Craig Skinner]

On 2016-08-08 Mon 13:33 PM |, Philip Guenther wrote:
> 
> You need to find a way that doesn't use the insane LESS_TERMCAP_*
> variables.  They vanished from the less in OpenBSD in this commit:
> --
> revision 1.18
[snip]
> uses terminfo instead of termcap
> 

Thanks Philip for the reminder less was replaced.

> You can probably emulate this by defining your own terminfo entry
> under ~/.terminfo/ with the desired overrides.
> 

I've been fiddling about a bit

In the meantime (for a quick hack), this gets things colourised:


$ printenv | fgrep -i less
PAGER=less
LESS=--LONG-PROMPT --ignore-case
MANPAGER=less
$ printenv TERM
screen
$ type man
man is an alias for 'TERM=xterm-pcolor; man'


WARNING:- it's fucking fruity. Lemons & limes squirting in to the eyes.

Inspired by this: http://stackoverflow.com/a/1257467

More TODO,
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: Dell Latitude E5570 on current/amd64

[Jan Stary]

On Aug 09 19:49:31, h...@stare.cz wrote:
> On Aug 09 19:43:38, h...@stare.cz wrote:
> > This is Dell Latitude E5570 running current (full dmesg below).
> > Basically works, but I experience problems with resuming the video.

Here is the acpidump tarball:
http://stare.cz/dmesg/dell-latitude-E5570-acpidump.tar

Jan

Re: Dell Latitude E5570 on current/amd64

[Jan Stary]

On Aug 09 19:43:38, h...@stare.cz wrote:
> This is Dell Latitude E5570 running current (full dmesg below).
> Basically works, but I experience problems with resuming the video.
> 
> This is what /var/log/messages has to say about the suspend/resume.
> 
>   Aug  9 19:05:18 dell apmd: system suspending
>   Aug  9 19:05:19 dell /bsd: ugen0 detached
>   Aug  9 19:05:20 dell /bsd: ugen1 detached
>   Aug  9 19:05:21 dell /bsd: video0 detached
>   Aug  9 19:05:21 dell /bsd: uvideo0 detached
>   Aug  9 19:05:22 dell /bsd: uhub0 detached
>   Aug  9 19:05:45 dell /bsd: uhub0 at usb0 "Intel xHCI root hub" rev 
> 3.00/1.00 addr 1
>   Aug  9 19:05:45 dell apmd: system resumed from sleep
>   Aug  9 19:05:45 dell /bsd: ugen0 at uhub0 port 6 "Intel product 0x0a2b" rev 
> 2.00/0.01 addr 2
>   Aug  9 19:05:46 dell /bsd: usbd_fill_iface_data: bad max packet size
>   Aug  9 19:05:46 dell last message repeated 7 times
>   Aug  9 19:05:46 dell /bsd: ugen1 at uhub0 port 10 "Broadcom Corp 5880" rev 
> 1.10/1.01 addr 3
>   Aug  9 19:05:46 dell /bsd: usbd_fill_iface_data: bad max packet size
>   Aug  9 19:05:46 dell last message repeated 7 times
>   Aug  9 19:05:47 dell /bsd: uvideo0 at uhub0 port 11 configuration 1 
> interface 0 "CN0J8NNP7248765RBBM6A00 Integrated_Webcam_HD" rev 2.00/54.13 
> addr 4
>   Aug  9 19:05:47 dell /bsd: video0 at uvideo0
> 
> The apmd is running as 'apmd -A'.
> The suspend was initiated by 'zzz' (and seems to go fine);
> the resume was initiated by pressing the blinking power button.
> It does not resume fully: the screen stays black. The detached
> usb devices re-attach, the machine is pingable, but I cannot
> connect with ssh.

I forgot to add: pressing the power button
in this not-fully-resumed state
makes the machine shutdown correctly.

relayd as transparent reverse proxy

[R0me0 ***]

Hello misc,

I'm trying to use relayd as transparent reverse proxy with httpd. The goal
is keep source IP

I'am using OBSD 5.9 stable branch

relayd and httpd coexist in the same machine.

pf.conf ( tried with rdr and divert-to )

pass in on egress   divert-to localhost port 8080


relayd.conf

relay "proxyrelay"
 listen on 127.0.0.1 port 8080
 protocol "httpfilter"
 transparent forward to destination ( used accordingly rdr/divert-to )


works great , but if I use the word "transparent" doesn't work.
Using tcpdump I am able to see the traffic being blocked from my egress and
source port of httpd.

Ok

I take a look on this
https://marc.info/?l=openbsd-misc=130479125318862=2

Removed from pf.conf "set skip on lo0" and tried to perform rules like the
thread above

The grammar in relay section doesn't accept "interface" keyword

but debuging with tcpdump,  now I see a "loop" and the  client never get a
response.


Is there a way to get it working in the same host ?


Thanks in advance.

Dell Latitude E5570 on current/amd64

[Jan Stary]

This is Dell Latitude E5570 running current (full dmesg below).
Basically works, but I experience problems with resuming the video.

This is what /var/log/messages has to say about the suspend/resume.

  Aug  9 19:05:18 dell apmd: system suspending
  Aug  9 19:05:19 dell /bsd: ugen0 detached
  Aug  9 19:05:20 dell /bsd: ugen1 detached
  Aug  9 19:05:21 dell /bsd: video0 detached
  Aug  9 19:05:21 dell /bsd: uvideo0 detached
  Aug  9 19:05:22 dell /bsd: uhub0 detached
  Aug  9 19:05:45 dell /bsd: uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
  Aug  9 19:05:45 dell apmd: system resumed from sleep
  Aug  9 19:05:45 dell /bsd: ugen0 at uhub0 port 6 "Intel product 0x0a2b" rev 
2.00/0.01 addr 2
  Aug  9 19:05:46 dell /bsd: usbd_fill_iface_data: bad max packet size
  Aug  9 19:05:46 dell last message repeated 7 times
  Aug  9 19:05:46 dell /bsd: ugen1 at uhub0 port 10 "Broadcom Corp 5880" rev 
1.10/1.01 addr 3
  Aug  9 19:05:46 dell /bsd: usbd_fill_iface_data: bad max packet size
  Aug  9 19:05:46 dell last message repeated 7 times
  Aug  9 19:05:47 dell /bsd: uvideo0 at uhub0 port 11 configuration 1 interface 
0 "CN0J8NNP7248765RBBM6A00 Integrated_Webcam_HD" rev 2.00/54.13 addr 4
  Aug  9 19:05:47 dell /bsd: video0 at uvideo0

The apmd is running as 'apmd -A'.
The suspend was initiated by 'zzz' (and seems to go fine);
the resume was initiated by pressing the blinking power button.
It does not resume fully: the screen stays black. The detached
usb devices re-attach, the machine is pingable, but I cannot
connect with ssh.

Maybe related: there is no vga0, but there is vga1.

  vga1 at pci0 dev 2 function 0 "Intel HD Graphics 530" rev 0x06
  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
  wsdisplay0: screen 1-5 added (80x25, vt100 emulation)

Maybe also related: on intel graphics, mplayer usually has no problem
going fullscreen; here, fullscren just means the original size centered
on an otherwise empty screen. 'xvinfo' says 'no adaptors present'.
Is that expected?

Also, there is quite a few devices "not configured".
See below for pcidump -xxvv.

How can I help further debug this machine?

Thank you

Jan



OpenBSD 6.0-current (GENERIC.MP) #1: Mon Aug  8 19:55:50 CEST 2016
r...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16810340352 (16031MB)
avail mem = 16296390656 (15541MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries)
bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016
bios0: Dell Inc. Latitude E5570
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP 
DBG2 SSDT UEFI SSDT SSDT SLIC DMAR ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
UAR1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) 
RP12(S4) PXSX(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-6440HQ CPU @ 2.60GHz, 2295.51 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,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 23MHz
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-6440HQ CPU @ 2.60GHz, 2294.63 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.63 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 

Re: opportunity to help: %s audit in mandoc

[attila]

Dariusz Sendkowski  writes:

> From the list below:
>
>   27 cgi.c:
>4 dbm.c:
>5 dbm_map.c:

I'll start on these three...

>// 3 eqn.c:

... and check you here.  When I get that far I'll post again, or if
it's taking me longer than I thought it would I'll post at the end of
the day anyway.

>5 html.c:
>   20 main.c:
>2 man.c:
>2 man_html.c:
>5 man_macro.c:
>// 2 man_term.c:
>9 man_validate.c:
>   37 mandocdb.c:
>2 manpath.c:
>   23 mansearch.c:
>4 mdoc_html.c:
>// 10 mdoc_macro.c:
>1 mdoc_man.c:
>2 mdoc_term.c:
>   43 mdoc_validate.c:
>6 read.c:
>   13 roff.c:
>// 1 tag.c:
>// 1 tbl_layout.c:
>// 1 tbl_opts.c:
>6 term_ps.c:
>   11 tree.c:
>
> I've checked the commented (//) files so far and they look fine. You can
> recheck or take new ones.
> Unfortunately, I don't have as much time as I'd like to so this goes rather
> slowly.
>

See you in a few hours :-)

Pax, -A

>
>
> 2016-08-09 18:41 GMT+02:00 attila :
>
>> Hi {Ingo,Darius,misc@},
>>
>> Ingo Schwarze  writes:
>>
>> > Hi Dariusz,
>> >
>> > Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:
>> >
>> >> OK, but from which branch?
>> >
>> > We don't use branches in OpenBSD.
>> > Just use the HEAD of the OpenBSD CVS repository.
>> >
>> > You don't need to worry about merging to the portable mandoc
>> > on mdocml.bsd.lv.  That's a no-brainer i'll take care of.
>> >
>> >> Can the results be sent incrementally?
>> >
>> > Yes, that's ideal.
>> >
>> > Don't work for days before sending anything.  Imagine you misunderstand
>> > something and only learn about your error after having wasted days
>> > of work.  That would be bad.  Or imagine two people start working
>> > on the same task and work for days, both preparing the same huge
>> > report.  That would be a waste, too.  That cannot happen if you
>> > send results incrementally right after finding them.
>>
>> Sorry I'm late to the party, as usual, but I had some trouble getting
>> my -current setup back to a reasonable state.  I would like to pitch
>> in on this if it is still needed, and don't want to duplicate work.  I
>> have a list of 221 hits for %s in /usr/src/usr.bin/mandoc in front of
>> me.  Shall I start at the top or has that already happened?
>>
>> > In general, OpenBSD prefers small patches that are easy to understand
>> > and verify, in particular from new contributors.  They need not be
>> > easy to produce, though.
>> >
>> > Yours,
>> >   Ingo
>>
>> Pax, -A
>> --
>> http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF


--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: opportunity to help: %s audit in mandoc

[Dariusz Sendkowski]

>From the list below:

  27 cgi.c:
   4 dbm.c:
   5 dbm_map.c:
   // 3 eqn.c:
   5 html.c:
  20 main.c:
   2 man.c:
   2 man_html.c:
   5 man_macro.c:
   // 2 man_term.c:
   9 man_validate.c:
  37 mandocdb.c:
   2 manpath.c:
  23 mansearch.c:
   4 mdoc_html.c:
   // 10 mdoc_macro.c:
   1 mdoc_man.c:
   2 mdoc_term.c:
  43 mdoc_validate.c:
   6 read.c:
  13 roff.c:
   // 1 tag.c:
   // 1 tbl_layout.c:
   // 1 tbl_opts.c:
   6 term_ps.c:
  11 tree.c:

I've checked the commented (//) files so far and they look fine. You can
recheck or take new ones.
Unfortunately, I don't have as much time as I'd like to so this goes rather
slowly.



2016-08-09 18:41 GMT+02:00 attila :

> Hi {Ingo,Darius,misc@},
>
> Ingo Schwarze  writes:
>
> > Hi Dariusz,
> >
> > Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:
> >
> >> OK, but from which branch?
> >
> > We don't use branches in OpenBSD.
> > Just use the HEAD of the OpenBSD CVS repository.
> >
> > You don't need to worry about merging to the portable mandoc
> > on mdocml.bsd.lv.  That's a no-brainer i'll take care of.
> >
> >> Can the results be sent incrementally?
> >
> > Yes, that's ideal.
> >
> > Don't work for days before sending anything.  Imagine you misunderstand
> > something and only learn about your error after having wasted days
> > of work.  That would be bad.  Or imagine two people start working
> > on the same task and work for days, both preparing the same huge
> > report.  That would be a waste, too.  That cannot happen if you
> > send results incrementally right after finding them.
>
> Sorry I'm late to the party, as usual, but I had some trouble getting
> my -current setup back to a reasonable state.  I would like to pitch
> in on this if it is still needed, and don't want to duplicate work.  I
> have a list of 221 hits for %s in /usr/src/usr.bin/mandoc in front of
> me.  Shall I start at the top or has that already happened?
>
> > In general, OpenBSD prefers small patches that are easy to understand
> > and verify, in particular from new contributors.  They need not be
> > easy to produce, though.
> >
> > Yours,
> >   Ingo
>
> Pax, -A
> --
> http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: opportunity to help: %s audit in mandoc

[attila]

Hi {Ingo,Darius,misc@},

Ingo Schwarze  writes:

> Hi Dariusz,
>
> Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:
>
>> OK, but from which branch?
>
> We don't use branches in OpenBSD.
> Just use the HEAD of the OpenBSD CVS repository.
>
> You don't need to worry about merging to the portable mandoc
> on mdocml.bsd.lv.  That's a no-brainer i'll take care of.
>
>> Can the results be sent incrementally?
>
> Yes, that's ideal.
>
> Don't work for days before sending anything.  Imagine you misunderstand
> something and only learn about your error after having wasted days
> of work.  That would be bad.  Or imagine two people start working
> on the same task and work for days, both preparing the same huge
> report.  That would be a waste, too.  That cannot happen if you
> send results incrementally right after finding them.

Sorry I'm late to the party, as usual, but I had some trouble getting
my -current setup back to a reasonable state.  I would like to pitch
in on this if it is still needed, and don't want to duplicate work.  I
have a list of 221 hits for %s in /usr/src/usr.bin/mandoc in front of
me.  Shall I start at the top or has that already happened?

> In general, OpenBSD prefers small patches that are easy to understand
> and verify, in particular from new contributors.  They need not be
> easy to produce, though.
>
> Yours,
>   Ingo

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: hostname.if manpage enhancement: be clearer about #

[Jason McIntyre]

On Mon, Aug 08, 2016 at 10:23:22AM +0200, Michal Bozon wrote:
> Hi, I've had an issue connecting to a wireless network
> (by doas sh /etc/netstart $if). Its password contained
> '#' character(s).
> 
> Even adding "debug" keyword did not assure me
> whether the problem is with my password definition:
> wpakey s3cur3-as-#311, for illustration (was not sure
> if the '#' has to be escaped somehow); or somewhere
> else. Finally, it was the latter, but it took me a while
> to realize that.
> 
> Current hostname.if manpage is not absolutely clear:
> 
>   #Comments are allowed.  Anything following a comment
>   character is treated as a comment.
> 
> It suggests that what is before '#' might have a meaning,
> while the broader context of the definition strongly suggests
> that comment it is when '#' "keyword" is at the beginning.
> 
> Looking into /etc/netstart might also be confusing -
> just at the beginning, there's stripcom() function definition,
> which clearly strips the input line from '#' and following.
> However, this function is NOT applied to /etc/hostname.if,
> it is treated differently, entire line beginning with '#'
> is skipped (see # Skip comments and empty lines).
> 
> I am therefore proposing following or similar change:
> 
> --- /usr/src/share/man/man5/hostname.if.5
> +++ /usr/src/share/man/man5/hostname.if.5
> @@ -201,7 +201,7 @@
>  the interface, such as 64.
>  .It Li #
>  Comments are allowed.
> -Anything following a comment character is treated as a comment.
> +Line beginning with a comment character is treated as a comment.
>  .It Li \&! Ns Ar command
>  Arbitrary shell commands can be executed using this directive, as
>  long as they are available in the single-user environment (for
> 

hi.

the diff as-is is wrong. i mean it's valid to have this in your
hostname.if file:

up  # blah blah

that's a very common construct, and is allowed.

however it might be that to the list of things that should be double
quoted (whitespace and single quotes) we should add the comment
character. i'm not sure though.

jmc

Re: PC Engines APU NIC (RTL8111E) performance

[Momtchil Momtchev]

On 09/08/16 12:26, Momtchil Momtchev wrote:

On 09/08/16 03:03, Darren Tucker wrote:

On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:

On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
[...] .



Also what I find very puzzling is that lower IRQ rates lead to 
lower CPU utilization but not higher throughput??


I just completely disabled the interrupt moderation by bypassing 
the code. 1 packet = 1 IRQ. Now I get a whopping 30k+ IRQ/s and the RX 
performance is still the same, even a little bit higher - 350 MBit/s - 
with the pf rules and everything. Now I am definitely CPU-bound - idle 
is about 5%, the interrupt load is about 110% and the system load is 
about 80% (the APU has 2 cores). Idle was 50% to 60% with interrupt 
moderation. I am testing on a remote board so I can't easily disable pf 
(it does NAT). I will try to properly test it with routing-only.
Then I did another test with interrupt moderation and mutithreaded 
iperf. This way the board goes up to 500 MBit/s and idle is down to 
practically 0% - which is consistent with your 600 MBit/s result without 
pf. So the main problem seems to be the interrupt moderation-induced 
latency which confuses the end-point TCP. I also get slightly higher 
performance with a larger TCP window. So one should actually aim to 
transfer less packets per IRQ in order to minimize the latency. 2 
packets per IRQ seems a very good compromise. So maybe this explains the 
0x5151 value? Where 1 is every second packet?

Re: ksh, ctrl-r followed by arrow key leaves "[D" or "[C" artifacts

[Dave Cohen]

Ingo,

I've been lurking, and delighted to see that my post led to a patch.  As a 
newbie, it's been interesting to see this process in action.  I'm in total 
agreement with the approach you've taken in the patch.

I'm not yet at the level of running -current.  But I look forward to the fix 
when I get there, or when the release comes out (which could well happen first).

Cheers,
-Dave



On Tue, Aug 9, 2016, at 05:39 AM, Ingo Schwarze wrote:
> Hi,
> 
> Dave Cohen wrote on Sun, Aug 07, 2016 at 04:52:50PM -0700:
> 
> > Problem happens when I navigate command history with ctrl-r, then
> > use left or right arrow.  Hitting left arrow writes "[D", right
> > inserts "[C".  I'm hitting the arrow keys so I can edit my prior
> > command.  It's a habit I'm used to that works in bash.
> 
> Fixed in -current, thanks for reminding us of the long-standing
> issue and providing a useful partial analysis of what was wrong.
> 
> Yours,
>   Ingo

Re: Relayd and stateful tracking options

[Sebastian Benoit]

Mathieu BLANC(mathieu.bl...@smile.fr) on 2016.08.09 11:18:57 +0200:
> Hello,
> 
> I'm using relayd with Redirections (OpenBSD 5.9)
> Relayd creates these rdr-to rules :
> anchor "_http" all {
>   pass in quick on rdomain 0 inet proto tcp from any to A.B.C.D port = 80 
> flags S/SA keep state (tcp.established 600) rdr-to  port 80 
> round-robin
> }
> 
> Is there a way to modify the Stateful Tracking Options after keep state ? (I'd
> want to add a max state on a specific redirection)
> 
> Thanks !

Use the "pftag name" option.

That will change the inserted rule to not have the quick keyword. Also it
gets a "tagged name" added.

Then, in pf.conf add another rule

 pass in tagged name keep state (max 3)

favicon editor

[jsg]

   Thanks for your replies
   :)

Re: ksh, ctrl-r followed by arrow key leaves "[D" or "[C" artifacts

[Ingo Schwarze]

Hi,

Dave Cohen wrote on Sun, Aug 07, 2016 at 04:52:50PM -0700:

> Problem happens when I navigate command history with ctrl-r, then
> use left or right arrow.  Hitting left arrow writes "[D", right
> inserts "[C".  I'm hitting the arrow keys so I can edit my prior
> command.  It's a habit I'm used to that works in bash.

Fixed in -current, thanks for reminding us of the long-standing
issue and providing a useful partial analysis of what was wrong.

Yours,
  Ingo

Re: PC Engines APU NIC (RTL8111E) performance

[Momtchil Momtchev]

On 09/08/16 03:03, Darren Tucker wrote:

On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:

On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
[...]

What is the problem with software interrupt moderation? That it has a
fixed timer while the hardware one scales with the RX rate?

The hardware moderation can do per-N-packets in addition to a timer.



I just went through the two Linux drivers. There is the GPLd r8169 
that is built into the official kernel written by someone at Realtek. 
This one uses hardware interrupt moderation with the 0x5151 magic. Then 
there is the r8168 driver distributed by Realtek on their site. It is 
also GPLd. That one is considered to be of better quality in the Linux 
world and it is repackaged by some Linux distros (Debian and Ubuntu for 
example) as a replacement for the built-in driver. This second driver 
uses a strategy similar to the current OpenBSD driver - schedule an 
interrupt, then whenever the queue is not empty, reschedule the next 
interrupt using a hardware timer (register 0x58) on the chip (ie. 
"simulated" interrupt moderation) and still has exceptional performance. 
The Realtek timer value in Linux is fixed 0x2600. The OpenBSD driver 
deduces it from the bus speed. Anyway I think that at least on the PC 
Engines APU the bottleneck is not CPU- or IRQ-related.

Re: Encrypting carp traffic with ipsec

[C. L. Martinez]

On Thu  4.Aug'16 at 12:30:56 +, C. L. Martinez wrote:
> On Tue  2.Aug'16 at  7:54:08 +, C. L. Martinez wrote:
> > On Mon  1.Aug'16 at  7:54:57 +, C. L. Martinez wrote:
> > > On Fri 29.Jul'16 at 10:55:01 +0300, Kapetanakis Giannis wrote:
> > > > On 28/07/16 22:47, C. L. Martinez wrote:
> > > > > Hi all,
> > > > > 
> > > > >  I will try to encrypt all carp traffic between two OpenBSD 5.9 fws
> > > > > (fully patched). According to ifconfig(8) man page:
> > > > > 
> > > > > carppeer peer_address
> > > > > Send the carp advertisements to a specified point-to-point peer or
> > > > > multicast group instead of sending the messages to the default carp
> > > > > multicast group. The peer_address is the IP address of the other host
> > > > > taking part in the carp cluster. With this option, carp(4) traffic can
> > > > > be protected using ipsec(4) and it may be desired in networks that do
> > > > > not allow or have problems with IPv4 multicast traffic.
> > > > > 
> > > > >  And the last sentence describes the type of problem that I want to
> > > > > avoid: "carp(4) traffic can be protected using ipsec(4) and it may be
> > > > > desired in networks that do not allow or have problems with IPv4
> > > > > multicast traffic".
> > > > > 
> > > > >  But I don't see how to implement this feature. If I am not wrong, I
> > > > > need to configure ipsec in transport mode. But how to encrypt carp
> > > > > protocol only and keep all others services and protocols out of ipsec
> > > > > tunnels??
> > > > > 
> > > > >  Any tip or sample??
> > > > > 
> > > > 
> > > > 
> > > > check proto (from protocol) in ipsec.conf(5)
> > > > 
> > > > G
> > > > 
> > > 
> > > Ok, after doing several tests these days, I have configured ipsec.conf 
> > > instead of iked.conf. But carp interfaces remains in MASTER mode in both 
> > > firewalls:
> > > 
> > > FwA:
> > > 
> > > carp0: flags=8843 mtu 1500
> > > lladdr 01:00:5e:00:01:01
> > > priority: 15
> > > carp: carpdev vio0 advbase 1 balancing ip carppeer 172.22.55.13
> > > state MASTER vhid 1 advskew 100
> > > state MASTER vhid 2 advskew 0
> > > groups: carp
> > > status: master
> > > inet 172.22.55.14 netmask 0x19f0 broadcast 172.22.247.15
> > > carp1: flags=8843 mtu 1500
> > > lladdr 01:00:5e:00:01:03
> > > priority: 15
> > > carp: carpdev vio1 advbase 1 balancing ip carppeer 172.30.77.3
> > > state MASTER vhid 3 advskew 100
> > > state MASTER vhid 4 advskew 0
> > > groups: carp
> > > status: master
> > > inet 172.30.77.1 netmask 0xfff8 broadcast 172.30.77.7
> > > 
> > > 
> > > 
> > > 
> > > FwB:
> > > 
> > > carp0: flags=8843 mtu 1500
> > > lladdr 01:00:5e:00:01:01
> > > priority: 15
> > > carp: carpdev vio0 advbase 1 balancing ip carppeer 172.22.55.12
> > > state MASTER vhid 1 advskew 0
> > > state MASTER vhid 2 advskew 100
> > > groups: carp
> > > status: master
> > > inet 172.22.55.14 netmask 0x19f0 broadcast 172.22.247.15
> > > carp1: flags=8843 mtu 1500
> > > lladdr 01:00:5e:00:01:03
> > > priority: 15
> > > carp: carpdev vio1 advbase 1 balancing ip carppeer 172.30.77.2
> > > state MASTER vhid 3 advskew 0
> > > state MASTER vhid 4 advskew 100
> > > groups: carp
> > > status: master
> > > inet 172.30.77.1 netmask 0xfff8 broadcast 172.30.77.7
> > > 
> > > 
> > > IPsec flows are established in both firewalls:
> > > 
> > > FwA:
> > > 
> > > FLOWS:
> > > flow esp in proto carp from 172.22.57.3 to 172.22.57.2 peer 172.22.57.3 
> > > srcid 172.22.57.2/32 dstid 172.22.57.3/32 type use
> > > flow esp out proto carp from 172.22.57.2 to 172.22.57.3 peer 172.22.57.3 
> > > srcid 172.22.57.2/32 dstid 172.22.57.3/32 type require
> > > flow esp in proto carp from 172.22.58.3 to 172.22.58.2 peer 172.22.58.3 
> > > srcid 172.22.58.2/32 dstid 172.22.58.3/32 type use
> > > flow esp out proto carp from 172.22.58.2 to 172.22.58.3 peer 172.22.58.3 
> > > srcid 172.22.58.2/32 dstid 172.22.58.3/32 type require
> > > flow esp in proto carp from 172.22.55.13 to 172.22.55.12 peer 
> > > 172.22.55.13 srcid 172.22.55.12/32 dstid 172.22.55.13/32 type use
> > > flow esp out proto carp from 172.22.55.12 to 172.22.55.13 peer 
> > > 172.22.55.13 srcid 172.22.55.12/32 dstid 172.22.55.13/32 type require
> > > flow esp in proto carp from 172.30.77.3 to 172.30.77.2 peer 172.30.77.3 
> > > srcid 172.30.77.2/32 dstid 172.30.77.3/32 type use
> > > flow esp out proto carp from 172.30.77.2 to 172.30.77.3 peer 172.30.77.3 
> > > srcid 172.30.77.2/32 dstid 172.30.77.3/32 type require
> > > flow esp in proto carp from 172.22.54.3 

Re: IPv6 fragmentation woes

[Laurent CARON]

Hi,

Does anybody have a clue about this issue ? Thanks



Setup:
Source: Linux box: 2a02:27d0:100:115:6000::200
Destination: OpenBSD 5.9-stable box: 2a02:27d0:116::3

Source#:  ping6 -M do -s 1232 2a02:27d0:100:114::3
PING 2a02:27d0:100:114::3(2a02:27d0:100:114::3) 1232 data bytes
1240 bytes from 2a02:27d0:100:114::3: icmp_seq=1 ttl=63 time=0.224 ms
...
1240 bytes from 2a02:27d0:100:114::3: icmp_seq=4 ttl=63 time=0.274 ms
^C
--- 2a02:27d0:100:114::3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.203/0.241/0.274/0.034 ms

Destination#: tcpdump -ni trunk0 host 2a02:27d0:100:115:6000::200
tcpdump: listening on trunk0, link-type EN10MB
16:26:22.236667 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:26:22.236684 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: 
icmp6: echo reply
16:26:23.235712 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:26:23.235732 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: 
icmp6: echo reply
16:26:24.234770 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:26:24.234786 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: 
icmp6: echo reply



Now when increasing to 1233 data bytes:

Source#: ping6 -M do -s 1233 2a02:27d0:100:114::3
PING 2a02:27d0:100:114::3(2a02:27d0:100:114::3) 1233 data bytes
1241 bytes from 2a02:27d0:100:114::3: icmp_seq=1 ttl=63 time=0.212 ms
...
1241 bytes from 2a02:27d0:100:114::3: icmp_seq=12 ttl=63 time=0.232 ms
^C
--- 2a02:27d0:100:114::3 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 10998ms
rtt min/avg/max/mdev = 0.206/0.236/0.342/0.043 ms

Destination#: tcpdump -ni trunk0 host 2a02:27d0:100:115:6000::200
16:28:23.922257 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:28:23.922284 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x11cd00dd:1232@0+) icmp6: echo reply
16:28:23.922289 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x11cd00dd:9@1232)
16:28:24.921229 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:28:24.921256 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x1be2a72d:1232@0+) icmp6: echo reply
16:28:24.921260 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x1be2a72d:9@1232)
16:28:25.920252 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:28:25.920290 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x15850f70:1232@0+) icmp6: echo reply
16:28:25.920294 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x15850f70:9@1232)
16:28:26.919167 2a02:27d0:100:115:6000::200 > 2a02:27d0:100:114::3: 
icmp6: echo request [flowlabel 0x9d84e]
16:28:26.919194 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x30d81daa:1232@0+) icmp6: echo reply
16:28:26.919200 2a02:27d0:100:114::3 > 2a02:27d0:100:115:6000::200: frag 
(0x30d81daa:9@1232)



Sounds like replies are fragmented.

Please note trunk0 is composed of one em and one bnx interface:

trunk0: flags=8943 mtu 1500
lladdr 00:1b:21:b5:2a:8d
priority: 0
trunk: trunkproto lacp
trunk id: [(8000,00:1b:21:b5:2a:8d,4074,,),
 (007F,64:87:88:bc:db:00,0006,,)]
trunkport bnx2 active,collecting,distributing
trunkport em3 active,collecting,distributing
groups: trunk
media: Ethernet autoselect
status: active

Am I mistaken on something, or is this behavior perfectly normal ?

Please note # tracepath6 from the linux box to the openbsd one reports:
Resume: pmtu 1500 hops 2 back 2

Thanks

Laurent

Re: PC Engines APU NIC (RTL8111E) performance

[Momtchil Momtchev]

On 09/08/16 03:03, Darren Tucker wrote:

On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:

On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
[...]


A quick test with this diff (just routing through it, no PF, no pool
debug) gives me:

$ iperf -c host -i 10 -t 60



[  3]  0.0-60.0 sec  5.16 GBytes   739 Mbits/sec




I tried this patch (5f22 in the RL_IM register) on 5.9-stable, no 
POOL_DEBUG, 30 pf rules and about 10k states and I got about 8000 IRQ/s 
(up from 6000/s on vanilla) and iperf RX throughput was down to 280 
MBit/s. I then tried upping the RXPKTS to 15 and the RXTIME to 4 (100us) 
- this is 5f4f in RL_IM. The IRQs dropped to 5000 IRQ/s and the CPU 
utilisation went down, but RX throughput went further down to 240 
MBit/s. Next I tried the magic value 5151 and IRQs dropped to 4000 IRQ/s 
(???), CPU went down and throughput went down to 200 MBit/s.
All these are RX values. On the TX side I get slightly higher 
throughput and a higher IRQ rate.
There are no public datasheets for the 8111E and I think there is 
something fishy with those values. The original source of the 5151 magic 
is the open-source driver by Realtek. Hopefully they know what they are 
doing. They have a Linux and a FreeBSD driver on their site. The one for 
FreeBSD seems to be based on that same driver by Bill Paul from 
Windriver and it uses this magic value which doesn't make any sense if 1 
is the number of packets to wait before sending an interrupt.


Also what I find very puzzling is that lower IRQ rates lead to 
lower CPU utilization but not higher throughput??


What hardware are you using? This is not an APU? Maybe there is 
some other bottleneck on the APU? Are you getting higher performance 
than on vanilla?

Re: athn0: device timeout with AR9271

[Kapfhammer, Stefan]

http://man.openbsd.org/usb.4

Go through all the manpages and look at "bugs",
mostly at the end of all manpages. I have no
recommen‎dation right now. Have no USB network
device‎. Good luck.

‎Wireless network interfaces
athn(4)
Atheros IEEE 802.11a/b/g/n wireless network device
atu(4)
Atmel AT76C50x IEEE 802.11b wireless network device
otus(4)
Atheros USB IEEE 802.11a/b/g/n wireless network device
rsu(4)
Realtek RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network device
rum(4)
Ralink Technology/MediaTek USB IEEE 802.11a/b/g wireless network device
run(4)
Ralink Technology/MediaTek USB IEEE 802.11a/b/g/n wireless network device
uath(4)
Atheros USB IEEE 802.11a/b/g wireless network device
upgt(4)
Conexant/Intersil PrismGT SoftMAC USB IEEE 802.11b/g wireless network device
ural(4)
Ralink Technology/MediaTek USB IEEE 802.11b/g wireless network device
urtw(4)
Realtek RTL8187L/RTL8187B USB IEEE 802.11b/g wireless network device
urtwn(4)
Realtek RTL8188CU/RTL8188EU/RTL8192CU USB IEEE 802.11b/g/n wireless network 
device
wi(4)
Intersil PRISM 2-3 IEEE 802.11b wireless network device
zyd(4)
ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device


Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht
Von: ML mail
Gesendet: Dienstag, 9. August 2016 10:13
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: Re: athn0: device timeout with AR9271


Uh oh, now it all makes sense with AP mode is not working propery with my
athn...

Can anyone recommend me a USB wireless adapter which does work as host AP on
OpenBSD?


On Monday, August 8, 2016 9:34 PM, "Kapfhammer, Stefan" 
wrote:



http://man.openbsd.org/OpenBSD-current/man4/athn.4

Last line "Bugs":

‎Host AP mode does not work with USB devices.

Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht

Von: ML mail
Gesendet: Montag, 25. Juli 2016 12:00
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: athn0: device timeout with AR9271


Hi,

I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to
time there are timeouts which prevents any access to it anymore until I either
plug out and in the Wifi dongle again or reboot.

Here is the hardware details of that Wifi USB dongle:


athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
2.00/1.08 addr 4
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx


There error is the following (many of these messages are repeated):


athn0: device timeout


My /etc/hostname.athn0 is the following:

inet 172.16.20.1 255.255.255.0
media autoselect
mediaopt hostap
mode 11b
chan 6
nwid 
wpakey 

So I was wondering what is going on here... Is my Wifi USB dongle crap? or am
I maybe doing something wrong?

Let me know if I should provide any other infos...


Regards
ML

Relayd and stateful tracking options

[Mathieu BLANC]

Hello,

I'm using relayd with Redirections (OpenBSD 5.9)
Relayd creates these rdr-to rules :
anchor "_http" all {
  pass in quick on rdomain 0 inet proto tcp from any to A.B.C.D port = 80 flags 
S/SA keep state (tcp.established 600) rdr-to  port 80 round-robin
}

Is there a way to modify the Stateful Tracking Options after keep state ? (I'd
want to add a max state on a specific redirection)

Thanks !

--
Mathieu

Re: athn0: device timeout with AR9271

[ML mail]

Uh oh, now it all makes sense with AP mode is not working propery with my
athn...

Can anyone recommend me a USB wireless adapter which does work as host AP on
OpenBSD?


On Monday, August 8, 2016 9:34 PM, "Kapfhammer, Stefan" 
wrote:



http://man.openbsd.org/OpenBSD-current/man4/athn.4

Last line "Bugs":

‎Host AP mode does not work with USB devices.

Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht

Von: ML mail
Gesendet: Montag, 25. Juli 2016 12:00
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: athn0: device timeout with AR9271


Hi,

I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to
time there are timeouts which prevents any access to it anymore until I either
plug out and in the Wifi dongle again or reboot.

Here is the hardware details of that Wifi USB dongle:


athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
2.00/1.08 addr 4
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx


There error is the following (many of these messages are repeated):


athn0: device timeout


My /etc/hostname.athn0 is the following:

inet 172.16.20.1 255.255.255.0
media autoselect
mediaopt hostap
mode 11b
chan 6
nwid 
wpakey 

So I was wondering what is going on here... Is my Wifi USB dongle crap? or am
I maybe doing something wrong?

Let me know if I should provide any other infos...


Regards
ML