Re: Simple IPSEC client with certificate - phase 1 time out

[Thor Lancelot Simon]

Consider disabling dead peer detection?

Thor

Re: Qemu + tiny core linux = poor man's chromium on NetBSD

[Mayuresh]

On Tue, Mar 01, 2016 at 10:12:38AM -0700, Swift Griggs wrote:

Thanks for a detailed response!

> >May be if someone has, kindly submit a package to pkgsrc or wip. (Just
> >like libreoffice has native as well as Linux emulation version we might
> >have both in future.)
> 
> That'd be nice. I like how that's done with Firefox.

Good to know you feel that way. I wonder whether we could attract NetBSD
community attention to this so that at least the emulated version could
come up sooner (if that were feasible).

> and/or friends. Even on very fast systems, the performance hit is
> massive.

Yes performance is a problem. I have to make do with it every time
reminding myself that this is temporary and the native version would come
sooner or later. As it is I have to use this only for some pesky sites
that wouldn't work with firefox.

> Are you using some kind of Docker version? I'm just curious.

I am using microcore Linux current version. Not aware of Docker.

> You're lucky then. I've done the same and it doesn't always work. Many
> times it complains about lack of some X11 extensions and XDMCP won't
> work. Sounds like your combination works well.

I think I have seen extension errors when launching chromium from
microcore terminal on host display, but it does come up. The problem is on
main host display the whole X11 freezes after some time. On nested display
(xnest) nothing freezes but I can't read many of the things.

> I suppose you could also try to launch it within an X11 session running
> in Xvnc. Of course, that sucks because you can't simply launch Chrome and
> redirect the display, you have to show the whole "desktop". That's my #1
> complaint about VNC - you can't share out apps (with the not-very-good
> exception of SeamlessRDP which is pretty breaky).

I'll have to use tinycore instead of microcore for that. Since I am
already doing this over Qemu, it could further slow down.

> Does the whole VM lock up or just Chrome within it?

It is host X11 session that locks up, with only mouse movement visible.
Qemu takes 100% CPU in this state. I have to kill -9 Qemu over ssh or by
switching to console.

Mayuresh.

Re: Simple IPSEC client with certificate - phase 1 time out

[Brett Lymn]

On Tue, Mar 01, 2016 at 09:09:07AM -0500, Greg Troxel wrote:
> 
> In my experience, SPD entries are added outside of racoon to tell the
> kernel that certain traffic should have IPsec protection.   I don't
> understand how in your setup that's supposed to work, or what is
> triggering racoon to start the negotiation.
> 

A SPD sets the policy for encrypting an outgoing packet.  If you are
simply creating a tunnel between two machines I think you don't need it
but if you have a machine that wants to access a network on the other
side of a tunnel then you need a SPD to tell ipsec to use a particular
SAD to encrypt and send the packet.  I cannot recall myself but I think
raccoon should set up the SPD if you have told it there is a network
range on the remote end.  If racoon is configured with passive off then
it will attempt negotiation when it starts, I expect this is what is
happening.

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.

Re: Simple IPSEC client with certificate - phase 1 time out

[Brett Lymn]

On Tue, Mar 01, 2016 at 01:11:08PM +0100, Frank Wille wrote:
> Brett Lymn wrote:
> 
> > OK, does phase 2 actually complete?
> 
> I doubt that. Currently I'm not even sure whether phase 1 completes, because
> the phase1-up script is never called. On the other hand the phase1-down
> script is called, as soon as the connection is terminated.
> 

Well, it does seem to get close see below.

> 
> > What does a "setkey -aD" output?
> 
> No SAD entries. And no SPD entries either.
> I guess they would be added by the phase1-up script...?
> 

In the logs you can see the SAD entries get created but they get removed
when the connection gets torn down.

> 
> > Have you tried a tcpdump to see what is going on at the network level?
> 
> Yes, always. I have attached the tcpdump from my client and the vpn-status
> log of the Lancom-router (the VPN "server").
> 

That's helpful.  I normally use -s 0 -x with my tcpdump so I can see
what is in the packets but it may not be very useful here.

> 
> > You should expect encrypted packets, if you are seeing stuff in the
> > clear then check your routing and ensure the packets are properly
> > routed to the vpn tunnel end point.
> 
> This is something to worry about as soon as both phases have been completed,
> which definitely is not the case. ;)
> 

Well, there is a chance that the negotiation was failing due to packets
not going where you expect.  That doesn't appear to be happening but
checking the simple things can't hurt and can save a lot of grief :)

> 
> > It has been a long while since I played with this but I seem to recall
> > that you do get a log of what is being proposed by both sides.
> 
> The proposal is accepted (refer to the Lancom VPN log).
> 

Yes and by NetBSD too, you can actually see the phase 1 has completed in
the racoon logs but then the SA gets removed.

> Looking at the tcpdump I wonder why the NetBSD client says it is exchanging
> "isakmp: phase 2" packets, while the Lancom still calls these isakmp
> notifies "Phase-1 SA"?
> 

As Greg said, this is probably just terminology, I wouldn't get hung up
on that too much.


OK, lets have a bit of a look at the logs and see what is going on...

> Mar  1 11:52:07 powerbook racoon: [1.2.3.4] INFO: received INITIAL-CONTACT 
> Mar  1 11:52:07 powerbook racoon: INFO: ISAKMP-SA established 
> 192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 

This is good - we have a security association here, note the SPI numbers
here, they will be useful later.

> Mar  1 11:53:12 powerbook racoon: [1.2.3.4] INFO: DPD: remote (ISAKMP-SA 
> spi=4da2f5f910bbdf44:444ae08dd7de45a5) seems to be dead. 
> Mar  1 11:53:12 powerbook racoon: INFO: purging ISAKMP-SA 
> spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
> Mar  1 11:53:12 powerbook racoon: INFO: purged ISAKMP-SA 
> spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
> Mar  1 11:53:12 powerbook racoon: INFO: ISAKMP-SA deleted 
> 192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 
> Mar  1 11:53:12 powerbook racoon: INFO: KA remove: 
> 192.168.1.5[4500]->1.2.3.4[4500] 

Then the SA gets torn down.

> 11:52:06.441891 IP 192.168.1.5.500 > 1.2.3.4.500: isakmp: phase 1 I ident

Nothing really out of place in the tcpdump...

the log from the other side is interesting:

> 
> [VPN-Status] 2016/03/01 11:52:07,096
> IKE info: exchange_finalize: assuming identified for road-warrior with cert, 
> id=VPNCLIENT15EF90, RemoteGW=91.56.237.127
> 
> 
> [VPN-Status] 2016/03/01 11:52:07,121
> IKE info: Phase-1 [responder] for peer VPNCLIENT15EF90 initiator id 
> CN=VPNCLIENT15,O=WPS,C=DE,L=HERFORD,ST=NRW,OU=IT,postalCode=32052, responder 
> id CN=ZENTRALE,O=WPS,C=DE,L=HERFORD,ST=NRW,OU=IT,postalCode=32052
> IKE info: initiator cookie: 0x4da2f5f910bbdf44, responder cookie: 
> 0x444ae08dd7de45a5
> IKE info: NAT-T enabled in mode rfc, we are not behind a nat, the remote side 
> is  behind a nat
> IKE info: SA ISAKMP for peer VPNCLIENT15EF90 encryption aes-cbc 
> authentication MD5
> IKE info: life time ( 28800 sec/ 0 kb) DPD 0 sec
> 

This is good - we have a phase 1 done here, note the initiator and
responder cookies match the SPI numbers from the NetBSD side.  Looking
good at this point.

> 
> [VPN-Status] 2016/03/01 11:52:23,541
> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE sent for Phase-1 SA to peer 
> VPNCLIENT15EF90, sequence nr 0x7a8b3f4b
> 
> 
> [VPN-Status] 2016/03/01 11:52:23,614
> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE_ACK for peer 
> VPNCLIENT15EF90 Seq-Nr 0x7a8b3f4b, expected 0x7a8b3f4b
> 

This is good, we see a query and response

> 
> [VPN-Status] 2016/03/01 11:52:27,223
> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer 
> VPNCLIENT15EF90 Seq-Nr 0xe8, expected 0xe8
> 
> 
> [VPN-Status] 2016/03/01 11:52:27,224
> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer 
> VPNCLIENT15EF90, sequence nr 0xe8
> 

OK and here is where things fall apart.  The client sends an "are you
there" request and vpn server sends 

Re: "No route to host" in Alpine

[Marco Beishuizen]

On Tue, 1 Mar 2016, the wise J. Lewis Muir wrote:


On 3/1/16 2:34 PM, Marco Beishuizen wrote:

Does anyone know where to look for things like this?


Just a guess, but maybe it tries IPv6 first and fails and prints that 
error, but then tries IPv4 and succeeds?


Could be I don't know. Is there a way to make try NetBSD IPv4 first?

Regards,

Marco

--
Boy, n.:
A noise with dirt on it.

Re: "No route to host" in Alpine

[J. Lewis Muir]

On 3/1/16 2:34 PM, Marco Beishuizen wrote:
> Does anyone know where to look for things like this?

Just a guess, but maybe it tries IPv6 first and fails and prints that
error, but then tries IPv4 and succeeds?

Lewis

"No route to host" in Alpine

[Marco Beishuizen]

Hi,

I use Alpine as mailclient on a Digital PWS600au with NetBSD 7.0. When 
accessing my mailboxes (a couple of IMAP mailboxes, including my own 
ISP, and at Yahoo and Google), I always get an error of which I can't get 
rid of: "Can't connect to imap.isp.com,993: No route to host". But after 
these messages Alpine connects to the imap hosts and opens the mailboxes.


Interesting point is though that it doesn't give this warning for the 
Yahoo mailbox. Pinging and traceroute to all hosts works fine. Settings in 
Alpine are the same for all imap servers.


I have the same setup at another computer which runs Alpine on FreeBSD 
10-STABLE (with exactly the same Alpine settings, even same network 
settings afaik). But there is no problem on that computer at all.


Does anyone know where to look for things like this?

Thanks,

Marco

--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
-- George Bernard Shaw, "Back to Methuselah"
   [No, it wasn't John F. Kennedy.  Ed.]

Re: nVidia vs NetBSD v7 resolving issue.

[Mike]

On Fri, Feb 26, 2016 at 05:54:49PM +0330, Mohammad Badie Zadegan wrote:
> I set vesa 0x118 mode in boot prompt and I saw the boot process was change 
> visiblity to new mode but still errored me (EE) No Device detected.
> BTW, I didn't use current version.
> Is that I must use current version for vesa?
> 
> > On Feb 26, 2016, at 3:23 PM, Roy Bixler  wrote:
> > 
> >> On Fri, Feb 26, 2016 at 06:56:17AM +0330, Mohammad BadieZadegan wrote:
> >> Yes, the main reason is that nVidia did not handle its source code.
> >> How i can try booting from vesa framebuffer?
> >> Which NetBSD image produce with vesa framebuffer defaultly?
> >> Thanks for your attention.
> > 
> > From the boot prompt.  Try a "man boot" to see the commands.  One of the
> > commands is "vesa" and you can do "vesa list" to see which modes are
> > available.
> > 
> > -- 
> > Roy Bixler 
> > "The fundamental principle of science, the definition almost, is this: the
> > sole test of the validity of any idea is experiment."
> > -- Richard P. Feynman
Hi Mohammad... I guess you don't need current... First of all - did you
try to start X without config at all?? Most probably you just have to
specify the right BUSID in xorg.conf I'm using similar configuration
- framebuffer mode+nvidia cards+Xorg... It works with both nv and
  vesa(I'm not sure about vesa... I do not remember exactly) and wsfb
drivers! But when using your own xorg.conf you should specify slightly
different BusID's with different drivers...) Can you send your
Xorg.0.log, then running X --configure/ startx with config( pls also attach
your video device section of config)/ startx w/out config / Xorg
-logverbose 4 /)??
I've had 1680x1050 resolution in both console and X(using nv driver -
it's better... but before I've had to use wsfb, because I couldn't
understand for a long time, how to make this works "right"... finnaly
i've found running X with wsfb driver had too many flaws...and figured
out about this part of configuration...)
So I think I can help you, if you will still have problems, after the
above actions...)

Re: Qemu + tiny core linux = poor man's chromium on NetBSD

[Roy Bixler]

I haven't gone so far as to try Linux emulation or running a Linux
instance under QEMU to get Chromium, but it would be nice to have it
under NetBSD.  One less reason to run Linux.  I've noticed for some
time that there has been an ancient version of Chromium under
pkgsrc-wip.  Just now, I noticed that someone has put a more modern
version of Chromium in pkgsrc-wip.  Those might be worth a try.

-- 
Roy Bixler 
"The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment."
-- Richard P. Feynman

Re: Qemu + tiny core linux = poor man's chromium on NetBSD

[Swift Griggs]

On Sat, 27 Feb 2016, Mayuresh wrote:
What doesn't change is, whether you like it or not, you have no option 
but to work with such websites. Well, had that not been the case I'd use 
elinks almost everywhere...


I feel the same way. I've used Chrome enough on other platforms to see 
that it's clearly faster than most and has some nice features. However, 
I'm distrustful of Google and Chrome seems to lack some of the privacy and 
anti-tracking features of others.


Best option is of course to have it natively on NetBSD and I am sure it 
will come some day.


I'm sure it will. FreeBSD and OpenBSD already have it. Hopefully, it's 
just a matter of time.


Linux emulation layer could be an option. But I personally do not have 
sufficient expertise to try Linux version of chromium through NetBSD 
Linux emulation layer.


I have tried it. It seems to fall apart somewhere in emulation-land.

May be if someone has, kindly submit a package to pkgsrc or wip. (Just 
like libreoffice has native as well as Linux emulation version we might 
have both in future.)


That'd be nice. I like how that's done with Firefox.

Linux as Xen DomU is an option and I know how to use it, but I have 
several other difficulties with xen, particularly related to graphics.


I have two problems with Xen. Lack of a console is problem #1. The second 
is that the Xen tools that are written in Python love to fail for a 
variety of reasons and when they don't fail, they often don't work 
properly. I've had terrible experiences with the toolset over the years on 
both NetBSD and Linux.



So I come to Qemu.


Qemu is categorically awesome, if you ask me. Fabrice Bellard is a genius. 
The only problem is the lack of any acceleration via kquemu and/or 
friends. Even on very fast systems, the performance hit is massive.


Tiny core Linux can be a very good option as it is lightweight and has 
chromium browser in its repository.


Are you using some kind of Docker version? I'm just curious.

Getting it work is pretty easy as well. After getting the terminal I set 
the DISPLAY to that of the host and launch chromium perfectly fine.


You're lucky then. I've done the same and it doesn't always work. Many 
times it complains about lack of some X11 extensions and XDMCP won't work. 
Sounds like your combination works well.


I tried to create a nested X server with Xnest and launched chromium in 
that.


I suppose you could also try to launch it within an X11 session running in 
Xvnc. Of course, that sucks because you can't simply launch Chrome and 
redirect the display, you have to show the whole "desktop". That's my #1 
complaint about VNC - you can't share out apps (with the not-very-good 
exception of SeamlessRDP which is pretty breaky).


Now the freezing behavior is gone. However the Xnested application does 
not render properly. Many of the widgets, text elements simply do not 
appear properly under Xnest.


That almost always happens to me when using Xnest.

Above was on NetBSD 7.0 amd64 Qemu 2.4.0.1, but I had witnessed similar 
behavior with older NetBSD and Qemu versions in the past.


Does the whole VM lock up or just Chrome within it?

-Swift

Re: create keys and certificates for postfix/tls

[Lucius Rizzo]

Hello,

Please allow me clarify many fallacies in your mail. For one, labelling this as 
souped up python script is simply incorrect. One git clones this project which 
is not very different from other OSS projects. Once setup, the script allow for 
some autodetection (apache for instance) but you (as a BSD user) can use the 
standalone option to generate a ssl cert -- which does work very well on 
FreeBSD. letencrypt.sh is also now in ports on FreeBSD although I recommend the 
git cloned version.

- Your point 3 is incorrect. The checks can be DNS or http (nginx) not just 
DNS. This is very similar to having a ssl cert these days (CNAME to comodo is 
one of the options to get a new ssl). Calling a special sauce is doing it a 
disservice as you fail to describe how it actually works.
- You don't run the script ^everyday^. You can sign for 30-90 days and automate 
the resigning via cron. Pretty easy. The symlinked /etc/letsencrypt will allow 
you to keep the ssl cert locations for httpd, sendmail, imap in one easy to 
find location,
- The latest git clone even launches it own http to do a quick check to 
generate/sign the ssl
- Major sponsors include Cisco, mozilla, chrome, gandi.net, ovh among others. 
Its quite interesting to see such big names support something that would impact 
the ssl market

Letsencrypt works well on FreeBSD stable. The latest git clone shows work to 
accommodate the *BSD. I haven't tried it on NetBSD yet. I hope this clarifies 
some of the misunderstanding about this project. 

Disclaimer: I am not part of the letsencrypt project 

--
L

From: netbsd-users-ow...@netbsd.org  on behalf 
of Swift Griggs 
Sent: Tuesday, March 1, 2016 10:43 AM
To: netbsd-users@netbsd.org
Subject: Re: create keys and certificates for postfix/tls

On Mon, 29 Feb 2016, Martin Husemann wrote:
> I am currently using free certificates from StartSSL.

Interesting that they even offer such a thing. I had to look them up.

> I looked at letsencrypt, but I couldn't make any sense of it - can
> somebody explain (from an admin point of view) how that is supposed to
> work?

It's a science project, for sure. I was playing with it recently under
FreeBSD. My impression of how it's supposed to work is this:

1. You install a Python script using git.

2. You run the script and it tries to autoconfigure for your system. It's
a script, so of course, that's mostly going to fail. The script tries
to detect things like your cert locations in your Apache config. It
does claim to be able to manage raw certs.

3. The script in conjunction with back-end tools on their site checks
your domain's TXT records for an x509 special record with some special
sauce to auth your CSR or whatever.

> Of course I will NOT install arbitrary 3rd party server side software
> (where my server OS isn't even officially supported) to handle
> important things like certificate renewals when it is a very simple
> task to do just once a year.

Their intention is, I believe, for you to run this Python script every day
until the end of time and it'll handle cert updates automagically. They
don't issue certs for any longer than 90 days as far as I can tell. So,
I'm guessing you'll be doing a lot of updating and it'd definitely need to
work. They have a protocol for the crypto ops called ACME. So, I suppose
the Python script is the first (and only?) implementation of that.

> Given all the hype about it, I am sure I must be missing something. What
> is it?

My take is that it's a way to get a quick domain cert if you have control
over your domain's DNS. I don't like the script-approach since it threw
all kinds of warnings and errors, then failed to work under FreeBSD, I'm
guessing it'll fail even worse for NetBSD.

In short, Linux Foundation + overly ambitious python script = meh.

-Swift

DRM issues with Xorg and intel

[Riccardo Mottola]

Hi,

I am running 7.0 (full dmesg below) and I noticed that my video card has 
bad performance and often worden its performance when e.g. browsing. I 
noticed these errors in the console:


DRM error in intel_pipe_set_base: pin & fence failed
DRM error in intel_pipe_set_base: pin & fence failed
DRM error in intel_pipe_set_base: pin & fence failed
DRM error in i8xx_irq_handler: pipe B underrun
DRM error in i8xx_irq_handler: pipe B underrun

The latter may repeat many times.

Anybody else has these issues? a kernel problem?
dmesg and Xorg report my card as being 915 (852/855), the code refers 
toi 8xx. Specifically, this is from my Xorg.log:


[  5937.603] (II) intel(0): Using Kernel Mode Setting driver: i915, 
version 1.6.0 20080730

[  5937.619] (WW) Falling back to old probe method for vesa
[  5937.619] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card 
support
[  5937.620] (--) intel(0): Integrated Graphics Chipset: Intel(R) 
852GM/855GM

[  5937.620] (--) intel(0): CPU: x86, sse2
[  5937.620] (II) intel(0): Creating default Display subsection in 
Screen section

"Builtin Default intel Screen 0" for depth/fbbpp 24/32
[  5937.620] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[  5937.620] (==) intel(0): RGB weight 888
[  5937.620] (==) intel(0): Default visual is TrueColor
[  5937.661] (II) intel(0): Output LVDS1 has no monitor section
[  5937.662] (II) intel(0): Enabled output LVDS1
[  5937.662] (II) intel(0): Output VGA1 has no monitor section
[  5937.662] (II) intel(0): Enabled output VGA1
[  5937.662] (--) intel(0): Using a maximum size of 64x64 for hardware 
cursors

[  5937.662] (II) intel(0): Output VIRTUAL1 has no monitor section
[  5937.662] (II) intel(0): Enabled output VIRTUAL1
[  5937.662] (--) intel(0): Output LVDS1 using initial mode 1024x768 on 
pipe 1

[  5937.662] (==) intel(0): TearFree disabled
[  5937.663] (==) intel(0): DPI set to (96, 96)
[  5937.663] (II) Loading sub module "dri2"


Riccardo

NetBSD 7.0 (GENERIC.201509250726Z)
total memory = 2038 MB
avail memory = 1988 MB
kern.module.path=/stand/i386/7.0/modules
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
IBM 288732G (ThinkPad R51)
mainbus0 (root)
ACPI: RSDP 0xf6da0 24 (v02 IBM   )
ACPI: XSDT 0x7f6eb16b 4C (v01 IBMTP-1V1290  LTP )
ACPI: FACP 0x7f6eb200 F4 (v03 IBMTP-1V1290 IBM 0001)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 
(20131218/tbfadt-634)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 
(20131218/tbfadt-634)
ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address 
or length: 0x102C/0x0 (20131218/tbfadt-664)

ACPI: DSDT 0x7f6eb3e7 00BA37 (v01 IBMTP-1V1290 MSFT 010E)
ACPI: FACS 0x7f6f8000 40
ACPI: SSDT 0x7f6eb3b4 33 (v01 IBMTP-1V1290 MSFT 010E)
ACPI: ECDT 0x7f6f6e1e 52 (v01 IBMTP-1V1290 IBM 0001)
ACPI: TCPA 0x7f6f6e70 32 (v01 IBMTP-1V1290 PTL 0001)
ACPI: BOOT 0x7f6f6fd8 28 (v01 IBMTP-1V1290  LTP 0001)
ACPI: All ACPI Tables successfully acquired
cpu0 at mainbus0: Intel(R) Pentium(R) M processor 1500MHz, id 0x695
acpi0 at mainbus0: Intel ACPICA 20131218
acpi0: X/RSDT: OemId , AslId < LTP,>
acpiecdt0 at acpi0: ACPI Embedded Controller via ECDT
LNKA: ACPI: Found matching pin for 0.2.INTA at func 0: 11
LNKA: ACPI: Found matching pin for 0.29.INTA at func 0: 11
LNKD: ACPI: Found matching pin for 0.29.INTB at func 1: 11
LNKC: ACPI: Found matching pin for 0.29.INTC at func 2: 11
LNKH: ACPI: Found matching pin for 0.29.INTD at func 7: 11
LNKC: ACPI: Found matching pin for 0.31.INTA at func 1: 255
LNKB: ACPI: Found matching pin for 0.31.INTB at func 3: 11
LNKA: ACPI: Found matching pin for 2.0.INTA at func 0: 11
LNKF: ACPI: Found matching pin for 2.2.INTA at func 0: 11
LNKE: ACPI: Found matching pin for 2.8.INTA at func 0: 11
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
acpiec0 at acpi0 (EC, PNP0C09-0): using acpiecdt0
MEM (PNP0C01) at acpi0 not configured
acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch
acpibut0 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button
SIO (PNP0C02) at acpi0 not configured
attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
FPU (PNP0C04) at acpi0 not configured
pckbc1 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1
pckbc2 at acpi0 (MOU, IBM0057) (aux port): irq 12
FDC (PNP0700) at acpi0 not configured
LPT (PNP0400) at acpi0 not configured
acpibat0 at acpi0 (BAT0, PNP0C0A-0): ACPI Battery
acpibat0: SANYO LION rechargeable battery
acpibat0: granularity: low->warn 0.001 Wh, warn->full 0.001 Wh
acpiacad0 at acpi0 (AC, ACPI0003-0): ACPI AC Adapter
thinkpad0 at acpi0 (HKEY, IBM0068)
acpivga0 at acpi0 (VID): ACPI Display Adapter
acpiout0 at 

Re: create keys and certificates for postfix/tls

[Swift Griggs]

On Mon, 29 Feb 2016, Martin Husemann wrote:

I am currently using free certificates from StartSSL.


Interesting that they even offer such a thing. I had to look them up.

I looked at letsencrypt, but I couldn't make any sense of it - can 
somebody explain (from an admin point of view) how that is supposed to 
work?


It's a science project, for sure. I was playing with it recently under 
FreeBSD. My impression of how it's supposed to work is this:


1. You install a Python script using git.

2. You run the script and it tries to autoconfigure for your system. It's
   a script, so of course, that's mostly going to fail. The script tries
   to detect things like your cert locations in your Apache config. It
   does claim to be able to manage raw certs.

3. The script in conjunction with back-end tools on their site checks
   your domain's TXT records for an x509 special record with some special
   sauce to auth your CSR or whatever.


Of course I will NOT install arbitrary 3rd party server side software
(where my server OS isn't even officially supported) to handle
important things like certificate renewals when it is a very simple
task to do just once a year.


Their intention is, I believe, for you to run this Python script every day 
until the end of time and it'll handle cert updates automagically. They 
don't issue certs for any longer than 90 days as far as I can tell. So, 
I'm guessing you'll be doing a lot of updating and it'd definitely need to 
work. They have a protocol for the crypto ops called ACME. So, I suppose 
the Python script is the first (and only?) implementation of that.


Given all the hype about it, I am sure I must be missing something. What 
is it?


My take is that it's a way to get a quick domain cert if you have control 
over your domain's DNS. I don't like the script-approach since it threw 
all kinds of warnings and errors, then failed to work under FreeBSD, I'm 
guessing it'll fail even worse for NetBSD.


In short, Linux Foundation + overly ambitious python script = meh.

-Swift

Re: RAIDframe corruption

[Greg Troxel]

Emmanuel Dreyfus  writes:

> But I still have no explanation why the kernel got corrupted and if that
> problem could be more widespread. RAIDframe is probably innocent there,
> though.

In my experience, RAIDframe has always been innocent, and I've had a lot
of failing disks (due to having ~10 RAIDframe systems for 10 years,
nothing unusual or unexpected) and bad RAM once.  That doesn't mean it
is guaranteed bug-free, and it's always good to check, but I bet it's
something else.

I would run pkgsrc/sysutils/memtestplus on the box for a few hours.



signature.asc
Description: PGP signature

Re: RAIDframe corruption

[Greg Troxel]

m...@netbsd.org (Emmanuel Dreyfus) writes:

> Greg Troxel  wrote:
>
>> > Should the disk content be exactly the same? Does it make sense to
>> > compare the whole 500 GB for differences? 
>> After the first 64 blocks, yes, they should be identical, and yes it's a
>> good test.
>
> cmp -l produces a 1 GB output, with roughtly 3 regions of change:
> - 32 bit word in MBR at offset 441
> - One byte at offset  1064977
> - 64 MB region at offset 498074652673 with many changes

I meant to run cmp not on the disk, but on the wd0j/wd1j (e in your case
I guess) shadow partitions that reference the underlying raid component
less the first 64 blocks.   But it sounds like your disks are ok.


signature.asc
Description: PGP signature

Re: Simple IPSEC client with certificate - phase 1 time out

[Greg Troxel]

Frank Wille  writes:

  >> What does a "setkey -aD" output?

  > No SAD entries. And no SPD entries either.
  > I guess they would be added by the phase1-up script...?

In my experience, SPD entries are added outside of racoon to tell the
kernel that certain traffic should have IPsec protection.   I don't
understand how in your setup that's supposed to work, or what is
triggering racoon to start the negotiation.

> Looking at the tcpdump I wonder why the NetBSD client says it is exchanging
> "isakmp: phase 2" packets, while the Lancom still calls these isakmp
> notifies "Phase-1 SA"?
>
> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE sent for Phase-1 SA to peer
> VPNCLIENT15EF90, sequence nr 0x7a8b3f4b

I think this is ok.   I have not read the specs in a long time, but I
think that notifications (INITIAL_CONTACT, DPD, etc.) are sent as phase
2 other messages (meaning they are protected in the phase 1 SA), but are
considered control messages about the phase 1 SA.   Other phase 2
messages are used to create a phase 2 SA, which is loaded into the
kernel, and then data flows over that.

So I don't think the 1/2 terminology difference about notifies is a problem.


signature.asc
Description: PGP signature

Re: Simple IPSEC client with certificate - phase 1 time out

[Frank Wille]

Brett Lymn wrote:

> OK, does phase 2 actually complete?

I doubt that. Currently I'm not even sure whether phase 1 completes, because
the phase1-up script is never called. On the other hand the phase1-down
script is called, as soon as the connection is terminated.


> What does a "setkey -aD" output?

No SAD entries. And no SPD entries either.
I guess they would be added by the phase1-up script...?


> Have you tried a tcpdump to see what is going on at the network level?

Yes, always. I have attached the tcpdump from my client and the vpn-status
log of the Lancom-router (the VPN "server").


> You should expect encrypted packets, if you are seeing stuff in the
> clear then check your routing and ensure the packets are properly
> routed to the vpn tunnel end point.

This is something to worry about as soon as both phases have been completed,
which definitely is not the case. ;)


> It has been a long while since I played with this but I seem to recall
> that you do get a log of what is being proposed by both sides.

The proposal is accepted (refer to the Lancom VPN log).

Looking at the tcpdump I wonder why the NetBSD client says it is exchanging
"isakmp: phase 2" packets, while the Lancom still calls these isakmp
notifies "Phase-1 SA"?

IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE sent for Phase-1 SA to peer
VPNCLIENT15EF90, sequence nr 0x7a8b3f4b

-- 
Frank Wille
Mar  1 11:40:50 powerbook racoon: INFO: @(#)ipsec-tools cvs 
(http://ipsec-tools.sourceforge.net) 
Mar  1 11:40:50 powerbook racoon: INFO: @(#)This product linked OpenSSL 1.0.1p 
9 Jul 2015 (http://www.openssl.org/) 
Mar  1 11:40:50 powerbook racoon: INFO: Reading configuration from 
"/etc/racoon/racoon.conf" 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[500] used as isakmp port 
(fd=7) 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[4500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[4500] used as isakmp port 
(fd=8) 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[500] used as isakmp port 
(fd=9) 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[4500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[4500] used as isakmp port 
(fd=10) 
Mar  1 11:52:06 powerbook racoon: INFO: accept a request to establish IKE-SA: 
1.2.3.4 
Mar  1 11:52:06 powerbook racoon: INFO: initiate new phase 1 negotiation: 
192.168.1.5[500]<=>1.2.3.4[500] 
Mar  1 11:52:06 powerbook racoon: INFO: begin Identity Protection mode. 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: 
draft-ietf-ipsec-nat-t-ike-02  
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: 
draft-ietf-ipsec-nat-t-ike-03 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: RFC 3947 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: 
draft-ietf-ipsra-isakmp-xauth-06.txt 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: DPD 
Mar  1 11:52:06 powerbook racoon: [1.2.3.4] INFO: Selected NAT-T version: RFC 
3947 
Mar  1 11:52:06 powerbook racoon: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with 
algo #1  
Mar  1 11:52:06 powerbook racoon: [192.168.1.5] INFO: Hashing 192.168.1.5[500] 
with algo #1  
Mar  1 11:52:06 powerbook racoon: INFO: Adding remote and local NAT-D payloads. 
Mar  1 11:52:06 powerbook racoon: [192.168.1.5] INFO: Hashing 192.168.1.5[500] 
with algo #1  
Mar  1 11:52:06 powerbook racoon: INFO: NAT-D payload #0 doesn't match 
Mar  1 11:52:06 powerbook racoon: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with 
algo #1  
Mar  1 11:52:06 powerbook racoon: INFO: NAT-D payload #1 verified 
Mar  1 11:52:06 powerbook racoon: INFO: NAT detected: ME  
Mar  1 11:52:06 powerbook racoon: INFO: KA list add: 
192.168.1.5[4500]->1.2.3.4[4500] 
Mar  1 11:52:07 powerbook racoon: WARNING: unable to get certificate CRL(3) at 
depth:0 
SubjectName:/postalCode=32052/OU=IT/ST=NRW/L=HERFORD/C=DE/O=WPS/CN=ZENTRALE 
Mar  1 11:52:07 powerbook racoon: WARNING: unable to get certificate CRL(3) at 
depth:1 SubjectName:/C=DE/O=LANCOM SYSTEMS/CN=LANCOM CA 
Mar  1 11:52:07 powerbook racoon: [1.2.3.4] INFO: received INITIAL-CONTACT 
Mar  1 11:52:07 powerbook racoon: INFO: ISAKMP-SA established 
192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 
Mar  1 11:53:12 powerbook racoon: [1.2.3.4] INFO: DPD: remote (ISAKMP-SA 
spi=4da2f5f910bbdf44:444ae08dd7de45a5) seems to be dead. 
Mar  1 11:53:12 powerbook racoon: INFO: purging ISAKMP-SA 
spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
Mar  1 11:53:12 powerbook racoon: INFO: purged ISAKMP-SA 
spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
Mar  1 11:53:12 powerbook racoon: INFO: ISAKMP-SA deleted 
192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 
Mar  1 11:53:12 powerbook racoon: INFO: KA remove: 
192.168.1.5[4500]->1.2.3.4[4500] 
11:52:06.441891 IP 192.168.1.5.500 > 1.2.3.4.500: isakmp: phase 1 I ident
11:52:06.500027 IP 1.2.3.4.500 > 

Re: RAIDframe corruption

[Robert Elz]

Date:Tue, 1 Mar 2016 08:55:03 +0100
From:m...@netbsd.org (Emmanuel Dreyfus)
Message-ID:  <1mjesf6.dj1fl5xzo35gm%m...@netbsd.org>

  | - 64 MB region at offset 498074652673 with many changes

You have 500GB dives, right?  So that is way out near the end.

What number(s) of sectors do the drives report (should be in dmesg) ?

What is in the labels for wd0 and wd1 (MBR probably, and the netbsd disklabel
if there is one, but GPT would be OK too - whatever you are using).
Note I mean the labels on the raw drives, not what is inside the raid
"device", that is irrelevant for this.

I assume the labels are the same on both drives, so only one (set) is needed.

And what are the raidframe parameters (the config file used).

It is possible that region is beyond what raidframe is managing, and
you have just compared 2 different sets of random crud.

kre