Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Raul Miller
On Tue, Dec 8, 2015 at 11:22 PM, Nick Holland
 wrote:
> https is a joke.  IF and WHEN it works properly, it's too complex for
> the real world to understand (ahem...and even recognize).

That's not the joke, though - that's the punchline.

(1) "Secure" and "Security" mean different (and often conflicting)
things to different people.

(2) Web browsers are broken by (details elided).

Traditional solutions to these issues seem to involve yelling at
people and/or escalating violence and/or ignoring the problems.

But that's ok. It's not like any of us had anything better to do with
our time, right?

(For the record, I highly approve of many https efforts, but think
that https everywhere would be an utter disaster.)

-- 
Raul



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Delan Azabani
On Wed, Dec 9, 2015 at 12:22 PM, Nick Holland
 wrote:
> HAHAHHAHAHA...
> you think adding a certificate changes this?
> https is a joke.

"Some people implement HTTPS poorly sometimes, so we shouldn't try."

The amount of effort "wasted" on Let's Encrypting the OpenBSD website
is so small compared to the immediate benefits that we would gain by
doing so. Nothing is perfect, and no approach is enough to be called
"security" on its own. Defense in depth calls for doing what we can
to provide multiple layers of security.

In the case of www.openbsd.org, using HTTPS isn't so much about
privacy as it is about integrity. Yes, signify(1) is a thing, but
using HTTPS in addition to it would make release and package
downloads more difficult to tamper with.



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Nick Holland
On 12/08/15 20:26, Anthony J. Bentley wrote:
> Giancarlo Razzolini writes:
>> One of the main benefits of the TLS wouldn't only be to render
>> impossible for anyone to know which pages you're accessing on the site,
>> but also the fact that we would get a little more security getting the
>> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> they are today, isn't very secure.
> 
> Another attack currently possible against www.openbsd.org is changing
> the https://openbsdstore.com links to http://openbsdstore.com, and
> running sslstrip on that. Or the PayPal links...

HAHAHHAHAHA...
you think adding a certificate changes this?

Pull up a chair, lemme tell you a story.


I used to work for a company I'm sure you have heard of -- Two letters,
starts with a G.  And they don't make cars.  When I hired in, one of my
coworkers told me, "Congrats, you now work for four or five of the
largest companies in the world".  That company.

This company was a target for cyber attack for a whole lot of reasons,
and they did all kinds of (token) security education things -- including
an annual "Security Week" ("token" as in chanting rules that are not
understood and easily broken), and lots of time and effort was put into
compliance, security technology, buzzwords and check-boxes so that
effort could be demonstrated.  And of course, there were lessons on
https and encryption and how encryption solves everything and always
look for the https:// and and and ...

My team was a hot-shot security team...I worked with some absolutely
amazing people in the world of incident response, including one who
literally wrote the book on it.  We tended to live in our own little
world significantly detached from the rest of the company.  We had our
own infrastructure in fact, which was part of my job to run.  So, most
of us didn't actually USE a lot of the corporate infrastructure, such as
the company web portal much.  But after I was there about three years,
they refreshed my laptop, and because things were kinda quiet in my job
at that point, I got to spend a little time looking around the new
machine, which I didn't do when I first started.  And this time, I
didn't immediately change the browser start screen from the company
portal to something more useful.

And ... I looked at the company portal for the first time...closely.
It looked something like this:

+-+
| url: http://intranet.bla.com/stupid/long/url/portal/|
+-+
| |
| +--+|
| |   _ Please log in!   ||
| | ,(_),||
| | |   |   SSO:__   ||
| | |___|PW:__   ||
| |  ||
| |  ||
| +--+|
| |
| |
+-+

That little thing that looks like an "i" is supposed to be a lock
graphic.  My ASCII art skills are lame.  But then, the "Single Sign-On"
screen on the portal wasn't much more than my ASCIIart, either.  A box.
 A couple boxes for user ID (SSO) and PW.  And a graphic of a lock.

And I stare at this some more...and realize that my eyes aren't fooling
me.  That's a graphic of a lock.  And no https:// in the URL.  No
encryption in sight.  I can't believe where I'm sitting and what I'm
looking at.

I walk over to one of my coworkers, a smart guy who knows the importance
and tools of "compliance", but understand real security, too.  I have
him go to the portal, and he immediately, reflexively starts typing in
his SSO and PW, in spite of my yelling "STOP! STOP!  DON'T DO IT!".  He
looked at me puzzled.  I tap the URL on his screen.  I tap the lock
graphic.  His look goes from "What silly crap has Nick got for me this
time?" to pure panic.
"oh. my. God.  We are going to have to do a password roll" (a change of
pw for EVERY SINGLE PERSON in the company -- as he realized this was a
major breach of security protocols).

(On further investigation, it turned out the BOX was a frame that did
happen to be encrypted, so there was no actual need for a PW roll, and
there was no actual obvious security event...but again, there was
absolutely nothing "proving" the communications was encrypted, and
anyone could set up a rogue page and snag passwords).

I put a ticket in to have this fixed.  It was closed without action,
with the explanation, "well, that will be a lot of work to change, we
won't be scheduling any time on this page for a year or so".

Note that something like 100,000 users all over th

University of Toronto Mirror upcoming outages

2015-12-08 Thread Nick Holland
Hi,

A heads-up for users of the University of Toronto mirror
(openbsd.cs.toronto.edu):

The University will be doing some power systems maintenance this week
and next, and anticipate two planned outages:

* Thursday, December 10 11:00p EST to Friday December 11, 7:00am EST
* Wednesday, December 16 11:00p EST to Thursday December 17, 7:00am EST

The mirror will be unavailable during these periods.

Thanks!

Nick.



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Stuart Henderson
On 2015-12-09, Giancarlo Razzolini  wrote:
> Also, now that we have two free TLS certs providers, one can use HPKP
> and completely disregard the CA's, which is a security benefit.

Also wosign (and, sort-of, cloudflare). btw, HPKP doesn't work too well
with letsencrypt as-is (which wants to generate a new key each time).
It can be hacked around but is a bit of a pain.. (I wasn't aware that
it lets you disregard the CAs though?)



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Anthony J. Bentley
Giancarlo Razzolini writes:
> One of the main benefits of the TLS wouldn't only be to render
> impossible for anyone to know which pages you're accessing on the site,
> but also the fact that we would get a little more security getting the
> SSH fingerprints for the anoncvs servers. Having them in clear text as
> they are today, isn't very secure.

Another attack currently possible against www.openbsd.org is changing
the https://openbsdstore.com links to http://openbsdstore.com, and
running sslstrip on that. Or the PayPal links...



Ikedv2 proper usage questions.

2015-12-08 Thread Daniel Ouellet
I have a few questions that I really need to clarify fro myself and I
would very much appreciate some input.

Reason is that I am having problem to keep the session up for a long
time and just doing /etc/rc.d/iked stop and the start on the client side
will bring the session back up, even if I see what suppose to be proper
flow with ipsecctl -s all

And For testing as I was trying to see what happen, I setup a gateway
between my home router and a data center gateway, both OpenBSD, home on
5.8 and gateway and data center for now on 5.7. Then I started to watch
Netflix on it to see and about every 50 minutes to 60, or so, the
connection went down for may be 50 seconds to 2 minutes every time, I
suppose to do the re-key things I guess, but shouldn't the flow continue
as it does this, or is it not possible? I guess the man page said it
should redo this every 3 hours by default or 500Mb of data transfer.
Will it always cut off the traffic when it redo this?

Anyway around this may be?

Also, doing ipsecctl reload or reset for testing will hang the client
side and you can't kill it. 100% CPU utilization and you can only do
kill -9 processid multiple times to kill it.

/etc/rc.d/iked stop will not do it ever.

Also, if no traffic for a while, over night for testing, then somehow
you see to reset the iked client to get it going again and in the
ipsecctl -s all you see more then the normal flow there, may be 6 or 8
at times and still no traffic.

So, some questions come to mind and it may be stupid, or not, but I do
wonder and try to find the answers for them.

1. Why does it need to be two connections(setup in iked.conf), one
between gateways and then networks when one does the same thing and works?

>From the mane page:

# Set up a VPN:
# First between the gateway machines 192.168.3.1 and 192.168.3.2
# Second between the networks 10.1.1.0/24 and 10.1.2.0/24
ikev2 esp from 192.168.3.1 to 192.168.3.2
ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

But this works as well and do not duplicate the SAD. May be that's what
create some kind of routing issue may be. I do not know but continue
testing this to find out.

ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

as long as oyu have the reverse on the other side as this:
ikev2 esp from 10.1.2.0/24 to 10.1.1.0/24 peer 192.168.3.1

you would see for example two of the same:
SAD:
esp tunnel from 192.168.3.1 to 192.168.3.2 spi 0x2ce28601 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.3.1 to 192.168.3.2 spi 0x6d67d248 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.3.2 to 192.168.3.1 spi 0xd5760dc0 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.3.2 to 192.168.3.1 spi 0xf5b3b824 auth
hmac-sha2-256 enc aes-256

Why two???

2. If you have the connection establish between the gateway only, oppose
to the network to peer as in question 1. and you configure a routing
protocol being eigrpd or ospfd and you that tpo announce client network
to gateway assuming you control both side as to not inject bad routers,
it is not safe or correct to say that the traffic woudl be also
encrypted when it flows through enc0 and it doesn't need to have the
network statement in the iked.conf? Or is that a very bad idea and if so
why? Wouldn't it achieve the same things? Is it safe s well. I just find
it easier and faster to manage routing protocol oppose to iked.cong
flows. But is there a reason not to do so, or a bad idea as well? After
all the man page said:

"IPsec traffic appears unencrypted on the enc(4) interface and can be
filtered accordingly using the OpenBSD packet filter, pf(4).  The
grammar for the packet filter is described in pf.conf(5)."

"enc0
Default interface for outgoing traffic before it's been
encapsulated, and incoming traffic after it's been decapsulated.
State on this interface should be interface bound; see enc(4) for
further information."

3. Not a big deal, but even if the man page said the active is the
default mode, why do I need to actually specifically say in iked.conf:

ikev2 active esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

to get it going as this will not do so:

ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

even if I have also this in the iked.conf file

set active

Or am I really miss understanding the man page in regards to the set
active part?

4. Do I need to setup some kind of keep alive or something to make sure
the flow between the boxes is always up. Or what could I look at to find
out what may be happening for the traffic to stop flowing properly.

Every time, nothing needs to be done other then /etc/rc.d/iked stop and
then start to get it going again after it wasn't used for a while.

Thanks

Daniel



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Giancarlo Razzolini
Em 08-12-2015 16:24, Michael McConville escreveu:
> There are still some privacy benefits to using HTTPS. It will confound a
> lot of simple filtering and monitoring software, and what you're reading
> on the site is pretty obfuscated. It also helps security on sketchy
> networks.
>
> HTTPS isn't a perfect solution, but it's something. Especially when ISPs
> are starting to inject beacons into HTTP requests and more closely
> observe usage.
>
> That said, I suspect none of the sysadmins have the time or interest,
> and that's understandable.
I started a thread regarding TLS on the OpenBSD site some time ago, I
think it was 2013. There was startcom at the time and I even offered to
buy certs if the startcom certs weren't acceptable. I don't see why this
changed with letsencrypt in town. There wasn't interest at the time, and
I don't see why there will be now.

One of the main benefits of the TLS wouldn't only be to render
impossible for anyone to know which pages you're accessing on the site,
but also the fact that we would get a little more security getting the
SSH fingerprints for the anoncvs servers. Having them in clear text as
they are today, isn't very secure.

Also, now that we have two free TLS certs providers, one can use HPKP
and completely disregard the CA's, which is a security benefit.

Cheers,
Giancarlo Razzolini



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Stuart Henderson
On 2015-12-08, Michael McConville  wrote:
> Jason Barbier wrote:
>> szs wrote:
>> > Not for security.
>> > For privacy.
>> 
>> It is a read only site, the privacy you seek is breached as soon as
>> you make a DNS call to openbsd.org
>
> There are still some privacy benefits to using HTTPS. It will confound a
> lot of simple filtering and monitoring software

For current TLS versions it is absolutely trivial to identify which
site you're connecting to, it's in cleartext in the clienthello,
there's no need to even spoof the TLS connection for this.
(Easy to log in squid. Anyone want to send a patch for dsniff? ;-)

(Doing something about this for TLS 1.3 gets discussed from time to
time on the IETF TLS mailing list, the latest iteration being
https://www.ietf.org/mail-archive/web/tls/current/msg18633.html)

> and what you're reading on the site is pretty obfuscated.

Not as much as it would be if you checked out the www tree from CVS :-)

> It also helps security on sketchy networks.
>
> HTTPS isn't a perfect solution, but it's something. Especially when ISPs
> are starting to inject beacons into HTTP requests and more closely
> observe usage.
>
> That said, I suspect none of the sysadmins have the time or interest,
> and that's understandable.

I don't think this is a "time or interest" thing. I haven't seen any
proposed viable solutions for the problems that have been mentioned when
this has come up on the lists in the past.

The technically-cleanest way I can think of would be to publish a
name-constrained private root and sign from there, but the only place we
could sanely distribute that root is cert.pem which doesn't work nicely
for !OpenBSD or for gui browsers on OpenBSD, and while that would have
some uses, the list questions will then change to "why don't you use a
publically recognized root", so I don't really consider that viable
either.



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Kevin Chadwick
> >It would actually reduce the security and potential for DDOS against
> >openbsd.org despite the heroic efforts that have gone into LibreSSL. So
> >where's the benefit to risk analysis for OpenBSD?  
> 
> Don't you mean reduce the securiry and _increase_ the potential for
> DDOS against openbsd.org?

yeah, was gonna correct it but thought everyone would get it ;)

-- 

KISSIS - Keep It Simple So It's Securable



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Tati Chevron

On Tue, Dec 08, 2015 at 10:11:34PM +, Kevin Chadwick wrote:

It would actually reduce the security and potential for DDOS against
openbsd.org despite the heroic efforts that have gone into LibreSSL. So
where's the benefit to risk analysis for OpenBSD?


Don't you mean reduce the securiry and _increase_ the potential for
DDOS against openbsd.org?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Kevin Chadwick
> > So with letsencrypt here, how about making the main site
> > default to https? Is this a good idea or is this a great idea?  
> 
> Don't mistake encryption for security.

It would actually reduce the security and potential for DDOS against
openbsd.org despite the heroic efforts that have gone into LibreSSL. So
where's the benefit to risk analysis for OpenBSD?

-- 

KISSIS - Keep It Simple So It's Securable



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Raul Miller
On Tue, Dec 8, 2015 at 3:23 PM, Ted Unangst  wrote:
> Michael McConville wrote:
>> Yes, but it is certainly "Websense" difficult, "Verizon traffic
>> monetization dept." difficult, "nosy VPN/exit node operator" difficult,
>> and "guy in cafe with Wireshark" difficult.
>
> But we don't care about any of those people anymore. The NSA is the only bad
> guy worth caring about

Wait, what... no other governments even exist?

Or just that they are not quite so incompetent at hiding their spys?

-- 
Raul



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Michael McConville
Ted Unangst wrote:
> Michael McConville wrote:
> > Jason Barbier wrote:
> > > szs wrote:
> > > > Not for security.
> > > > For privacy.
> > > 
> > > It is a read only site, the privacy you seek is breached as soon as
> > > you make a DNS call to openbsd.org
> > 
> > There are still some privacy benefits to using HTTPS. It will confound a
> > lot of simple filtering and monitoring software, and what you're reading
> > on the site is pretty obfuscated. It also helps security on sketchy
> > networks.
> 
> Note that simple length correlation is enough to determine what you're
> reading. And this isn't even "NSA intern" difficult, it's "NSA internship
> interview question" difficult.

Yes, but it is certainly "Websense" difficult, "Verizon traffic
monetization dept." difficult, "nosy VPN/exit node operator" difficult,
and "guy in cafe with Wireshark" difficult.

I'll stop responding publicly, though.



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Ted Unangst
Michael McConville wrote:
> Yes, but it is certainly "Websense" difficult, "Verizon traffic
> monetization dept." difficult, "nosy VPN/exit node operator" difficult,
> and "guy in cafe with Wireshark" difficult.

But we don't care about any of those people anymore. The NSA is the only bad
guy worth caring about



Re: Empty MFS on root

2015-12-08 Thread Alexander Hall
On December 8, 2015 4:21:16 PM GMT+01:00, Otto Moerbeek  wrote:
>On Tue, Dec 08, 2015 at 03:03:14PM +, Tati Chevron wrote:
>
>> Currently, it's possible, (as root), to do something like:
>> 
>> # mount_mfs -s 1g swap /
>> 
>> which succeeds, and mounts the empty filesystem as the root
>filesystem.
>> 
>> This makes the machine inoperable and requires a physical reset,
>without a clean shutdown, as no system binaries are available.
>> 
>> Shouldn't we make mount_mfs error out in this case?
>
>Why? Unix does not prevent you from doing stupid things in general. 
>
>Besides, a small variation (using -P) could be a proper and sane use
>of mount_mfs on /

FWIW, I don't think so, as the mfs is populated after being mounted. 

>
>   -Otto



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Ted Unangst
Michael McConville wrote:
> Jason Barbier wrote:
> > szs wrote:
> > > Not for security.
> > > For privacy.
> > 
> > It is a read only site, the privacy you seek is breached as soon as
> > you make a DNS call to openbsd.org
> 
> There are still some privacy benefits to using HTTPS. It will confound a
> lot of simple filtering and monitoring software, and what you're reading
> on the site is pretty obfuscated. It also helps security on sketchy
> networks.

Note that simple length correlation is enough to determine what you're
reading. And this isn't even "NSA intern" difficult, it's "NSA internship
interview question" difficult.



Re: serious watchdog timeout issues with em driver

2015-12-08 Thread Kapetanakis Giannis

On 08/12/15 19:39, Chris Cappuccio wrote:

Kapetanakis Giannis [bil...@edu.physics.uoc.gr] wrote:

On 20/11/15 15:12, Martin Pieuchot wrote:

I just committed a revert to 1.305 keeping the API changes needed for
the driver to build.

This should bring your stability back, please let us know if that's not
the case.

I'm sorry for your troubles.

Hi,

I've upgraded yesterday to Dec 6 snapshot and today I got my first
em0: watchdog timeout -- resetting

em0 at pci1 dev 10 function 0 "Intel 82541EI" rev 0x00: apic 2 int 22, address 
00:30:48:72:28:58
em1 at pci1 dev 11 function 0 "Intel 82541EI" rev 0x00: apic 2 int 23, address 
00:30:48:72:28:59

Can you try to pinpoint when it started?


You mean what type of traffic caused it? Don't know.
The server is a ~ busy internal-only recursive DNS server (bind).
Other than that I was playing in it's shell when the event occurred, 
nothing special.


If you mean time since boot, it was after ~ 22hours
Dec  7 15:53:20  /bsd: OpenBSD 5.8-current (GENERIC.MP) #1468: Sun Dec  
6 11:27:59 MST 2015

Dec  8 16:06:59  /bsd: em0: watchdog timeout -- resetting
Dec  8 16:07:00  named[10537]: client: warning: client xx.xx.xx.xx#30399 
(mail.expressionclones.com): error sending response: host unreachable
Dec  8 16:07:00  named[10537]: client: warning: client yy.yy.yy.yy#52263 
(85.151.91.139.sa-accredit.habeas.com): error sending response: host 
unreachable


The event happened only once and it's network recovered after a few 
seconds. no reboot.


G



Re: multiple certificates in httpd

2015-12-08 Thread Adam Wolk
On Tue, 8 Dec 2015 18:04:13 +0100
Torsten  wrote:

> Hi!
> 
> man httpd.conf says:
> [tls option]
> "Set the TLS configuration for the server."
> 
> I assumed that "the server" would mean that every (virtual) server can
> have its own tls options (and certificates). Otherwise it would have
> said "Set the TLS configuration for httpd and all virtual servers."
> 
> Is that wrong? Can I only have ONE key and ONE cert and the cert must
> be a multi domain certificate?
> 

httpd(8) does not yet support SNI[1][2]. It is on the TODO[3]

[1] - http://marc.info/?l=openbsd-misc&m=142642449514312&w=2
[2] - https://marc.info/?l=openbsd-misc&m=142797475322402&w=2
[3] - https://github.com/reyk/httpd/issues/17

Regards,
Adam



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Michael McConville
Jason Barbier wrote:
> szs wrote:
> > Not for security.
> > For privacy.
> 
> It is a read only site, the privacy you seek is breached as soon as
> you make a DNS call to openbsd.org

There are still some privacy benefits to using HTTPS. It will confound a
lot of simple filtering and monitoring software, and what you're reading
on the site is pretty obfuscated. It also helps security on sketchy
networks.

HTTPS isn't a perfect solution, but it's something. Especially when ISPs
are starting to inject beacons into HTTP requests and more closely
observe usage.

That said, I suspect none of the sysadmins have the time or interest,
and that's understandable.



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Jason Barbier
It is a read only site, the privacy you seek is breached as soon as you
make a DNS call to openbsd.org

-- 
Jason Barbier | E: jab...@serversave.us
GPG Key-ID: B5F75B47(http://kusuriya.devio.us/pubkey.asc)

On Tue, Dec 8, 2015, at 09:58 AM, szs wrote:
> Not for security.
> For privacy.
> 
> 
>  Original Message 
> Subject: Re: letsencrypt && https && openbsd.org =
> https://www.openbsd.org/
> Local Time: December 8 2015 5:36 pm
> UTC Time: December 8 2015 5:36 pm
> From: s...@spacehopper.org
> To: misc@openbsd.org
> 
> On 2015-12-08, szs  wrote:
> > So with letsencrypt here, how about making the main site
> > default to https? Is this a good idea or is this a great idea?
> 
> Don't mistake encryption for security.
> 
> Besides, who is going to agree to the Subscriber Agreement and indemnify
> ISRG?



multiple certificates in httpd

2015-12-08 Thread Torsten
Hi!

man httpd.conf says:
[tls option]
"Set the TLS configuration for the server."

I assumed that "the server" would mean that every (virtual) server can
have its own tls options (and certificates). Otherwise it would have
said "Set the TLS configuration for httpd and all virtual servers."

Is that wrong? Can I only have ONE key and ONE cert and the cert must be
a multi domain certificate?

I tried this:


ext_addr="*"
prefork 3

server "domaina.com" {
alias "www.domaina.com"
listen on $ext_addr tls port 443
tls dhe "auto"
root "/htdocs/domaina"
}

server "domainb.com" {
alias "www.domainb.com"
listen on $ext_addr tls port 443
tls dhe "auto"
tls certificate "/etc/ssl/domainb.crt"
tls key "/etc/ssl/private/domainb.key"
root "/htdocs/domainb"
}


You see in domaina.com there is no certificate specification. According
to the documentation the default values should be used. And they are. On
OpenBSD 5.7 I get the cert from the default files when I try to access
https://www.domaina.com

On OpenBSD5.7 I also get the certificate for domaina when I access
domainb.com, which results in a certificate error.

On OpenBSD5.8 it's the other way round: when accessing domainb the
browser reports the correct certificate. When accessing domaina I get
the certificate of domainb (and the corresponding cert error).

I started
httpd -d -
on OpenBSD5.7 to check the output and found that the messages
server_tls_load_keypair: using certificate /etc/ssl/cert.pem
server_tls_load_keypair: using private key /etc/ssl/private/server.key
only appear for those two files. So the httpd obviously does not read
the other certificates.

T.



Re: cannot get output from pflow on openbsd v. 5.8 amd64

2015-12-08 Thread Imre Oolberg

Hi!

On 2015-12-08 10:50, Stuart Henderson wrote:

On 2015-12-08, Imre Oolberg  wrote:

Hi!

I have used pflow 5 successfully before but now on OpenBSD v. 5.8 it
seems to refuse working. Config looks like this

# cat /etc/hostname.pflow0
flowsrc 192.168.10.125 flowdst 192.168.10.250:9784 pflowproto 5
description "pflow"

and i start it with (also tried to start manually as man pflow says)

# sh /etc/netstart pflow0

As a result new pflow0 interface appears

# ifconfig pflow0
pflow0: flags=41 mtu 1492
 description: pflow
 priority: 0
 pflow: sender: 192.168.10.125 receiver: 192.168.10.250:9784
version: 5
 groups: pflow

but there isnt seen any associated traffic with dst port 9784


Do you have any PF rules (or a "set state-defaults" line) with the
"pflow" keyword?


Yes, i do with

set state-defaults pflow

and for example one rule is like this

# pfctl -sr | egrep xx.35.252.35 | grep 80
pass in quick on seadmed inet proto tcp from any to xx.35.252.35 port = 
80 flags S/SA keep state (pflow) tag TO_KOHTVORK rdr-to 192.168.5.8


Otherwise this new firewall is working quite beautifully.


Imre



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread szs
Not for security.
For privacy.


 Original Message 
Subject: Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Local Time: December 8 2015 5:36 pm
UTC Time: December 8 2015 5:36 pm
From: s...@spacehopper.org
To: misc@openbsd.org

On 2015-12-08, szs  wrote:
> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?

Don't mistake encryption for security.

Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Ted Unangst
Stuart Henderson wrote:
> 
> Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?

Huh? You don't trust robots to perform surgery correctly?

oh, wrong ISRG.



Re: serious watchdog timeout issues with em driver

2015-12-08 Thread Chris Cappuccio
Kapetanakis Giannis [bil...@edu.physics.uoc.gr] wrote:
> On 20/11/15 15:12, Martin Pieuchot wrote:
> >I just committed a revert to 1.305 keeping the API changes needed for
> >the driver to build.
> >
> >This should bring your stability back, please let us know if that's not
> >the case.
> >
> >I'm sorry for your troubles.
> 
> Hi,
> 
> I've upgraded yesterday to Dec 6 snapshot and today I got my first
> em0: watchdog timeout -- resetting
> 
> em0 at pci1 dev 10 function 0 "Intel 82541EI" rev 0x00: apic 2 int 22, 
> address 00:30:48:72:28:58
> em1 at pci1 dev 11 function 0 "Intel 82541EI" rev 0x00: apic 2 int 23, 
> address 00:30:48:72:28:59

Can you try to pinpoint when it started?



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Stefan Sperling
On Tue, Dec 08, 2015 at 12:06:52PM -0500, szs wrote:
> Fb jvgu yrgfrapelcg urer, ubj nobhg znxvat gur znva fvgr
> qrsnhyg gb uggcf? Vf guvf n tbbq vqrn be vf guvf n terng vqrn?

I'm sorry, I couldn't read your message because it was encrypted.
How about you sign your messages instead? That way, everyone can
read it and also verify its authenticity.



Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread Stuart Henderson
On 2015-12-08, szs  wrote:
> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?

Don't mistake encryption for security.

Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?



letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread szs
So with letsencrypt here, how about making the main site
default to https? Is this a good idea or is this a great idea?



Re: Empty MFS on root

2015-12-08 Thread Ted Unangst
Tati Chevron wrote:
> On Tue, Dec 08, 2015 at 08:09:47AM -0700, Theo de Raadt wrote:
> >> Currently, it's possible, (as root), to do something like:
> >>
> >> # mount_mfs -s 1g swap /
> >>
> >> which succeeds, and mounts the empty filesystem as the root filesystem.
> >>
> >> This makes the machine inoperable and requires a physical reset, without a 
> >> clean shutdown, as no system binaries are available.
> >>
> >> Shouldn't we make mount_mfs error out in this case?
> >
> >what is "this case"?
> 
> mount_mfs as opposed to mount.
> 
> It's possible to mount a regular filesystem on a mount point that is
> already in use, except for /, which fails with an error.
> 
> The behaviour of mount_mfs is inconsistent with that of mount, in
> that it allows the root directory to be used as a mount point, whereas
> mount does not.

This would have been interesting information to include in your original
email. As far as I can see, there's no reason why mount and mount_mfs would
behave differently here.



Re: Empty MFS on root

2015-12-08 Thread Tati Chevron

On Tue, Dec 08, 2015 at 08:09:47AM -0700, Theo de Raadt wrote:

Currently, it's possible, (as root), to do something like:

# mount_mfs -s 1g swap /

which succeeds, and mounts the empty filesystem as the root filesystem.

This makes the machine inoperable and requires a physical reset, without a 
clean shutdown, as no system binaries are available.

Shouldn't we make mount_mfs error out in this case?


what is "this case"?


mount_mfs as opposed to mount.

It's possible to mount a regular filesystem on a mount point that is
already in use, except for /, which fails with an error.

The behaviour of mount_mfs is inconsistent with that of mount, in
that it allows the root directory to be used as a mount point, whereas
mount does not.

As otto points out, using with -P is potentially useful, but without
there doesn't appear to be a use case.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com



Re: serious watchdog timeout issues with em driver

2015-12-08 Thread Kapetanakis Giannis

On 20/11/15 15:12, Martin Pieuchot wrote:

I just committed a revert to 1.305 keeping the API changes needed for
the driver to build.

This should bring your stability back, please let us know if that's not
the case.

I'm sorry for your troubles.


Hi,

I've upgraded yesterday to Dec 6 snapshot and today I got my first
em0: watchdog timeout -- resetting

regards,

G

OpenBSD 5.8-current (GENERIC.MP) #1468: Sun Dec  6 11:27:59 MST 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0: 
FPU,V86,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,CNXT-ID,xTPR,PERF
real mem  = 2146910208 (2047MB)
avail mem = 2093232128 (1996MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/13/04, BIOS32 rev. 0 @ 0xfb7f0, SMBIOS rev. 2.3 @ 
0xf0800 (42 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 04/13/2004
bios0: Supermicro P4SCE
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices HUB0(S5) UAR1(S5) UAR2(S5) USB0(S1) USB1(S1) USB2(S1) 
USB3(S1) USBE(S1) MODM(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu1: 
FPU,V86,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,CNXT-ID,xTPR,PERF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (HUB0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0x8000 0xc8000/0x8000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82875P Host" rev 0x02
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2
pci1 at ppb0 bus 1
vga1 at pci1 dev 9 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci1 dev 10 function 0 "Intel 82541EI" rev 0x00: apic 2 int 22, address 
00:30:48:72:28:58
em1 at pci1 dev 11 function 0 "Intel 82541EI" rev 0x00: apic 2 int 23, address 
00:30:48:72:28:59
ichpcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA, channel 
0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801EB SATA" rev 0x02: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 2 int 18 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 78533MB, 160836480 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801EB/ER SMBus" rev 0x02: apic 2 int 
17
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC3200CL3.0
spdmem1 at iic0 addr 0x51: 512MB DDR SDRAM non-parity PC3200CL3.0
spdmem2 at iic0 addr 0x52: 512MB DDR SDRAM non-parity PC3200CL3.0
spdmem3 at iic0 addr 0x53: 512MB DDR SDRAM non-parity PC3200CL3.0
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x17
lm1 at wbsio0 port 0x290/8: W83627HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exceptio

Re: Empty MFS on root

2015-12-08 Thread Uwe Werler
Am 08.12.2015 16:03:14, schrieb Tati Chevron:
> Currently, it's possible, (as
root), to do something like:
> 
> # mount_mfs -s 1g swap /
> 
> which
succeeds, and mounts the empty filesystem as the root filesystem.
> 
> This
makes the machine inoperable and requires a physical reset, without a clean
shutdown, as no system binaries are available.
> 
> Shouldn't we make
mount_mfs error out in this case?
> 
> -- 
> Tati Chevron
> Perl and FORTRAN
specialist.
> SWABSIT development and migration department.
>
http://www.swabsit.com
> 


Hehe, You can even shutdown the machine as root.
Should there be a warning too? Windoof-like? Or a bunch of questions if You're
really really sure?



Re: Empty MFS on root

2015-12-08 Thread Otto Moerbeek
On Tue, Dec 08, 2015 at 03:03:14PM +, Tati Chevron wrote:

> Currently, it's possible, (as root), to do something like:
> 
> # mount_mfs -s 1g swap /
> 
> which succeeds, and mounts the empty filesystem as the root filesystem.
> 
> This makes the machine inoperable and requires a physical reset, without a 
> clean shutdown, as no system binaries are available.
> 
> Shouldn't we make mount_mfs error out in this case?

Why? Unix does not prevent you from doing stupid things in general. 

Besides, a small variation (using -P) could be a proper and sane use
of mount_mfs on /

-Otto



Re: Empty MFS on root

2015-12-08 Thread Ted Unangst
Tati Chevron wrote:
> Currently, it's possible, (as root), to do something like:
> 
> # mount_mfs -s 1g swap /
> 
> which succeeds, and mounts the empty filesystem as the root filesystem.
> 
> This makes the machine inoperable and requires a physical reset, without a 
> clean shutdown, as no system binaries are available.
> 
> Shouldn't we make mount_mfs error out in this case?

No. You should not do that.



Empty MFS on root

2015-12-08 Thread Tati Chevron

Currently, it's possible, (as root), to do something like:

# mount_mfs -s 1g swap /

which succeeds, and mounts the empty filesystem as the root filesystem.

This makes the machine inoperable and requires a physical reset, without a 
clean shutdown, as no system binaries are available.

Shouldn't we make mount_mfs error out in this case?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com



Re: Empty MFS on root

2015-12-08 Thread Theo de Raadt
> Currently, it's possible, (as root), to do something like:
> 
> # mount_mfs -s 1g swap /
> 
> which succeeds, and mounts the empty filesystem as the root filesystem.
> 
> This makes the machine inoperable and requires a physical reset, without a 
> clean shutdown, as no system binaries are available.
> 
> Shouldn't we make mount_mfs error out in this case?

what is "this case"?

The root issue is that you are root, and root is allpowerful.  You
need to be careful, because all the tools are strong.  There are a
million ways to completely screw your machine.  You found one.
Tomorrow you could find another, but it won't take long before you
learn to be careful...



[drm:pid0:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt

2015-12-08 Thread Stefan Wollny
HI there,

is this issue known or should I file a bug report?

Best,
STEFAN


OpenBSD 5.8-current (GENERIC.MP) #1726: Mon Dec  7 22:06:49 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17082359808 (16291MB)
avail mem = 16560525312 (15793MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries)
bios0: vendor American Megatrends Inc. version "1.05.01" date 08/05/2015
bios0: Notebook W65_67SZ
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT
SSDT SSDT DMAR
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4)
RP03(S4) PXSX(S4) RP04(S4) RLAN(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4)
PXSX(S4) RP07(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-4210M CPU @ 2.60GHz, 3093.24 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 1 (P0P2)
acpiprt5 at acpi0: bus -1 (P0PA)
acpiprt6 at acpi0: bus -1 (P0PB)
acpiprt7 at acpi0: bus 1 (PEG0)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 120 degC
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: LID0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "BAT" serial 0001 type LION oem "Notebook"
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD0
cpu0: Enhanced SpeedStep 3093 MHz: speeds: 2601, 2600, 2500, 2300, 2200,
2100, 2000, 1800, 1700, 1600, 1400, 1300, 1200, 1100, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06
ppb0 at pci0 dev 1 function 0 "Intel Core 4G PCIE" rev 0x06: msi
pci1 at ppb0 bus 1
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x05: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 

Re: which in /dev/* for tethering to android?

2015-12-08 Thread Stuart Henderson
On 2015-12-07, luke...@onemodel.org  wrote:
> On 11/28/15 15:15, Jiri B wrote:
>> On Sat, Nov 28, 2015 at 03:07:15PM -0700, luke...@onemodel.org wrote:
>>> I'd like to get an internet connection via my android phone (on
>>> tmobile).  After connecting the phone via usb and turning on its
>>> tethering option, I see the usb info in dmesg, but when I try to run
>>> the pppd chat script it doesn't get any response from the phone.
>>
>> Why do you do this? urndis is like ethernet iface, it is you phone
>> which establishes connection and acts as a gateway for your laptop.
>
> Thanks.  It seems the key part I didn't realize was where 'man urndis'
> mentions 'man ifconfig', which in turn mentions the hostname.if file:
> It seems that I needed to create that file, with one line
> saying 'dhcp' in it.

In case it's not clear, that isn't a literal ".if", it's replaced with the
interface name e.g. hostname.urndis0 - but it's only used automatically at
boot. If you wanted to configure it automatically at runtime you could use
hotplugd, though I think most people just run dhclient manually.

> But it disconnects after a couple of minutes, with android saying
> something about can't connect to data, but maybe that's something to do
> with android and I need to get a later cyanogenmod release and see if
> that helps, or something else phone-related.  (The data plan works fine
> w/ the built-in android browser.)

It works fairly reliably for me; if you want to isolate the mobile network
when testing, you could connect the phone to wifi then connect to that via
urndis. That'll help pinpoint the problem.



Re: cannot get output from pflow on openbsd v. 5.8 amd64

2015-12-08 Thread Stuart Henderson
On 2015-12-08, Imre Oolberg  wrote:
> Hi!
>
> I have used pflow 5 successfully before but now on OpenBSD v. 5.8 it 
> seems to refuse working. Config looks like this
>
> # cat /etc/hostname.pflow0
> flowsrc 192.168.10.125 flowdst 192.168.10.250:9784 pflowproto 5 
> description "pflow"
>
> and i start it with (also tried to start manually as man pflow says)
>
> # sh /etc/netstart pflow0
>
> As a result new pflow0 interface appears
>
> # ifconfig pflow0
> pflow0: flags=41 mtu 1492
>  description: pflow
>  priority: 0
>  pflow: sender: 192.168.10.125 receiver: 192.168.10.250:9784 
> version: 5
>  groups: pflow
>
> but there isnt seen any associated traffic with dst port 9784

Do you have any PF rules (or a "set state-defaults" line) with the "pflow" 
keyword?