Leonardo Santagostini | 21 Oct 04:44 2014

Strange behaviour with X

Hello  <at> misc.

Just for the record (having in mind that 5.6 its almost here !!!), im using
5.5 Release and X was hunged for a while, but get restored.

Here goes dmesg

OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST 2014
    deraadt <at> amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80<clock_battery>
real mem = 4138713088 (3946MB)
avail mem = 4019929088 (3833MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7  <at>  0xe6fd0 (59 entries)
bios0: vendor LENOVO version "5ECN95WW(V9.00)" date 12/19/2012
bios0: LENOVO 20150
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: wakeup devices P0P1(S0) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S0) PXSX(S3)
RP07(S0) PXSX(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU B980  <at>  2.40GHz, 2394.95 MHz
(Continue reading)

Giancarlo Razzolini | 21 Oct 02:01 2014

Re: Shadow TCP stacks

On 20-10-2014 21:52, Ian Grant wrote:
> How else can one protect a system from DoS attacks, other than by
> concealing it some way? And what is cryptography if it's not
> concealing the meaning of a communication in some way?
Oh my. DoS can be mitigated. You could never "protect" a system. Even if
there isn't any port open, they can flood you uplink, even if you stop
sending FIN or ACK. There is UDP. Cryptography is not just concealment.
It's integrity. It's authentication (in some cases). So it's the only
way to be sure your message wasn't modified because the math behind it
is solid.
> Sure they can see it, but that's not going to tell them where it went
> next. So they can analyse all the traffic and what they learn from
> that won't be worth knowing half an hour later.
Man, real time traffic analysis. We told you so many times. They'll
learn it right away. Because they can see ALL traffic in real time.
Simple as that.
>   I live in Bolivia, and
> I want to implement something like this here, so that the Bolivian
> government can have secure communications within Bolivia, and across
> her borders.
I live in Brazil. And I'm aware of the situation of many countries in
South America, ours included. If you want that, please tell them to use
known and proven cryptography solutions such as Tor, IPSEC, Off the
record messaging, etc. Do not reinvent the wheel, because it will only
make their traffic stand out even further.
> I can make and a maintain any modifications to OpenBSD that I please.
Of course you can. But if you go along these lines of reinventing the
wheel and security through obscurity you'll never get your contributions
into it.

(Continue reading)

Max Fillinger | 21 Oct 01:38 2014

current.html: Remove group _lkm

current.html has no instructions to remove the _lkm group yet.

Index: www/faq/current.html
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.562
diff -u -p -r1.562 current.html
--- www/faq/current.html	19 Oct 2014 13:21:42 -0000	1.562
+++ www/faq/current.html	20 Oct 2014 23:38:08 -0000
 <at>  <at>  -914,6 +914,10  <at>  <at>  and the lkm directory should be deleted:
 	rm -f /usr/share/man/man4/lkm.4
 	rm -f /usr/share/mk/bsd.lkm.mk /usr/include/sys/lkm.h
+Also, the group _lkm should be removed:
+	groupdel _lkm


Ian Grant | 21 Oct 00:46 2014

Re: Shadow TCP stacks

On Mon, Oct 20, 2014 at 6:18 PM, john slee <indigoid <at> oldcorollas.org> wrote:
> On 20 October 2014 14:13, Worik Stanton <worik.stanton <at> gmail.com> wrote:
>> Yes all traffic of a country can be analysed, fairly close to real time.
>>  With some basic statistics, smart sampling and a dedicated team
>> crafting cleaver algorithms...  That is what those big budgets are for!
> Can throw in some real-world experience here - worked on a project in
> Malaysia that was doing near-realtime (no more than 5 minutes lag)
> analytics of cellular and data traffic on that country's largest cellular
> network. The kit fit in less than five 42U racks, including dev/test kit,
> and four of those racks were an inefficiently-used Netezza appliance.
> It wasn't even that expensive - private industry budget.

There's analysis, and there's analysis. None of this is particularly
interesting without knowledge of what depth of analysis was being
done. I doubt they were looking for steganographic transport encoding
in audio and image data, for example.

And I said before, using WiFi cells, they simply won't have access to
all the traffic without snooping all the WiFi cells. And they would
have a hard time dealing with USBstickNet traffic. high-latency, but
massive bandwidth :-)


Dylan Socolobsky | 20 Oct 23:54 2014

Realtek RTL8192SE wireless card support in OpenBSD 5.5


I just decided to give OpenBSD 5.5 (amd64) a go in my netbook,
everything is working flawlessly so far, except for the Wireless
Network. I did install "rsu-firmware" which did nothing.

My netbook has a Realtek RTL8192SE wireless chip, which I can't get to
work with OpenBSD. When running "ifconfig" this is what I get:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33144
        priority: 0
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet netmask 0xff000000
        lladdr 00:03:0d:fb:20:69
        priority: 0
        groups: egress
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::203:dff:fefb:2069%re0 prefixlen 64 scopeid 0x1
        inet netmask 0xffffff00 broadcast
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
        priority: 0
        groups: pflog
(Continue reading)

Daniel Pajonzeck | 20 Oct 23:31 2014

openssl: format error in certificate's notBefore field

Hi list,

I'm running OpenBSD-5.5-amd64. Today, I patched the 012_openssl.patch,
built and installed the new version, but now, I'm not able to establish
secure connections. For example via

  # https
  $ wget -O /dev/null https://bitfactory.ws/test.txt
  $ curl curl https://google.com

  # smtps
  $ openssl s_client -CAfile /etc/ssl/cert.pem -connect

The error message is always: 'format error in certificate's notBefore

But, if I check a local certificate file, I get the right expiration
date with the following command:

  $ openssl x509 -in fb_ca_chain_bundle.crt -noout -text

The system time and timezone is accurate and I also tried the
I don't know where the problem is. Does anyone have any advice?

Thanks for help
// Daniel

(Continue reading)

Craig R. Skinner | 20 Oct 22:22 2014

Publishing SSH public key fingerprints bit length?


I noticed OpenBSD anon CVS SSH fingerprints have the bit length
published with the algorithm type:

A couple of other popular non-OpenBSD sites omit the bit length:

16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 (RSA)
ad:1c:08:a4:40:e3:6f:9c:f5:66:26:5d:4b:33:5d:8c (DSA)

97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)

Maybe the default length for the algorithm is implied if not stated?

The bit length doesn't appear in the known_hosts file.

Is it important to have the bit length published with the fingerprint?


Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7

John Merriam | 20 Oct 20:12 2014

Staus of stacked softraid root (RAID1C for root)?

Hello.  I was wondering if there was any new information about the status 
of stacked softraid for the root partition?  I am particularly interested 
in using RAID1C for root partitions.

I searched and the last message I could find regarding the subject was 
from over a year ago and I think the result was 'they are working on it'.

From what I can find it doesn't look like it will be working for 5.6.  I 
hope there will be a blurb about it in the release notes whenever it is 

Assuming it isn't right around the corner, is there anywhere that I can 
track the development of stacked softraid for the root partition?

Any information you can provide would be greatly appreciated.



John Merriam - refugee from the land of systemd

Stefan Wollny | 20 Oct 19:16 2014

systat: What are "dirty pages"?

Hi there!

Still investigating some strange behaviour I run
~ $ sudo systat states

Scrolling some pages to the right I get some information related to
'devices' (I reformatted the page showing the last column underneath the
first columns for better readability):

1 users    Load 1.21 1.31 1.37   Mon Oct 20 18:54:43 2014

wd0          0      0      0      0    0.0
sd0      65536  39321      1      1    0.0
Totals   65536  39321      1      1    0.0

152169 total pages
    84 dirty pages
    11 delwri bufs
     0 busymap bufs
  6553 avail kvaslots
  6553 kvaslots
     0 pending writes
     0 pending reads
  2139 cache hits

DIRTY pages???
(Continue reading)

Stefan Wollny | 20 Oct 17:04 2014

tcpdump: WARNING: compensating for unaligned libpcap packets

Hi there!

I use a Lenovo T60 with amd64-5.6-current / #452 from Oct. 20th.

Looking at what 'tcpdump -nettti pflog0 inbound and action block'
reports I noticed the following:

~ $ sudo tcpdump -nettti pflog0 inbound and action block
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Oct 20 16:48:38.881272 rule 3/(match) block in on trunk0: \ > udp 169
tcpdump: WARNING: compensating for unaligned libpcap packets

Google came up with an old thread from 2010 that was of no help to me.

Is this WARNING expected behaviour or s.th. to be taken care of?

I found the following version of libpcap:

~ $ ls -alh //usr/src/lib/libpcap
total 672
drwxr-xr-x   3 root  wheel   1.0K Oct 18 15:10 .
drwxr-xr-x  34 root  wheel   1.5K Oct 20 11:34 ..
-rw-r--r--   1 root  wheel   8.8K Apr 11  2014 CHANGES
drwxr-xr-x   2 root  wheel   512B Oct 18 15:10 CVS
-rw-r--r--   1 root  wheel   2.7K Jun 19  2013 Makefile
-rw-r--r--   1 root  wheel   2.3K Apr 11  2014 README
(Continue reading)

Justin Mayes | 20 Oct 16:25 2014

Making tftp download large files from tftpd

I will spare you all the backstory but I found that tftp could not download
files over 32 mb by default from tftpd. I know you can pass blocksize to tftpd
to handle much larger files but I was originally working with a client where
this wasn't possible. Tftp protocol has 2 bytes for block number which put a
65535 limit on that. tftpd data doesn't care and will just roll that over back
to 0 and keep sending data. Tftp client fails when there is block number roll
over because it is tracking all the blocks with an int so ends up comparing
its block counter which is now at 65536 to what comes off the network, 0 and
quits. I updated the tftp client code to use same data type as the network
side structs are using  - u_int16_t. Now tftp counter rolls along with server
and can send file of any size with or without a blocksize change. I feel like
this is mostly pointless but doesn't hurt anything. Will gladly provide the
actuall diffs. I have to look into that process for openbsd but just wanted to
check with the group first in case there was a reason an int was used that I
do not understand.