WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)

2017-03-28 Thread bg2200 
I follow i386 stable and after applying the WPA1/WPA2 MITM fix to 6.0 (#018) I 
can no longer obtain an IP address via dhclient when WPA2 is in use. This 
happens with both PSK and enterprise modes (via wpa_supplicant). Wireless 
(iwi0) connections without encryption work fine.

I tried the 03/25/17 snapshot and that does not resolve the issue.

I reversed patch #018 and and built a stable kernel and that does resolve the 
issue.

With the iwi debug flag enabled I see the expected rssi lines and then the 4 
handshake messages without patch #018. These messages are then followed by 
normal dhclient success.

Mar 28 22:14:51  /bsd: iwi0: begin active scan
Mar 28 22:14:51  /bsd: iwi0: received probe_resp from 00:0f:66:b0:d9:dc rssi 66 
mode auto
Mar 28 22:14:51  /bsd: iwi0: received beacon from 00:0f:66:b0:d9:dc rssi 60 
mode auto
Mar 28 22:14:51  /bsd: iwi0: received probe_resp from 00:0f:66:b0:d9:dc rssi 63 
mode auto
Mar 28 22:14:51  /bsd: iwi0: received beacon from 2c:59:e5:f4:57:e3 rssi 44 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 44:94:fc:78:a4:40 rssi 56 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 2c:59:e5:f4:57:e3 rssi 47 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received beacon from 2c:59:e5:f4:57:e3 rssi 47 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 44:94:fc:78:a4:40 rssi 54 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 37 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 38 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 37 
mode auto
Mar 28 22:14:52  /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 38 
mode auto
Mar 28 22:14:52  /bsd: iwi0: end active scan
Mar 28 22:14:52  /bsd: iwi0: received msg 1/4 of the 4-way handshake from 
00:0f:66:b0:d9:dc
Mar 28 22:14:52  /bsd: iwi0: sending msg 2/4 of the 4-way handshake to 
00:0f:66:b0:d9:dc
Mar 28 22:14:52  /bsd: iwi0: received msg 3/4 of the 4-way handshake from 
00:0f:66:b0:d9:dc
Mar 28 22:14:52  /bsd: iwi0: sending msg 4/4 of the 4-way handshake to 
00:0f:66:b0:d9:dc

With patch #018 applied or with 3/25 snapshot, active scanning occurs and ends, 
but no RSNA handshake happens. Therefore, dhclient does not succeed.




OpenBSD 6.0 (GENERIC) #5: Thu Mar 23 11:13:03 CDT 2017

r...@slartibartfast.jamesjerkinscomputer.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1500MHz ("GenuineIntel" 686-class) 1.50 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF
real mem  = 536027136 (511MB)
avail mem = 513101824 (489MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/29/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 
0xf8cb0 (61 entries)
bios0: vendor Dell Computer Corporation version "A17" date 06/29/2005
bios0: Dell Computer Corporation Inspiron 600m
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S1) USB1(S1) USB2(S1) 
USB3(S1) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (PCIE)
acpicpu0 at acpi0
C1: unknown FFH class 0: !C3(100@185 io@0x816), !C3(250@85 io@0x815), !C2(500@1 
io@0x814), C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 89 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0F13" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0401" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
bios0: ROM list: 0xc/0x1
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: Enhanced SpeedStep 1496 MHz: speeds: 1500, 1500, 1500, 1400, 1200, 1000, 
800, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe000, size 0x800
ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility M9" rev 0x02
drm0 at radeondrm0
radeondrm0: irq 11
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
pci2 at ppb1 bus 2
bge0 at pci2 dev 0 function 0 "Broadcom BCM5705M" rev 0x01, BCM5705 A1 
(0x3001):

Re: Xenodm login

2017-03-28 Thread Edgar Pettijohn 

On 03/28/17 10:31, joshua stein wrote:

On Tue, 28 Mar 2017 at 10:22:32 -0500, Edgar Pettijohn wrote:

I recently switched to using xenodm to login/startx. Previously I just used
startx at the command prompt. I'm curious if it's possible to change the
background around the login prompt. Currently it's a herringbone black and
gray that is not very appealing. I found where to change the attributes to the
login box and I have it looking good, but this background is killing me.  Any
help is appreciated.

/etc/X11/xenodm/Xsetup_0 is run before showing the login dialog, so
you can put something in there like "xsetroot -solid purple".


That did it. Thanks.

Re: Opinion about Rust and Go

2017-03-28 Thread Donald Allen 
On 28 March 2017 at 17:59,   wrote:
> Hello,
>
> I just want to know the opinion of OpenBSD developpers about Rust and Go,
> I already know Ted's opinion.
> http://www.tedunangst.com/flak/post/thoughts-on-replacement-languages
>
> As they are both touted as memory safe, what do you think about them ?

I've written some code in both and given up on both of them. I found
Rust difficult to learn, mostly because the documentation is just
awful, in my opinion. The principal writer, Klabnick, knows the
subject matter, but he just doesn't write well, again, in my opinion.
His first attempt at a Rust "Book" is currently being re-written. He
now has a co-author. I've looked at the second attempt, filed some PRs
to try to help, but finally threw up my hands when I was told that
something that is standard practice in C *and* is supported by their
software was not "idiomatic". They use that term a lot. It's a bit
like a certain political party in the US that talks about freedom a
lot. Then you find out that their definition of the word is "we want
you to be free to do what we want you to do". It's too bad the
documentation situation is at it is, because the language and its
compiler have real potential.

Go is much better documented and, in general, feels more mature, more
finished. But it just felt uninspired to me and I felt a sense of
relief when I went back to C. C is far from perfect, but after all
these years, we know its warts, the compilers are solid, it's
extremely well documented (K, Harbison and Steele) and the libraries
are . well, you all know.

When I don't need C's performance, I use Haskell, a brilliant language
and the Glasgow compiler and libraries are excellent. Hackage provides
a rich assortment of additional libraries.

>
> Regards

Opinion about Rust and Go

2017-03-28 Thread narvu454 
Hello,

I just want to know the opinion of OpenBSD developpers about Rust and Go,
I already know Ted's opinion.
http://www.tedunangst.com/flak/post/thoughts-on-replacement-languages

As they are both touted as memory safe, what do you think about them ?

Regards

Re: Remote LAN access from local IPSec Gateway

2017-03-28 Thread Dante F . B . Colò 

Hi Rosen

It`s working now, many thanks !!



On 3/28/17 3:48 PM, Rosen Iliev wrote:

Hi Dante,

It was an dirty hack if I recall, you'll need an static route to 
destination network to the LAN:Address.


Regards,

Rosen

Dante F. B. Colò wrote on 3/28/2017 11:52 AM:

Hi everyone,

i configured an ipsec network using isakmpd on both sides, access 
between local networks are ok  except from the gateways theirselves  
, is it accomplishable ?



Regards

Dante F. B. Colò

Re: Remote LAN access from local IPSec Gateway

2017-03-28 Thread Rosen Iliev 

Hi Dante,

It was an dirty hack if I recall, you'll need an static route to 
destination network to the LAN:Address.


Regards,

Rosen

Dante F. B. Colò wrote on 3/28/2017 11:52 AM:

Hi everyone,

i configured an ipsec network using isakmpd on both sides, access 
between local networks are ok  except from the gateways theirselves  , 
is it accomplishable ?



Regards

Dante F. B. Colò

Remote LAN access from local IPSec Gateway

2017-03-28 Thread Dante F . B . Colò 

Hi everyone,

i configured an ipsec network using isakmpd on both sides, access 
between local networks are ok  except from the gateways theirselves  , 
is it accomplishable ?



Regards

Dante F. B. Colò

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

2017-03-28 Thread Hiltjo Posthuma 
On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > I can reproduce the bug (on the slave firewall) as many times as I want.
> > 
> 
> I've just read https://www.openbsd.org/ddb.html and saw that you need a trace
> for all cpu.
> 
> http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> 
> (it's a different crash from the last screenshots i've made, if it's not good 
> i
> can provide a full new set of pics)
> 
> -- 
> Mathieu
> 

Hey,

Can you also provide your pf.conf ?

Can you test if it also happens on -current?

-- 
Kind regards,
Hiltjo

Re: OpenBSD to Dell Latitude E6510

2017-03-28 Thread Ryan Freeman 
On Tue, Mar 28, 2017 at 01:14:59PM +, Majerní?ek ?tefan wrote:
> Hi All.
> I have question.
> 
> Is it possible install openbsd to notebook dell latitude E6510?
> 

I have one of these, OpenBSD worked with pretty much every device in
the unit.  Wifi cards can be different, but the intel hd graphics,
ethernet, audio, wifi, all work good!

No dmesg to share as the laptop is asleep at home :-)

Hibernate and sleep works well on the laptop too, as I have let it
sleep for so long the uptime almost elapsed 365 days, and everything
still works when it comes back awake.

Great job and kudos to the OpenBSD crew for such a solid laptop OS ;-)

> Thank you a lot.
> 
> Stevo

Re: Xenodm login

2017-03-28 Thread joshua stein 
On Tue, 28 Mar 2017 at 10:22:32 -0500, Edgar Pettijohn wrote:
> I recently switched to using xenodm to login/startx. Previously I just used
> startx at the command prompt. I'm curious if it's possible to change the
> background around the login prompt. Currently it's a herringbone black and
> gray that is not very appealing. I found where to change the attributes to the
> login box and I have it looking good, but this background is killing me.  Any
> help is appreciated.

/etc/X11/xenodm/Xsetup_0 is run before showing the login dialog, so
you can put something in there like "xsetroot -solid purple".

Xenodm login

2017-03-28 Thread Edgar Pettijohn 
I recently switched to using xenodm to login/startx. Previously I just used
startx at the command prompt. I'm curious if it's possible to change the
background around the login prompt. Currently it's a herringbone black and
gray that is not very appealing. I found where to change the attributes to the
login box and I have it looking good, but this background is killing me.  Any
help is appreciated.

Thanks,

Edgar

Sent from my iPhone

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

2017-03-28 Thread Comète 
28 mars 2017 16:40 "Scott Bonds"  a écrit:

> Interesting. I
may have a similar problem and was planning to post about it soon...in my case
I've
> been playing with rdomains, using PF to NAT
> between them, and ikedv2.
I've found that when I use ikedv2 to layer IPSEC on top of my NATing
> traffic
between rdomains, TCP passes fine, UDP does not, though I can see requests and
replies
> moving across enc0 (DNS requests that show the answer in the tcpdump
output). So, host -T
> google.com 8.8.8.8 (TCP DNS lookup) works but host
google.com 8.8.8.8 (UDP DNS lookup) does not.
> 
> On 03/28, Comète wrote:
>
>> Hi,
>> 
>> I'm trying to build an IPSEC encrypted tunnel that works as a
bridge. For
>> this, I use isakmpd and etherip, vether, bridge interfaces. On
each VPN server
>> (Host A and B), I've got PF running on the external
interface (em2). Both
>> hosts run OpenBSD 6.0 stable amd64.
>> Host A is my
main server and host B is the
>> client.
>> 
>> Now the strange part:
>> 
>> -
If PF is running on each host (A and B),
>> UDP queries from B to A network
don't work (UDP only, TCP is ok. But I can see
>> UDP packets with tcpdump
going from B to A and coming back but they don't go
>> out from the interface)
>> 
>> - I disable PF on Host B only with "rcctl disable pf
>> && reboot", all
is working after reboot, all queries (dns, ntp...) are well
>> sent from B to
A through the VPN. Now, I enable PF again without rebooting
>> with "pfctl -e
&& pfctl -f /etc/pf.conf" and it's still working. Then I start
>> "rcctl
enable pf" and reboot, and it doesn't work anymore for UDP queries...
>> So to
resume, if PF is started automatically at boot on host B (rcctl enable
>> pf)
then UDP don't pass but if I start it manually (pfctl -e && pfctl -f
>>
/etc/pf.conf), it works.
>> 
>> I've tried tcpdump -nettti pflog0 during
DNS/NTP
>> queries but I don't see anything blocked. As I said, if I try
tcpdump -nettti
>> em0 I can even see the answer from the DNS server coming
back but dig doesn't
>> get it.
>> 
>> I just don't understand why my UDP
packets don't pass, so if you have
>> a idea, you're welcome ;)
>> 
>> thanks.
>> 
>> This my setup on Host B (Host A is
>> similar)
>> 
>> ipsec.conf:
>>
---
>> 
>> ike active esp proto etherip from $local_gw
>> to
$remote_gw \
>> main auth "hmac-sha1" enc "aes-128" group modp2048
>> lifetime
1800 \
>> quick enc "aes-128-gcm" group modp2048 lifetime 1200 \
>> srcid
$local_gw
>> 
>> ipsecctl -sa
>> ---
>> ipsecctl -sa
>> FLOWS:
>> flow
esp in
>> proto etherip from 10.65.12.10 to 10.65.13.10 peer 10.65.12.10 srcid
>> 10.65.13.10/32 dstid 10.65.12.10/32 type use
>> flow esp out proto etherip
from
>> 10.65.13.10 to 10.65.12.10 peer 10.65.12.10 srcid 10.65.13.10/32 dstid
>> 10.65.12.10/32 type require
>> 
>> SAD:
>> esp tunnel from 10.65.13.10 to
10.65.12.10
>> spi 0xd5acc570 enc aes-128-gcm
>> esp tunnel from 10.65.12.10
to 10.65.13.10 spi
>> 0xe19efd9f enc aes-128-gcm
>> 
>> pf.conf:
>> 
>> ext_if = "em2"
>> int_if =
>> "internal"
>> 
>> match in all scrub (no-df
random-id max-mss 1200)
>> antispoof for {
>> $ext_if, $int_if } inet
>> set
skip on { lo, enc, $int_if }
>> set loginterface
>> $ext_if
>> match out on
$ext_if from any to any nat-to ($ext_if)
>> block log all
>> pass quick on em0
>> 
>> # VPN
>> pass in on $ext_if proto udp from any to $ext_if port
>> {
isakmp, ipsec-nat-t }
>> pass out on $ext_if proto udp from $ext_if to any
port
>> { isakmp, ipsec-nat-t }
>> pass in on $ext_if proto esp from any to
$ext_if
>> pass
>> out on $ext_if proto esp from $ext_if to any
>> 
>>
/etc/hostname.bridge0:
>> --
>> link2
>> add etherip0
>>
add vether0
>> add em0
>> group "internal"
>> up
>> 
>> /etc/hostname.etherip0
>> --
>> tunnel 10.65.13.10
>> 10.65.12.10
>> group
internal
>> up
>> 
>> /etc/hostname.vether0
>> -
>> inet
10.14.254.35 255.255.0.0 NONE
>> description "Interconnexion"
>> group
>>
"internal"
>> up
>> 
>> /etc/hostname.em0
>> --
>> up
>> 
>>
/etc/hostname.em2
>> --
>> inet 10.65.13.10 255.255.255.0 NONE
>> description "Evil
>> Network"
>> group "external"
>> up
>> !route add -inet
10.65.12.0/24 10.65.13.1
>> /etc/sysctl.conf
>> 
>>
net.inet.ip.forwarding=1
>> net.inet.etherip.allow=1


Yes this is exactly
what I have noticed too, I can clearly see the reply of my DNS query with the
DNS record resolved, but it stops here, dig can't get it. All TCP queries are
ok but no UDP at all (dns, ntp, tcpbench -u, ...)

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

2017-03-28 Thread Scott Bonds 
Interesting. I may have a similar problem and was planning to post about 
it soon...in my case I've been playing with rdomains, using PF to NAT
between them, and ikedv2. I've found that when I use ikedv2 to layer 
IPSEC on top of my NATing traffic between rdomains, TCP passes fine, UDP 
does not, though I can see requests and replies moving across enc0 (DNS 
requests that show the answer in the tcpdump output). So, host -T 
google.com 8.8.8.8 (TCP DNS lookup) works but host google.com 8.8.8.8 
(UDP DNS lookup) does not.


On 03/28, Comète wrote:

Hi,

I'm trying to build an IPSEC encrypted tunnel that works as a bridge. For
this, I use isakmpd and etherip, vether, bridge interfaces. On each VPN server
(Host A and B), I've got PF running on the external interface (em2). Both
hosts run OpenBSD 6.0 stable amd64.
Host A is my main server and host B is the
client.

Now the strange part:

- If PF is running on each host (A and B),
UDP queries from B to A network don't work (UDP only, TCP is ok. But I can see
UDP packets with tcpdump going from B to A and coming back but they don't go
out from the interface)

- I disable PF on Host B only with "rcctl disable pf
&& reboot", all is working after reboot, all queries (dns, ntp...) are well
sent from B to A through the VPN. Now, I enable PF again without rebooting
with "pfctl -e && pfctl -f /etc/pf.conf" and it's still working. Then I start
"rcctl enable pf" and reboot, and it doesn't work anymore for UDP queries...
So to resume, if PF is started automatically at boot on host B (rcctl enable
pf) then UDP don't pass but if I start it manually (pfctl -e && pfctl -f
/etc/pf.conf), it works.

I've tried tcpdump -nettti pflog0 during DNS/NTP
queries but I don't see anything blocked. As I said, if I try tcpdump -nettti
em0 I can even see the answer from the DNS server coming back but dig doesn't
get it.

I just don't understand why my UDP packets don't pass, so if you have
a idea, you're welcome ;)

thanks.

This my setup on Host B (Host A is
similar)

ipsec.conf:
---

ike active esp proto etherip from $local_gw
to $remote_gw \
   main auth "hmac-sha1" enc "aes-128" group modp2048
lifetime 1800 \
   quick enc "aes-128-gcm" group modp2048 lifetime 1200 \
srcid $local_gw

ipsecctl -sa
---
ipsecctl -sa
FLOWS:
flow esp in
proto etherip from 10.65.12.10 to 10.65.13.10 peer 10.65.12.10 srcid
10.65.13.10/32 dstid 10.65.12.10/32 type use
flow esp out proto etherip from
10.65.13.10 to 10.65.12.10 peer 10.65.12.10 srcid 10.65.13.10/32 dstid
10.65.12.10/32 type require

SAD:
esp tunnel from 10.65.13.10 to 10.65.12.10
spi 0xd5acc570 enc aes-128-gcm
esp tunnel from 10.65.12.10 to 10.65.13.10 spi
0xe19efd9f enc aes-128-gcm

pf.conf:

ext_if = "em2"
int_if =
"internal"

match in all scrub (no-df random-id max-mss 1200)
antispoof for {
$ext_if, $int_if } inet
set skip on { lo, enc, $int_if }
set loginterface
$ext_if
match out on $ext_if from any to any nat-to ($ext_if)
block log all
pass quick on em0

# VPN
pass in on $ext_if proto udp from any to $ext_if port
{ isakmp, ipsec-nat-t }
pass out on $ext_if proto udp from $ext_if to any port
{ isakmp, ipsec-nat-t }
pass in on $ext_if proto esp from any to $ext_if
pass
out on $ext_if proto esp from $ext_if to any

/etc/hostname.bridge0:
--
link2
add etherip0
add vether0
add em0
group "internal"
up

/etc/hostname.etherip0
--
tunnel 10.65.13.10
10.65.12.10
group internal
up

/etc/hostname.vether0
-
inet 10.14.254.35 255.255.0.0 NONE
description "Interconnexion"
group
"internal"
up

/etc/hostname.em0
--
up

/etc/hostname.em2
--
inet 10.65.13.10 255.255.255.0 NONE
description "Evil
Network"
group "external"
up
!route add -inet 10.65.12.0/24 10.65.13.1
/etc/sysctl.conf

net.inet.ip.forwarding=1
net.inet.etherip.allow=1

Re: OpenBSD to Dell Latitude E6510

2017-03-28 Thread Claus Assmann 
On Tue, Mar 28, 2017, Majern??ek ?tefan wrote:

> Is it possible install openbsd to notebook dell latitude E6510?

Yes.

An old install:

OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 30
real mem = 8495951872 (8102MB)
avail mem = 8261009408 (7878MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf2440 (67 entries)
bios0: vendor Dell Inc. version "A12" date 05/09/2012
bios0: Dell Inc. Latitude E6510
...

I don't have a dmesg from 6.0 available right now.

Re: OpenBSD to Dell Latitude E6510

2017-03-28 Thread Jan Lambertz 
Hi,

the dell latitude E6510 is available with different hardware inside.
so i can not say if yours will work. mine works.
try yours by installing openbsd to a usb-drive (via qemu or something)
and boot openbsd.

Jan

OpenBSD to Dell Latitude E6510

2017-03-28 Thread Majerníček Štefan 
Hi All.
I have question.

Is it possible install openbsd to notebook dell latitude E6510?

Thank you a lot.

Stevo

strange behaviour with etherip bridge over IPSEC and UDP queries

2017-03-28 Thread Comète 
Hi,

I'm trying to build an IPSEC encrypted tunnel that works as a bridge. For
this, I use isakmpd and etherip, vether, bridge interfaces. On each VPN server
(Host A and B), I've got PF running on the external interface (em2). Both
hosts run OpenBSD 6.0 stable amd64.
Host A is my main server and host B is the
client. 

Now the strange part:

- If PF is running on each host (A and B),
UDP queries from B to A network don't work (UDP only, TCP is ok. But I can see
UDP packets with tcpdump going from B to A and coming back but they don't go
out from the interface)

- I disable PF on Host B only with "rcctl disable pf
&& reboot", all is working after reboot, all queries (dns, ntp...) are well
sent from B to A through the VPN. Now, I enable PF again without rebooting
with "pfctl -e && pfctl -f /etc/pf.conf" and it's still working. Then I start
"rcctl enable pf" and reboot, and it doesn't work anymore for UDP queries...
So to resume, if PF is started automatically at boot on host B (rcctl enable
pf) then UDP don't pass but if I start it manually (pfctl -e && pfctl -f
/etc/pf.conf), it works.

I've tried tcpdump -nettti pflog0 during DNS/NTP
queries but I don't see anything blocked. As I said, if I try tcpdump -nettti
em0 I can even see the answer from the DNS server coming back but dig doesn't
get it.

I just don't understand why my UDP packets don't pass, so if you have
a idea, you're welcome ;)

thanks.

This my setup on Host B (Host A is
similar)

ipsec.conf:
---

ike active esp proto etherip from $local_gw
to $remote_gw \
main auth "hmac-sha1" enc "aes-128" group modp2048
lifetime 1800 \
quick enc "aes-128-gcm" group modp2048 lifetime 1200 \
srcid $local_gw

ipsecctl -sa
---
ipsecctl -sa
FLOWS:
flow esp in
proto etherip from 10.65.12.10 to 10.65.13.10 peer 10.65.12.10 srcid
10.65.13.10/32 dstid 10.65.12.10/32 type use
flow esp out proto etherip from
10.65.13.10 to 10.65.12.10 peer 10.65.12.10 srcid 10.65.13.10/32 dstid
10.65.12.10/32 type require

SAD:
esp tunnel from 10.65.13.10 to 10.65.12.10
spi 0xd5acc570 enc aes-128-gcm
esp tunnel from 10.65.12.10 to 10.65.13.10 spi
0xe19efd9f enc aes-128-gcm

pf.conf:

ext_if = "em2"
int_if =
"internal"

match in all scrub (no-df random-id max-mss 1200)
antispoof for {
$ext_if, $int_if } inet
set skip on { lo, enc, $int_if }
set loginterface
$ext_if
match out on $ext_if from any to any nat-to ($ext_if)
block log all
pass quick on em0

# VPN
pass in on $ext_if proto udp from any to $ext_if port
{ isakmp, ipsec-nat-t }
pass out on $ext_if proto udp from $ext_if to any port
{ isakmp, ipsec-nat-t }
pass in on $ext_if proto esp from any to $ext_if
pass
out on $ext_if proto esp from $ext_if to any

/etc/hostname.bridge0:
--
link2
add etherip0
add vether0
add em0
group "internal"
up

/etc/hostname.etherip0
--
tunnel 10.65.13.10
10.65.12.10
group internal
up

/etc/hostname.vether0
-
inet 10.14.254.35 255.255.0.0 NONE
description "Interconnexion"
group
"internal"
up

/etc/hostname.em0
--
up

/etc/hostname.em2
--
inet 10.65.13.10 255.255.255.0 NONE
description "Evil
Network"
group "external"
up
!route add -inet 10.65.12.0/24 10.65.13.1
/etc/sysctl.conf

net.inet.ip.forwarding=1
net.inet.etherip.allow=1

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

2017-03-28 Thread Mathieu BLANC 
On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> I can reproduce the bug (on the slave firewall) as many times as I want.
> 

I've just read https://www.openbsd.org/ddb.html and saw that you need a trace
for all cpu.

http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
http://www.hostingpics.net/viewer.php?id=220012panic12.jpg

(it's a different crash from the last screenshots i've made, if it's not good i
can provide a full new set of pics)

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

2017-03-28 Thread Mathieu BLANC 
On Tue, Mar 28, 2017 at 12:05:56PM +0300, Mihai Popescu wrote:
> Isn't there a CAPSLOOK written message at panic time on the screen?
> If not, look here:
> http://www.openbsd.org/report.html
> 

I can reproduce the bug (on the slave firewall) as many times as I want.

I made some screenshots. Sorry, I didn't manage to provide text logs (i'm in
DRAC). 

In http://man.openbsd.org/OpenBSD-6.0/crash i saw that i might be able to have
the ddb logs in dmesg after a warm reboot but it didn't work for me.

I don't know if you prefer http links or attached files. I have uploaded the
jpg here : 
http://www.hostingpics.net/viewer.php?id=835545panic1.jpg
http://www.hostingpics.net/viewer.php?id=149061panic2.jpg
http://www.hostingpics.net/viewer.php?id=328015panic3.jpg
http://www.hostingpics.net/viewer.php?id=730910panic4.jpg
http://www.hostingpics.net/viewer.php?id=607164panic5.jpg
http://www.hostingpics.net/viewer.php?id=272177panic6.jpg
http://www.hostingpics.net/viewer.php?id=689399panic7.jpg
http://www.hostingpics.net/viewer.php?id=499214panic8.jpg

I can attach the files if you want.

Here is my relayd conf :

_front_vip="A.B.C.D"

_front1="E.F.G.H"
_front2="I.J.K.L"

table  { $_front1 $_front2 }

redirect _http_vip {
listen on $_front_vip port http
forward to  mode source-hash check tcp
pftag RELAYD_VIP_NAT
}

On front1, if i made this command, my openbsd system crash. With DROP instead
of REJECT it's OK (tested 5-6 times) :
iptables -I INPUT -j REJECT -p tcp --dport 80 -s 

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

2017-03-28 Thread Mihai Popescu 
Isn't there a CAPSLOOK written message at panic time on the screen?
If not, look here:
http://www.openbsd.org/report.html

Re: Spamd question with Spamtrap

2017-03-28 Thread Boudewijn Dijkstra 

Op Mon, 13 Mar 2017 18:25:30 +0100 schreef Mik J :
Spamd has been really efficient in blocking spam. A few of them passed  
through once in a while but there's no discomfort.


So this is not really an OpenSMTPd question.


But, I'm not able to use spamtrap.
# spamdb -T -a ""


The example in the manpage doesn't use angle brackets. Remove them.


# spamdb | grep SPAMTRAP
SPAMTRAP|
But when I telnet port 25 and try to send a mail, a GREY entry is  
created, and after the holdtime mail are passing through


When a SPAMTRAP is hit, no GREY entry is created.



--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

2017-03-28 Thread Mathieu BLANC 
On Mon, Mar 27, 2017 at 02:42:23PM +0200, Mathieu BLANC wrote:
> Hello all,
> 
> I have a pair of firewalls running 6.0 (patched with openup in october, no 
> patch
> applied since then). 
> 
> Since the upgrade, this pair has some problem with kernel
> panics (4 times since the upgrade in october).
> 
> The last one was this morning. The two firewall crashed at the same time with
> these logs :
> 
> /bsd: panic: kernel diagnostic assertion "(sk->inp == NULL) || 
> (sk->inp->inp_pf_sk == NULL)" failed: file "../../../../net/pf.c", line 6891
> /bsd: Starting stack trace...
> /bsd: panic() at panic+0x10b
> /bsd: __assert() at __assert+0x25
> /bsd: pf_state_key_unref() at pf_state_key_unref+0xc6
> /bsd: pf_pkt_unlink_state_key() at pf_pkt_unlink_state_key+0x15
> /bsd: m_free() at m_free+0xa0
> /bsd: sbdroprecord() at sbdroprecord+0x61
> /bsd: soreceive() at soreceive+0xb4f
> /bsd: recvit() at recvit+0x139
> /bsd: sys_recvfrom() at sys_recvfrom+0x9d
> /bsd: syscall() at syscall+0x27b
> /bsd: --- syscall (number 29) ---
> /bsd: end of kernel
> /bsd: end trace frame: 0x7f7dc870, count: 247
> /bsd: 0x18ccb3b21ada:
> /bsd: End of stack trace. 
> 

Hello,

This morning, another crash.

I found in daemon.log something very interesting. At the same second the
firewall crashed, i had the same resource checked by relayd which was gone down 
:

Yesterday :
Mar 27 11:51:48 fw5 relayd[94179]: host W.X.Y.Z, check tcp (16010ms,tcp connect 
timeout), state up -> down, availability 99.94%
Mar 27 11:51:48 fw5 relayd[89662]: table _http_vip: 0 added, 1 deleted, 0 
changed, 0 killed

This morning :
Mar 28 09:08:54 fw5 relayd[46733]: host W.X.Y.Z, check tcp (16010ms,tcp connect 
timeout), state up -> down, availability 99.95%
Mar 28 09:08:54 fw5 relayd[29633]: table _http_vip: 0 added, 1 deleted, 0 
changed, 0 killed

I called the admin in charge of host W.X.Y.Z. What he did on W.X.Y.Z was an
iptables REJECT command on the host (to remove it from relayd). We have tested
with DROP and it seems to not trigger the bug (i'll try to make more tests).

Re: whois ends with core dump

2017-03-28 Thread Theo Buehler 
On Tue, Mar 28, 2017 at 10:34:16AM +0300, Mihai Popescu wrote:
> Hello,
> 
> whois [address] ends with core dump and this message:
> 
> whois(23584) in free(): bogus pointer (double free?) 0xc588e902129
> Abort trap (core dumped)
> 
> The gdb message is this:
> 
> (gdb) core-file whois.core
> Core was generated by `whois'.
> Program terminated with signal 6, Aborted.
> #0  0x0c5ab4dc2a3a in ?? ()
> 
> This is for every address I try to use.
> 
> OpenBSD 6.1-beta (GENERIC.MP) #30: Thu Mar 16 16:39:27 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

this was fixed on Mar 17:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/whois/whois.c#rev1.55

whois ends with core dump

2017-03-28 Thread Mihai Popescu 
Hello,

whois [address] ends with core dump and this message:

whois(23584) in free(): bogus pointer (double free?) 0xc588e902129
Abort trap (core dumped)

The gdb message is this:

(gdb) core-file whois.core
Core was generated by `whois'.
Program terminated with signal 6, Aborted.
#0  0x0c5ab4dc2a3a in ?? ()

This is for every address I try to use.

OpenBSD 6.1-beta (GENERIC.MP) #30: Thu Mar 16 16:39:27 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8029429760 (7657MB)
avail mem = 7781400576 (7420MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeebc0 (57 entries)
bios0: vendor LENOVO version "9VKT33AUS" date 09/11/2013
bios0: LENOVO 1990RZ2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC TCPA MCFG SLIC MCFG HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4)
PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4)
PE20(S4) PE21(S4) PE22(S4) PE23(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II X2 B26 Processor, 3192.42 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: TSC frequency 3192422470 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II X2 B26 Processor, 3192.02 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimcfg1 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus -1 (PCE4)
acpiprt5 at acpi0: bus -1 (PCE5)
acpiprt6 at acpi0: bus -1 (PCE6)
acpiprt7 at acpi0: bus -1 (PCE7)
acpiprt8 at acpi0: bus -1 (PCE9)
acpiprt9 at acpi0: bus -1 (PCEA)
acpiprt10 at acpi0: bus 2 (P0PC)
acpiprt11 at acpi0: bus 3 (PE20)
acpiprt12 at acpi0: bus -1 (PE21)
acpiprt13 at acpi0: bus -1 (PE22)
acpiprt14 at acpi0: bus 4 (PE23)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
"PNP0501" at acpi0 not configured
tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e
acpibtn0 at acpi0: PWRB
cpu0: 3192 MHz: speeds: 3200 2500 1900 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 unknown vendor 0x17aa product 0x9602 rev 0x00
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 4250" rev 0x00
drm0 at radeondrm0
radeondrm0: apic 3 int 18
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 3 int
19, AHCI 1.2
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3
0/direct fixed naa.50014ee1018094dc
sd0: 305245MB, 512 bytes/sector, 625142448 sectors
cd0 at scsibus1 targ 1 lun 0:  ATAPI
5/cdrom removable
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 3 int
18, version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev
2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 3 int
18, version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "ATI EHCI root hub" rev
2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling
iic0 at piixpm0
spdmem0 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr