strange behaviour with pkg_add -z

2014-03-06 Thread Comète

Hi,

i need to script some packages install, so i tried to use pkg_add -z 
option like this:


pkg_add -vzI python-idle-2

python-idle-2.7.5p0: ok
--- +python-idle-2.7.5p0 ---
If you want to use this package as your default system idle, as root
create symbolic links like so (overwriting any previous default):
ln -sf /usr/local/bin/idle2.7 /usr/local/bin/idle
Packages with signatures: 1

So it seems to work, but when i give another try with:

pkg_add -vzI python-idle-3
Ambiguous: python-idle-3 could be python-idle-2.7.5p0 
python-idle-3.3.2p0


So i don't really understand why i doesn't work with '-3'...
After deleting 'python-idle', i tried again to install python-idle-3 
first and... same problem.


I tried with 'python' package too without success.

So it seems that only a command like 'pkg_add -vzI mypackage-2' will 
work.


Is it a bug or simply something i didn't understand ?

Thanks

Morgan



Re: strange behaviour with pkg_add -z

2014-03-06 Thread Marc Espie
On Thu, Mar 06, 2014 at 09:59:07AM +0100, Comète wrote:
 Hi,
 
 i need to script some packages install, so i tried to use pkg_add -z
 option like this:
 
 pkg_add -vzI python-idle-2
 
 python-idle-2.7.5p0: ok
 --- +python-idle-2.7.5p0 ---
 If you want to use this package as your default system idle, as root
 create symbolic links like so (overwriting any previous default):
 ln -sf /usr/local/bin/idle2.7 /usr/local/bin/idle
 Packages with signatures: 1
 
 So it seems to work, but when i give another try with:
 
 pkg_add -vzI python-idle-3
 Ambiguous: python-idle-3 could be python-idle-2.7.5p0
 python-idle-3.3.2p0
 
 So i don't really understand why i doesn't work with '-3'...
 After deleting 'python-idle', i tried again to install python-idle-3
 first and... same problem.
 
 I tried with 'python' package too without success.
 
 So it seems that only a command like 'pkg_add -vzI mypackage-2' will
 work.
 
 Is it a bug or simply something i didn't understand ?

It's a limitation, not a bug. 3 doesn't look like anything in particular to
pkg_add.  It's more likely to converge with a real version number, like
pkg_add -z python-idle-3.3.0  ought to work better.



Re: [patch] vmstat(8) usage

2014-03-06 Thread Jason McIntyre
On Mon, Mar 03, 2014 at 04:03:08PM +, Jason McIntyre wrote:
 On Sat, Mar 01, 2014 at 09:34:10PM +0100, Denis Fondras wrote:
  Hi all,
  
  I've just discovered that OpenBSD vmstat(8) can use wait and count
  arguments without using -c/-w. Here is a small patch to mention this
  usage in the manual :
  
  Regards,
  Denis
  
  --- vmstat.8.orig   Sun Feb 23 15:50:17 2014
  +++ vmstat.8Sun Feb 23 15:54:24 2014
  @@ -45,6 +45,11 @@
   .Op Fl N Ar system
   .Op Fl w Ar wait
   .Op Ar disk ...
  +.Nm vmstat
  +.Op Ar wait Op Ar count
  +.Op Fl M Ar core
  +.Op Fl N Ar system
  +.Op Ar disk ...
   .Sh DESCRIPTION
   .Nm
   reports certain kernel statistics kept about process, virtual memory,
  
 
 hi. i don;t much like adding another synopsis for this. it's just makes
 it more complicated, without adding much.
 
 i note usage() and SYNOPSIS are already out of sync here ;( i had no
 idea we had split synopsis up this way.
 
 i guess, properly, we should somehow show stuff like: [[-c] count]
 or just reword the description of the options to say under which
 circumstances it's optional.
 
 and looking at BUGS:
 
  This manual page lacks an incredible amount of detail.
 
 we could just paste this into all our pages ;)
 
 before doing anything, i'd like to ask if anyone knows of a reason why
 we wouldn;t document this, or the history of when this was added?
 
 i'll think on it a bit more.
 
 jmc

no one has replied, so i'll just say i don;t want to do this. i already
dislike that we've split SYNOPSIS into two forms (where neither freebsd or
netbsd have), and i don;t see a third form adding much. and i don;t see
a way to add this to SYNOPSIS correctly without adding a third form ;)

i think trying to document it is just going to make for more confusing
text.

think of it as a trick that only you know!

sorry,
jmc



Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Dmitrij D. Czarkoff
Hello!

I have a strange problem. Recently I added following to my /etc/fstab:

  /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0

I can't mount this partition using mount -a:

  $ sudo mount -a
  mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs

The same message appears on boot. Still, I can mount it by hand:

  $ sudo mount /mnt/arch
  $ mount
  /dev/sd0a on / type ffs (local)
  /dev/sd0d on /home type ffs (local, nodev, nosuid)
  /dev/sd0i on /mnt/arch type ext2fs (local, nodev, noexec, nosuid)

The partition is actually of type 0x83, and the first 2 Mb of disk were
zero-outed before Linux and OpenBSD were installed. If it is of any
importance, the system is Lenovo ThinkPad E325, and the Linux partition
contains working, bootable Archlinux installation. Bootloader is
Syslinux.

I'm running OpenBSD-current from snapshots, updating every several days.
First time I tried it was probably about a week ago and it consistently
keeps behaving the same.


==
  Fdisk
==

Disk: sd0   geometry: 38913/255/63 [625142448 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
*0: 83  0  32  33 -   6527  53  54 [2048:   104857600 ] Linux files*
 1: A6   6527  53  55 -  38912 254  63 [   104859648:   520277697 ] OpenBSD 
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 3: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  


==
  Disklabel
==

# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: ST320LT007-9ZV14
duid: d02babcb5f5d80c4
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
boundstart: 104859648
boundend: 625137345
drivedata: 0 

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  a: 33556384104859648  4.2BSD   2048 163841 # /
  b:  8385938138416032swap   # none
  c:6251424480  unused   
  d:478335360146801984  4.2BSD   4096 327681 # /home
  i:104857600 2048NTFS   # /mnt/arch


==
  Dmesg
==

OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3849388032 (3671MB)
avail mem = 3738304512 (3565MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9d00 (58 entries)
bios0: vendor LENOVO version 8SET33WW (1.15 ) date 11/17/2011
bios0: LENOVO 12972UG
acpi0 at bios0: rev 4
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI
acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S3) EHC1(S3) 
OHC2(S3) SBAZ(S4) GEC_(S4) P2P_(S5) SPB0(S4) SPB1(S4) SPB2(S4) SPB3(S4) LID_(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD E-450 APU with Radeon(tm) HD Graphics, 1647.48 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,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
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, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD E-450 APU with Radeon(tm) HD Graphics, 1646.49 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,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2

Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Ted Unangst
On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote:
 Hello!
 
 I have a strange problem. Recently I added following to my /etc/fstab:
 
   /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0
 
 I can't mount this partition using mount -a:
 
   $ sudo mount -a
   mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs

   i:104857600 2048NTFS   # /mnt/arch

Edit the disklabel to say ext2fs?



Re: [patch] vmstat(8) usage

2014-03-06 Thread Ted Unangst
On Sat, Mar 01, 2014 at 21:34, Denis Fondras wrote:
 Hi all,
 
 I've just discovered that OpenBSD vmstat(8) can use wait and count
 arguments without using -c/-w. Here is a small patch to mention this
 usage in the manual :

This is a holdover from olden days. If I could kill it, I would, so
maybe best not to rely on it.



Re: [patch] vmstat(8) usage

2014-03-06 Thread Theo de Raadt
 On Sat, Mar 01, 2014 at 21:34, Denis Fondras wrote:
  Hi all,
  
  I've just discovered that OpenBSD vmstat(8) can use wait and count
  arguments without using -c/-w. Here is a small patch to mention this
  usage in the manual :
 
 This is a holdover from olden days. If I could kill it, I would, so
 maybe best not to rely on it.

That's right.

Back in the grand old days when the CSRG guys would regularily join
in the drum circle at the edge of UCB campus, argv handling was still
very different from program to program, and getopt() was still young.

If you dig around, you'll find quite a few commands with hidden arguments
like this, and most have Berkeley origins.  The most common ones are so
familiar that they cannot be removed, there are even a few cases of POSIX
bending over backwards to admit they exist.

A good example is ps(1).  You don't need the '-'.



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Kenneth Westerback
On 6 March 2014 12:49, Dmitrij D. Czarkoff czark...@gmail.com wrote:
 Hello!

 I have a strange problem. Recently I added following to my /etc/fstab:

   /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0

 I can't mount this partition using mount -a:

   $ sudo mount -a
   mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs

 The same message appears on boot. Still, I can mount it by hand:

   $ sudo mount /mnt/arch
   $ mount
   /dev/sd0a on / type ffs (local)
   /dev/sd0d on /home type ffs (local, nodev, nosuid)
   /dev/sd0i on /mnt/arch type ext2fs (local, nodev, noexec, nosuid)

 The partition is actually of type 0x83, and the first 2 Mb of disk were
 zero-outed before Linux and OpenBSD were installed. If it is of any
 importance, the system is Lenovo ThinkPad E325, and the Linux partition
 contains working, bootable Archlinux installation. Bootloader is
 Syslinux.

 I'm running OpenBSD-current from snapshots, updating every several days.
 First time I tried it was probably about a week ago and it consistently
 keeps behaving the same.


 ==
   Fdisk
 ==

 Disk: sd0   geometry: 38913/255/63 [625142448 Sectors]
 Offset: 0   Signature: 0xAA55
 Starting Ending LBA Info:
  #: id  C   H   S -  C   H   S [   start:size ]
 ---
 *0: 83  0  32  33 -   6527  53  54 [2048:   104857600 ] Linux 
 files*
  1: A6   6527  53  55 -  38912 254  63 [   104859648:   520277697 ] OpenBSD
  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
  3: 00  0   0   0 -  0   0   0 [   0:   0 ] unused


 ==
   Disklabel
 ==

 # /dev/rsd0c:
 type: SCSI
 disk: SCSI disk
 label: ST320LT007-9ZV14
 duid: d02babcb5f5d80c4
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 38913
 total sectors: 625142448
 boundstart: 104859648
 boundend: 625137345
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a: 33556384104859648  4.2BSD   2048 163841 # /
   b:  8385938138416032swap   # none
   c:6251424480  unused
   d:478335360146801984  4.2BSD   4096 327681 # /home
   i:104857600 2048NTFS   # /mnt/arch

Your disklabel seems to have NTFS down as the file system for 'i'.
Which might explain the error and inconsistant behaviour. This may be
an old disklabel, since zero'ing out the first 2MB doesn't look like
it would have reached the OpenBSD partition where the disklabel would
be stored.

I created an MBR with partition 0 of type 0x83, and disklabel here
spoofs that correctly to 'ext2fs'.

What does 'disklabel -d sd0' show?

 Ken



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Dmitrij D. Czarkoff
Ted Unangst said:
 On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote:
  Hello!
  
  I have a strange problem. Recently I added following to my /etc/fstab:
  
/dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0
  
  I can't mount this partition using mount -a:
  
$ sudo mount -a
mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs
 
i:104857600 2048NTFS   # /mnt/arch
 
 Edit the disklabel to say ext2fs?

I was under impression that fdisk edits MBR partitions and disklabel
only edits BSD labels. Anyway:

  $ sudo disklabel -E sd0
  Label editor (enter '?' for help at any prompt)
   p
  OpenBSD area: 104859648-625137345; size: 520277697; free: 15
  #size   offset  fstype [fsize bsize  cpg]
a: 33556384104859648  4.2BSD   2048 163841 # /
b:  8385938138416032swap   # none
c:6251424480  unused   
d:478335360146801984  4.2BSD   4096 327681 # /home
i:104857600 2048NTFS   #
  /mnt/arch
   m i
  offset: [2048] 
  The offset must be = 104859648 and  625137345, the limits of the
  OpenBSD portion
  of the disk. The 'b' command can change these limits.
  

Any other ideas?

-- 
Dmitrij D. Czarkoff



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Kenneth Westerback
On 6 March 2014 13:23, Dmitrij D. Czarkoff czark...@gmail.com wrote:
 Ted Unangst said:
 On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote:
  Hello!
 
  I have a strange problem. Recently I added following to my /etc/fstab:
 
/dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0
 
  I can't mount this partition using mount -a:
 
$ sudo mount -a
mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs

i:104857600 2048NTFS   # 
  /mnt/arch

 Edit the disklabel to say ext2fs?

 I was under impression that fdisk edits MBR partitions and disklabel
 only edits BSD labels. Anyway:

   $ sudo disklabel -E sd0
   Label editor (enter '?' for help at any prompt)
p
   OpenBSD area: 104859648-625137345; size: 520277697; free: 15
   #size   offset  fstype [fsize bsize  cpg]
 a: 33556384104859648  4.2BSD   2048 16384 1 # /
 b:  8385938138416032swap   # none
 c:6251424480  unused
 d:478335360146801984  4.2BSD   4096 327681 # /home
 i:104857600 2048NTFS   #
   /mnt/arch
m i
   offset: [2048]
   The offset must be = 104859648 and  625137345, the limits of the
   OpenBSD portion
   of the disk. The 'b' command can change these limits.
   

 Any other ideas?

delete the partition 'i'. You don't need it, as it will be
automatically created when necessary.

 Ken


 --
 Dmitrij D. Czarkoff



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Dmitrij D. Czarkoff
Kenneth Westerback said:
 delete the partition 'i'. You don't need it, as it will be
 automatically created when necessary.

Thanks!

Apparently it wasn't re-created automatically, but I could rebuild my
disklabel using disklabel -dE sd0, so now it works as expected.

-- 
Dmitrij D. Czarkoff



Re: IPSec Packet Loss Help

2014-03-06 Thread Zach Leslie
On Wed, Mar 05, 2014 at 11:05:11PM -0600, Amit Kulkarni wrote:
  If PF information is needed, I can provide and obscure, but I didn't
  expect it to be
  the issue.
 
 
 i am no expert on this. but if it is a packet loss issue, you need to post
 the obscured pf.conf

Fair point.  I've not seen any related dropped packets due to PF with
tcpdump -nei pflog0, so I didn't think it would be related to PF.

Not line-wrapped for readability.

match out on em0 from ! (em0:network) to any nat-to (em0:0)
block drop in log all
pass out all flags S/SA
pass out on em0 proto tcp all flags S/SA modulate state
pass in proto icmp from routed_networks to routed_networks
pass in proto ipv6-icmp from routed_networks to routed_networks
pass in from routed_networks to ! routed_networks flags S/SA
pass in from routed_networks to any flags S/SA
pass in proto udp from routed_networks to dns_servers port = 53
pass out on em0 proto udp all
pass out on em0 proto icmp all
pass on em0 inet proto carp all
pass on em0 proto icmp from any to (em0:network)
pass on em1 inet proto pfsync all
pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 500
pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 4500
pass in on em0 inet proto esp from 66.77.88.10 to 1.2.3.5
pass in on enc0 inet proto ipencap from 66.77.88.10 to 1.2.3.5 keep state 
(if-bound)
pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 500
pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 4500
pass out on em0 inet proto esp from 1.2.3.5 to 66.77.88.10
pass out on enc0 inet proto ipencap from 1.2.3.5 to 66.77.88.10 keep state 
(if-bound)
pass out on enc0 inet from 1.2.3.5 to pdx_nets flags S/SA keep state 
(if-bound)
pass out on enc0 from opdx_nets to pdx_nets flags S/SA keep state (if-bound)
pass in on enc0 from pdx_nets to opdx_nets flags S/SA keep state (if-bound)
pass in on enc0 inet from 66.77.88.10 to opdx_nets flags S/SA keep state 
(if-bound)
pass in on em0 inet proto tcp from 66.77.88.17 to any port = 22 flags S/SA
pass in on em0 inet proto tcp from 1.2.3.7 to 1.2.3.6 port = 500 flags S/SA

This morning as a test, I've disabled isakmpd sync feature, and shutdown
sasycnd on all firewalls, as well as isakmpd on the secondaries at each
location and the connection seems to be much improved.  I've not lost
any connections in the last 4 hours which is much improved.

Not sure if sasyncd is actually causing the issue, but disabling it
to gain an improved connections certainly doesn't seem great from an HA
standpoint.

I've also got a couple static routes in the inet table that point the
remote network to the internal carp address for routing purposes.  This
allows the traffic generated by the secondary firewall to reach the
remote network due to the fact that the secondary does not hold the
master status of the carp, and therfore can't use the IPSec directly.

I do wonder though, since I also have a flow for the same network, the
encap and inet routing table have a route for the same network.  Which
takes priority?  Just something to point out since it could be causing
troubles.

Regards,

-- 
Zach



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Alexander Hall
On March 6, 2014 7:23:50 PM CET, Dmitrij D. Czarkoff czark...@gmail.com 
wrote:
Ted Unangst said:
 On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote:
  Hello!
  
  I have a strange problem. Recently I added following to my
/etc/fstab:
  
/dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0
  
  I can't mount this partition using mount -a:
  
$ sudo mount -a
mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs
 
i:104857600 2048NTFS   #
/mnt/arch
 
 Edit the disklabel to say ext2fs?

I was under impression that fdisk edits MBR partitions and disklabel
only edits BSD labels. Anyway:

  $ sudo disklabel -E sd0
  Label editor (enter '?' for help at any prompt)
   p
  OpenBSD area: 104859648-625137345; size: 520277697; free: 15
  #size   offset  fstype [fsize bsize  cpg]
a: 33556384104859648  4.2BSD   2048 163841 # /
  b:  8385938138416032swap   # none
c:6251424480  unused   
 d:478335360146801984  4.2BSD   4096 327681 # /home
i:104857600 2048NTFS   #
  /mnt/arch
   m i
  offset: [2048] 
  The offset must be = 104859648 and  625137345, the limits of the
  OpenBSD portion
  of the disk. The 'b' command can change these limits.
  

Any other ideas?

Read the error message you just posted?

/Alexander



Re: IPSec Packet Loss Help

2014-03-06 Thread Andy Lemin
Hi, haven't read your original email but if my assumptions about your setup are 
correct is the VPN tunnel dropping every now and then?

I had a similar issue with 4 OBSD firewalls (2 at each end), all running 
isakmpd and sasyncd to keep the SAs in sync between a pair. With the tunnels 
explicitly set to use the CARP IPs as endpoints.

You need the static route to point to the internal interface to make sure that 
packets generated by the firewall itself have a source IP set to the internal 
net thus allowing the IPSec policy route to be used (as it defines both the 
source and dest net, not just the dest net like a normal route).

However whilst pinging the remote net from the live firewall works, I found 
that if you try and ping the remote net from the backup firewall, the packet 
does *not* get routed to the CARP master (why would it!). The IPSec route is 
there..

The backup firewall encaps the packet and sends it out its own external 
interface using the dets from sasyncd, but the master firewall at the other end 
will see the packet as coming from 'another' box with the same details but not 
the full correct policy and so the tunnel is blocked for a period until the 
master renegotiates it.

We had to modify all our monitoring scripts to not 'phone home' if the box is a 
backup. Only the master firewall can use the VPN.

I also submitted some suggested modifications to /etc/rc.d/sasyncd and 
/etc/rc.d/isakmpd here in the past which makes the setup and failover of VPNs 
much faster and more stable.

Can dig out if you can't find them.

Cheers, Andy

Sent from my iPhone

 On 6 Mar 2014, at 19:00, Zach Leslie xaque...@gmail.com wrote:
 
 On Wed, Mar 05, 2014 at 11:05:11PM -0600, Amit Kulkarni wrote:
 If PF information is needed, I can provide and obscure, but I didn't
 expect it to be
 the issue.
 
 i am no expert on this. but if it is a packet loss issue, you need to post
 the obscured pf.conf
 
 Fair point.  I've not seen any related dropped packets due to PF with
 tcpdump -nei pflog0, so I didn't think it would be related to PF.
 
 Not line-wrapped for readability.
 
 match out on em0 from ! (em0:network) to any nat-to (em0:0)
 block drop in log all
 pass out all flags S/SA
 pass out on em0 proto tcp all flags S/SA modulate state
 pass in proto icmp from routed_networks to routed_networks
 pass in proto ipv6-icmp from routed_networks to routed_networks
 pass in from routed_networks to ! routed_networks flags S/SA
 pass in from routed_networks to any flags S/SA
 pass in proto udp from routed_networks to dns_servers port = 53
 pass out on em0 proto udp all
 pass out on em0 proto icmp all
 pass on em0 inet proto carp all
 pass on em0 proto icmp from any to (em0:network)
 pass on em1 inet proto pfsync all
 pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 500
 pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 4500
 pass in on em0 inet proto esp from 66.77.88.10 to 1.2.3.5
 pass in on enc0 inet proto ipencap from 66.77.88.10 to 1.2.3.5 keep state 
 (if-bound)
 pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 500
 pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 4500
 pass out on em0 inet proto esp from 1.2.3.5 to 66.77.88.10
 pass out on enc0 inet proto ipencap from 1.2.3.5 to 66.77.88.10 keep state 
 (if-bound)
 pass out on enc0 inet from 1.2.3.5 to pdx_nets flags S/SA keep state 
 (if-bound)
 pass out on enc0 from opdx_nets to pdx_nets flags S/SA keep state 
 (if-bound)
 pass in on enc0 from pdx_nets to opdx_nets flags S/SA keep state 
 (if-bound)
 pass in on enc0 inet from 66.77.88.10 to opdx_nets flags S/SA keep state 
 (if-bound)
 pass in on em0 inet proto tcp from 66.77.88.17 to any port = 22 flags S/SA
 pass in on em0 inet proto tcp from 1.2.3.7 to 1.2.3.6 port = 500 flags S/SA
 
 This morning as a test, I've disabled isakmpd sync feature, and shutdown
 sasycnd on all firewalls, as well as isakmpd on the secondaries at each
 location and the connection seems to be much improved.  I've not lost
 any connections in the last 4 hours which is much improved.
 
 Not sure if sasyncd is actually causing the issue, but disabling it
 to gain an improved connections certainly doesn't seem great from an HA
 standpoint.
 
 I've also got a couple static routes in the inet table that point the
 remote network to the internal carp address for routing purposes.  This
 allows the traffic generated by the secondary firewall to reach the
 remote network due to the fact that the secondary does not hold the
 master status of the carp, and therfore can't use the IPSec directly.
 
 I do wonder though, since I also have a flow for the same network, the
 encap and inet routing table have a route for the same network.  Which
 takes priority?  Just something to point out since it could be causing
 troubles.
 
 Regards,
 
 -- 
 Zach



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Kenneth Westerback
On 6 March 2014 13:59, Dmitrij D. Czarkoff czark...@gmail.com wrote:
 Kenneth Westerback said:
 delete the partition 'i'. You don't need it, as it will be
 automatically created when necessary.

Something would have been added. Again, the output of
'disklabel -d sd0' would be useful.

 Ken


 Thanks!

 Apparently it wasn't re-created automatically, but I could rebuild my
 disklabel using disklabel -dE sd0, so now it works as expected.

 --
 Dmitrij D. Czarkoff



Re: prices of cdset in eu

2014-03-06 Thread Stijn

On 3/03/2014 22:59, Peter N. M. Hansteen wrote:

Axel Scheepers axel.scheep...@xs4all.nl writes:


Can anyone tell me about the difference in price regarding a cdset in EU?

original ca $50   36.41 (CA)
mensys eur 50,- vat incl. 60.50 (NL)
comcol.nl same as mensys, 60,50 (NL)
getdigital(de)39,00 (DE)
lehmanns media39,95 (DE)

My guess is that the differences between the EU outlets comes in apart
at least from the size of batches they order -- larger orders get
discounts.

I've tended to order from the CA one unless early copies have turned
up at a conference I've been to and I hadn't gotten around to order
yet.  And I suppose there is a better range T-shirts and other related
mercandise if you order from there.

I've had a few of the packages from Canada stopped for extra customs
inspection (with an aditional fee, of course), but it's been a while
since that happened. That in turn could mean the Norwegian customs
organization are actually learning to spend their resources wisely.

- Peter
Looks like those customs guys moved to Belgium... :( I never had issues 
with customs before until now. Now they want to charge me 86€ on taxes 
on a shipment of 240€! Though luck guys, I'm not paying that. I rather 
send 86€ to the project so I'm sure the money is used for something useful.


PS: For those ordering stuff in the Computer Shop from Belgium: keep the 
total cost below 150€. Below 150€ they only charge you 12€ for 
administrative costs + 21% VAT on the whole package price (or they 
don't charge you at whole like I had with all my previous shipments). 
For shipments above 150€ (first time for me) they charge you 30€ +21% VAT.


HTH,
Stijn



Re: prices of cdset in eu

2014-03-06 Thread Ingo Schwarze
Hi,

as you are in Europe, you might also consider this online shop:

  http://openbsdeurope.com/

It's not associated with the project, but so far worked reliably
for me.  Shipping to Germany, they charged me 39.75 Pound Sterling
including Taxes and shipping for one 5.4 CD, which ended up as
46.76 Euro grand total on my credit card including bank fees.
That seemed more or less reasonable to me.

It doubt it will be much different in Belgium, given that Germany
and Belgium are both in the EU.

Of course, an additional donation using the usual channels is
always welcome.  :-)

Yours,
  Ingo



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Alexander Hall

[cc:ing misc@ for the archives]

On 03/06/14 21:29, Dmitrij D. Czarkoff wrote:

Alexander Hall said:

  The offset must be = 104859648 and  625137345, the limits of the
  OpenBSD portion
  of the disk. The 'b' command can change these limits.
  

Any other ideas?


Read the error message you just posted?


I thought that bounds of BSD label should correspond to MBR partition
holding such label.  Am I wrong?  At least disklabel(8) warns against
extending them beyond this limit.


Normally, yes, and those bounds are what you are experiencing.

However, to be able to reach disk areas lying outside the A6 partition 
(in this case, the ext2fs partition) from within OpenBSD, it needs to be 
mapped to a partition in the disklabel. Therefore you need to circumvent 
those bounds using the suggested 'b' command.


Unless you, as noted, started over with a default disklabel, which will 
automatically set up disklabel partitions for some (but not all IIRC) 
external fdisk entries, starting from i: and up.


/Alexander



Re: Linux partition appears as ext2 partition in disklabel

2014-03-06 Thread Ted Unangst
On Thu, Mar 06, 2014 at 23:06, Alexander Hall wrote:
 I thought that bounds of BSD label should correspond to MBR partition
 holding such label.  Am I wrong?  At least disklabel(8) warns against
 extending them beyond this limit.

Of course. If you start using some other operating system's space for
OpenBSD, you're going to write over that other system's data. In this
case, that's exactly what you want.



Re: IPSec Packet Loss Help

2014-03-06 Thread Zach Leslie
On Thu, Mar 06, 2014 at 08:16:34PM +, Andy Lemin wrote:
 Hi, haven't read your original email but if my assumptions about your setup 
 are correct is the VPN tunnel dropping every now and then?

Thats correct.  Daemons start up quick, negotiations happen, and then
periodically the tunnel is just not available, despite the SAs being
available on the masters and the slaves.  Disabling -S on isakmpd and
turning off sasyncd makes the tunnel stay up for much longer, 7 hours
and counting.

 You need the static route to point to the internal interface to make sure 
 that packets generated by the firewall itself have a source IP set to the 
 internal net thus allowing the IPSec policy route to be used (as it defines 
 both the source and dest net, not just the dest net like a normal route).

This I have, and packets flow.  Still unclear about which route takes
precedence, encap or inet.

 We had to modify all our monitoring scripts to not 'phone home' if the box is 
 a backup. Only the master firewall can use the VPN.

I've ended up monitoring the host using internal interface, which in
turn tells me the tunnel is available.

 I also submitted some suggested modifications to /etc/rc.d/sasyncd and 
 /etc/rc.d/isakmpd here in the past which makes the setup and failover of VPNs 
 much faster and more stable.

I did see those scripts, though they seem to be more solving the startup
time of the daemons.  My issue is more keeping the service up than start
time.

It sounds like your setup is similar to my own.  You don't see theses
kinds of instability using sasyncd?  If you have a look at my OP, the
sasyncd.conf is in there.  Its possible I have a configuration error,
but just reading over the manpage again, I don't know what it would be.

This is really troubling me.

-- 
Zach



Re: prices of cdset in eu

2014-03-06 Thread Stijn

On 6/03/2014 22:52, Ingo Schwarze wrote:

Hi,

as you are in Europe, you might also consider this online shop:

   http://openbsdeurope.com/

It's not associated with the project, but so far worked reliably
for me.  Shipping to Germany, they charged me 39.75 Pound Sterling
including Taxes and shipping for one 5.4 CD, which ended up as
46.76 Euro grand total on my credit card including bank fees.
That seemed more or less reasonable to me.

It doubt it will be much different in Belgium, given that Germany
and Belgium are both in the EU.

Of course, an additional donation using the usual channels is
always welcome.  :-)

Yours,
   Ingo

Yeah, I know about them, but they didn't had the 2.x CD's I was still 
lacking...


G,
Stijn



Re: ypldap 1024 character limit on groups?

2014-03-06 Thread Israel Brewster
On Mar 3, 2014, at 3:14 PM, Israel Brewster isr...@eraalaska.net wrote:

 I am working on setting up my OpenBSD 5.2 box to connect to my company LDAP
 server (Mac OS X 10.8.5 OpenDirectory). I have successfully installed
 login_ldap from ports and configured ypldap and the login.conf file such
that
 I can now authenticate as any of my ldap users. However, when ypldap pulls
in
 the group membership information from my LDAP server, it appears to be
cutting
 off the group membership listing at 1024 characters. The end result is that
 only about half of my users are actually showing up as members of the
 appropriate group(s). I have confirmed this not only by behavior (sftp is
not
 chrooted for some users even though I have the proper entries to match the
 group in sshd_conf), but also by using the userinfo command: userinfo for a
 user that shows up in the first 1024 characters of the group membership
 listing properly shows the user as a member of the group. userinfo for a
user
 that does not show up in the first 1024 characters show the user as only
being
 part of the default group (staff in this case). How can I get ypldap to
show
 the full member listing?
 ---
 Israel Brewster
 Computer Support Technician II
 Era Alaska
 5245 Airport Industrial Rd
 Fairbanks, AK 99709
 (907) 450-7250 x7293
 ---


I was thinking: is there any chance this is due to a problem with the Apple
OpenDirectory LDAP, and not with ypldap? When I use a LDAB browser such as
explorer, it shows all the groups, but perhaps it works differently. Any
suggestions would be appreciated, as right now the LDAP binding is useless,
and if I can't get this working I'll have to start over on a different OS
where I can make this work - which will not be fun :-(. Thanks.

---
Israel Brewster
Computer Support Technician II
Era Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7250 x7293
---

[demime 1.01d removed an attachment of type text/directory which had a name of 
Israel Brewster.vcf]



Re: ypldap 1024 character limit on groups?

2014-03-06 Thread Philip Guenther
On Mon, Mar 3, 2014 at 4:14 PM, Israel Brewster isr...@eraalaska.net wrote:
 I am working on setting up my OpenBSD 5.2 box to connect to my company LDAP
 server (Mac OS X 10.8.5 OpenDirectory). I have successfully installed
 login_ldap from ports and configured ypldap and the login.conf file such that
 I can now authenticate as any of my ldap users. However, when ypldap pulls in
 the group membership information from my LDAP server, it appears to be cutting
 off the group membership listing at 1024 characters. The end result is that
 only about half of my users are actually showing up as members of the
 appropriate group(s). I have confirmed this not only by behavior (sftp is not
 chrooted for some users even though I have the proper entries to match the
 group in sshd_conf), but also by using the userinfo command: userinfo for a
 user that shows up in the first 1024 characters of the group membership
 listing properly shows the user as a member of the group. userinfo for a user
 that does not show up in the first 1024 characters show the user as only being
 part of the default group (staff in this case). How can I get ypldap to show
 the full member listing?

The 1024 byte limit is hardcoded in libc's getgr* routines.

/usr/src/lib/libc/gen/getgrent.c:#defineMAXLINELENGTH   1024
/usr/src/lib/libc/gen/getgrouplist.c:#define MAXLINELENGTH  1024

Increasing those would also require an increase to grp.h's _GR_BUF_LEN
and possibly other places in the tree.  Not tested: good luck!


Philip Guenther



Re: NAT reliability in light of recent checksum changes

2014-03-06 Thread Richard Procter
On 27/02/2014, at 11:04 AM, Theo de Raadt wrote:
 
 There was a method of converting an in-bound checksum, due to NAT
 conversion, into a new out-bound checksum.  A process is required,
 it's how NAT works.
 
 A new method of version is being used.  It is mathematically equivelant
 to the old method.

First, I agree with Theo that modifying a checksum is
mathematically equivalent to regenerating it; both give the same
result on ideal hardware.

Of course, we use checksums because our hardware isn't ideal, so
let's look at how the two approaches differ when a router 
fault occurs.

Take Stuart Henderson's example:

 Consider this scenario, which has happened in real life.
 
 - NIC supports checksum offloading, verified checksum is OK.
 
 - PCI transfers are broken (in my case it affected multiple
 machines of a certain type, so most likely a motherboard bug),
 causing some corruption in the payload, but the machine won't
 detect them because it doesn't look at checksums itself, just
 trusts the NIC's rx csum good flag.
 
 In this situation, packets which have been NATted that are
 corrupt now get a new checksum that is valid; so the final
 endpoint can not detect the breakage.

That is, when the router offloads and regenerates, the router's
egress NIC will hide any card, stack, bus or memory fault a
verified packet suffered in passing through the router when it
regenerates a new checksum from the now corrupt data.

Looking at the code, the relevant functions are
pf.c:pf_check_proto_cksum(), which trusts the ingress NIC's
checksum good flag, and pf.c:pf_cksum(), which zeros the existing
checksum on that basis and flags it to be regenerated by the
egress NIC[1].

By contrast, checksum modification is far more reliable. In order
to hide payload corruption the update code[1] would have to
modify the checksum to exactly account for it. But that would
have to happen by accident --- by a fault that in effect computes
the necessary change --- as the update code never considers the
payload[0]. It's not impossible but, on the other hand,
checksum regeneration guarantees to hide faults in the
regenerating router. 

We conclude that in the typical offloading case, regenerated
checksums, unlike modified ones, cannot detect faults in the
regenerating routers. 

Whether this difference is significant is a matter 
of judgment and a separate issue.

I've some ideas about solutions but will leave those for 
another email.

best, 
Richard. 

PS. I find the following terminology helpful:

Checksums calculated from the origin data are 'original';
checksums calculated from a copy are 'regenerated'.

Checksums may also be 'modified' to account for altered data in
such a way as to preserve originality for any unaltered data[0].

A checksum is 'end-to-end' if it is delivered original with
respect to the payload. A modified checksum may be end-to-end but
never a regenerated checksum as it is not original.

[0] Strikingly, RFC1631 (1994) and RFC3022 (2001), the NAT RFCs, 
fail to say end-to-end preservation is a property of their checksum 
modification algorithm. I presume it just didn't seem worth 
mentioning as, lacking hardware offload back then, one wouldn't 
regenerate in software on performance grounds alone. It is only 
alluded to in RFC1071 (1988) Computing the Internet Checksum, 
which states that a checksum remains end-to-end when modified 
'since it was not fully recomputed'. Although that's still true 
if NAT modifies it, NAT makes the meaning of 'end-to-end' 
more complex; I think my above terminology helps there. 

[1]
I'll quote OpenBSD code here for completeness, contrasting 
modification (OpenBSD 5.3) with regeneration (OpenBSD 5.4) 

OpenBSD 5.3 NAT modified the checksum as follows: 

--- pf.c 1.818 (OPENBSD_5_3) --- 

Assuming an AF_INET - AF_INET TCP connection. 

pf_test_rule()
3862: pf_translate()
  3881: pf_change_ap()  [ src addr/port ]
 1671: PF_ACPY  [ = pf_addrcpy() ] 
 1689: pf_cksum_fixup(...) 
   [ 
 psuedo code is: 
 sum = fixup(sum, addr16[1]) 
 sum = fixup(sum, addr16[0]) 
 sum = fixup(sum, port) 
   ] 
1662: l = cksum + old - new --- checksum modified 
  [ then presumably account for ones-complement carries ] 
  3887: pf_change_ap() etc [ dst addr/port ] 

On subsequent state matching:  

pf_test()
6788: pf_test_state_tcp() [ for TCP ] 
  4566: pf_change_ap() etc [ for src addr/port ] 
  4574: pf_change_ap() etc [ for dst addr/port ]  

---

OpenBSD 5.4 NAT regenerates checksums as follows: 

--- pf.c 1.863 (post OPENBSD_5_4) --- 

Assuming an AF_INET - AF_INET TCP connection.

On initial rule match: 
pf_test_rule()
3445: pf_translate()
  3707: pf_change_ap()
 1677: PF_ACPY [= pf_addrcpy()] 
3461: pf_cksum()
  6775: pd-hdr.tcp-th_sum = 0; --- checksum zeroed
m-m_pkthdr.csum_flags |= M_TCP_CSUM_OUT --- flagged for recalculation
(if orig checksum good) 

On subsequent state matching: 

OBSD 5.4 and OpenLDAP

2014-03-06 Thread Friedrich Locke
Hi folks!

I would like to setup a OpenLDAP server using OpenBSD and the ports
collection.
I wonder if the current OpenLDAP  in the ports is still broken ?
Do it supports mdb/hdb/bdb ?

Thanks a lot.

gustavo.



Re: OBSD 5.4 and OpenLDAP

2014-03-06 Thread Vijay Sankar

Why do you say it is still broken?

I am running

openldap-client-2.4.35p1 open-source LDAP software (client)
openldap-server-2.4.35p2 open-source LDAP software (server)

on OpenBSD 5.4 without any problems. The package works beautifully,  
works with samba, horde, etc., far better than anything else out  
there. I am using the following:


# Load dynamic backend modules:
modulepath  /usr/local/libexec/openldap
moduleload  back_bdb.la

Quoting Friedrich Locke friedrich.lo...@gmail.com:


Hi folks!

I would like to setup a OpenLDAP server using OpenBSD and the ports
collection.
I wonder if the current OpenLDAP  in the ports is still broken ?
Do it supports mdb/hdb/bdb ?

Thanks a lot.

gustavo.






Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

-
This message was sent using ForeTell-POST 4.9