Re: HP 1020 G1 OpenBSD 6.0 Beta status and dmesg

[Bodie]

On 15.06.2016 20:29, Mike Larkin wrote:

On Wed, Jun 15, 2016 at 09:47:35AM +0200, Bodie wrote:

Hi all,

trying to find if OpenBSD will be usable on this laptop via USB live 
OpenBSD
6.0 Beta install. There was some fight with old USB flash and EFI, 
but is

already resolved so that I can provide some outputs and info.

1) VGA works including 3D
2) USB camera is detected (I have firmware on flash disk), but 
video(1) does

not work with it, will play more later on
3) ACPI/apm seems reasonable , but reported battery life is only 
around 231
minutes (when regular is around 8 hours), except of boot CPU other 
threads
have problems with identification, but scaling and load is ok and 
acpitz5


This probably happens only when booting off battery, right? (Eg, the 
"failed

to identify" messages). If you boot when plugged in to AC, I bet it
doesn't do


However it is same if on battery or AC and dmesgs were collected with 
AC.

Still IRQ, us,sy,wa are ok on CPUs including freq scaling.



that.

zone is showing somewhat suspicious high temperature right from 
start


hw.sensors.cpu0.temp0=42.00 degC
hw.sensors.acpitz0.temp0=43.00 degC (zone temperature)
hw.sensors.acpitz1.temp0=0.00 degC (zone temperature)
hw.sensors.acpitz2.temp0=37.00 degC (zone temperature)
hw.sensors.acpitz3.temp0=40.00 degC (zone temperature)
hw.sensors.acpitz4.temp0=35.00 degC (zone temperature)
hw.sensors.acpitz5.temp0=84.00 degC (zone temperature)
hw.sensors.acpitz6.temp0=0.00 degC (zone temperature)
hw.sensors.acpitz7.temp0=0.00 degC (zone temperature)
hw.sensors.acpibat0.volt0=7.60 VDC (voltage)
hw.sensors.acpibat0.volt1=8.57 VDC (current voltage)
hw.sensors.acpibat0.current0=1.21 A (rate)
hw.sensors.acpibat0.amphour0=4.66 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.20 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.10 Ah (low capacity)
hw.sensors.acpibat0.amphour3=4.66 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=4.66 Ah (design capacity)
hw.sensors.acpibat0.raw0=1 (battery full), OK
hw.sensors.acpiac0.indicator0=Off (power supply)
hw.sensors.acpibtn1.indicator0=On (lid open)

$ cat apm.txt
Battery state: high, 100% remaining, 231 minutes life estimate
A/C adapter state: not connected
Performance adjustment mode: auto (500 MHz)
$

Can provide acpidump directly from OpenBSD later on if some 
developer will
be interested. Right now I have them only from Windows via iasl in 
.dat and

.dsl format

4) Network devices are detected, but iwm0 does not work properly (do 
not
know if firmware or driver related). I am able to associate with AP, 
but
dhclient is not getting any lease. Thought it may be related to 
802.11n
usage as my AP transmit in yet unsupported way by OpenBSD so I 
switched to
802.11g only, but the problem with dhclient was same. No errors 
either from

dhclient or firmware of iwm0 during those steps

5) dmesg of 1st boot after install

OpenBSD 6.0-beta (GENERIC.MP) #2165: Thu Jun  2 08:37:59 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8203530240 (7823MB)
avail mem = 7950278656 (7581MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9ba3f000 (33 entries)
bios0: vendor Hewlett-Packard version "M77 Ver. 01.11" date 
01/18/2016

bios0: Hewlett-Packard HP EliteBook Folio 1020 G1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SSDT SLIC MSDM FPDT 
BGRT

SSDT SSDT SSDT SSDT SSDT SSDT ASF! DMAR
acpi0: wakeup devices LANC(S0) EHC1(S0) XHC_(S0) PCIB(S5) RP03(S0) 
NIC_(S0)

RP04(S5) WNIC(S5) HST1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.63 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,BMI1,HLE,AV
X2,SMEP,BMI2,ERMS,INVPCID,RTM,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 1 (application processor)
cpu1: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.46 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,BMI1,HLE,AV
X2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 

ipsec routing issues

[rizz2pro]

Hi, im not sure if this is some kind of bug or by design but I thought
i would ask.

Firstly check out this diagram I made: http://i.imgur.com/EUXqauH.png
- I hope im allowed to post that link.


The servers have default routes to their firewalls.
Firewall A has a default route to 10.100.100.2
Firewall B has a default route to 10.100.100.1

I turn off ipsec, kill all my tunnels.

Server A can ping Server Z and on both firewalls I see the ICMP
traffic coming on em1. Great, thats exactly what I expected.

In /etc/ipsec.conf on each firewall I set the peer to use the
172.16.0.x IP instead of using what I've set as the default
gateways(don't ask why..).

FW1:
ike esp from 192.168.99.0/24 to 192.168.200.0/24 peer 172.16.0.2

FW2:
ike esp from 192.168.200.0/24 to 192.168.99.0/24 peer 172.16.0.1

I enable isakmpd, enable ipsec, my flows/SADs are good. My continuous
ping still works but now I have no traffic flowing through em1 and all
traffic is encrypted and flowing over em2. I figure that ipsec is
ignoring the routing table and sending that matching traffic to his
peer. I deleted the default routes altogether since no traffic is
being passed through there anymore. All my pings stopped working.

Another interesting thing is it seems like as long as there is any
kind of entry in the routing table for the network you're trying to
reach, it will fix things:

On FW1 and FW2 this fixed my pings between Server A and Server Z:

# route add default 127.0.0.1

That fixes my pings. If I delete all default routes and add static routes:

FW1:
# route delete default
# route add 192.168.200.0/24 127.0.0.1

FW2:
# route delete default
# route add 192.168.99.0/24 127.0.0.1

This also fixes my pings. I can also set the gateway to an IP that
doesn't even exist:

FW1:
# route delete default
# route add 192.168.200.0/24 192.168.99.45

FW2:
# route delete default
# route add 192.168.99.0/24 192.168.200.27

All of these things will fix my connectivity. The moment the route
doesn't exist or I remove the default route it breaks everything.


So I am wondering what is going on. I can fix my pings by adding fake
routes, routes that point at a loopback address and creating default
routes that lead to non-existant IP's, but everything seems to break
if I delete the route altogether.

Hopefully someone here can shed some light. If you need to see any
config files, I can provide them but I felt like it's a pretty
straight forward issue.

Thanks

Re: opensmtd failing and a work a round

[Gilles Chehade]

On Wed, Jun 15, 2016 at 07:33:47PM +, Peter Fraser wrote:
> I apologize for the missing newlines in the earlier messages
> 
> opensmtpd has a bug, that I know is being worked on. It leave streams open
> that should be closed and will eventually stop listening for new connections.
> 
> The only fix I know at the moment is to restart opensmtpd.
> 

Just to clarify since your mail might confuse people:

The bug triggers in the filter code which is NOT production-ready and we
enabled with an EXPERIMENTAL note in the release mail so developers help
spot bugs and improve the API.

If you need a stable setup, don't use filters before we announce that it
is a stable feature.

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

smtpd failing and a work around

[Peter Fraser]

Trying again to get the line feeds. Microsoft outlook seems intent on deleting
them.
I apologize for mistake

opensmtpd has a bug, that I know is being worked on. It leave streams open
that should be closed and will eventually stop listening for new connections.

The only fix I know at the moment is to restart opensmtpd.

My first attempt to mitigate this problem was to use timeout to see if "telnet
mail 25" responded.
If I didn't get the 2220 mail.thinkage.ca ESMTP OpenSMTPD. I knew it was time
to restart smtpd

When I was doing this I did miss the timeout command that linux has
(https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.h
tml)

But knowing that it was the total number of stream that were open that cause
the problem enabled a simple solution.
I used the following shell script under a nohup

#ksh
while true ;do
  p=`pgrep -f "smtpd: pony express"`
  i=`fstat -p $p |grep -c " stream "`
  m=""
  if test  $i -ge 100 ; then
 /etc/rc.d/smtpd restart
 m=restarted
  fi
  logger smtpd - pony express streams $i $m
  sleep 600
done

all the smtpd processes seem to leave extra streams open.
"pony express" seems to leave the most open.

This generates output in /var/log/messages on my system and you can see how
the number streams build.

Since I have running this I have not had a problem will smtpd hanging,
although I recognize that it is crude work around



Jun 12 12:25:30 gateway root: smtpd - pony express streams 23

Jun 12 12:35:32 gateway root: smtpd - pony express streams 25

Jun 12 12:45:33 gateway root: smtpd - pony express streams 26

Jun 12 12:55:33 gateway root: smtpd - pony express streams 25

Jun 12 13:05:33 gateway root: smtpd - pony express streams 25

Jun 12 13:15:33 gateway root: smtpd - pony express streams 27

Jun 12 13:25:33 gateway root: smtpd - pony express streams 29

Jun 12 13:35:33 gateway root: smtpd - pony express streams 29

Jun 12 13:45:33 gateway root: smtpd - pony express streams 31

Jun 12 13:55:33 gateway root: smtpd - pony express streams 33

Jun 12 14:05:33 gateway root: smtpd - pony express streams 34

Jun 12 14:15:33 gateway root: smtpd - pony express streams 33

Jun 12 14:25:33 gateway root: smtpd - pony express streams 33

Jun 12 14:35:33 gateway root: smtpd - pony express streams 33

Jun 12 14:45:33 gateway root: smtpd - pony express streams 33

Jun 12 14:55:33 gateway root: smtpd - pony express streams 33

Jun 12 15:05:33 gateway root: smtpd - pony express streams 33

Jun 12 15:15:33 gateway root: smtpd - pony express streams 37

Jun 12 15:25:33 gateway root: smtpd - pony express streams 43

Jun 12 15:35:33 gateway root: smtpd - pony express streams 43

Jun 12 15:45:33 gateway root: smtpd - pony express streams 44

Jun 12 15:55:33 gateway root: smtpd - pony express streams 43

Jun 12 16:05:33 gateway root: smtpd - pony express streams 43

Jun 12 16:15:33 gateway root: smtpd - pony express streams 43

Jun 12 16:25:33 gateway root: smtpd - pony express streams 43

Jun 12 16:35:33 gateway root: smtpd - pony express streams 49

Jun 12 16:45:34 gateway root: smtpd - pony express streams 49

Jun 12 16:55:34 gateway root: smtpd - pony express streams 49

Jun 12 17:05:34 gateway root: smtpd - pony express streams 51

Jun 12 17:15:34 gateway root: smtpd - pony express streams 51

Jun 12 17:25:34 gateway root: smtpd - pony express streams 51

Jun 12 17:35:34 gateway root: smtpd - pony express streams 51

Jun 12 17:45:34 gateway root: smtpd - pony express streams 54

Jun 12 17:55:34 gateway root: smtpd - pony express streams 53

Jun 12 18:05:34 gateway root: smtpd - pony express streams 53

Jun 12 18:15:34 gateway root: smtpd - pony express streams 53

Jun 12 18:25:34 gateway root: smtpd - pony express streams 53

Jun 12 18:35:34 gateway root: smtpd - pony express streams 53

Jun 12 18:45:34 gateway root: smtpd - pony express streams 53

Jun 12 18:55:34 gateway root: smtpd - pony express streams 53

Jun 12 19:05:34 gateway root: smtpd - pony express streams 53

Jun 12 19:15:34 gateway root: smtpd - pony express streams 55

Jun 12 19:25:34 gateway root: smtpd - pony express streams 55

Jun 12 19:35:34 gateway root: smtpd - pony express streams 55

Jun 12 19:45:34 gateway root: smtpd - pony express streams 55

Jun 12 19:55:34 gateway root: smtpd - pony express streams 56

Jun 12 20:05:34 gateway root: smtpd - pony express streams 56

Jun 12 20:15:34 gateway root: smtpd - pony express streams 55

Jun 12 20:25:35 gateway root: smtpd - pony express streams 55

Jun 12 20:35:35 gateway root: smtpd - pony express streams 57

Jun 12 20:45:35 gateway root: smtpd - pony express streams 58

Jun 12 20:55:35 gateway root: smtpd - pony express streams 57

Jun 12 21:05:35 gateway root: smtpd - pony express streams 57

Jun 12 21:15:35 gateway root: smtpd - pony express streams 57

Jun 12 21:25:35 gateway root: smtpd - pony express streams 57

Jun 12 21:35:35 gateway root: smtpd - pony express streams 57

Jun 12 21:45:35 gateway 

opensmtd failing and a work a round

[Peter Fraser]

I apologize for the missing newlines in the earlier messages

opensmtpd has a bug, that I know is being worked on. It leave streams open
that should be closed and will eventually stop listening for new connections.

The only fix I know at the moment is to restart opensmtpd.

My first attempt to mitigate this problem was to use timeout to see if "telnet
mail 25" responded.
If I didn't get the 2220 mail.thinkage.ca ESMTP OpenSMTPD. I knew it was time
to restart smtpd

When I was doing this I did miss the timeout command that linux has
(https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.h
tml)

But knowing that it was the total number of stream that were open that cause
the problem enabled a simple solution.
I used the following shell script under a nohup

#ksh
while true ;do
  p=`pgrep -f "smtpd: pony express"`
  i=`fstat -p $p |grep -c " stream "`
  m=""
  if test  $i -ge 100 ; then
 /etc/rc.d/smtpd restart
 m=restarted
  fi
  logger smtpd - pony express streams $i $m
  sleep 600
done

all the smtpd processes seem to leave extra streams open.
"pony express" seems to leave the most open.

This generates output in /var/log/messages on my system and you can see how
the number streams build.

Since I have running this I have not had a problem will smtpd hanging,
although I recognize that it is crude work around


Jun 12 12:25:30 gateway root: smtpd - pony express streams 23
Jun 12 12:35:32 gateway root: smtpd - pony express streams 25
Jun 12 12:45:33 gateway root: smtpd - pony express streams 26
Jun 12 12:55:33 gateway root: smtpd - pony express streams 25
Jun 12 13:05:33 gateway root: smtpd - pony express streams 25
Jun 12 13:15:33 gateway root: smtpd - pony express streams 27
Jun 12 13:25:33 gateway root: smtpd - pony express streams 29
Jun 12 13:35:33 gateway root: smtpd - pony express streams 29
Jun 12 13:45:33 gateway root: smtpd - pony express streams 31
Jun 12 13:55:33 gateway root: smtpd - pony express streams 33
Jun 12 14:05:33 gateway root: smtpd - pony express streams 34
Jun 12 14:15:33 gateway root: smtpd - pony express streams 33
Jun 12 14:25:33 gateway root: smtpd - pony express streams 33
Jun 12 14:35:33 gateway root: smtpd - pony express streams 33
Jun 12 14:45:33 gateway root: smtpd - pony express streams 33
Jun 12 14:55:33 gateway root: smtpd - pony express streams 33
Jun 12 15:05:33 gateway root: smtpd - pony express streams 33
Jun 12 15:15:33 gateway root: smtpd - pony express streams 37
Jun 12 15:25:33 gateway root: smtpd - pony express streams 43
Jun 12 15:35:33 gateway root: smtpd - pony express streams 43
Jun 12 15:45:33 gateway root: smtpd - pony express streams 44
Jun 12 15:55:33 gateway root: smtpd - pony express streams 43
Jun 12 16:05:33 gateway root: smtpd - pony express streams 43
Jun 12 16:15:33 gateway root: smtpd - pony express streams 43
Jun 12 16:25:33 gateway root: smtpd - pony express streams 43
Jun 12 16:35:33 gateway root: smtpd - pony express streams 49
Jun 12 16:45:34 gateway root: smtpd - pony express streams 49
Jun 12 16:55:34 gateway root: smtpd - pony express streams 49
Jun 12 17:05:34 gateway root: smtpd - pony express streams 51
Jun 12 17:15:34 gateway root: smtpd - pony express streams 51
Jun 12 17:25:34 gateway root: smtpd - pony express streams 51
Jun 12 17:35:34 gateway root: smtpd - pony express streams 51
Jun 12 17:45:34 gateway root: smtpd - pony express streams 54
Jun 12 17:55:34 gateway root: smtpd - pony express streams 53
Jun 12 18:05:34 gateway root: smtpd - pony express streams 53
Jun 12 18:15:34 gateway root: smtpd - pony express streams 53
Jun 12 18:25:34 gateway root: smtpd - pony express streams 53
Jun 12 18:35:34 gateway root: smtpd - pony express streams 53
Jun 12 18:45:34 gateway root: smtpd - pony express streams 53
Jun 12 18:55:34 gateway root: smtpd - pony express streams 53
Jun 12 19:05:34 gateway root: smtpd - pony express streams 53
Jun 12 19:15:34 gateway root: smtpd - pony express streams 55
Jun 12 19:25:34 gateway root: smtpd - pony express streams 55
Jun 12 19:35:34 gateway root: smtpd - pony express streams 55
Jun 12 19:45:34 gateway root: smtpd - pony express streams 55
Jun 12 19:55:34 gateway root: smtpd - pony express streams 56
Jun 12 20:05:34 gateway root: smtpd - pony express streams 56
Jun 12 20:15:34 gateway root: smtpd - pony express streams 55
Jun 12 20:25:35 gateway root: smtpd - pony express streams 55
Jun 12 20:35:35 gateway root: smtpd - pony express streams 57
Jun 12 20:45:35 gateway root: smtpd - pony express streams 58
Jun 12 20:55:35 gateway root: smtpd - pony express streams 57
Jun 12 21:05:35 gateway root: smtpd - pony express streams 57
Jun 12 21:15:35 gateway root: smtpd - pony express streams 57
Jun 12 21:25:35 gateway root: smtpd - pony express streams 57
Jun 12 21:35:35 gateway root: smtpd - pony express streams 57
Jun 12 21:45:35 gateway root: smtpd - pony express streams 57
Jun 12 21:55:35 gateway root: smtpd - pony express streams 60
Jun 

Re: bluetooth audio -> usb dongle?

[frantisek holop]

Edgar Pettijohn, 14 Jun 2016 17:41:
> Someone answered a similiar question recently.  I believe
> the answer was "if the dongle handles the bluetooth" then 
> it will work.  However, if it expects the OS to do any 
> part of the pairing, etc then it will not work.

a quick search for "openbsd bluetooth audio usb"
came up only with my question :]

does anybody have some actual model numbers that are
verified to work?

-f
-- 
i thank my lucky stars i'm not superstitious.

Re: is 'set prio' in pf unidirectional or bidirectional?

[Andy Lemin]

Ohh, Forgot to mention.. PF by default sets good ToS values on its CARP
heartbeats, but we use HP Procurve switches with DiffServ enabled.

By default with HP, HP maps the ToS value that PF uses for CARP by default,
into a low priority CoS queue! Yes really ;) Don't you just love HP. And on
many HP switches, you cannot modify this DiffServ <-> CoS mapping.

So the suggestion at the bottom is just to set a ToS that HP switches will
prioritise..

Have fun, all the best.

Andy Lemin


On Wed, Jun 15, 2016 at 8:18 PM, Andy Lemin  wrote:

> Peter is quite right, to add some examples to his suggestion;
>
> tcpdump -nettti pflog0 <- Shows only dropped packets
> tcpdump -nettti em0 <- Shows all packets on the interface, including ToS
> values and VLAN ID etc.
> tcpdump -nettti vlanX <- Shows only packets on the VLAN without the extra
> info.
>
> Sure you can figure out the rest..
>
> There are also a few caveats to writing good PF QoS rules that some are
> not aware off. For example the PRIO value is copied into the VLAN header as
> the CoS value, but if it is an untagged VLAN the frame wont have a value as
> their is no VLAN header to store it in. I.e. PRIO is only transitive for
> connected VLAN subnets, beyond the nexthop you cannot control layer 2 CoS,
> only layer 3 QoS is transitive.
>
> Also PRIO is strictly speaking internal to the firewall, and it works for
> both ingress and egress, whereas queuing/shaping is egress only. Best to
> think of it as a priority picker or scheduler. I.e. packets get selected
> from the buffers for processing based on their priority whether they are
> input or output buffers (I am only 90% sure of this, so please correct me
> if I am wrong).
>
> Also common good practice assumes that you would normally want to use two
> prio values; E.g.
>
> pass quick on { $if_ext, $if_DMZ } proto { tcp, udp } from any to {
> $int_ip_dns0 } port { 53 } queue (wan_web,wan_pri) set prio (2,4)
> The first prio (2) is used for the payload packets in the session (ToS not
> set), and the second prio (4) is used for the control packets (ACKs etc
> because they have the ToS set). This again also sets the VLAN CoS correctly
> for each packet type in the same session.
>
> Another thing to be careful of is setting ToS yourself and using PRIO (and
> if using queues too). For example;
>
> match in proto tcp all scrub (no-df max-mss 1460)
>
> match in proto { udp, icmp } all scrub (no-df max-mss 1472)
>
> match out on { $if_ext } proto { tcp, udp } from any to {
>  } scrub (no-df max-mss 1420) set (tos ef, prio 7)
>
> The first two lines are just housekeeping. But the third line will set the
> ToS value EF on every single packet in the session (payload and ACKs) for
> the VoIP traffic. This means that the later pass rules will place all
> voip traffic into 'second' "queue" and second "priority".
>
> And if you didn't spot the clue in the first example, yes, I believe state
> does match returning traffic and does apply the prio to return traffic
> also. But you wont see it with tcpdump unless you are using VLANs to
> inspect the CoS field.
>
>
> In my first example you will also notice I have only one rule that matches
> traffic on both the inside and outside interfaces, so you need to make sure
> you are using the same queue names on both the inside and outside
> interfaces. This is done by adding the "on $if_ext" directive to your
> queues. E.g.
>
> queue ext_root on $if_ext bandwidth 800M
>
> queue qlocal on $if_ext parent ext_root bandwidth 600M
>
> queue local_kern on $if_ext parent qlocal bandwidth 6M min 6M
> burst 10M for 1000ms
>
> queue local_pri on $if_ext parent qlocal bandwidth 60M min 60M
>
> queue local_data on $if_ext parent qlocal bandwidth 510M min 100M
>
> queue qwan on $if_ext  parent ext_root bandwidth 190M
>
> queue wan_rt on $if_ext  parent qwan bandwidth 38M min 19M burst
> 38M for 5000ms
>
> queue wan_int on $if_ext parent qwan bandwidth 19M min 9M
>
> queue wan_pri on $if_ext parent qwan bandwidth 19M min 10M burst
> 25M for 2000ms
>
> queue wan_vpn on $if_ext parent qwan bandwidth 50M min 25M
>
> queue wan_web on $if_ext parent qwan bandwidth 19M min 10M burst
> 19M for 3000ms
>
> queue wan_dflt on $if_ext parent qwan bandwidth 19M min 10M burst
> 19M for 5000ms
>
> queue wan_bulk on $if_ext parent qwan bandwidth 20M max 50M
> default
>
>
> queue trunk_root on $if_trunk bandwidth 4294M
>
> queue qlocal on $if_trunk parent trunk_root bandwidth 4.1G
>
> queue local_kern on $if_trunk parent qlocal bandwidth 8M min 8M
> burst 8M for 1000ms
>
> queue local_pri on $if_trunk parent qlocal bandwidth 150M min
> 150M burst 200M for 2500ms
>
> queue local_data on $if_trunk parent qlocal bandwidth 4G min 1G
>
> queue qwan on $if_trunk parent trunk_root bandwidth 190M
>
> queue wan_rt on $if_trunk  parent qwan bandwidth 38M min 19M
> burst 38M 

smtpd failing and a work around.

[Peter Fraser]

opensmtpd has a bug, that I know is being worked on. It leave streams open
that should be closed and will eventually
stop listening for new connections.

The only fix I know at the moment is to restart opensmtpd.

My first attempt to mitigate this problem was to use timeout to see if "telnet
mail 25" responded.
If I didn't get the 2220 mail.thinkage.ca ESMTP OpenSMTPD. I knew it was time
to restart smtpd

When I was doing this I did miss the timeout command that linux has
(https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.h
tml)

But knowing that it was the total number of stream that were open that cause
the problem enabled a simple solution.
I used the following shell script under a nohup

#ksh
while true ;do
  p=`pgrep -f "smtpd: pony express"`
  i=`fstat -p $p |grep -c " stream "`
  m=""
  if test  $i -ge 100 ; then
 /etc/rc.d/smtpd restart
 m=restarted
  fi
  logger smtpd - pony express streams $i $m
  sleep 600
done

all the smtpd processes seem to leave extra streams open.
"pony express" seems to leave the most open.

This generates output in /var/log/messages on my system and you can see how
the number streams build.

Since I have running this I have not had a problem will smtpd hanging,
although I recognize that it is crude work around

Jun 12 12:25:30 gateway root: smtpd - pony express streams 23
Jun 12 12:35:32 gateway root: smtpd - pony express streams 25
Jun 12 12:45:33 gateway root: smtpd - pony express streams 26
Jun 12 12:55:33 gateway root: smtpd - pony express streams 25
Jun 12 13:05:33 gateway root: smtpd - pony express streams 25
Jun 12 13:15:33 gateway root: smtpd - pony express streams 27
Jun 12 13:25:33 gateway root: smtpd - pony express streams 29
Jun 12 13:35:33 gateway root: smtpd - pony express streams 29
Jun 12 13:45:33 gateway root: smtpd - pony express streams 31
Jun 12 13:55:33 gateway root: smtpd - pony express streams 33
Jun 12 14:05:33 gateway root: smtpd - pony express streams 34
Jun 12 14:15:33 gateway root: smtpd - pony express streams 33
Jun 12 14:25:33 gateway root: smtpd - pony express streams 33
Jun 12 14:35:33 gateway root: smtpd - pony express streams 33
Jun 12 14:45:33 gateway root: smtpd - pony express streams 33
Jun 12 14:55:33 gateway root: smtpd - pony express streams 33
Jun 12 15:05:33 gateway root: smtpd - pony express streams 33
Jun 12 15:15:33 gateway root: smtpd - pony express streams 37
Jun 12 15:25:33 gateway root: smtpd - pony express streams 43
Jun 12 15:35:33 gateway root: smtpd - pony express streams 43
Jun 12 15:45:33 gateway root: smtpd - pony express streams 44
Jun 12 15:55:33 gateway root: smtpd - pony express streams 43
Jun 12 16:05:33 gateway root: smtpd - pony express streams 43
Jun 12 16:15:33 gateway root: smtpd - pony express streams 43
Jun 12 16:25:33 gateway root: smtpd - pony express streams 43
Jun 12 16:35:33 gateway root: smtpd - pony express streams 49
Jun 12 16:45:34 gateway root: smtpd - pony express streams 49
Jun 12 16:55:34 gateway root: smtpd - pony express streams 49
Jun 12 17:05:34 gateway root: smtpd - pony express streams 51
Jun 12 17:15:34 gateway root: smtpd - pony express streams 51
Jun 12 17:25:34 gateway root: smtpd - pony express streams 51
Jun 12 17:35:34 gateway root: smtpd - pony express streams 51
Jun 12 17:45:34 gateway root: smtpd - pony express streams 54
Jun 12 17:55:34 gateway root: smtpd - pony express streams 53
Jun 12 18:05:34 gateway root: smtpd - pony express streams 53
Jun 12 18:15:34 gateway root: smtpd - pony express streams 53
Jun 12 18:25:34 gateway root: smtpd - pony express streams 53
Jun 12 18:35:34 gateway root: smtpd - pony express streams 53
Jun 12 18:45:34 gateway root: smtpd - pony express streams 53
Jun 12 18:55:34 gateway root: smtpd - pony express streams 53
Jun 12 19:05:34 gateway root: smtpd - pony express streams 53
Jun 12 19:15:34 gateway root: smtpd - pony express streams 55
Jun 12 19:25:34 gateway root: smtpd - pony express streams 55
Jun 12 19:35:34 gateway root: smtpd - pony express streams 55
Jun 12 19:45:34 gateway root: smtpd - pony express streams 55
Jun 12 19:55:34 gateway root: smtpd - pony express streams 56
Jun 12 20:05:34 gateway root: smtpd - pony express streams 56
Jun 12 20:15:34 gateway root: smtpd - pony express streams 55
Jun 12 20:25:35 gateway root: smtpd - pony express streams 55
Jun 12 20:35:35 gateway root: smtpd - pony express streams 57
Jun 12 20:45:35 gateway root: smtpd - pony express streams 58
Jun 12 20:55:35 gateway root: smtpd - pony express streams 57
Jun 12 21:05:35 gateway root: smtpd - pony express streams 57
Jun 12 21:15:35 gateway root: smtpd - pony express streams 57
Jun 12 21:25:35 gateway root: smtpd - pony express streams 57
Jun 12 21:35:35 gateway root: smtpd - pony express streams 57
Jun 12 21:45:35 gateway root: smtpd - pony express streams 57
Jun 12 21:55:35 gateway root: smtpd - pony express streams 60
Jun 12 22:05:35 gateway root: smtpd - pony express streams 59
Jun 

Re: is 'set prio' in pf unidirectional or bidirectional?

[Andy Lemin]

Peter is quite right, to add some examples to his suggestion;

tcpdump -nettti pflog0 <- Shows only dropped packets
tcpdump -nettti em0 <- Shows all packets on the interface, including ToS
values and VLAN ID etc.
tcpdump -nettti vlanX <- Shows only packets on the VLAN without the extra
info.

Sure you can figure out the rest..

There are also a few caveats to writing good PF QoS rules that some are not
aware off. For example the PRIO value is copied into the VLAN header as the
CoS value, but if it is an untagged VLAN the frame wont have a value as
their is no VLAN header to store it in. I.e. PRIO is only transitive for
connected VLAN subnets, beyond the nexthop you cannot control layer 2 CoS,
only layer 3 QoS is transitive.

Also PRIO is strictly speaking internal to the firewall, and it works for
both ingress and egress, whereas queuing/shaping is egress only. Best to
think of it as a priority picker or scheduler. I.e. packets get selected
from the buffers for processing based on their priority whether they are
input or output buffers (I am only 90% sure of this, so please correct me
if I am wrong).

Also common good practice assumes that you would normally want to use two
prio values; E.g.

pass quick on { $if_ext, $if_DMZ } proto { tcp, udp } from any to {
$int_ip_dns0 } port { 53 } queue (wan_web,wan_pri) set prio (2,4)
The first prio (2) is used for the payload packets in the session (ToS not
set), and the second prio (4) is used for the control packets (ACKs etc
because they have the ToS set). This again also sets the VLAN CoS correctly
for each packet type in the same session.

Another thing to be careful of is setting ToS yourself and using PRIO (and
if using queues too). For example;

match in proto tcp all scrub (no-df max-mss 1460)

match in proto { udp, icmp } all scrub (no-df max-mss 1472)

match out on { $if_ext } proto { tcp, udp } from any to { 
} scrub (no-df max-mss 1420) set (tos ef, prio 7)

The first two lines are just housekeeping. But the third line will set the
ToS value EF on every single packet in the session (payload and ACKs) for
the VoIP traffic. This means that the later pass rules will place all voip
traffic into 'second' "queue" and second "priority".

And if you didn't spot the clue in the first example, yes, I believe state
does match returning traffic and does apply the prio to return traffic
also. But you wont see it with tcpdump unless you are using VLANs to
inspect the CoS field.


In my first example you will also notice I have only one rule that matches
traffic on both the inside and outside interfaces, so you need to make sure
you are using the same queue names on both the inside and outside
interfaces. This is done by adding the "on $if_ext" directive to your
queues. E.g.

queue ext_root on $if_ext bandwidth 800M

queue qlocal on $if_ext parent ext_root bandwidth 600M

queue local_kern on $if_ext parent qlocal bandwidth 6M min 6M burst
10M for 1000ms

queue local_pri on $if_ext parent qlocal bandwidth 60M min 60M

queue local_data on $if_ext parent qlocal bandwidth 510M min 100M

queue qwan on $if_ext  parent ext_root bandwidth 190M

queue wan_rt on $if_ext  parent qwan bandwidth 38M min 19M burst
38M for 5000ms

queue wan_int on $if_ext parent qwan bandwidth 19M min 9M

queue wan_pri on $if_ext parent qwan bandwidth 19M min 10M burst
25M for 2000ms

queue wan_vpn on $if_ext parent qwan bandwidth 50M min 25M

queue wan_web on $if_ext parent qwan bandwidth 19M min 10M burst
19M for 3000ms

queue wan_dflt on $if_ext parent qwan bandwidth 19M min 10M burst
19M for 5000ms

queue wan_bulk on $if_ext parent qwan bandwidth 20M max 50M default


queue trunk_root on $if_trunk bandwidth 4294M

queue qlocal on $if_trunk parent trunk_root bandwidth 4.1G

queue local_kern on $if_trunk parent qlocal bandwidth 8M min 8M
burst 8M for 1000ms

queue local_pri on $if_trunk parent qlocal bandwidth 150M min 150M
burst 200M for 2500ms

queue local_data on $if_trunk parent qlocal bandwidth 4G min 1G

queue qwan on $if_trunk parent trunk_root bandwidth 190M

queue wan_rt on $if_trunk  parent qwan bandwidth 38M min 19M burst
38M for 5000ms

queue wan_int on $if_trunk parent qwan bandwidth 19M min 9M

queue wan_pri on $if_trunk parent qwan bandwidth 19M min 10M burst
25M for 2000ms

queue wan_vpn on $if_trunk parent qwan bandwidth 50M min 25M

queue wan_web on $if_trunk parent qwan bandwidth 19M min 10M burst
19M for 3000ms

queue wan_dflt on $if_trunk parent qwan bandwidth 19M min 10M burst
19M for 5000ms

queue wan_bulk on $if_trunk parent qwan bandwidth 20M max 50M
default


Another hint, if you are using VLANs to gain the benefit of using the
priority field in the VLAN header, to maintain your CoS on your layer 2 all
the way to the client, you should apply your queues to the trunk interface,
and not each VLAN.

Re: HP 1020 G1 OpenBSD 6.0 Beta status and dmesg

[Mike Larkin]

On Wed, Jun 15, 2016 at 09:47:35AM +0200, Bodie wrote:
> Hi all,
> 
> trying to find if OpenBSD will be usable on this laptop via USB live OpenBSD
> 6.0 Beta install. There was some fight with old USB flash and EFI, but is
> already resolved so that I can provide some outputs and info.
> 
> 1) VGA works including 3D
> 2) USB camera is detected (I have firmware on flash disk), but video(1) does
> not work with it, will play more later on
> 3) ACPI/apm seems reasonable , but reported battery life is only around 231
> minutes (when regular is around 8 hours), except of boot CPU other threads
> have problems with identification, but scaling and load is ok and acpitz5

This probably happens only when booting off battery, right? (Eg, the "failed
to identify" messages). If you boot when plugged in to AC, I bet it doesn't do
that.

> zone is showing somewhat suspicious high temperature right from start
> 
> hw.sensors.cpu0.temp0=42.00 degC
> hw.sensors.acpitz0.temp0=43.00 degC (zone temperature)
> hw.sensors.acpitz1.temp0=0.00 degC (zone temperature)
> hw.sensors.acpitz2.temp0=37.00 degC (zone temperature)
> hw.sensors.acpitz3.temp0=40.00 degC (zone temperature)
> hw.sensors.acpitz4.temp0=35.00 degC (zone temperature)
> hw.sensors.acpitz5.temp0=84.00 degC (zone temperature)
> hw.sensors.acpitz6.temp0=0.00 degC (zone temperature)
> hw.sensors.acpitz7.temp0=0.00 degC (zone temperature)
> hw.sensors.acpibat0.volt0=7.60 VDC (voltage)
> hw.sensors.acpibat0.volt1=8.57 VDC (current voltage)
> hw.sensors.acpibat0.current0=1.21 A (rate)
> hw.sensors.acpibat0.amphour0=4.66 Ah (last full capacity)
> hw.sensors.acpibat0.amphour1=0.20 Ah (warning capacity)
> hw.sensors.acpibat0.amphour2=0.10 Ah (low capacity)
> hw.sensors.acpibat0.amphour3=4.66 Ah (remaining capacity), OK
> hw.sensors.acpibat0.amphour4=4.66 Ah (design capacity)
> hw.sensors.acpibat0.raw0=1 (battery full), OK
> hw.sensors.acpiac0.indicator0=Off (power supply)
> hw.sensors.acpibtn1.indicator0=On (lid open)
> 
> $ cat apm.txt
> Battery state: high, 100% remaining, 231 minutes life estimate
> A/C adapter state: not connected
> Performance adjustment mode: auto (500 MHz)
> $
> 
> Can provide acpidump directly from OpenBSD later on if some developer will
> be interested. Right now I have them only from Windows via iasl in .dat and
> .dsl format
> 
> 4) Network devices are detected, but iwm0 does not work properly (do not
> know if firmware or driver related). I am able to associate with AP, but
> dhclient is not getting any lease. Thought it may be related to 802.11n
> usage as my AP transmit in yet unsupported way by OpenBSD so I switched to
> 802.11g only, but the problem with dhclient was same. No errors either from
> dhclient or firmware of iwm0 during those steps
> 
> 5) dmesg of 1st boot after install
> 
> OpenBSD 6.0-beta (GENERIC.MP) #2165: Thu Jun  2 08:37:59 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8203530240 (7823MB)
> avail mem = 7950278656 (7581MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9ba3f000 (33 entries)
> bios0: vendor Hewlett-Packard version "M77 Ver. 01.11" date 01/18/2016
> bios0: Hewlett-Packard HP EliteBook Folio 1020 G1
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SSDT SLIC MSDM FPDT BGRT
> SSDT SSDT SSDT SSDT SSDT SSDT ASF! DMAR
> acpi0: wakeup devices LANC(S0) EHC1(S0) XHC_(S0) PCIB(S5) RP03(S0) NIC_(S0)
> RP04(S5) WNIC(S5) HST1(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.63 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,BMI1,HLE,AV
> X2,SMEP,BMI2,ERMS,INVPCID,RTM,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 1 (application processor)
> cpu1: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.46 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,BMI1,HLE,AV
> X2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: failed to 

Re: Creating https certificates dynamically for redirected/blocked requests

[lists]

Tue, 14 Jun 2016 17:53:25 -0500 "Ted Wynnychenko" 
> >How are you identifying connections to block?  
> 
> I block connections based on a list from malwaredomains.com.  A script runs
> nightly that downloads the list/changes, creates zone files, and reloads
> unbound/nsd.  The "blocked" zone files point those domains at an internal
> (10.0.x.x) IP address.

Have you considered an allow list instead (semi-evil grin, no really)?
Please do not get offended by the idea which might be a lot less work.
Then you could just transparently relay & not worry about it any more.

Re: HP 1020 G1 OpenBSD 6.0 Beta status and dmesg

[Sean Howard]

Sent from my phone.
  Original Message  
From: Bodie
Sent: Wednesday, June 15, 2016 03:49
To: misc@openbsd.org
Reply To: bodz...@openbsd.cz
Subject: HP 1020 G1 OpenBSD 6.0 Beta status and dmesg

Hi all,

trying to find if OpenBSD will be usable on this laptop via USB live
OpenBSD 6.0 Beta install. There was some fight with old USB flash and
EFI, but is already resolved so that I can provide some outputs and
info.

1) VGA works including 3D
2) USB camera is detected (I have firmware on flash disk), but video(1)
does not work with it, will play more later on
3) ACPI/apm seems reasonable , but reported battery life is only around
231 minutes (when regular is around 8 hours), except of boot CPU other
threads have problems with identification, but scaling and load is ok
and acpitz5 zone is showing somewhat suspicious high temperature right
from start

hw.sensors.cpu0.temp0=42.00 degC
hw.sensors.acpitz0.temp0=43.00 degC (zone temperature)
hw.sensors.acpitz1.temp0=0.00 degC (zone temperature)
hw.sensors.acpitz2.temp0=37.00 degC (zone temperature)
hw.sensors.acpitz3.temp0=40.00 degC (zone temperature)
hw.sensors.acpitz4.temp0=35.00 degC (zone temperature)
hw.sensors.acpitz5.temp0=84.00 degC (zone temperature)
hw.sensors.acpitz6.temp0=0.00 degC (zone temperature)
hw.sensors.acpitz7.temp0=0.00 degC (zone temperature)
hw.sensors.acpibat0.volt0=7.60 VDC (voltage)
hw.sensors.acpibat0.volt1=8.57 VDC (current voltage)
hw.sensors.acpibat0.current0=1.21 A (rate)
hw.sensors.acpibat0.amphour0=4.66 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.20 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.10 Ah (low capacity)
hw.sensors.acpibat0.amphour3=4.66 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=4.66 Ah (design capacity)
hw.sensors.acpibat0.raw0=1 (battery full), OK
hw.sensors.acpiac0.indicator0=Off (power supply)
hw.sensors.acpibtn1.indicator0=On (lid open)

$ cat apm.txt
Battery state: high, 100% remaining, 231 minutes life estimate
A/C adapter state: not connected
Performance adjustment mode: auto (500 MHz)
$

Can provide acpidump directly from OpenBSD later on if some developer
will be interested. Right now I have them only from Windows via iasl in
.dat and .dsl format

4) Network devices are detected, but iwm0 does not work properly (do
not know if firmware or driver related). I am able to associate with AP,
but dhclient is not getting any lease. Thought it may be related to
802.11n usage as my AP transmit in yet unsupported way by OpenBSD so I
switched to 802.11g only, but the problem with dhclient was same. No
errors either from dhclient or firmware of iwm0 during those steps

5) dmesg of 1st boot after install

OpenBSD 6.0-beta (GENERIC.MP) #2165: Thu Jun 2 08:37:59 MDT 2016

dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8203530240 (7823MB)
avail mem = 7950278656 (7581MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9ba3f000 (33 entries)
bios0: vendor Hewlett-Packard version "M77 Ver. 01.11" date 01/18/2016
bios0: Hewlett-Packard HP EliteBook Folio 1020 G1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SSDT SLIC MSDM FPDT
BGRT SSDT SSDT SSDT SSDT SSDT SSDT ASF! DMAR
acpi0: wakeup devices LANC(S0) EHC1(S0) XHC_(S0) PCIB(S5) RP03(S0)
NIC_(S0) RP04(S5) WNIC(S5) HST1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.63 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
,SMX,EST
,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLIN
E,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBA
SE,BMI1,HLE,AV
X2,SMEP,BMI2,ERMS,INVPCID,RTM,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 1 (application processor)
cpu1: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.46 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
,SMX,EST
,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLIN
E,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBA
SE,BMI1,HLE,AV
X2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: failed to identify
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.46 MHz
cpu2:

Re: is 'set prio' in pf unidirectional or bidirectional?

[Peter N. M. Hansteen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is one of the cases where the best possible answer is, "tcpdump
is your friend".

You have outlined a number of test cases. It would be really useful if
you try each one of them, and use tcpdump to record and identify the
effects of each one. It's worth noting that tcpdump with the right
options is able to display information such as the packets's ToS and
which rule in the loaded PF rule set the packet matched.

If you run those tests properly and report your findings, I'm sure it
will be appreciated.

- -- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
iQIcBAEBCAAGBQJXYSecAAoJELJiGF9h4DyeghcP/RZQeJ/4P8cj6DUoBhSw7HuZ
q0t8fgnnyfw7ItkWGP6WayW9aT7oMfR9XdgX3jn/jFBLj8aW55K1i/v4PbXFJTkB
yjnJ1WJN7fohVSYOYyfnjxCxw2RdGbcVUZpYkFCfIzsKPTxsuJynJyR7i6Ke8dYE
5FiF68oqhKq0yAiHcE91UlMVFH/v8NAy3crzkeK1yjgYK3sU5dVs0H7D/qR8Zlfe
fmOO9SqDDcvMMn/7c6bQ9sHKBXSsHizZcf//yuQseSXv9ttsl/3XZyUEhS3fyqNt
WKw80vNwQ7MJShOFqjn12G+j72s0kaSkiDEi93rXUZJxsoD28Vn6dyBJhcrWFtfr
eEOwuyp82FiNabAvn3StzkKE+cAQ01Kag0hFhgwx/u1sD/9K31B9J8IiMpSIplFV
tx4jfWBh1MjadAu3DIvHINYzEPoaju4zUY1mh840l5Wz7SpaBUyeJce0eNtA3n6Z
pbpZQsi9mHCP7MOR2b+RvzcjFc4m5XoiLz29aMQDzeLj4GzroY9H0ramWchqbj1y
BXKtFNgOglKIkjickdlSnzahFAf53r5T6vv1KY7Ea4Z5PP88e8OiXdcJqiuJlo0T
c9VXE5cCy37i21ZPV4YK3LsuiCxMVuGtQ63B/OnP1kX34NVoatpZz6gcx5Y62MWA
rsxLSEMFHSJuoJzgGF7j
=mgmr
-END PGP SIGNATURE-

Re: DNS servers around here not working for days. dig works. fix?

[Abel Abraham Camarillo Ojeda]

On Tue, Jun 14, 2016 at 3:49 PM, Chris Bennett
 wrote:
> On Tue, Jun 14, 2016 at 09:05:57PM +0100, Stuart Henderson wrote:
>>
>> If you can't find some other way to get things working then at least
>> you should be able to browse by "ssh -D 1080 somehost" and setting the
>> browser to use 127.0.0.1:1080 as SOCKS proxy, and tell it to have the
>> far end resolve DNS (in Firefox, tick the 'remote DNS' box).
>>
>
> For now, this works. I'm a little tired right now. This is working.
> I will try later or tomorrow to get a proper solution. This is not going
> to be an everyday solution!
>
> Thanks,
> Chris Bennett
>

Which mexican ISP are you using?

Here in mexico I know some big ISP get arrangements with companies
like google to provide 'local cache' of some of its services - like 8.8.8.8
DNS; I'm referring to Axtel in Mexico, precisely...

Re: DNS servers around here not working for days. dig works. fix?

[Peter Hessler]

On 2016 Jun 14 (Tue) at 11:38:03 -0700 (-0700), Christopher Ahrens wrote:
:li...@wrant.com wrote:
:>Tue, 14 Jun 2016 11:46:39 -0500 Chris Bennett
:>
:>>$ dig  bsd.org @8.8.4.4 +trace
:>>dig: couldn't get address for 'm.root-servers.net': not found
:>>
:>>pass ~ $ dig  bsd.org @8.8.8.8 +trace
:>>dig: couldn't get address for 'i.root-servers.net': not found
:>
:>You know I'm thinking you may be behind captive DNS, while still not
:>into tunnelling mode (of solving the problem), you could try another
:>group of public DNS servers.  Just search online for some others too.
:>
:4.2.2.2 - 4.2.2.6 are pretty reliable.
:

Level3 (the operators of those IPs) will block you whenever they feel
like it.  Those are _not_ public IPs, but are convienently numbered for
customers of Level3.


-- 
Eisenhower was very nice,
Nixon was his only vice.
-- C. Degen

HP 1020 G1 OpenBSD 6.0 Beta status and dmesg

[Bodie]

Hi all,

trying to find if OpenBSD will be usable on this laptop via USB live 
OpenBSD 6.0 Beta install. There was some fight with old USB flash and 
EFI, but is already resolved so that I can provide some outputs and 
info.


1) VGA works including 3D
2) USB camera is detected (I have firmware on flash disk), but video(1) 
does not work with it, will play more later on
3) ACPI/apm seems reasonable , but reported battery life is only around 
231 minutes (when regular is around 8 hours), except of boot CPU other 
threads have problems with identification, but scaling and load is ok 
and acpitz5 zone is showing somewhat suspicious high temperature right 
from start


hw.sensors.cpu0.temp0=42.00 degC
hw.sensors.acpitz0.temp0=43.00 degC (zone temperature)
hw.sensors.acpitz1.temp0=0.00 degC (zone temperature)
hw.sensors.acpitz2.temp0=37.00 degC (zone temperature)
hw.sensors.acpitz3.temp0=40.00 degC (zone temperature)
hw.sensors.acpitz4.temp0=35.00 degC (zone temperature)
hw.sensors.acpitz5.temp0=84.00 degC (zone temperature)
hw.sensors.acpitz6.temp0=0.00 degC (zone temperature)
hw.sensors.acpitz7.temp0=0.00 degC (zone temperature)
hw.sensors.acpibat0.volt0=7.60 VDC (voltage)
hw.sensors.acpibat0.volt1=8.57 VDC (current voltage)
hw.sensors.acpibat0.current0=1.21 A (rate)
hw.sensors.acpibat0.amphour0=4.66 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.20 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.10 Ah (low capacity)
hw.sensors.acpibat0.amphour3=4.66 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=4.66 Ah (design capacity)
hw.sensors.acpibat0.raw0=1 (battery full), OK
hw.sensors.acpiac0.indicator0=Off (power supply)
hw.sensors.acpibtn1.indicator0=On (lid open)

$ cat apm.txt
Battery state: high, 100% remaining, 231 minutes life estimate
A/C adapter state: not connected
Performance adjustment mode: auto (500 MHz)
$

Can provide acpidump directly from OpenBSD later on if some developer 
will be interested. Right now I have them only from Windows via iasl in 
.dat and .dsl format


4) Network devices are detected, but iwm0 does not work properly (do 
not know if firmware or driver related). I am able to associate with AP, 
but dhclient is not getting any lease. Thought it may be related to 
802.11n usage as my AP transmit in yet unsupported way by OpenBSD so I 
switched to 802.11g only, but the problem with dhclient was same. No 
errors either from dhclient or firmware of iwm0 during those steps


5) dmesg of 1st boot after install

OpenBSD 6.0-beta (GENERIC.MP) #2165: Thu Jun  2 08:37:59 MDT 2016

dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 8203530240 (7823MB)
avail mem = 7950278656 (7581MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9ba3f000 (33 entries)
bios0: vendor Hewlett-Packard version "M77 Ver. 01.11" date 01/18/2016
bios0: Hewlett-Packard HP EliteBook Folio 1020 G1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SSDT SLIC MSDM FPDT 
BGRT SSDT SSDT SSDT SSDT SSDT SSDT ASF! DMAR
acpi0: wakeup devices LANC(S0) EHC1(S0) XHC_(S0) PCIB(S5) RP03(S0) 
NIC_(S0) RP04(S5) WNIC(S5) HST1(S5)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.63 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,BMI1,HLE,AV
X2,SMEP,BMI2,ERMS,INVPCID,RTM,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 1 (application processor)
cpu1: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.46 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,BMI1,HLE,AV
X2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: failed to identify
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 1097.46 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

Re: Creating https certificates dynamically for redirected/blocked requests

[Peter Fokker]

Ted Wynnychenko wrote:
[...]
> I block connections based on a list from malwaredomains.com.
> A script runs nightly that downloads the list/changes, creates
> zone files, and reloads unbound/nsd.  The "blocked" zone files
> point those domains at an internal (10.0.x.x) IP address.
[...]
> From my looking, it appears that a certificate is only accepted
> by browsers with "one level" of domain wildcard present; so I am
> not sure how to get a certificate with a common name of * to be
> accepted for any/every domain.

Perhaps this is an idea: enable the v3 extensions in your
configuration file and add something like

subjectAltName = @bad_actors

[bad_actors]
DNS.1 = malware1.tld
DNS.2 = *.malware1.tld
DNS.3 = malware2.tld
DNS.4 = *.malware2.tld
...

After your nightly download from malwaredomains.com you
could add the new malware-domains to the list [bad_actors]
too and regenerate this multi-domain wildcard certificate.
This should work around the "one level" of wildcards limit
you discovered in Firefox.

As long as you use your own CA to sign (as opposed to
selfsigning) and the browser knows about the corresponding
Root Certificate there should be no problem with having a
new certificate every morning.

However, this hinges on the fact that entries in the
subjectAltName section are in fact allowed to contain
wildcards. RFC5280 [1] carefully avoids "the semantics of
subject alternative names that include wildcard characters"
so it may or may not work in different browsers.

Also, I am not sure how many entries are allowed in that
section, I suppose there is some limit somewhere. However,
perhaps it is worth a try?

--Peter Fokker

[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6
and https://tools.ietf.org/html/rfc5280#page-38