PF: (max-src-conn 1, max-src-conn-rate 1/1, overload )

[Maxim Bourmistrov]

Hello, 
I’m not part of this maillist, so rply me directly if necessery.
(Sent this pf@ which seems do not exists any more)
 
Following is given in pf.conf:
 
### int
pass in on int from any to any keep state \
        (max-src-conn 1, max-src-conn-rate 1/1, overload  )
pass out on int from any to  keep state \
       (max-src-conn 1, max-src-conn-rate 1/1, overload  )
 
This ever slows down traffic or gives none at all.
Idea is to to track all IOT and connections.
PF ever take to long to process this or even refuses(time out).
 
Rest of rules are old enough to state that those are working.
Above is new modd I’d like to introduce. Not working.
 
Prev. rule: pass on int all keep state. ← working all good.
 
Any one seen this before.
 
Br
//mxb
 
 
--
Maxim
 
--
Maxim

Re: Reboot and re-link

[Maxim Bourmistrov]

Why the f I have old kernel?
The ONE taking care of all sh.

On Thu, 20 Jun 2019 at 22:43, Maxim Bourmistrov 
wrote:

> btw, after reboot, sys converted to 6.4 kernel. yet again
> I removed all /bsd*
> Do I need to rm /usr/obj* as well
>
> On Thu, 20 Jun 2019 at 22:12, Theo de Raadt  wrote:
>
>> Maxim Bourmistrov  wrote:
>>
>> > What is seen in 'top' is what compile does to the sys. snmpd just
>> freacks
>> > out, and the rest as well.
>> > This is VMWare. Storage below is VSAN.
>> > bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here.
>> Private
>> > stuff, no massive peering. No peering at all, except mentioned.
>> > Compile sucks out all rss and I don't think this is OK to have this
>> machine
>> > in line, handling traffic.
>> > If I had only one node, with active connections, I'd say I'm offline
>> while
>> > compile is active.
>>
>> My laptop does the required relink in under 10 seconds.
>>
>> 0m05.54s real 0m03.21s user 0m02.15s system
>>
>> My landisk with 64MB of ram and a 266MHz cpu is a little slow.
>>
>> It's great you have an opinion.  I have a different opinion.
>> Isn't it great we can all have different opinions?
>>
>> Must say, I'm glad I'm not relying on your failing services..
>>
>

Re: Reboot and re-link

[Maxim Bourmistrov]

What is seen in 'top' is what compile does to the sys. snmpd just freacks
out, and the rest as well.
This is VMWare. Storage below is VSAN.
bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here. Private
stuff, no massive peering. No peering at all, except mentioned.
Compile sucks out all rss and I don't think this is OK to have this machine
in line, handling traffic.
If I had only one node, with active connections, I'd say I'm offline while
compile is active.

//mxb

On Thu, 20 Jun 2019 at 13:05, Stuart Henderson  wrote:

> On 2019-06-20, Otto Moerbeek  wrote:
> > On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:
> >
> >> Hey,
> >>
> >> long story short: reboot and re-link is not practical.
> >>
> >> Long story:
> >> Time to upgrade 6.4 to 6.5.
> >> If re-link been active in 6.4 (don't remember) - I never noticed it.
> >> Installing via NOT RECOMMENDED WAY(following upgrade65.html) -
> scripting on
> >> steroides (ansible).
> >> All down. Reboot.
> >> and now I get a SLOW sys - why ?! - compiling new kernel:
> >>
> >> load averages:  3.25,  1.45,  0.60
> >>
> >> 53 processes: 1 running, 49 idle, 3 on processor
> >>
> >>  up  0:04
> >> CPU0 states:  0.0% user,  0.0% nice, 21.0% sys, 63.7% spin,  0.6% intr,
> >> 14.7% idle
> >> CPU1 states:  0.5% user,  0.0% nice, 22.3% sys, 56.2% spin,  0.0% intr,
> >> 20.9% idle
> >> CPU2 states:  0.7% user,  0.0% nice, 71.5% sys, 19.6% spin,  0.0% intr,
> >>  8.3% idle
> >> CPU3 states:  0.5% user,  0.0% nice,  6.3% sys, 63.3% spin,  0.0% intr,
> >> 29.9% idle
> >> Memory: Real: 382M/792M act/tot Free: 1177M Cache: 310M Swap: 0K/1279M
> >>
> >>   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU
> COMMAND
> >> 51958 _snmpd640  956K 3148K run/0 - 3:25 119.87%
> snmpd
> >> 17683 root  640  166M  174M onproc/2  - 3:10 99.41% ld
> >> 59133 root   20 1404K 4248K sleep/0   select0:08 16.70% sshd
> >> 39714 root  180  908K  988K sleep/1   pause 0:05 12.55% ksh
> >> 69806 _tor   20   29M   41M sleep/3   kqread0:28  8.15% tor
> >> 56629 _pflogd40  744K  576K sleep/3   bpf   0:19  7.57%
> pflogd
> >> 92193 _iscsid20  732K 1256K sleep/3   kqread0:15  4.64%
> iscsid
> >>   288 _squid 20   17M   14M sleep/0   kqread0:11  4.00%
> squid
> >> 53448 _lldpd 20 2656K 3848K sleep/3   kqread0:07  3.32%
> lldpd
> >> 42939 _syslogd   20 1108K 1692K sleep/3   kqread0:03  1.66%
> syslogd
> >>  2842 _bgpd 100 1172K 1896K onproc/1  - 0:03  1.46% bgpd
> >>
> >>
> >> I don't think THIS IS OK.
> >> I'm lucky - secondary (but, if ONLY primary??)
> >>
> >>
> >> For whatever reason, after rebooting, I got back 6.4 kernel.
> >> (I'd like to here some great explanation here and MORE around the
> )
> >
> > Why not investigate why your system is slow? To me it looks like at
> > least snmpd is having a problem. The ld will disappear at some point.
>
> Depends on what bgpd is being used for, but there's a high chance snmpd is
> churning while bgpd adds new routes. If so then try "filter-routes yes" in
> snmpd.conf.
>
> But there are certainly some situations where the relinking is very slow
> and a major resource drain indeed. On this system there's plenty of RAM
> so maybe just slow disks or cpu (but can't really say much as there's
> NO DMESG...*sigh*). On systems with <=256MB running the relink in the
> background can be quite a problem depending on what daemons are running.
>
> > You could start with following the proper upgrade procedure.
> >
> > What's difficult about booting into bsd.rd and doing an upgrade?
>
> Again depends on what bgpd is being used for, but prior to sysupgrade
> (which isn't relevant to OP yet as it's on 6.5), getting network in bsd.rd
> in order to do a standard upgrade can be quite a challenge.
>
>
>

Reboot and re-link

[Maxim Bourmistrov]

Hey,

long story short: reboot and re-link is not practical.

Long story:
Time to upgrade 6.4 to 6.5.
If re-link been active in 6.4 (don't remember) - I never noticed it.
Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on
steroides (ansible).
All down. Reboot.
and now I get a SLOW sys - why ?! - compiling new kernel:

load averages:  3.25,  1.45,  0.60

53 processes: 1 running, 49 idle, 3 on processor

 up  0:04
CPU0 states:  0.0% user,  0.0% nice, 21.0% sys, 63.7% spin,  0.6% intr,
14.7% idle
CPU1 states:  0.5% user,  0.0% nice, 22.3% sys, 56.2% spin,  0.0% intr,
20.9% idle
CPU2 states:  0.7% user,  0.0% nice, 71.5% sys, 19.6% spin,  0.0% intr,
 8.3% idle
CPU3 states:  0.5% user,  0.0% nice,  6.3% sys, 63.3% spin,  0.0% intr,
29.9% idle
Memory: Real: 382M/792M act/tot Free: 1177M Cache: 310M Swap: 0K/1279M

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
51958 _snmpd640  956K 3148K run/0 - 3:25 119.87% snmpd
17683 root  640  166M  174M onproc/2  - 3:10 99.41% ld
59133 root   20 1404K 4248K sleep/0   select0:08 16.70% sshd
39714 root  180  908K  988K sleep/1   pause 0:05 12.55% ksh
69806 _tor   20   29M   41M sleep/3   kqread0:28  8.15% tor
56629 _pflogd40  744K  576K sleep/3   bpf   0:19  7.57% pflogd
92193 _iscsid20  732K 1256K sleep/3   kqread0:15  4.64% iscsid
  288 _squid 20   17M   14M sleep/0   kqread0:11  4.00% squid
53448 _lldpd 20 2656K 3848K sleep/3   kqread0:07  3.32% lldpd
42939 _syslogd   20 1108K 1692K sleep/3   kqread0:03  1.66% syslogd
 2842 _bgpd 100 1172K 1896K onproc/1  - 0:03  1.46% bgpd


I don't think THIS IS OK.
I'm lucky - secondary (but, if ONLY primary??)


For whatever reason, after rebooting, I got back 6.4 kernel.
(I'd like to here some great explanation here and MORE around the )

P.S.
I remember old times then you could fork and forget.
OS position it self as "an ASCII, no sh around and simple". Then why the
process to upgrade became a nightmare?! Was not like this BEFORE.

Hit me with stright answers and no "bs wrap-around".

Ye, btw, the "ansible way" been working before.

//mxb

Re: Upgrade 6.0 -> 6.1: ix mmba is not mem space

[Maxim Bourmistrov]

Yepp.
I ended up with a -stable kernel and syspatch refusing to pull down patches, 
but this is another story.
It’s up2date now.
Thanks all.

Br

> 30 maj 2018 kl. 09:36 skrev Peter Hessler :
> 
> Assuming 1.140 is the "problem", 1.151 should fix it.

Re: Upgrade 6.0 -> 6.1: ix mmba is not mem space

[Maxim Bourmistrov]

Diff, discussed in the thread, seems to follow all the way to 6.3.
Sure I probably can try out 6.3, but I have a feeling that this will not help.

dmesg can be arranged.

Br 

> 29 maj 2018 kl. 20:56 skrev Chris Cappuccio :
> 
> No magic expected here, but why not try 6.3? 6.1 is not supported anymore, 
> and in any event, you need to include full dmesg so that others without DL360 
> Gen9 have a chance at helping you.
> 
> Maxim Bourmistrov [m...@alumni.chalmers.se] wrote:
>> Hey,
>> While moving one of machines from 6.0 to 6.1, I found 6.1 not able to attach 
>> ix-device.
>> Machine is HP DL360 Gen9.
>> 
>> ix0 at pci5 dev 0 function 0 "Intel 82599" rev 0x01: mmba is not mem space
>> ix1 at pci5 dev 0 function 1 "Intel 82599" rev 0x01: mmba is not mem space
>> 
>> Found this thread
>> http://openbsd-archive.7691.n7.nabble.com/OpenBSD-6-1-ix-Intel-82598EB-issue-td317072.html
>>  
>> <http://openbsd-archive.7691.n7.nabble.com/OpenBSD-6-1-ix-Intel-82598EB-issue-td317072.html>
>> 
>> and as far as I can see, this diff is in tree, but not helping here :(
>> 
>> Any clues? 
>> 
>> 4:0:1: Intel 82599
>>   0x: Vendor ID: 8086 Product ID: 10fb
>>   0x0004: Command: 0147 Status: 0010
>>   0x0008: Class: 02 Subclass: 00 Interface: 00 Revision: 01
>>   0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 10
>>   0x0010: BAR mem 32bit addr: 0x92c0/0x0010
>>   0x0014: BAR empty ()
>>   0x0018: BAR io addr: 0x2000/0x0020
>>   0x001c: BAR mem 32bit addr: 0x92e0/0x4000
>>   0x0020: BAR empty ()
>>   0x0024: BAR empty ()
>>   0x0028: Cardbus CIS: 
>>   0x002c: Subsystem Vendor ID: 103c Product ID: 17d0
>>   0x0030: Expansion ROM Base Address: 
>>   0x0038: 
>>   0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
>>   0x0040: Capability 0x01: Power Management
>>   State: D0 PME# enabled
>>   0x0050: Capability 0x05: Message Signalled Interrupts (MSI)
>>   0x0070: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
>>   0x00a0: Capability 0x10: PCI Express
>>   Link Speed: 5.0 / 5.0 GT/s Link Width: x8 / x8
>>   0x0100: Enhanced Capability 0x01: Advanced Error Reporting
>>   0x0140: Enhanced Capability 0x03: Device Serial Number
>>   0x0150: Enhanced Capability 0x0e: Alternate Routing ID
>>   0x0160: Enhanced Capability 0x10: Single Root I/O Virtualization
>>   0x00e0: Capability 0x03: Vital Product Data (VPD)
>> 
>> Br
>> 
>> 

Upgrade 6.0 -> 6.1: ix mmba is not mem space

[Maxim Bourmistrov]

Hey,
While moving one of machines from 6.0 to 6.1, I found 6.1 not able to attach 
ix-device.
Machine is HP DL360 Gen9.

ix0 at pci5 dev 0 function 0 "Intel 82599" rev 0x01: mmba is not mem space
ix1 at pci5 dev 0 function 1 "Intel 82599" rev 0x01: mmba is not mem space

Found this thread
http://openbsd-archive.7691.n7.nabble.com/OpenBSD-6-1-ix-Intel-82598EB-issue-td317072.html
 


and as far as I can see, this diff is in tree, but not helping here :(

Any clues? 

4:0:1: Intel 82599
   0x: Vendor ID: 8086 Product ID: 10fb
   0x0004: Command: 0147 Status: 0010
   0x0008: Class: 02 Subclass: 00 Interface: 00 Revision: 01
   0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 10
   0x0010: BAR mem 32bit addr: 0x92c0/0x0010
   0x0014: BAR empty ()
   0x0018: BAR io addr: 0x2000/0x0020
   0x001c: BAR mem 32bit addr: 0x92e0/0x4000
   0x0020: BAR empty ()
   0x0024: BAR empty ()
   0x0028: Cardbus CIS: 
   0x002c: Subsystem Vendor ID: 103c Product ID: 17d0
   0x0030: Expansion ROM Base Address: 
   0x0038: 
   0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
   0x0040: Capability 0x01: Power Management
   State: D0 PME# enabled
   0x0050: Capability 0x05: Message Signalled Interrupts (MSI)
   0x0070: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
   0x00a0: Capability 0x10: PCI Express
   Link Speed: 5.0 / 5.0 GT/s Link Width: x8 / x8
   0x0100: Enhanced Capability 0x01: Advanced Error Reporting
   0x0140: Enhanced Capability 0x03: Device Serial Number
   0x0150: Enhanced Capability 0x0e: Alternate Routing ID
   0x0160: Enhanced Capability 0x10: Single Root I/O Virtualization
   0x00e0: Capability 0x03: Vital Product Data (VPD)

Br

Re: nsd does not stop

[Maxim Bourmistrov]

Is nsd.conf broken?

shell# nsd-checkconf /var/nsd/etc/nsd.conf



> 3 maj 2018 kl. 16:27 skrev Vivek Vinod :
> 
> Dear Misc,
> 
> on stopping nsd from command line, nsd does not stop at all
> 
> Config:
> OpenBSD 6.3
> nsd remote control is disabled
> nsd ipv6 is disabled
> 
> $doas rcctl restart nsd
> (failed)
> 
> $doas rcctl stop nsd
> $echo $?
> 0
> 
> $doas rcctl start nsd
> (failed)
> 
> $doas tail -f /var/log/nsd.log
> error: can't bind udp socket: Address already in use
> error: server initialization failed, nsd could not be started
> 
> $ps aux | grep nsd
> shows running processes
> 
> if I kill the processes, I can start nsd. However, it is just that nsd does
> not stop if I want it to
> 
> even
> $doas /etc/rc.d/nsd stop | restart
> does not work.
> 
> What am I doing wrong here? Pooped. Any help would be appreciated.
> 
> regards,
> Vivek

Re: Intel X-550T 10 GbE Adapter cards

[Maxim Bourmistrov]

> 6 maj 2018 kl. 22:43 skrev Sebastian Benoit :
> 
> Peter J. Philipp(p...@centroid.eu) on 2018.05.06 21:47:02 +0200:
>> Hi,
>> 
>> The ix(4) manpage mentions there is support:
>> 
>> o Intel X550-T 10GbE Adapter (10GbaseT/1000baseT/100baseTX)
>> 
>> However there is a X550-T1 and a X550-T2 model are both supported or
>> 
>> just the X550-T1?
> 
> its the same card, just with 1 port ort 2 ports.
> 

Exactly.
For instance, I have X540, both T1 and T2, working.

Re: OSPF over gif on top of IPsec transport -current

[Maxim Bourmistrov]

> 13 mars 2018 kl. 11:56 skrev Marc Peters :
> 
> On Tue, Mar 13, 2018 at 10:24:43AM +0100, Remi Locherer wrote:
>>> and it is harder for traffic inside the tunnel
>>> to leak out of ipsec. more specifically, gif handles 3 ip protocols,
>>> ipv4, ipv6, and mpls, which are ip protocol numbers 4, 41, and 137
>>> respectively. it is likely that people could set up ipsec to protect
>>> ipv4, but forget about ipv6 and mpls. if you then configure v6 or mpls
>>> on the gif interface, that traffic will leak.
>> 
>> I don't see the big difference here between gif and gre. To prevent traffic
>> leave your box unprotected you have to setup pf rules in both cases.
>> 
>>> gre on the other hand is a single ip protocol, so more straightforward
>>> to protect. there's also a very clear line in the sand between the
>>> inner and outer traffic, which esp tunnel and transport mode lack.
>> 
>> But gre alone does not protect the traffic! You still need esp transport
>> for protection.
>> 
>> My main point about this is:
>> The setup described by Atanas used to work. There are setups out there
>> (including mine) that are operational for years and rely on OSPF working
>> via gif + esp transport. With the current state of gif these setups will
>> break.
> 
> Our setup relies on gif interfaces and ipsec in transport mode, too. When 
> setting this up, we had issues with the gre setup and gre packets itself 
> brings in more headers, which would reduce the payload. That's why we are 
> using ipsec (in transport mode) protected gif tunnels for ospf and bgp.
> 
> Best,
> Marc
> 

I moved over to etherip(4) some time ago. In transition to etherip, combo of 
etherip on one side and gif on another worked well.
I also remember announcement of gif(4) to be retired.

HISTORY
 The gif device first appeared in WIDE hydrangea IPv6 kit.

 Previously, gif supported RFC 3378 EtherIP tunnels over bridge(4)
 interfaces.  This is now handled by etherip(4).


//mxb

Re: acme-client No registration exists matching provided key

[Maxim Bourmistrov]

I also had to remove /etc/acme/letsencrypt-privkey.pem and re-do the process.
Just updating link to pdf not helped out.

> 2 feb. 2018 kl. 05:01 skrev Predrag Punosevac :
> 
> Jordan Geoghegan  wrote:
> 
>> Hi,
>> 
>> I recently dealt with this issue as well and the solution was quite 
>> silly. The problem is that acme-client is failing due to the agreement 
>> url being out of date; there is a new agreement v1.2. acme-client has 
>> been patched in current I believe to fix this issue and automatically 
>> update the agreement url. For now, just change your config to list the 
>> latest agreement url: 
>> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf";
>> 
>> Hope this helps,
>> 
>> Jordan
> 
> Thank you so much for this prompt replay. I already signed certificate
> using certbot as we were hitting deadline. However, this is going to be
> very useful going forward with renewals. 
> 
> Best,
> Predrag
> 
>> 
>> 
>> 
>> 
>> On 02/01/18 17:16, Predrag Punosevac wrote:
>>> Hi Misc,
>>> 
>>> I have done this half dozen times in the past but I am having helluva
>>> time using acme-client to sign certificate for a domain. Any clues?
>>> Please see below machine, acme-client.conf and httpd.conf files
>>> 
>>> # uname -a
>>> OpenBSD mcba.autonlab.org 6.2 GENERIC.MP#2 amd64
>>> 
>>> # more /etc/acme-client.conf
>>> 
>>> #
>>> # $OpenBSD: acme-client.conf,v 1.4 2017/03/22 11:14:14 benno Exp $
>>> #
>>> authority letsencrypt {
>>> agreement url
>>> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf";
>>> api url "https://acme-v01.api.letsencrypt.org/directory";
>>> account key "/etc/acme/letsencrypt-privkey.pem"
>>> }
>>> 
>>> authority letsencrypt-staging {
>>> agreement url
>>> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf";
>>> api url "https://acme-staging.api.letsencrypt.org/directory";
>>> account key "/etc/acme/letsencrypt-staging-privkey.pem"
>>> }
>>> 
>>> domain mcba.autonlab.org {
>>> #   alternative names { secure.mcba.autonlab.org }
>>> domain key "/etc/ssl/acme/private/mcba.autonlab.org.key"
>>> domain certificate "/etc/ssl/acme/mcba.autonlab.org.crt"
>>> domain full chain certificate
>>> "/etc/ssl/acme/mcba.autonlab.org.fullchain.pem"
>>> sign with letsencrypt
>>> }
>>> 
>>> 
>>> 
>>> # more /etc/httpd.conf
>>> 
>>> # $OpenBSD: httpd.conf,v 1.17 2017/04/16 08:50:49 ajacoutot Exp $
>>> 
>>> #
>>> # Macros
>>> #
>>> ext_addr="*"
>>> 
>>> #
>>> # Global Options
>>> #
>>> # prefork 3
>>> 
>>> #
>>> # Servers
>>> #
>>> 
>>> # A name-based "virtual" server on the same address
>>> # server "mcba.autonlab.org" {
>>> server "mcba.autonlab.org" {
>>> listen on $ext_addr port 80
>>> 
>>> location "/.well-known/acme-challenge/*" {
>>> root "/acme"
>>> root strip 2
>>> }
>>> #   block return 301 "https://$SERVER_NAME$REQUEST_URI";
>>> }
>>> 
>>> # An HTTPS server using SSL/TLS
>>> # server "mcba.autonlab.org" {
>>> #   listen on $ext_addr tls port 443
>>> 
>>> # TLS certificate and key files created with acme-client(1)
>>> #   tls certificate "/etc/ssl/acme/www.autonsys.com.fullchain.pem"
>>> #   tls key "/etc/ssl/acme/private/www.autonsys.com.key"
>>> 
>>> # Define server-specific log files relative to /logs
>>> #   log { access "secure-access.log", error "secure-error.log" }
>>> 
>>> # Increase connection limits to extend the lifetime
>>> #   connection { max requests 500, timeout 3600 }
>>> 
>>> #   root "/htdocs/mcba/pub"
>>> #}
>>> 
>>> 
>>> # Include MIME types instead of the built-in ones
>>> types {
>>> include "/usr/share/misc/mime.types"
>>> }
>>> 
>>> 
>>> 
>>> # acme-client -vAD mcba.autonlab.org
>>> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
>>> creating)
>>> acme-client: /etc/ssl/acme/private/mcba.autonlab.org.key: generated RSA 
>>> domain key
>>> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
>>> acme-client: acme-v01.api.letsencrypt.org: DNS: 23.196.58.251
>>> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: 
>>> mcba.autonlab.org
>>> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 
>>> 403
>>> acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized",
>>> "detail": "No registration exists matching provided key", "status": 403
>>> }] (120 bytes)
>>> acme-client: bad exit: netproc(58513): 1
>>> 
>>> 
> 

Re: Kernel panic with openbsd 6.2

[Maxim Bourmistrov]

As Stuart mentioned, em(4) on top of e1000 proven to be more stable.
Even under higher load.
Vmx starting to misbehave under high load, resulting for ex. with unstable CARP 
setup.

//mxb

> 25 jan. 2018 kl. 02:40 skrev trondd :
> 
> On Mon, January 22, 2018 10:47 am, Mik J wrote:
>> Hello Stuart,
>> For me it takes just a few days...
>> I have a crash every 3/4 days maybe (2 crashes so far) and my server does
>> not handle load.
>> Yes I read your reports this morning, although you wrote that there was a
>> combination with snmpd, I have it with nginx on my side.
>> 
>> Regards
>> 
>>Le lundi 22 janvier 2018 Ã
 10:35:47 UTC+1, Stuart Henderson
>>  a écrit :
>> 
>> On 2018/01/22 00:22, Mik J wrote:
>>> Le dimanche 21 janvier 2018 Ã
 11:48:00 UTC+1, Stuart Henderson
>>>  a écrit :
>>> On 2018-01-19, Mik J  wrote:
 I had many kernel panic these past days. This is a 6.2 openbsd VM
>>> running o=
 n esxi 5.5
 
 # grep "" /tmp/if_vmx.dis
>>> 
>>> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
>>> I suggest switching to e1000 in the vmx file, this works with the em(4)
>>> driver and has been stable so far.
>>> 
>>> 
>>> Hello Stuart,
>>> Thank you for your answer.
>>> I had my VM running for months in version 6.1 and had not problem but I
>>> reinstalled it in
>>> version 6.2 and the problem is happening.
>>> It seems to me that something in version 6.2 is producing the error.
>>> One crash today again
>> 
>> I hit this in last April, which was either 6.1 or -current from soon
>> after.
>> It can take weeks to run into it though so bisecting to find a working
>> kernel
>> is futile.
>> 
>> 
> 
> I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
> one VM that panics with vmxnet3_getbuf but only when it's being
> snapshotted.  And not every time, but usually.
> 
> I think once it paniced when I was snapshotting a lot of other VMs in the
> cluster but I don't trust that memory now.  I've not seen that again.
> 
> Tim.
> 

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

6.2-stable is NOT STABLE.
Backport, backport,backport.

6.2-stable is a beta release. 
This is what its IS.

5.9 vs. 6.2 - last one is a major downwards.
I know a lot of stuff done in tcp/ip stack and this is a good job (abt time to 
ack SMP), but
Keep those changes in beta, don’t tell ”we have rel and stable here. Eat it”.

//mxb

> 21 dec. 2017 kl. 23:19 skrev Maxim Bourmistrov :
> 
> 
> Fixed in HEAD?! - my ass. Whom puts HEAD into prod?! Not me any more, that's 
> for sure.
> IS LIKE DROPPING A TURBO ENGINE INTO CAR WITH NO WHEELS.
> 
> I can dig into this as much as I want/like ON MY OWN TIME.
> But if MONEY are on the table…….
> 
> I think I’ll revert to 5.9 all of it.
> 
> //mxb
> 
>> 21 dec. 2017 kl. 23:07 skrev Maxim Bourmistrov :
>> 
>> Solved?1
>> 
>> What abt OPTIONS in relay_http.c ?
>> Solved?
>> Maybe in HEAD.(?)
>> I have to hand-rolle this in src for 6.2 to have it working.
>> —> toread=0;
>> You know.
>> 
>> //mxb
>> 
>>> 21 dec. 2017 kl. 22:40 skrev Janne Johansson >> <mailto:icepic...@gmail.com>>:
>>> 
>>> 2017-12-21 21:58 GMT+01:00 Maxim Bourmistrov >> <mailto:m...@alumni.chalmers.se>>:
>>> 
>>> Sorry, but I have to say
>>> Releases after 5.9 are NOT production stable.
>>> (Until all bugs are smashed within stack changes and SMP unlock).
>>> After 5.9 - cost money and effort.
>>> MONEY.
>>> 
>>> As long as they get quality reports like this, it would soon be solved.
>>>  
>> 
> 

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

Fixed in HEAD?! - my ass. Whom puts HEAD into prod?! Not me any more, that's 
for sure.
IS LIKE DROPPING A TURBO ENGINE INTO A CAR WITH NO WHEELS.

I can dig into this as much as I want/like ON MY OWN TIME.
But if MONEY are on the table…….

I think I’ll revert to 5.9 all of it.

//mxb

> 21 dec. 2017 kl. 23:07 skrev Maxim Bourmistrov :
> 
> Solved?1
> 
> What abt OPTIONS in relay_http.c ?
> Solved?
> Maybe in HEAD.(?)
> I have to hand-rolle this in src for 6.2 to have it working.
> —> toread=0;
> You know.
> 
> //mxb
> 
>> 21 dec. 2017 kl. 22:40 skrev Janne Johansson > <mailto:icepic...@gmail.com>>:
>> 
>> 2017-12-21 21:58 GMT+01:00 Maxim Bourmistrov > <mailto:m...@alumni.chalmers.se>>:
>> 
>> Sorry, but I have to say
>> Releases after 5.9 are NOT production stable.
>> (Until all bugs are smashed within stack changes and SMP unlock).
>> After 5.9 - cost money and effort.
>> MONEY.
>> 
>> As long as they get quality reports like this, it would soon be solved.
>>  
> 

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

Solved?1

What abt OPTIONS in relay_http.c ?
Solved?
Maybe in HEAD.(?)
I have to hand-rolle this in src for 6.2 to have it working.
—> toread=0;
You know.

//mxb

> 21 dec. 2017 kl. 22:40 skrev Janne Johansson :
> 
> 2017-12-21 21:58 GMT+01:00 Maxim Bourmistrov  <mailto:m...@alumni.chalmers.se>>:
> 
> Sorry, but I have to say
> Releases after 5.9 are NOT production stable.
> (Until all bugs are smashed within stack changes and SMP unlock).
> After 5.9 - cost money and effort.
> MONEY.
> 
> As long as they get quality reports like this, it would soon be solved.
>  

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

I had to bypass relayd to roll prod stable.
Down to apache. Taking care of http and https.
By redirect.
Now this setup (if I can call it) is stable.

.

P.S.
Looks like we have to move forward from here.

> 21 dec. 2017 kl. 21:58 skrev Maxim Bourmistrov :
> 
> 
> Sorry, but I have to say
> Releases after 5.9 are NOT production stable.
> (Until all bugs are smashed within stack changes and SMP unlock).
> After 5.9 - cost money and effort.
> MONEY.
> 
> //mxb
> 
>> 21 dec. 2017 kl. 20:29 skrev Maxim Bourmistrov :
>> 
>> Hey,
>> After upgrading from 6.0-stable to 6.2-stable (syspatch) existing setup 
>> started to hang.
>> As of burst of emails from me following is known:
>> 
>> Relayd is a main process to take CPU.
>> Also running ospfd and bgpd (for blocklist distrib)
>> 
>> With 6.0, relayd used to have two or more procs with high CPU usage (99,9% - 
>> 100%, per core).
>> Now, setup is just adjusted to conform new reality with TLS protocol, all 
>> just hangs.
>> No core (even it is enabled in sysctl), no panic - nothing.
>> Syslog sending to remote shows nothing.
>> 
>> I know, it is now enough for any debug and troubleshooting at all.
>> Just FYI.
>> 
>> Any ideas are welcome.
>> 
>> //mxb
> 

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

Sorry, but I have to say
Releases after 5.9 are NOT production stable.
(Until all bugs are smashed within stack changes and SMP unlock).
After 5.9 - cost money and effort.
MONEY.

//mxb

> 21 dec. 2017 kl. 20:29 skrev Maxim Bourmistrov :
> 
> Hey,
> After upgrading from 6.0-stable to 6.2-stable (syspatch) existing setup 
> started to hang.
> As of burst of emails from me following is known:
> 
> Relayd is a main process to take CPU.
> Also running ospfd and bgpd (for blocklist distrib)
> 
> With 6.0, relayd used to have two or more procs with high CPU usage (99,9% - 
> 100%, per core).
> Now, setup is just adjusted to conform new reality with TLS protocol, all 
> just hangs.
> No core (even it is enabled in sysctl), no panic - nothing.
> Syslog sending to remote shows nothing.
> 
> I know, it is now enough for any debug and troubleshooting at all.
> Just FYI.
> 
> Any ideas are welcome.
> 
> //mxb

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

The first node out of two started to respond as soon as second one got reset.
I don’t see any saturation on the network stack.
"Netstat -m” shows 0 for mem denied.
Sysctl -a|grep ifq
or
Sysctl -a|grep drop 
Shows 0 as well.

Whole thing looked like a tcp/ip stack hang.

//mxb

> 21 dec. 2017 kl. 20:29 skrev Maxim Bourmistrov :
> 
> Hey,
> After upgrading from 6.0-stable to 6.2-stable (syspatch) existing setup 
> started to hang.
> As of burst of emails from me following is known:
> 
> Relayd is a main process to take CPU.
> Also running ospfd and bgpd (for blocklist distrib)
> 
> With 6.0, relayd used to have two or more procs with high CPU usage (99,9% - 
> 100%, per core).
> Now, setup is just adjusted to conform new reality with TLS protocol, all 
> just hangs.
> No core (even it is enabled in sysctl), no panic - nothing.
> Syslog sending to remote shows nothing.
> 
> I know, it is now enough for any debug and troubleshooting at all.
> Just FYI.
> 
> Any ideas are welcome.
> 
> //mxb

OpenBSD 6.2 (up2date with syspatch) - HANGING

[Maxim Bourmistrov]

Hey,
After upgrading from 6.0-stable to 6.2-stable (syspatch) existing setup started 
to hang.
As of burst of emails from me following is known:

Relayd is a main process to take CPU.
Also running ospfd and bgpd (for blocklist distrib)

With 6.0, relayd used to have two or more procs with high CPU usage (99,9% - 
100%, per core).
Now, setup is just adjusted to conform new reality with TLS protocol, all just 
hangs.
No core (even it is enabled in sysctl), no panic - nothing.
Syslog sending to remote shows nothing.

I know, it is now enough for any debug and troubleshooting at all.
Just FYI.

Any ideas are welcome.

//mxb

Re: IPMI still requires Java! I'm screwed.

[Maxim Bourmistrov]

Yepp.
I have
bios0: Supermicro X10DRT-PT
With latest IPMI firmware and have html5.


> 21 dec. 2017 kl. 12:00 skrev kasak :
> 
> 
>> 21 дек. 2017 г., в 12:16, Maxim Bourmistrov  
>> написал(а):
>> 
>> 
>> Even X10 can be upgraded to get in html5.
>> 
>>> 21 dec. 2017 kl. 06:50 skrev kasak :
>>> 
>>> 
>>>> 21 дек. 2017 г., в 0:03, Chris Bennett  
>>>> написал(а):
>>>> 
>>>> I found a new server that uses IPMI and offers using it
>>>> to setup your own custom OS. So I bought in.
>>>> 
>>>> Damn thing requires Java.
>>>> They offered me some pretty worthless advice on using
>>>> Java.
>>>> 
>>>> I'm screwed into having to use Windows 7.
>>>> I've tried the Firefox ESR 32bit that supports Java.
>>>> Nope.
>>>> Opera. Nope
>>>> Edge. Nope
>>>> Chrome. Nope, including trying to use IEtab
>>>> 
>>>> Is it actually possible to get any web browser to 
>>>> open a Java applet?
>>>> 
>>>> I'm using a friends laptop and it can't stay on while
>>>> in the BIOS or after booting OpenBSD just to the point
>>>> of running memtest.
>>>> 
>>>> I'm a bit confused about what to do.
>>>> They offer IPMI that won't work without Java.
>>>> 
>>>> Is this even anything more than a scam??
>>>> I don't know squat about windows other than it sucks.
>>>> 
>>>> 
>>>> Serious question:
>>>> Is it acceptable practice to offer remote access that
>>>> cannot be used?
>>>> 
>>>> 
>>>> 
>>> Look at the newest servers with aspeed ast2500, such as supermicro x11 
>>> platforms, they are manageable through html5. If you still need to manage 
>>> your server try jdk-1.8.0.144v0.tgz package from ports
>>> 
>> 
> Just by updating firmware?  What a pity, Asus hasn’t upgraded firmwares to 
> support html5, I have some of them in usage with p10 platforms

Re: IPMI still requires Java! I'm screwed.

[Maxim Bourmistrov]

Even X10 can be upgraded to get in html5.
 
> 21 dec. 2017 kl. 06:50 skrev kasak :
> 
> 
>> 21 дек. 2017 г., в 0:03, Chris Bennett  
>> написал(а):
>> 
>> I found a new server that uses IPMI and offers using it
>> to setup your own custom OS. So I bought in.
>> 
>> Damn thing requires Java.
>> They offered me some pretty worthless advice on using
>> Java.
>> 
>> I'm screwed into having to use Windows 7.
>> I've tried the Firefox ESR 32bit that supports Java.
>> Nope.
>> Opera. Nope
>> Edge. Nope
>> Chrome. Nope, including trying to use IEtab
>> 
>> Is it actually possible to get any web browser to 
>> open a Java applet?
>> 
>> I'm using a friends laptop and it can't stay on while
>> in the BIOS or after booting OpenBSD just to the point
>> of running memtest.
>> 
>> I'm a bit confused about what to do.
>> They offer IPMI that won't work without Java.
>> 
>> Is this even anything more than a scam??
>> I don't know squat about windows other than it sucks.
>> 
>> 
>> Serious question:
>> Is it acceptable practice to offer remote access that
>> cannot be used?
>> 
>> 
>> 
> Look at the newest servers with aspeed ast2500, such as supermicro x11 
> platforms, they are manageable through html5. If you still need to manage 
> your server try jdk-1.8.0.144v0.tgz package from ports
> 

Re: Upgrade 6.1 -> 6.2: No /mnt/etc/myname

[Maxim Bourmistrov]

This is, indeed, a symlink.
Thanks for opening my eyes. 

//mxb

> 12 okt. 2017 kl. 01:42 skrev Steven McDonald :
> 
> This is a complete guess, but is /etc/myname a symbolic link? If it is
> a symlink to an absolute path, that is unlikely to exist in the bsd.rd
> filesystem and would cause this error.
> 
> If that's not it, please clarify what you mean by the "file is there".
> What command did you run, and what was its output? What sort of file is
> it? And is sd0 the correct disk?

Re: relayd: high CPU usage by one or two proc. of many

[Maxim Bourmistrov]

Ok,
ktrace showed up that processes having problems to grab a socket. e.g. out of 
fds.

Question:
How far can I rise kern.maxfiles having following conditions:

16G RAM total
prefork 16 relayd procs
openfiles-max=65536 in login.conf for relayd class.
Out of my calc it is 16*65536 just to accommodate relayd.
Am I safe to have 1+M of fds as kern.maxfiles ??

//mxb 

> 27 sep. 2017 kl. 21:34 skrev Maxim Bourmistrov :
> 
> My intention with this mail is to gather more qualitative help
> to, hopefully, ever solve this or to have more info so it can be provided 
> to someone whom can solve this, if it is a bug.
> 
> What I know for sure is that those boxes (dual-node setup) are exposed to a 
> large HTTP PUT/POST requests.
> Large does not means ”put a 1G-sized stream”. Text it is.
> 
> Of cause it is not a bug report.
> No info, if any, states this.
> 
> Let’s see what I can gather more with fstat.
> Thanks.
> 
> Br
> Maxim
> 
> 
> 
>> 27 sep. 2017 kl. 20:51 skrev Theo de Raadt > <mailto:dera...@openbsd.org>>:
>> 
>> This probably means the process has run out of file descriptors.
>> fstat might expose what is going on.  If that's the case, roll your
>> sleeves up and study the code.  As usual, the circumstances that
>> create this event are not being completely documented - I MEAN, what
>> I'm seeing here isn't a bug report including a configuration file
>> that reliably reproduces it.
> 

Upgrade 6.1 -> 6.2: No /mnt/etc/myname

[Maxim Bourmistrov]

Hey,
Upgrade from 6.1 to 6.2 via bsd.rd fails.

Mounting /dev/sd0a /mnt - OK
No /mnt/etc/myname!
#

Mount of sd0a as read-only OK - shows in ’mount’
#cat /mnt/etc/myname - no such file

Booting back to bsd (6.1) and file is there.

6.2 files are as of Oct 4 from ftp.eu.openbsd.org .

Any clues?

//mxb

Re: relayd: high CPU usage by one or two proc. of many

[Maxim Bourmistrov]

My intention with this mail is to gather more qualitative help
to, hopefully, ever solve this or to have more info so it can be provided 
to someone whom can solve this, if it is a bug.

What I know for sure is that those boxes (dual-node setup) are exposed to a 
large HTTP PUT/POST requests.
Large does not means ”put a 1G-sized stream”. Text it is.

Of cause it is not a bug report.
No info, if any, states this.

Let’s see what I can gather more with fstat.
Thanks.

Br
Maxim



> 27 sep. 2017 kl. 20:51 skrev Theo de Raadt :
> 
> This probably means the process has run out of file descriptors.
> fstat might expose what is going on.  If that's the case, roll your
> sleeves up and study the code.  As usual, the circumstances that
> create this event are not being completely documented - I MEAN, what
> I'm seeing here isn't a bug report including a configuration file
> that reliably reproduces it.

Re: relayd: high CPU usage by one or two proc. of many

[Maxim Bourmistrov]

Hey,
had to bring this up again as I’m facing the same problem.
Exactly with the same ’error 35’ in trace.
This time it is a 6.0-stable.

Anything else can be done to track this down?

Br
Maxim

> 24 feb. 2016 kl. 10:53 skrev Stuart Henderson :
> 
> On 2016-02-24, mxb mailto:m...@alumni.chalmers.se>> 
> wrote:
>> Hey,
>> I have a strange behavior of relayd running on 5.8.
>> This machine almost exclusively terminates TLS traffic.
>> Exceptions are forwards which are in backup state (listen on CARP).
>> 
>> Some times one or two relayd processes out of many consumes a lot of CPU
>> and stays like this until I restart relayd.
> 
>> ktrace gives me following:
>> 4013 relayd   CALL  getdtablecount()
>>  4013 relayd   RET   getdtablecount 101/0x65
>>  4013 relayd   CALL  getrlimit(RLIMIT_NOFILE,0x7f7bb630)
>>  4013 relayd   STRU  struct rlimit { cur=65536, max=65536 }
>>  4013 relayd   RET   getrlimit 0
>>  4013 relayd   CALL  recvmsg(550,0x7f7bb6a0,0)
>>  4013 relayd   RET   recvmsg -1 errno 35 Resource temporarily unavailable
>>  4013 relayd   CALL  getdtablecount()
>>  4013 relayd   RET   getdtablecount 101/0x65
>>  4013 relayd   CALL  getrlimit(RLIMIT_NOFILE,0x7f7bb630)
>>  4013 relayd   STRU  struct rlimit { cur=65536, max=65536 }
>>  4013 relayd   RET   getrlimit 0
>>  4013 relayd   CALL  recvmsg(550,0x7f7bb6a0,0)
>>  4013 relayd   RET   recvmsg -1 errno 35 Resource temporarily unavailable
>>  4013 relayd   CALL  getdtablecount()
>>  4013 relayd   RET   getdtablecount 101/0x65
>>  4013 relayd   CALL  getrlimit(RLIMIT_NOFILE,0x7f7bb630)
>>  4013 relayd   STRU  struct rlimit { cur=65536, max=65536 }
>>  4013 relayd   RET   getrlimit 0
>>  4013 relayd   CALL  recvmsg(550,0x7f7bb6a0,0)
>>  4013 relayd   RET   recvmsg -1 errno 35 Resource temporarily unavailable
>> 
>> Human readable file after kdump is filled with those lines.
>> This as far of my understanding is about limit of openfiles.
> 
> It's not files; errno 35 is EAGAIN - it is likely that this was
> fixed in -current (2015/12/05).

OpenBSD 6.1-stable lock up

[Maxim Bourmistrov]

Hey,
having a dual-node setup of 6.0 in prod, I decided to move forward with one of 
machines
and upgrade to 6.1-stable. Ending up in benchmark tool ”locking” the 6.1 
machine.

Background:
Nodes are Xeon E5-2642v3 3.4Ghz x12, 16G RAM, 64G DOM modules as hdd,
4x X540T (ix) - 2x on-board and 2x PCI-card.

All 4x X540T are connected to 2x Cisco Nexus 3000-series, creating an LACP 
trunk (1x on-board + 1x PCI).
trunk0 - external (VLAN), 1x NIC connected to switch1 and 1x NIC connected to 
switch2 (ix0 + ix3)
trunk1 - internal (VLAN) , 1x NIC connected to switch1 and 1x NIC connected to 
switch2 (ix1 + ix2)
As I have 2x Nexus 3000, VPC is configured and sitting on top of LACP trunk on 
their end.

Each obsd node have several carp interfaces configured on top of trunk0.
Only one carp interface on trunk1 - carp1.

Each switch acting as a default gw (VRRP configured) for any existing VLAN, 
except one towards trunk1.
Default gateway for those switches is IP on carp1.
Those switches run OSPF as well as obsd nodes do.

obsd nodes are the front line, facing the Internet. (2x uplink goes into 2x 
Nexus and then traffic is passed to 2x obsd.)
Running relayd with SSL-offload and plain HTTP.
Except relayd, there is ospfd, ntpd, snmpd, and bgpd(for distributed 
blacklisting around other global nodes).

The problem:
While doing a bench with https://github.com/wg/wrk  
from my laptop (OS X, 1Gbps max. pipe) agains the environment (HTTPS)
relayd experienced problems with handling the traffic.

shell# ./wrk -t16 -c1500 -d90s —latency 

wrk hammering apache 2.4(behind those nodes), serving a txt file with avg 
7k-10k req/s as an output:

wrk -t16 -c1500 -d90s --latency https://ping.txt
Running 2m test @ https:///ping.txt
  16 threads and 1500 connections
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency   131.17ms   70.91ms   1.97s91.70%
Req/Sec   651.06135.80 1.09k84.95%
  Latency Distribution
 50%  131.90ms
 75%  144.63ms
 90%  159.63ms
 99%  230.92ms
  927039 requests in 1.50m, 190.12MB read
  Socket errors: connect 0, read 0, write 0, timeout 1330
Requests/sec:  10290.54
Transfer/sec:  2.11MB

wrk hammering apache 2.4, mod_proxy_balance, with NodeJS nodes behind apache:

wrk -t16 -c1500 -d90s --latency https:///nodejs
Running 2m test @ https:///nodejs
  16 threads and 1500 connections
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency   445.91ms  518.66ms   2.00s83.49%
Req/Sec56.80 26.89   180.00 68.48%
  Latency Distribution
 50%  217.57ms
 75%  374.15ms
 90%1.50s
 99%1.95s
  80673 requests in 1.50m, 1.12GB read
  Socket errors: connect 0, read 5534, write 0, timeout 18099
Requests/sec:895.42
Transfer/sec: 12.72MB 

’top’ showed none interrupting at all, but rather heavy system load values and 
some user values.
20-30% - user
80-90% - system
relayd (12 forks as the number of cores) - 99% usage.

I basically killed both machines running 6.0, thus my decision to upgrade to 
6.1.
However, during the tests against 6.0, my ssh session never got terminated 
(”kicked out”) even with this hight load (0% CPU idle).
6.1 showed different symptoms - ssh session termination, login via web based 
IPMI GUI hanging after log in part,
ping not responding(from the switches and node1 which is 6.0 yet).
After a while, with bench aborted, 6.1 eventually let me in via ssh (terminal 
via IPMI stil hanging).

snmpd which been running (remember), been polled by other sys doing graphs.
What been seen on those graphs is high rate of output err pkts on trunks, not 
NICs (ix) them selves.
Also, syslog, with enabled ’log all’ for relayd showed a lot of ’buffer timeout 
event’,
ospfd yeilding about ’no buffer space available’.

I had to modd relayd.conf to spawn only 8 preforks instead of 12
and 

kern.maxclusters=24576 #12288
kern.maxfiles=65536 #32768

in order to survive the bench (e.g.. having ssh session alive).
Values commented out are from the 6.0 setup.

I’m looking for any advice here, which hopefully will lead to a stable and 
performant setup.
Configuration follows.

———sysct.conf (obsd 6.0)
net.inet.ip.forwarding=1
net.inet.ipcomp.enable=1# 1=Enable the IPCOMP protocol
net.inet.etherip.allow=1# 1=Enable the Ethernet-over-IP protocol
net.inet.tcp.ecn=1  # 1=Enable the TCP ECN extension
net.inet.carp.preempt=1 # 1=Enable carp(4) preemption
net.inet.carp.log=3 # log level of carp(4) info, default 2
ddb.panic=0 # 0=Do not drop into ddb on a kernel panic
ddb.console=1   # 1=Permit entry of ddb from the console
kern.pool_debug=0
net.inet.ip.maxqueue=2048
kern.somaxconn=4096
kern.maxclusters=12288
kern.maxfiles=32768
net.inet.ip.ifq.maxlen=2048


login.conf———
relayd:\
:maxproc-max=31:\
:openfiles-cur=65536:\
:openfiles-max=65536:\
:tc=daemon:

—pf.conf———
set 

Re: relayd l7 loadbalancing

[Maxim Bourmistrov]

Once connection is established, state is created in PF. Subsequent requests 
will be ’pipelined’.
It is possible to influence this behavior by manipulating tcp.established in 
pf.conf,
but I don’t think this is what you want.

> 16 aug. 2017 kl. 10:05 skrev Mischa Peters :
> 
> Hi All,
> 
> I have somewhat the following config for relayd running on 6.1.
> And I am trying to forward certain request paths to different hosts.
> 
> table  { xx.xx.xx.131 }
> table  { xx.xx.xx.31 }
> http protocol httpsfilter {
>   match request header remove "Proxy"
>   match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
>   match request header append "X-Forwarded-By" value 
> "$SERVER_ADDR:$SERVER_PORT"
> 
>   match response header set "Server" value "Sever"
>   match response header set "X-Powered-By" value "Power"
>   match response header set "X-Frame-Options" value "SAMEORIGIN"
>   match response header set "X-Xss-Protection" value "1; mode=block"
>   match response header set "X-Content-Type-Options" value "nosniff"
> 
>   match request quick path "/crm/" forward to 
> 
>   tcp { no splice }
> }
> relay host_tls {
>   listen on $ext_addr_v4 port 443 tls
>   listen on $ext_addr_v6 port 443 tls
>   protocol httpsfilter
>   forward to  port 80 check http "/" host example.com code 200
>   forward to  port 80
> }
> 
> I have tried both "match request quick path" and "match request quick url" 
> but what I noticed is that as soon as you have visited one of the URLs that 
> needs forwarding to a different host you end up at the  for all 
> subsequent requests.
> With "match request quick url" this is to be expected as it checks everything 
> up to /.
> 
> For example:
> 
> http://example.com/ -> wwwhost
> http://example.com/crm/ -> otherhost
> http://exmaple.com/folder/ -> otherhost
> 
> Is this expected behaviour for "match request quick path" as well?
> Is there any way to do this type of load balancing?
> 
> Thanx!!
> 
> Mischa
> 

rdomain and loopback ifs

[Maxim Bourmistrov]

Hey,
Not sure if this already known, but
while creating rdomain
shell# ifconfig vmx5 rdomain 1
OS assumes that for this particular domain number 1, lo1 will be used as a 
”glue” between domains.
However, it is not checked if this loopback is already within any rdomain.

I my case, it is yet another loopback, configured in rdomain 0.

lo1: flags=8049 mtu 32768
description: DNS_ANYCAST
index 32 priority 0 llprio 3
groups: lo
inet 10.30.30.10 netmask 0x

The command ' ifconfig vmx5 rdomain 1’ will fail with
ifconfig: SIOCSIFRDOMAIN: File exists

Is this a minor ”leftover” ?


Also, ifconfig does not contain ’-rdomain’ flag. Is it intentionally?

Br

Re: Limit internet connection by time of day and number of hours

[Maxim Bourmistrov]

Hey,
I have somewhat similar situation at home.
However, I never found a straight forward setup.

I can do a manual BLOCK OUT with a script, and probably, if I’d link this script
to a cron, I’d get some how setup you are after.

I do depend on dhcpd giving out static IP to a give MAC and thus
I don’t expect kids to take over MACs on the LAN.
They are not there yet :)

Following I have in pf.conf. Script is up to you (or I can share prvtly what I 
have).

table  persist

### block machines out
block out quick on egress tagged BLOCK
pass out quick on egress from  to any nat-to (egress:0) keep 
state \
(max-src-conn 1, max-src-conn-rate 1/1, overload  
flush global) tag BLOCK


Script adds adresses to  .
  - really, as name implies, not defined at all, anywhere 
in pf.conf.

Br
Mxb

> 6 juli 2017 kl. 00:19 skrev Stefan Wollny :
> 
> Hi there!
> 
> "Security" means to constantly re-evaluate your options and processes -
> right? So the other day I checked the settings in the Fritz!Box router
> and remembered that they had implemented a time quota for a defined
> group of users (=IPs).
> 
> Example: My young son has a tablet and a mobile phone (both Android) and
> has access to the internet with any device within a defined time frame
> and an overall maximum of x hours, individually set for each day of the
> week. In the rare cases that he needs more time he uses the joker named
> "Mama" ... ;-) (Side note: Just like pocket money the allowed time is
> regularly revised for age and experience - not behaviour!)
> 
> Consider other situations where you'd like to meet your responsibilities:
> - There may be usual office times from 06:30 am to 21:00 pm (some people
> like to work early, other late): Outside of this time frame access to
> the internet may not be acceptable (with rare exections) - or might mean
> that a machine is hijacked to be a part of a bot or to do some bitcoin
> calculations... whatever.
> - Within this time frame noone is legally permitted to work longer than
> 8 hours based on his login credentials to the office net (not device).
> - Just some specified servers do backups to the cloud and e.g. are
> granted access the internet exclusively at night time (thus being
> exceptions to the general rule above).
> - The web and mail servers are seperate to the office net and always-on.
> 
> The technical quest is in principal the same as the one I described
> above. Simply spoken: If noone of the 'guys and gals' responsible for
> safe and smooth operations is around the internet is turned off (or s/he
> gets paid overtime hours :-)).
> 
> Can s.th. like this set up with OpenBSD being the central router? I
> searched the FAQ and several man-pages but didn't get an idea of how to
> proceed. My very first idea (=dream) was "e.g. set the general time
> frame with PF" and "the individual quotas or access times within
> anchors". Unfortunately nothing appropriate was found by the "leading"
> internet search engine.
> 
> If someone has found a solution to such a task it would be great to get
> to know how this was achieved, of course with OpenBSD.
> 
> Please: I am just curious and interested to learn about my (realistic)
> options.
> 
> TIA.
> 
> Best,
> STEFAN
> 

Re: relayd: incomplete response from a TLS-accelerated apache

[Maxim Bourmistrov]

Compiling relayd with -DDEBUG=3 and watching the output gave me nothing.
No errors what so ever about out of buffers or something else.

However, removing 'socket buffer 65536’ solved my problem.

Br

> 8 maj 2017 kl. 13:27 skrev Maxim Bourmistrov :
> 
> Hey,
> I investigate a problem were TLS-asselerated machine response is incomplete.
> I was able to reproduce this on OpenBSD 5.9, 6.0 and 6.1. Test on 5.8 is 
> about to be.
> 
> Following env I have:
> 
> relay1: relayd machine
> web1: apache 2.2.31 serving the request
> client1: requester
> 
> relay1 is configured following way (relevant lines):
> 
> http protocol http_relay {
>tcp { nodelay, sack, socket buffer 65536, backlog 1024 }
>match header append "X-Forwarded-For" value "$REMOTE_ADDR"
>match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
>match header set "Keep-Alive" value "$TIMEOUT"
>match request header remove "Proxy"
> }
> 
> http protocol tls_accel {
>tcp { nodelay, sack, socket buffer 65536, backlog 1024 }
>match header append "X-Forwarded-For" value "$REMOTE_ADDR"
>match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
>match header set "X-Forwarded-Proto" value "https"
>match header set "X-Forwarded-Port" value "443"
>match header set "Keep-Alive" value "$TIMEOUT"
>match request header remove "Proxy"
> 
>tls { tlsv1, \
>ciphers "AES:!AES256:!aNULL" \
>  }
> }
> 
> table  { 172.16.1.111 }
> 
> relay int_test_tls {
>listen on 172.16.1.99 port 443 tls
>protocol tls_accel
>forward to  port 80 mode roundrobin check http "/" code 200
> }
> 
> relay int_test_http {
>listen on 172.16.1.99 port 80
>protocol http_relay
>forward to  port 80 mode roundrobin check http "/" code 200
> }
> 
> web1 is a std Apache 2.2.31 with enabled deflate for the following
> 
> AddOutputFilterByType DEFLATE application/json
> AddOutputFilterByType DEFLATE text/html
> AddOutputFilterByType DEFLATE text/plain
> AddOutputFilterByType DEFLATE text/xml
> AddOutputFilterByType DEFLATE text/css
> AddOutputFilterByType DEFLATE application/x-javascript
> AddOutputFilterByType DEFLATE application/javascript
> 
> and serving a JS file.
> 
> client1 is running PHP code from CLI to reproduce this problem.
> 
> 
> Following is observed:
> 
> 1. Client1 requests web1 directly on port 80 and gets full response
> 
> shell$ php client3.php
> Expected length: 547204
> Received length: 547204
> 
> [Response Headers]
> HTTP/1.1 200 OK
> Date: Mon, 08 May 2017 11:08:27 GMT
> Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips
> Last-Modified: Mon, 08 May 2017 07:22:43 GMT
> ETag: "60319-85984-54efe1ae42be3"
> Accept-Ranges: bytes
> Content-Length: 547204
> Vary: Accept-Encoding
> Connection: close
> Content-Type: application/javascript 
> 
> 2. Client1 requests web1 directly on port 80 WITH GZIP enabled and gets full 
> response back
> I see gzipped stream on the screen and then it gets decoded to a complete 
> file. File I get is not cut.
> 
> Expected length: Content-Length not recieved
> Received length: 165454
> 
> [Response Headers]
> HTTP/1.1 200 OK
> Date: Mon, 08 May 2017 11:10:18 GMT
> Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips
> Last-Modified: Mon, 08 May 2017 07:22:43 GMT
> ETag: "60319-85984-54efe1ae42be3"
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Connection: close
> Content-Type: application/javascript
> 
> 3. and 4. Clien1 requests relay1 on port 80 (with and without GZIP) and gets 
> complete response
> 
> 5. Client1 requests relay1 on port 443 without GZIP - response is incomplete
> 
> Expected length: 547204
> Received length: 396424
> 
> [Response Headers]
> HTTP/1.1 200 OK
> Accept-Ranges: bytes
> Connection: close
> Content-Length: 547204
> Content-Type: application/javascript
> Date: Mon, 08 May 2017 11:14:59 GMT
> ETag: "60319-85984-54efe1ae42be3"
> Last-Modified: Mon, 08 May 2017 07:22:43 GMT
> Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips
> Vary: Accept-Encoding
> 
> 6. Client1 requests relay1 on port 443 with GZIP - response is complete.
> 
> 
> So non-gzipped response from behind the relay1 is incomplete while doing TLS 
> termination.
> Files server.js and client.php can be provided upon request.
> 
> Any ideas?
> 
> Br
> 
> 
> 

relayd: incomplete response from a TLS-accelerated apache

[Maxim Bourmistrov]

Hey,
I investigate a problem were TLS-asselerated machine response is incomplete.
I was able to reproduce this on OpenBSD 5.9, 6.0 and 6.1. Test on 5.8 is about 
to be.

Following env I have:

relay1: relayd machine
web1: apache 2.2.31 serving the request
client1: requester

relay1 is configured following way (relevant lines):

http protocol http_relay {
tcp { nodelay, sack, socket buffer 65536, backlog 1024 }
match header append "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"
match request header remove "Proxy"
}

http protocol tls_accel {
tcp { nodelay, sack, socket buffer 65536, backlog 1024 }
match header append "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
match header set "X-Forwarded-Proto" value "https"
match header set "X-Forwarded-Port" value "443"
match header set "Keep-Alive" value "$TIMEOUT"
match request header remove "Proxy"

tls { tlsv1, \
ciphers "AES:!AES256:!aNULL" \
  }
}

table  { 172.16.1.111 }

relay int_test_tls {
listen on 172.16.1.99 port 443 tls
protocol tls_accel
forward to  port 80 mode roundrobin check http "/" code 200
}

relay int_test_http {
listen on 172.16.1.99 port 80
protocol http_relay
forward to  port 80 mode roundrobin check http "/" code 200
}

web1 is a std Apache 2.2.31 with enabled deflate for the following

AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/javascript

and serving a JS file.

client1 is running PHP code from CLI to reproduce this problem.


Following is observed:

1. Client1 requests web1 directly on port 80 and gets full response

shell$ php client3.php
Expected length: 547204
Received length: 547204

[Response Headers]
HTTP/1.1 200 OK
Date: Mon, 08 May 2017 11:08:27 GMT
Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips
Last-Modified: Mon, 08 May 2017 07:22:43 GMT
ETag: "60319-85984-54efe1ae42be3"
Accept-Ranges: bytes
Content-Length: 547204
Vary: Accept-Encoding
Connection: close
Content-Type: application/javascript 

2. Client1 requests web1 directly on port 80 WITH GZIP enabled and gets full 
response back
I see gzipped stream on the screen and then it gets decoded to a complete file. 
File I get is not cut.

Expected length: Content-Length not recieved
Received length: 165454

[Response Headers]
HTTP/1.1 200 OK
Date: Mon, 08 May 2017 11:10:18 GMT
Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips
Last-Modified: Mon, 08 May 2017 07:22:43 GMT
ETag: "60319-85984-54efe1ae42be3"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: close
Content-Type: application/javascript

3. and 4. Clien1 requests relay1 on port 80 (with and without GZIP) and gets 
complete response

5. Client1 requests relay1 on port 443 without GZIP - response is incomplete

Expected length: 547204
Received length: 396424

[Response Headers]
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: close
Content-Length: 547204
Content-Type: application/javascript
Date: Mon, 08 May 2017 11:14:59 GMT
ETag: "60319-85984-54efe1ae42be3"
Last-Modified: Mon, 08 May 2017 07:22:43 GMT
Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips
Vary: Accept-Encoding

6. Client1 requests relay1 on port 443 with GZIP - response is complete.


So non-gzipped response from behind the relay1 is incomplete while doing TLS 
termination.
Files server.js and client.php can be provided upon request.

Any ideas?

Br

Re: OpenBSD 6.1: relayd does not start more than 3 processes

[Maxim Bourmistrov]

> 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov :
> 
> 
>> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
>> 
>> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>>> 
>>> Hey,
>>> on OpenBSD 6.0-stable I have following configuration for relayd:
>>> 
>>> snip———
>>> interval 10
>>> timeout 1200
>>> prefork 15
>>> log all
>>> ——
>>> 
>>> Respective login.conf to spawn more relayd procs:
>>> 
>>> relayd:\
>>>   :maxproc-max=31:\
>>>   :maxproc-cur=15:\
>>>   :openfiles=65536:\
>>>   :tc=daemon:
>>> 
>>> 
>>> With config options above moved to a 6.1 creates following:
>>> 
>>> relayd starts but brings up no more that 3 relay-processes.
>>> Also after start up it refuses to do any checks configured (in my simple 
>>> test I used check tcp) 
>>> 
>>> [mxb-test]-[12:21:41]# relayctl sh su
>>> Id  TypeNameAvlblty Status
>>> 1   relay   rabbitmqactive
>>> 1   table   rabbitmqpool:5672   empty
>>> 1   host10.5.96.8   unknown
>>> 2   table   rabbitmqfallback:5672   empty
>>> 2   host10.5.96.9   unknown
>>> 
>>> 
>>> Changing ’prefork’ from 15 to 3 makes it work.
>>> 
>>> Is this a bug?
>>> 
>>> Br
>>> 
>>> 
>>> 
>> 
>> Hey,
>> 
>> This is a random guess since you haven't posted the whole config, but I think
>> it has bitten me too sometime:
>> 
>> Do you have the global options such as prefork defined before your
>> relays and routes or not?
>> 
>> The order of the global options matter. If the global options are set after
>> the table they are not initialized on the tables and can actually crash 
>> relayd.
>> This is because the health checking uses a different prefork value and checks
>> the "wrong" amount.
>> 
>> I'm not sure, but I think it is not a bug: it is documented in 
>> relayd.conf(5).
>> 
>> Thinking about it: would it be acceptable if `relayd -n` shows a warning if
>> global options are defined in the wrong order? I can write the patch for it
>> if it makes sense.
>> 
>> I hope this helps you in some way,
>> 
>> -- 
>> Kind regards,
>> Hiltjo
> 
> The whole config is like this:
> 
> include "/etc/pj/nz/akl1/shared/pf/int/networks"
> include "/etc/pj/nz/akl1/shared/pf/int/common_tables"
> 
> interval 10
> timeout 1000
> prefork 3 #15
> log all
> 
> #include "/etc/pj/shared/relayd/protocols"
> 
> tcp protocol tcp_proto {
>tcp { nodelay, sack, socket buffer 65536, backlog 128 }
> }
> 
> relay rabbitmq {
>listen on 10.5.128.16 port 5674
> #protocol tcp_proto
> #   session timeout 10800
>forward to  port 5672 mode roundrobin check tcp
>forward to  port 5672 mode roundrobin check tcp
> }
> 
> Tables are shared with PF so I don’t have to re-define those.
> ”common_tables” in config contains:
> 
> table  { $RMQ1_VLAN302 }
> table  { $RMQ2_VLAN302 }
> 
> I seems not be able to find a place in manage were it states that global 
> options need to go before
> table definitions. 
> 
> Note, config layout exactly the same which runs already on 6.0-stable.
> 
> My original question is why I can’t fork more than 3 procs any more
> and why relayd starts then prefork > 3 and does not do a health check.
> 
> Br

Hm, I tried this out - re-ordering the layout of the config.
You are, indeed, correct here.

Strange that this runs on 6.0.

Case closed.
Sorry for the noise.

Br

Re: OpenBSD 6.1: relayd does not start more than 3 processes

[Maxim Bourmistrov]

> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
> 
> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>> 
>> Hey,
>> on OpenBSD 6.0-stable I have following configuration for relayd:
>> 
>> snip———
>> interval 10
>> timeout 1200
>> prefork 15
>> log all
>> ——
>> 
>> Respective login.conf to spawn more relayd procs:
>> 
>> relayd:\
>>:maxproc-max=31:\
>>:maxproc-cur=15:\
>>:openfiles=65536:\
>>:tc=daemon:
>> 
>> 
>> With config options above moved to a 6.1 creates following:
>> 
>> relayd starts but brings up no more that 3 relay-processes.
>> Also after start up it refuses to do any checks configured (in my simple 
>> test I used check tcp) 
>> 
>> [mxb-test]-[12:21:41]# relayctl sh su
>> Id  TypeNameAvlblty Status
>> 1   relay   rabbitmqactive
>> 1   table   rabbitmqpool:5672   empty
>> 1   host10.5.96.8   unknown
>> 2   table   rabbitmqfallback:5672   empty
>> 2   host10.5.96.9   unknown
>> 
>> 
>> Changing ’prefork’ from 15 to 3 makes it work.
>> 
>> Is this a bug?
>> 
>> Br
>> 
>> 
>> 
> 
> Hey,
> 
> This is a random guess since you haven't posted the whole config, but I think
> it has bitten me too sometime:
> 
> Do you have the global options such as prefork defined before your
> relays and routes or not?
> 
> The order of the global options matter. If the global options are set after
> the table they are not initialized on the tables and can actually crash 
> relayd.
> This is because the health checking uses a different prefork value and checks
> the "wrong" amount.
> 
> I'm not sure, but I think it is not a bug: it is documented in relayd.conf(5).
> 
> Thinking about it: would it be acceptable if `relayd -n` shows a warning if
> global options are defined in the wrong order? I can write the patch for it
> if it makes sense.
> 
> I hope this helps you in some way,
> 
> -- 
> Kind regards,
> Hiltjo

The whole config is like this:

include "/etc/pj/nz/akl1/shared/pf/int/networks"
include "/etc/pj/nz/akl1/shared/pf/int/common_tables"

interval 10
timeout 1000
prefork 3 #15
log all

#include "/etc/pj/shared/relayd/protocols"

tcp protocol tcp_proto {
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}

relay rabbitmq {
listen on 10.5.128.16 port 5674
#protocol tcp_proto
#   session timeout 10800
forward to  port 5672 mode roundrobin check tcp
forward to  port 5672 mode roundrobin check tcp
}

Tables are shared with PF so I don’t have to re-define those.
”common_tables” in config contains:

table  { $RMQ1_VLAN302 }
table  { $RMQ2_VLAN302 }

I seems not be able to find a place in manage were it states that global 
options need to go before
table definitions. 

Note, config layout exactly the same which runs already on 6.0-stable.

My original question is why I can’t fork more than 3 procs any more
and why relayd starts then prefork > 3 and does not do a health check.

Br
 

OpenBSD 6.1: relayd does not start more than 3 processes

[Maxim Bourmistrov]

Hey,
on OpenBSD 6.0-stable I have following configuration for relayd:

snip———
interval 10
timeout 1200
prefork 15
log all
——
 
Respective login.conf to spawn more relayd procs:

relayd:\
:maxproc-max=31:\
:maxproc-cur=15:\
:openfiles=65536:\
:tc=daemon:


With config options above moved to a 6.1 creates following:

relayd starts but brings up no more that 3 relay-processes.
Also after start up it refuses to do any checks configured (in my simple test I 
used check tcp) 

[mxb-test]-[12:21:41]# relayctl sh su
Id  TypeNameAvlblty Status
1   relay   rabbitmqactive
1   table   rabbitmqpool:5672   empty
1   host10.5.96.8   unknown
2   table   rabbitmqfallback:5672   empty
2   host10.5.96.9   unknown


Changing ’prefork’ from 15 to 3 makes it work.

Is this a bug?

Br

Relayd: session timeout

[Maxim Bourmistrov]

Hey list,

I have following relay configured on two-node setup. Each node acts as MASTER 
for one IP and BACKUP for another.
The opposite on the second node.


tcp protocol tcp_proto {
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}

relay rabbitmq {
listen on $VIP1 port 5672
listen on $VIP2 port 5672
protocol tcp_proto
#   session timeout 10800
forward to  port 5672 mode roundrobin check tcp
forward to  port 5672 mode roundrobin check tcp
}

Default timeout is 600s (10 min).

In my test I have a client requesting data from a machine(web1) sitting behind 
this relay(node1).
web1 has its def gw pointed to node1, e.g. NAT:ed.
node1, obviously, have EXT and INT interfaces, VIP1 and VIP2 been external ones.

What I see in tcpdump running on both EXT and INT interfaces is a tcp stream 
between 
client and web1 via node1 - PUSH ACK. At some point (600s) node1 cuts the 
connection (FIN seen in tcpdump).

Question is this expected behavior?
As states in PF are updated due to continuous tcp stream, session shouldn’t be 
cut, right?
Any clues?

node1 runs 6.0-stable

Br
mxb

Re: Playstations and PF de-fragmentation

[Maxim Bourmistrov]

Thanks for sharing.
I’ll re-use this at home.

Br

> 1 maj 2017 kl. 01:43 skrev Kevin Chadwick :
> 
> 
> I find that to prevent connection timeouts on playstations, the
> following is required. Hopefully they will fix their packet AND
> connection handling one day.
> 
> match from ! $ps3 scrub(tcp reassembly)
> match from $ps3 scrub(without tcp reassembly)
> 

Re: torrent downloads

[Maxim Bourmistrov]

ISO is burned down to the CD you buy.
To install you really just need to PXE.


> 27 apr. 2017 kl. 13:55 skrev Thuban :
> 
> Hello,
> I was wondering if there is any particular reason explaining why there
> is no torrent file to retrieve OpenBSD *.fs and *.iso. 
> 
> I've been looking on the list and only found this site that doesn't
> seems up to date [1].
> 
> If the reason is a lack of human ressources, I think I can handle it.
> 
> Regards.
> 
> [1] : http://openbsd.somedomain.net/
> -- 
>  

Re: 6.1: /usr/local/bin/node: W^X binary outside wxallowed mountpoint

[Maxim Bourmistrov]

Thanks all for replying.
The key part was 1) in Todds’ answer.

Mounted /home with wxallowed already.
Just needed to ’cp’ binary into it.

Br

> 25 apr. 2017 kl. 22:43 skrev Todd C. Miller :
> 
> On Tue, 25 Apr 2017 16:49:36 +0200, Maxim Bourmistrov wrote:
> 
>> Any work around for this one?
>> 
>> Mount with wxallowed not working.
> 
> Two things are required:
> 
> 1) The binary must be on a file system mounted with the wxallowed
>   option.
> 
> 2) The binary must have the OPENBSD_WXNEED type in the ELF header.
> 
> You can check for #2 by running "readelf -l /usr/local/bin/node".
> The output should include a section similar to the following.
> If you don't see OPENBSD_WXNEED in there, that is the problem
> and you probably need to update your packages to the 6.1 versions.
> 
> Program Headers:
>  Type   Offset VirtAddr   PhysAddr
> FileSizMemSiz  Flags  Align
>  PHDR   0x0040 0x0040 0x0040
> 0x0348 0x0348  R E8
>  INTERP 0x00af82be 0x00bf82be 0x00bf82be
> 0x0013 0x0013  R  1
>  [Requesting program interpreter: /usr/libexec/ld.so]
>  LOAD   0x 0x 0x
> 0x00af82be 0x00af82be  R E10
>  LOAD   0x00af82be 0x00bf82be 0x00bf82be
> 0x00bfe59a 0x00bfe59a  R  10
>  LOAD   0x016f6910 0x018f6910 0x018f6910
> 0x000a5af0 0x000b6e00  RW 10
>  DYNAMIC0x0177dda8 0x0197dda8 0x0197dda8
> 0x01b0 0x01b0  RW 8
>  NOTE   0x00af82d4 0x00bf82d4 0x00bf82d4
> 0x0018 0x0018  R  4
>  GNU_EH_FRAME   0x01533634 0x01633634 0x01633634
> 0x00049dac 0x00049dac  R  4
>  OPENBSD_WXNEED 0x 0x 0x
> 0x 0xE8
>  OPENBSD_RANDOM 0x016f6910 0x018f6910 0x018f6910
> 0x0008 0x0008  RW 8
>  GNU_RELRO  0x016f6910 0x018f6910 0x018f6910
> 0x0008f6f0 0x0008f6f0  R  1
> 

6.1: /usr/local/bin/node: W^X binary outside wxallowed mountpoint

[Maxim Bourmistrov]

Hey,
Any work around for this one?

Mount with wxallowed not working.

Br

Re: Can't kill a state with pfctl?

[Maxim Bourmistrov]

I’m doing something like this at home.

table  persist

### block machines out
block out quick on egress tagged BLOCK
pass out quick on egress from  to any nat-to (egress:0) keep
state \
(max-src-conn 1, max-src-conn-rate 1/1, overload 
flush global) tag BLOCK


Then I just add IP to , the rest will be fixed per auto, eg
blocking and flushing states.

Note that  really DOES NOT EXIST. Never created.
Not sure of implication on the underlying system. Maybe it leaks RAM or
something else.


> 5 mars 2017 kl. 08:30 skrev luckman212 :
>
> Is 7 years too long to wait for an answer?
>
> I had been struggling with the same issue/question, and since yours was the
> only related post I could find, I figured I'd come back to share what I
> found. Try putting a slash and then the creatorid, like this:
>
> I didn't test this on OpenBSD but I did test it on pfSense which I believe
> uses a very similar if not identical binary.
>
>
>
> --
> View this message in context:
http://openbsd-archive.7691.n7.nabble.com/Can-t-kill-a-state-with-pfctl-tp100
879p314187.html
> Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: relayd(8) relay: redirect based on URL paths

[Maxim Bourmistrov]

table  { 192.168.10.31 }
table  { 192.168.10.78 }

http protocol somename {
tcp { nodelay, sack, backlog 1024 }
match header set "Proxy" value "filtered"
match header set "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$REMOTE_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"
match request header remove "Proxy"

match request path "/hello*" forward to 
}

relay somerelay {
   listen on 1.2.3.4 port 80
   protocol somename
   forward to  port 80 mode roundrobin check http "/" code 200
   forward to  port 92 mode roundrobin check tcp
}


Something like this.

But there is a catch with PF in between.
Once client hits http://whatever.org/hello , PF state will be created and if
it tries to reach normal http://whatever.org it WILL BE
redirected to servers housing /hello part.

One way to solve it is to lower tcp.established towards internal machines. In
example above, to :

pass out on { $INT_IF } proto tcp from self to  port 92 keep state
(tcp.established 10)

br
P.S.
In my env. I share file with tables between pf and relayd. eg include
”/etc/pf/tables” in relays.conf .


> 23 feb. 2017 kl. 03:02 skrev Lyndon Nerenberg :
>
> My relayd.conf fu is lame and needs help.  Given the following config:
>
>
> ---8<---8<---
>
> interval 60
> timeout 2000
>
> table  { w1.example.com w2.example.com w3.example.com }
>
> http protocol https {
>
>tcp { nodelay, sack }
>match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
>match request header append "X-Forwarded-By" \
>value "$SERVER_ADDR:$SERVER_PORT"
>match request header set "Connection" value "close"
>
> }
>
> relay web {
>
>listen on 203.0.113.5 port 443 tls
>protocol https
>
>forward with tls to  port https mode loadbalance \
>check https "/" code 200
>
> }
>
> ---8<---8<---
>
> I am trying to figure out how to intercept request paths beginning with
"/xy/"
> so that I can forward them to a different port in the same server pool.
> I.e.:
>
>  https://host.example.com/xy/mumblebarge ->
> https://:/xy/mumblebarge
>
>  https://host.example.com/anything_else  ->
https:///anything_else
>
> It seems this should be possible, but I just can't get my head around
> relayd.conf(5) :-(
>
> --lyndon

Re: Content filtering through pf?

[Maxim Bourmistrov]

privoxy will be faster I think. as well as footprint on the system.
But both privoxy and squid are a bit different, especially if you’ll need to
chain proxies.


> 24 feb. 2017 kl. 17:39 skrev Alan Corey :
>
> I'm looking at privoxy although I'm not sure it's more appropriate
> than squid.  I'm hoping to run this on a Raspberry Pi or Zero so it'll
> most likely be under Raspbian.

Re: two ip with carp

[Maxim Bourmistrov]

Just create carp3 and configure it the same way as carp0, except for the
password.
No aliases what so ever. Later in pf.conf do a nat-to from dnz to carp3.

fw1# ifconfig trunk0
trunk0: flags=8943 mtu 1500
lladdr 00:25:90:f9:74:b0
index 7 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,00:25:90:f9:74:b0,403C,,),
 (0001,1c:aa:07:01:9b:80,0001,,)]
trunkport ix3 active,collecting,distributing
trunkport ix0 active,collecting,distributing
groups: trunk egress
media: Ethernet autoselect
status: active
inet 155.4.x.121 netmask 0xff80 broadcast 155.4.x.127

fw1# ifconfig carp165
carp165: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:a5
description: VIP65
index 53 priority 15 llprio 3
carp: MASTER carpdev trunk0 vhid 165 advbase 1 advskew 0
groups: carp
status: master
inet 155.4.x.65 netmask 0xff80 broadcast 155.4.x.127

fw1# ifconfig carp167
carp167: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:a7
description: VIP67
index 75 priority 15 llprio 3
carp: MASTER carpdev trunk0 vhid 167 advbase 1 advskew 0
groups: carp
status: master
inet 155.4.x.67 netmask 0xff80 broadcast 155.4.x.127

fw1# cat /etc/hostname.carp165
inet 155.4.x.65 255.255.255.128 155.4.x.127 -inet6 vhid 165 advbase 1 advskew
0 carpdev trunk0 pass abc1234 description VIP65

fw1# cat /etc/hostname.carp167
inet 155.4.x.67 255.255.255.128 155.4.x.127 -inet6 vhid 167 advbase 1 advskew
0 carpdev trunk0 pass 1234abc description VIP67



> 27 feb. 2017 kl. 12:07 skrev Frank White :
>
> hi,
> I have 2 firewall in cluster with carp. The following is my configuration
> (8.x.x.x are examples for wan ip):
> first firewall
> 1) bnx0 8.8.8.7 (internet)
> 2) bge0 192.168.100.2 (lan)
> 3) bnx1 pfsync
> 4) 10.1.1.2 dmz
>
> carp0 8.8.8.8 (internet)
> carp1 192.168.100.1 (gateway for the lan)
> carp2 10.1.1.1 (gateway for the dmz)
>
> now I want add the ip 8.8.8.10 to redirect all traffic from it to the
dmz...
> how should I configure it ?
> I know how to redirect the traffic with pf.. my question concern how to
> configure carp and the nic..
> for example should I create a new carp with ip 8.8.8.10 and an alias for
> the bnx0 with ip 8.8.8.11 ?

Re: OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

Ok, this smells like a buggy implementation of OSPF on the dot-com
vendor-side.
Upgrade of firmware on the both Cisco Nexus 3000-series to
NXOS: version 7.0(3)I4(4) fixed my problem with
ospf stuck in EXCHG/EXSTA.

Setup involving Dell switch shows following then ospfd on the obsd side is run
with ’-dvvv’:

spf_calc: area 0.0.0.0 calculated
nbr_fsm: event HELLO_RECEIVED resulted in action START_INACTIVITY_TIMER and
changing state for neighbor ID 10.4.255.26 from DOWN to INIT
nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for
neighbor ID 10.4.255.26 from INIT to 2-WAY
if_fsm: event NEIGHBORCHANGE resulted in action NOTHING and changing state for
interface trunk1 from WAIT to WAIT
nbr_fsm: event HELLO_RECEIVED resulted in action START_INACTIVITY_TIMER and
changing state for neighbor ID 10.4.255.29 from DOWN to INIT
nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for
neighbor ID 10.4.255.29 from INIT to 2-WAY
if_fsm: event NEIGHBORCHANGE resulted in action NOTHING and changing state for
interface trunk1 from WAIT to WAIT
recv_db_description: neighbor ID 10.4.255.29: packet ignored in state 2-WAY
if_act_elect: interface trunk1 old dr none new dr 10.4.255.29, old bdr none
new bdr 10.4.255.26
nbr_fsm: event ADJ_OK resulted in action EVAL and changing state for neighbor
ID 10.4.255.29 from 2-WAY to EXSTA
nbr_fsm: event ADJ_OK resulted in action EVAL and changing state for neighbor
ID 10.4.255.26 from 2-WAY to EXSTA
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface trunk1
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface trunk1
if_fsm: event BACKUPSEEN resulted in action ELECT and changing state for
interface trunk1 from WAIT to OTHER
nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing state
for neighbor ID 10.4.255.29 from EXSTA to SNAP
nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing
state for neighbor ID 10.4.255.29 from SNAP to EXCHG
recv_db_description: dupe from neighbor ID 10.4.255.29
recv_db_description: neighbor ID 10.4.255.29: seq num mismatch, bad flags
nbr_fsm: event SEQ_NUM_MISMATCH resulted in action RESET_DD and changing state
for neighbor ID 10.4.255.29 from EXCHG to EXSTA
nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing state
for neighbor ID 10.4.255.29 from EXSTA to SNAP
nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing
state for neighbor ID 10.4.255.29 from SNAP to EXCHG
recv_db_description: dupe from neighbor ID 10.4.255.29
recv_db_description: neighbor ID 10.4.255.29: seq num mismatch, bad flags

Eg:
recv_db_description: dupe from neighbor ID 10.4.255.29
recv_db_description: neighbor ID 10.4.255.29: seq num mismatch, bad flags



> 14 feb. 2017 kl. 11:56 skrev Maxim Bourmistrov :
>
>
>> 14 feb. 2017 kl. 11:33 skrev Jeremie Courreges-Anglas mailto:j...@wxcvbn.org>>:
>>
>> I have no idea why you're getting this kind of error, but maybe you
>> can simplify your setup a bit more.  Can you reproduce when using just
>> em1 (out of the trunk) instead of trunk1?  Just bnx1?
>
> I’ll try to modd this setup.
>
> Any how, I see almost exactly the same behavior with another setup
> involving  Cisco Nexus 3000-series.
> Similarities in those two is - trunk used in both locations.
> However reboot does not solve problem with Nexus.
>
> [fw1]-[11:33:02]# ospfctl sh nei
> ID  Pri StateDeadTime Address Iface Uptime
> 10.6.255.1  1   2-WAY/OTHER  00:00:38 10.6.255.1  trunk1-
> 10.6.255.28 1   2-WAY/OTHER  00:00:35 10.6.255.28 trunk1-
> 10.6.255.2  1   2-WAY/OTHER  00:00:38 10.6.255.2  trunk1-
> 10.6.255.30 1   EXSTA/DR 00:00:31 10.6.255.30 trunk1-
> 10.6.255.29 1   FULL/BCKUP   00:00:35 10.6.255.29 trunk1
01:24:41
>
>
> [fw2]-[11:45:00]# ospfctl sh nei
> ID  Pri StateDeadTime Address Iface Uptime
> 10.6.255.1  1   2-WAY/OTHER  00:00:37 10.6.255.1  trunk1-
> 10.6.255.27 1   2-WAY/OTHER  00:00:37 10.6.255.27 trunk1-
> 10.6.255.2  1   2-WAY/OTHER  00:00:37 10.6.255.2  trunk1-
> 10.6.255.30 1   EXCHG/DR 00:00:39 10.6.255.30 trunk1-
> 10.6.255.29 1   EXSTA/BCKUP  00:00:31 10.6.255.29 trunk1-
>
> fw1/fw2 - openbsd 6.0-stable
> fw1 local IP on trunk1 - 10.6.255.27
> fw2 local IP on trunk1 - 10.6.255.28
>
> 10.6.255.{1,2} - openbsd 5.9-stable VMs
>
> 10.6.255.{29,30} - two Nexus with vPC (MLAG)
>
> fw1/fw2 connected to both switches and forming vPC (vPC on top of LAPC. LACP
required for vPC to work).
> Both are identical hardware wise as well as configuration wise.
>
> trunk1: flags=8943 mtu 1500
> lladdr a0:36:9f:37:d3:60
> description: VLAN990
> index 8 pr

Re: OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

> 14 feb. 2017 kl. 11:33 skrev Jeremie Courreges-Anglas :
>
> I have no idea why you're getting this kind of error, but maybe you
> can simplify your setup a bit more.  Can you reproduce when using just
> em1 (out of the trunk) instead of trunk1?  Just bnx1?

I’ll try to modd this setup.

Any how, I see almost exactly the same behavior with another setup
involving  Cisco Nexus 3000-series.
Similarities in those two is - trunk used in both locations.
However reboot does not solve problem with Nexus.

[fw1]-[11:33:02]# ospfctl sh nei
ID  Pri StateDeadTime Address Iface Uptime
10.6.255.1  1   2-WAY/OTHER  00:00:38 10.6.255.1  trunk1-
10.6.255.28 1   2-WAY/OTHER  00:00:35 10.6.255.28 trunk1-
10.6.255.2  1   2-WAY/OTHER  00:00:38 10.6.255.2  trunk1-
10.6.255.30 1   EXSTA/DR 00:00:31 10.6.255.30 trunk1-
10.6.255.29 1   FULL/BCKUP   00:00:35 10.6.255.29 trunk101:24:41


[fw2]-[11:45:00]# ospfctl sh nei
ID  Pri StateDeadTime Address Iface Uptime
10.6.255.1  1   2-WAY/OTHER  00:00:37 10.6.255.1  trunk1-
10.6.255.27 1   2-WAY/OTHER  00:00:37 10.6.255.27 trunk1-
10.6.255.2  1   2-WAY/OTHER  00:00:37 10.6.255.2  trunk1-
10.6.255.30 1   EXCHG/DR 00:00:39 10.6.255.30 trunk1-
10.6.255.29 1   EXSTA/BCKUP  00:00:31 10.6.255.29 trunk1-

fw1/fw2 - openbsd 6.0-stable
fw1 local IP on trunk1 - 10.6.255.27
fw2 local IP on trunk1 - 10.6.255.28

10.6.255.{1,2} - openbsd 5.9-stable VMs

10.6.255.{29,30} - two Nexus with vPC (MLAG)

fw1/fw2 connected to both switches and forming vPC (vPC on top of LAPC. LACP
required for vPC to work).
Both are identical hardware wise as well as configuration wise.

trunk1: flags=8943 mtu 1500
lladdr a0:36:9f:37:d3:60
description: VLAN990
index 8 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,a0:36:9f:37:d3:60,4045,,),
 (7F9B,00:23:04:ee:be:01,802E,,)]
trunkport ix1 active,collecting,distributing
trunkport ix2 active,collecting,distributing
groups: trunk
media: Ethernet autoselect
status: active
inet 10.6.255.28 netmask 0xffe0 broadcast 10.6.255.31


Sometimes fw1/fw2 get connected to both switches. Sometimes not. Sometimes to
only one, sometimes to none.

[fw2]-[11:52:00]# tcpdump -n -i trunk1 proto ospf
tcpdump: listening on trunk1, link-type EN10MB
11:52:09.039855 10.6.255.1 > 224.0.0.5: OSPFv2-hello  64: rtrid 10.6.255.1
backbone dr 10.6.255.30 bdr 10.6.255.29 [tos 0xc0] [ttl 1]
11:52:09.039901 10.6.255.28 > 224.0.0.5: OSPFv2-hello  64: rtrid 10.6.255.28
backbone dr 10.6.255.30 bdr 10.6.255.29 [tos 0xc0] [ttl 1]
11:52:09.039981 10.6.255.27 > 224.0.0.5: OSPFv2-hello  64: rtrid 10.6.255.27
backbone dr 10.6.255.30 bdr 10.6.255.29 [tos 0xc0] [ttl 1]
11:52:09.040108 10.6.255.2 > 224.0.0.5: OSPFv2-hello  64: rtrid 10.6.255.2
backbone dr 10.6.255.30 bdr 10.6.255.29 [tos 0xc0] [ttl 1]
11:52:09.463707 10.6.255.30 > 10.6.255.28: OSPFv2-dd  32: rtrid 10.6.255.30
backbone E I/M/MS mtu 1500 S 3522476A [tos 0xc0] [ttl 1]
11:52:09.463798 10.6.255.28 > 10.6.255.30: OSPFv2-dd  32: rtrid 10.6.255.28
backbone E I/M/MS mtu 1500 S 352265AF [tos 0xc0] [ttl 1]
11:52:09.955800 10.6.255.29 > 10.6.255.28: OSPFv2-dd  32: rtrid 10.6.255.29
backbone E I/M/MS mtu 1500 S 84F508D [tos 0xc0] [ttl 1]
11:52:09.955838 10.6.255.28 > 10.6.255.29: OSPFv2-dd  32: rtrid 10.6.255.28
backbone E I/M/MS mtu 1500 S 84F932C [tos 0xc0] [ttl 1]
11:52:10.832978 10.6.255.2 > 224.0.0.6: OSPFv2-ls_upd  64: rtrid 10.6.255.2
backbone [tos 0xc0] [ttl 1]
11:52:11.278971 10.6.255.1 > 224.0.0.6: OSPFv2-ls_upd  72: rtrid 10.6.255.1
backbone [tos 0xc0] [ttl 1]
11:52:11.560311 10.6.255.30 > 224.0.0.5: OSPFv2-hello  64: rtrid 10.6.255.30
backbone dr 10.6.255.30 bdr 10.6.255.29 [tos 0xc0] [ttl 1]
11:52:11.596931 10.6.255.30 > 224.0.0.5: OSPFv2-ls_ack  64: rtrid 10.6.255.30
backbone [tos 0xc0] [ttl 1]
11:52:14.475690 10.6.255.28 > 10.6.255.30: OSPFv2-dd  32: rtrid 10.6.255.28
backbone E I/M/MS mtu 1500 S 352265AF [tos 0xc0] [ttl 1]
11:52:14.730459 10.6.255.30 > 10.6.255.28: OSPFv2-dd  32: rtrid 10.6.255.30
backbone E I/M/MS mtu 1500 S 3522476A [tos 0xc0] [ttl 1]
11:52:14.730613 10.6.255.28 > 10.6.255.30: OSPFv2-dd  132: rtrid 10.6.255.28
backbone E M mtu 1500 S 3522476A [tos 0xc0] [ttl 1]
11:52:14.965713 10.6.255.28 > 10.6.255.29: OSPFv2-dd  32: rtrid 10.6.255.28
backbone E I/M/MS mtu 1500 S 84F932C [tos 0xc0] [ttl 1]
11:52:15.019118 10.6.255.29 > 10.6.255.28: OSPFv2-dd  32: rtrid 10.6.255.29
backbone E I/M/MS mtu 1500 S 84F508D [tos 0xc0] [ttl 1]
11:52:15.019252 10.6.255.28 > 10.6.255.29: OSPFv2-dd  132: rtrid 10.6.255.28
backbone E M mtu 1500 S 84F508D [tos 0xc0] [ttl 1]
11:52:16.287215 10.6.255.1 > 224.0.0.6: OSPFv2-ls_upd  72: rtrid 10.6.255.1
backbone [tos 0xc0] [ttl 1]
^C
68 packets received by filter
0 packets dr

Re: OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

Unfortunately, this diff alone does not solves this problem.
Again, only reboot solved it.

Before reboot, ospfd from 6.0-stable patched with this diff:

# ospfctl sh nei
ID  Pri StateDeadTime Address Iface Uptime
10.4.255.26 1   FULL/BCKUP   00:00:38 10.4.255.26 trunk100:00:06
10.4.255.29 1   EXCHG/DR 00:00:36 10.4.255.29 trunk1-


After reboot:
# ospfctl sh nei
ID  Pri StateDeadTime Address Iface Uptime
10.4.255.26 1   FULL/BCKUP   00:00:33 10.4.255.26 trunk100:00:51
10.4.255.29 1   FULL/DR  00:00:36 10.4.255.29 trunk100:00:52



> 9 feb. 2017 kl. 15:26 skrev Peter Hessler :
>
> OSPF is sensitive to MTU changes.  You probably want the change in
>
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ospfd/ospfe.c.diff?r1=1
.96&r2=1.97
> from -current.  This will track interface MTU changes.
>
>
> On 2017 Feb 09 (Thu) at 14:51:05 +0100 (+0100), Maxim Bourmistrov wrote:
> :This actually a default setting for this switch, then you don’t
configure
> :jumbo at all.
> :'sh running-config all’ shows this.
> :
> :I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help,
so
> :it is gone now.
> :
> :I’ll try with 1518.
> :As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500
in
> :ospf.
> :ospfd complains in loggs on bad seq.
> :
> :ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num
mismatch,
> :bad flags
> :
> :Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while
initial
> :setup is already with MTU 1500?
> :
> ://mxb
> :
> :
> :> 9 feb. 2017 kl. 14:31 skrev Peter Hessler :
> :>
> :> Are you establishing an ospf session with the N3048?  If you are, then
> :> there is an MTU miss-match.
> :>
> :> Either "system jumbo mtu" refers to the IP packet, which doesn't match
> :> the 1500 set on trunk1, or it refers to the ethernet packet which should
> :> be 1518 (16 bytes for the ethernet header).
> :>
> :> Is it fixed if you change it to 1518, or drop that line completely?
> :>
> :>
> :>
> :> On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote:
> :> :I see similar behavior with Cisco Nexus and 5.9-stable.
> :> :How ever not 100% sure if it is the same trigger.
> :> :
> :> :
> :> :
> :> :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov
:
> :> :>
> :> :> Hey,
> :> :>
> :> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell
> :N3048
> :> :switch.
> :> :> According to some documentation around, this is due to MTU mismatch.
> :> :>
> :> :> This is not in my case.
> :> :>
> :> :> N3048:
> :> :> system jumbo mtu 1512
> :> :>
> :> :> obsd:
> :> :> trunk1: flags=8943
mtu
> :1500
> :> :>lladdr 00:25:90:78:62:b6
> :> :>description: HW_INTERNAL
> :> :>index 12 priority 0 llprio 3
> :> :>trunk: trunkproto lacp
> :> :>trunk id: [(8000,00:25:90:78:62:b6,4064,,),
> :> :> (0001,f8:b1:56:61:a1:e4,02AE,,)]
> :> :>trunkport bnx1 active,collecting,distributing
> :> :>trunkport em1 active,collecting,distributing
> :> :>groups: trunk
> :> :>media: Ethernet autoselect
> :> :>status: active
> :> :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31
> :> :>
> :> :> ping with diff size of pkts and tcpdump reveals that there is no MTU
> :> :mismatch.
> :> :>
> :> :> Restart of ospfd does not helps, only REBOOT.
> :> :>
> :> :> I decided to dig into this and found that changing MTU size on trunk1
> :can
> :> :reproduce this 100%.
> :> :> Actually value does not changes, but problem with ospfd can be
triggered
> :> :this way:
> :> :>
> :> :> # ifconfig trunk1 mtu 1500
> :> :> # rcctl restart ospfd
> :> :>
> :> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always.
> :> :>
> :> :> Then I tried to put mtu for each face involved in trunk1. Result is
then
> :> :same - triggered with ’ifconfig trunk1 mtu 1500’.
> :> :>
> :> :> # cat /etc/hostname.bnx1
> :> :> up mtu 1500
> :> :>
> :> :> # cat /etc/hostname.em1
> :> :> up mtu 1500
> :> :>
> :> :> Any ideas?
> :> :>
> :> :> Br
> :> :> mxb
> :> :
> :>
> :> --
> :> No matter how subtle the wizard, a knife in the shoulder blades will
> :> seriously cramp his style.
> :
>
> --
> It's not an optical illusion; it just looks like one.
>   -- Phil White

Re: OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

Hm, seems that I mistyped MTU in my original mail.

lacp system-priority 1
rate-limit cpu direction input pps 1024
system jumbo mtu 1518

It is 1518 by default.


> 9 feb. 2017 kl. 14:51 skrev Maxim Bourmistrov :
>
>
> This actually a default setting for this switch, then you don’t configure
jumbo at all.
> 'sh running-config all’ shows this.
>
> I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help,
so it is gone now.
>
> I’ll try with 1518.
> As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500
in ospf.
> ospfd complains in loggs on bad seq.
>
> ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num
mismatch, bad flags
>
> Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while initial
setup is already with MTU 1500?
>
> //mxb
>
>
>> 9 feb. 2017 kl. 14:31 skrev Peter Hessler :
>>
>> Are you establishing an ospf session with the N3048?  If you are, then
>> there is an MTU miss-match.
>>
>> Either "system jumbo mtu" refers to the IP packet, which doesn't match
>> the 1500 set on trunk1, or it refers to the ethernet packet which should
>> be 1518 (16 bytes for the ethernet header).
>>
>> Is it fixed if you change it to 1518, or drop that line completely?
>>
>>
>>
>> On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote:
>> :I see similar behavior with Cisco Nexus and 5.9-stable.
>> :How ever not 100% sure if it is the same trigger.
>> :
>> :
>> :
>> :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov :
>> :>
>> :> Hey,
>> :>
>> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell
N3048
>> :switch.
>> :> According to some documentation around, this is due to MTU mismatch.
>> :>
>> :> This is not in my case.
>> :>
>> :> N3048:
>> :> system jumbo mtu 1512
>> :>
>> :> obsd:
>> :> trunk1: flags=8943 mtu
1500
>> :>lladdr 00:25:90:78:62:b6
>> :>description: HW_INTERNAL
>> :>index 12 priority 0 llprio 3
>> :>trunk: trunkproto lacp
>> :>trunk id: [(8000,00:25:90:78:62:b6,4064,,),
>> :> (0001,f8:b1:56:61:a1:e4,02AE,,)]
>> :>trunkport bnx1 active,collecting,distributing
>> :>trunkport em1 active,collecting,distributing
>> :>groups: trunk
>> :>media: Ethernet autoselect
>> :>status: active
>> :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31
>> :>
>> :> ping with diff size of pkts and tcpdump reveals that there is no MTU
>> :mismatch.
>> :>
>> :> Restart of ospfd does not helps, only REBOOT.
>> :>
>> :> I decided to dig into this and found that changing MTU size on trunk1
can
>> :reproduce this 100%.
>> :> Actually value does not changes, but problem with ospfd can be
triggered
>> :this way:
>> :>
>> :> # ifconfig trunk1 mtu 1500
>> :> # rcctl restart ospfd
>> :>
>> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always.
>> :>
>> :> Then I tried to put mtu for each face involved in trunk1. Result is
then
>> :same - triggered with ’ifconfig trunk1 mtu 1500’.
>> :>
>> :> # cat /etc/hostname.bnx1
>> :> up mtu 1500
>> :>
>> :> # cat /etc/hostname.em1
>> :> up mtu 1500
>> :>
>> :> Any ideas?
>> :>
>> :> Br
>> :> mxb
>> :
>>
>> --
>> No matter how subtle the wizard, a knife in the shoulder blades will
>> seriously cramp his style.

Re: OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

This actually a default setting for this switch, then you don’t configure
jumbo at all.
'sh running-config all’ shows this.

I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help, so
it is gone now.

I’ll try with 1518.
As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500 in
ospf.
ospfd complains in loggs on bad seq.

ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num mismatch,
bad flags

Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while initial
setup is already with MTU 1500?

//mxb


> 9 feb. 2017 kl. 14:31 skrev Peter Hessler :
>
> Are you establishing an ospf session with the N3048?  If you are, then
> there is an MTU miss-match.
>
> Either "system jumbo mtu" refers to the IP packet, which doesn't match
> the 1500 set on trunk1, or it refers to the ethernet packet which should
> be 1518 (16 bytes for the ethernet header).
>
> Is it fixed if you change it to 1518, or drop that line completely?
>
>
>
> On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote:
> :I see similar behavior with Cisco Nexus and 5.9-stable.
> :How ever not 100% sure if it is the same trigger.
> :
> :
> :
> :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov :
> :>
> :> Hey,
> :>
> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell
N3048
> :switch.
> :> According to some documentation around, this is due to MTU mismatch.
> :>
> :> This is not in my case.
> :>
> :> N3048:
> :> system jumbo mtu 1512
> :>
> :> obsd:
> :> trunk1: flags=8943 mtu
1500
> :>lladdr 00:25:90:78:62:b6
> :>description: HW_INTERNAL
> :>index 12 priority 0 llprio 3
> :>trunk: trunkproto lacp
> :>trunk id: [(8000,00:25:90:78:62:b6,4064,,),
> :> (0001,f8:b1:56:61:a1:e4,02AE,,)]
> :>trunkport bnx1 active,collecting,distributing
> :>trunkport em1 active,collecting,distributing
> :>groups: trunk
> :>media: Ethernet autoselect
> :>status: active
> :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31
> :>
> :> ping with diff size of pkts and tcpdump reveals that there is no MTU
> :mismatch.
> :>
> :> Restart of ospfd does not helps, only REBOOT.
> :>
> :> I decided to dig into this and found that changing MTU size on trunk1
can
> :reproduce this 100%.
> :> Actually value does not changes, but problem with ospfd can be triggered
> :this way:
> :>
> :> # ifconfig trunk1 mtu 1500
> :> # rcctl restart ospfd
> :>
> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always.
> :>
> :> Then I tried to put mtu for each face involved in trunk1. Result is then
> :same - triggered with ’ifconfig trunk1 mtu 1500’.
> :>
> :> # cat /etc/hostname.bnx1
> :> up mtu 1500
> :>
> :> # cat /etc/hostname.em1
> :> up mtu 1500
> :>
> :> Any ideas?
> :>
> :> Br
> :> mxb
> :
>
> --
> No matter how subtle the wizard, a knife in the shoulder blades will
> seriously cramp his style.

Re: OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

I see similar behavior with Cisco Nexus and 5.9-stable.
How ever not 100% sure if it is the same trigger.



> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov :
>
> Hey,
>
> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048
switch.
> According to some documentation around, this is due to MTU mismatch.
>
> This is not in my case.
>
> N3048:
> system jumbo mtu 1512
>
> obsd:
> trunk1: flags=8943 mtu 1500
>lladdr 00:25:90:78:62:b6
>description: HW_INTERNAL
>index 12 priority 0 llprio 3
>trunk: trunkproto lacp
>trunk id: [(8000,00:25:90:78:62:b6,4064,,),
> (0001,f8:b1:56:61:a1:e4,02AE,,)]
>trunkport bnx1 active,collecting,distributing
>trunkport em1 active,collecting,distributing
>groups: trunk
>media: Ethernet autoselect
>status: active
>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31
>
> ping with diff size of pkts and tcpdump reveals that there is no MTU
mismatch.
>
> Restart of ospfd does not helps, only REBOOT.
>
> I decided to dig into this and found that changing MTU size on trunk1 can
reproduce this 100%.
> Actually value does not changes, but problem with ospfd can be triggered
this way:
>
> # ifconfig trunk1 mtu 1500
> # rcctl restart ospfd
>
> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always.
>
> Then I tried to put mtu for each face involved in trunk1. Result is then
same - triggered with ’ifconfig trunk1 mtu 1500’.
>
> # cat /etc/hostname.bnx1
> up mtu 1500
>
> # cat /etc/hostname.em1
> up mtu 1500
>
> Any ideas?
>
> Br
> mxb

OSPFd stucks in EXCHG/EXSTA

[Maxim Bourmistrov]

Hey,

ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048
switch.
According to some documentation around, this is due to MTU mismatch.

This is not in my case.

N3048:
system jumbo mtu 1512

obsd:
trunk1: flags=8943 mtu 1500
lladdr 00:25:90:78:62:b6
description: HW_INTERNAL
index 12 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,00:25:90:78:62:b6,4064,,),
 (0001,f8:b1:56:61:a1:e4,02AE,,)]
trunkport bnx1 active,collecting,distributing
trunkport em1 active,collecting,distributing
groups: trunk
media: Ethernet autoselect
status: active
inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31

ping with diff size of pkts and tcpdump reveals that there is no MTU
mismatch.

Restart of ospfd does not helps, only REBOOT.

I decided to dig into this and found that changing MTU size on trunk1 can
reproduce this 100%.
Actually value does not changes, but problem with ospfd can be triggered this
way:

# ifconfig trunk1 mtu 1500
# rcctl restart ospfd

and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always.

Then I tried to put mtu for each face involved in trunk1. Result is then same
- triggered with ’ifconfig trunk1 mtu 1500’.

# cat /etc/hostname.bnx1
up mtu 1500

# cat /etc/hostname.em1
up mtu 1500

Any ideas?

Br
mxb

OpenBSD 5.2-current - "panic: mtx_enter: locking against myself"

[Maxim Bourmistrov]

Hi,

I'm getting "panic: mtx_enter: locking against myself" on not so
-current OpenBSD 5.2-current (snapshot).

Machine is not dropping into ddb even if sysctl.conf says it should.
Console is filled with "panic: mtx_enter: locking against myself"
and seems to loop.

OpenBSD 5.2-current (GENERIC.MP) #378: Mon Aug 20 12:55:12 MDT 2012
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4284039168 (4085MB)
avail mem = 4147576832 (3955MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeadc0 (105 entries)
bios0: vendor American Megatrends Inc. version "4.6.4" date 06/30/2011
bios0: Supermicro X9SCL/X9SCM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET SPMI EINJ ERST HEST BERT
acpi0: wakeup devices PS2K(S1) PS2M(S1) UAR1(S4) UAR2(S4) BR20(S1)
EUSB(S4) USBE(S4) PEX0(S4) PEX4(S4) PEX6(S4) GBE_(S4) P0P1(S4) P0P2(S4)
P0P3(S4) P0P4(S4) SLPB(S0) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.30 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.02 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.02 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.02 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (BR20)
acpiprt2 at acpi0: bus 5 (PEX0)
acpiprt3 at acpi0: bus 6 (PEX4)
acpiprt4 at acpi0: bus -1 (PEX6)
acpiprt5 at acpi0: bus 1 (P0P1)
acpiprt6 at acpi0: bus 2 (P0P2)
acpiprt7 at acpi0: bus -1 (P0P3)
acpiprt8 at acpi0: bus -1 (P0P4)
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2195 MHz: speeds: 2201, 2200, 2100, 2000, 1900,
1800, 1700, 1600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 1 function 1 "Intel Core 2G PCIE" rev 0x09: msi
pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 "Intel 41210 PCIE-PCIX" rev 0x09
pci3 at ppb2 bus 3
bnx0 at pci3 dev 4 function 0 "Broadcom BCM5706" rev 0x02: apic 0 int 17
ppb3 at pci2 dev 0 function 2 "Intel 41210 PCIE-PCIX" rev 0x09
pci4 at ppb3 bus 4
bnx1 at pci4 dev 5 function 0 "Broadcom BCM5706" rev 0x02: apic 0 int 18
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msi, address
00:25:90:27:da:85
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: msi
pci5 at ppb4 bus 5
ppb5 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5: msi
pci6 at ppb5 bus 6
em1 at pci6 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi,
address 00:25:90:27:da:84
ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xa5
pci7 at ppb6 bus 7
vga1 at pci7 dev 3 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel C204 LPC" rev 0x05
ahci0 at pci0 dev 31 function 2 "Intel 6 Series AHCI" rev 0x05: msi,
AHCI 1.3
scsibus0 at

Re: PF: table sync

[Maxim Bourmistrov]

On Feb 5, 2012, at 8:17 PM, Camiel Dobbelaar wrote:

> On 5-2-2012 16:01, OSN | Marian Fischer wrote:
>> Am 05.02.2012 11:32, schrieb Maxim Bourmistrov:
>>> On Feb 5, 2012, at 10:47 AM, Otto Moerbeek wrote:
>>>
>>>> pfsync does not sync pf tables.
>>> Exactly, but it would be nice to have.
>>>
>>> //maxim
>>>
>> Hi,
>>
>> you should also take a look at wolfermann.org/pftabled.html
>>
>> Maybe that works out for you ...
>
> Syncing pf tables with a userland daemon could definitely work.
>
> I'm not sure that pftabled is still maintained though.  I reported a big
> flaw to the author in 2010 and it was never fixed.
>
>
> --
> Cam
>

"In-kernel" sync would be more elegant solution, a specially then everything
is already in place.
But I'll check this daemon out.

//maxim

Re: PF: table sync

[Maxim Bourmistrov]

On Feb 5, 2012, at 10:47 AM, Otto Moerbeek wrote:

> pfsync does not sync pf tables.

Exactly, but it would be nice to have.

//maxim

PF: table sync

[Maxim Bourmistrov]

Hi misc@,

my question is probably directed to devs working with/on PF.

Is something like table sync is planed to implement in PF?

eg:
"table  persist sync" would sync all entries to the remote peer, inc.
tracking add/del to it.

//maxim

Re: pfsync states growing on carp backup firewall

[Maxim Bourmistrov]

This bug will probably be fixed soon with a back-ported solution from
-current.
Meanwhile you can force all states on the failover-side to expire quicker.

I had (pf.conf):
set limit { states 5 } - rise nr. of states from default 1 to 5
set optimization aggressive - this sets exp. time for states to 5h
set timeout { adaptive.start 12000, adaptive.end 5 } - start reducing
exp.time if nr. of states reached 12000 and expire(flush) all if we reach
5.

You did not encounter it yet, but you probably will soon as I did.
States did not flush then, with default 1-limit I reached it. So
adaptive.start/end did it for me.

P.S.
Downside of this forced expire is if it flushes and you do failover and the
same time you'll lose all connections - no states.

//maxim


On Nov 9, 2011, at 10:58 AM, ML mail wrote:

> Hi Maxim,
>
> Thanks for your feedback. The firewall setup is productive already so I
don't really want to mess it up with compiling right now. I'de rather wait for
an official patch or upgrade to OpenBSD 5.1 next May.
>
> So in the meantime and as suggested I have used adaptive.start/.end to keep
the states at a reasonable value on the on the backup firewall with:
>
> set timeout { adaptive.start 1, adaptive.end 3 }
>
> So despite this small issue, is the fail-over with keeping states still
functional?
>
> Regards,
> ML
>
>
>
> - Original Message -
> From: Maxim Bourmistrov 
> To: ML mail 
> Cc: "misc@openbsd.org" 
> Sent: Wednesday, November 9, 2011 10:30 AM
> Subject: Re: pfsync states growing on carp backup firewall
>
>
> You might test to pull down if_pfsync.c from -current
> or
> flush states much sooner on failover with pf.conf (adaptive.start
adaptive.end)
>
> //maxim
>
> On Nov 9, 2011, at 9:49 AM, ML mail wrote:
>
>> Hi,
>>
>> I am running OpenBSD 5.0 amd64 on two firewalls using CARP (one master
>> and one backup) for redundancy/fail-over purpose. Now on the backup
firewall I
>> noticed that the states synchronised using pfsync on a dedicated NIC with
a
>> cross-over cable are at least double as much as on the master firewall. So
for
>> example right now there are 15k states on the master firewall and 40k on
the
>> backup firewall. From my understanding these numbers should pretty much
>> correlate.
>>
>> I don't have the feeling I've been doing anything wrong neither as
>> I have documented myself about how configuring CARP and have been running
it
>> successfully before using OpenBSD 4.4 (I just re-installed with OpenBSD
5.0).
>> Just in case here are the relevant hostname.* config files:
>>
>> #
>> /etc/hostname.em7 (master fw)
>> inet 10.10.10.1 255.255.255.0
>>
>> #
>> /etc/hostname.em7 (backup fw)
>> inet 10.10.10.2 255.255.255.0
>>
>>
>> #
>> /etc/hostname.pfsync0 (master fw)
>> up syncpeer 10.10.10.2 syndev em7
>>
>> #
>> /etc/hostname.pfsync0 (backup fw)
>> up syncpeer 10.10.10.1 syndev em7
>>
>> Could it
>> be that my cross-over cable is somehow faulty? or my config is wrong?
>>
>> Thanks
>> for the feedback.
>>
>> Regards,
>> ML

Re: pfsync states growing on carp backup firewall

[Maxim Bourmistrov]

You might test to pull down if_pfsync.c from -current
or
flush states much sooner on failover with pf.conf (adaptive.start
adaptive.end)

//maxim

On Nov 9, 2011, at 9:49 AM, ML mail wrote:

> Hi,
>
> I am running OpenBSD 5.0 amd64 on two firewalls using CARP (one master
> and one backup) for redundancy/fail-over purpose. Now on the backup firewall
I
> noticed that the states synchronised using pfsync on a dedicated NIC with a
> cross-over cable are at least double as much as on the master firewall. So
for
> example right now there are 15k states on the master firewall and 40k on
the
> backup firewall. From my understanding these numbers should pretty much
> correlate.
>
> I don't have the feeling I've been doing anything wrong neither as
> I have documented myself about how configuring CARP and have been running
it
> successfully before using OpenBSD 4.4 (I just re-installed with OpenBSD
5.0).
> Just in case here are the relevant hostname.* config files:
>
> #
> /etc/hostname.em7 (master fw)
> inet 10.10.10.1 255.255.255.0
>
> #
> /etc/hostname.em7 (backup fw)
> inet 10.10.10.2 255.255.255.0
>
>
> #
> /etc/hostname.pfsync0 (master fw)
> up syncpeer 10.10.10.2 syndev em7
>
> #
> /etc/hostname.pfsync0 (backup fw)
> up syncpeer 10.10.10.1 syndev em7
>
> Could it
> be that my cross-over cable is somehow faulty? or my config is wrong?
>
> Thanks
> for the feedback.
>
> Regards,
> ML

Re: CARP failover and states expiration

[Maxim Bourmistrov]

For the record:

mikeb@ picked this up in "PFSYNC - pf.conf best practice"-thread.

On 10/31/2011 12:48 PM, Henning Brauer wrote:

* Maxim Bourmistrov  [2011-10-26 08:23]:

I have a CARP setup in failover.
Is there any reason for ESTABLISHED states on the failover node to
have double expiration time?
Eg. on master the exp. time is 5h (set optimisation aggressive),
while on slave it is 10h.

wow. I have never noticed that. That is a bug.


Is there any way to control it?

find&  fix the bug :)

Re: PFSYNC - pf.conf best practice

[Maxim Bourmistrov]

I have this diff running on the failover-side currently.
I'v disabled all extra "set timeout"-settings on failover-side which I used to
hold down the exp. time.

The replication of exp. time seems to work.
I have a long-lived tcp connection which used to show up with double exp. time
on the failover-side.
The time for this connection is almost identical now on both sides(1 sec. is a
diff in between).

The rest of connections seems to be OK too - I don't see doubled exp. time
values anymore while scrolling in systat.

//maxim


On Oct 28, 2011, at 3:49 PM, Mike Belopuhov wrote:

> On Fri, Oct 28, 2011 at 11:25 AM, Mike Belopuhov  wrote:
>> On Thu, Oct 27, 2011 at 11:18 AM, Mike Belopuhov  wrote:
>>>>> On 26-10-2011 20:32, Maxim Bourmistrov wrote:
>>>>>> The side question, after observing 'systat -s1 states', is WHY
"failover"-side
>>>>>> doubles exp. time??
>>>>>> I'm more expected to have it like a "copy" of the current state of the
>>>>>> master.
>>>
>>> i've started looking into the problem, but it's not yet apparent as to
>>> why it happens.
>>>
>>
>> ok, so what i've figured out is that expire timeouts are transferred
>> as values of "rule->timeout[state->timeout]" and not absolute ones
>> (to compensate for a local time difference).  but when you insert
>> the rule into the state table you have to subtract the timeout value
>> as pf_state_expires does a good job itself by adding those back.
>>
>> so here's a diff. i've tried to solve "no adaptive scaling" caveat as
well.
>>
>> ok?
>>
>
> need to assign a rule pointer before dereferencing it, right?
>
> Index: if_pfsync.c
> ===
> RCS file: /cvs/src/sys/net/if_pfsync.c,v
> retrieving revision 1.169
> diff -u -p -u -p -r1.169 if_pfsync.c
> --- if_pfsync.c   20 Oct 2011 08:57:26 -  1.169
> +++ if_pfsync.c   28 Oct 2011 13:46:12 -
> @@ -266,6 +266,8 @@ void  pfsync_bulk_status(u_int8_t);
> void  pfsync_bulk_update(void *);
> void  pfsync_bulk_fail(void *);
>
> +u_int32_t pfsync_expires(const struct pf_state *, u_int32_t, u_int8_t);
> +
> #define PFSYNC_MAX_BULKTRIES  12
> int   pfsync_sync_ok;
>
> @@ -578,13 +580,7 @@ pfsync_state_import(struct pfsync_state
>   /* copy to state */
>   bcopy(&sp->rt_addr, &st->rt_addr, sizeof(st->rt_addr));
>   st->creation = time_second - ntohl(sp->creation);
> - st->expire = time_second;
> - if (sp->expire) {
> - /* XXX No adaptive scaling. */
> - st->expire -= r->timeout[sp->timeout] - ntohl(sp->expire);
> - }
>
> - st->expire = ntohl(sp->expire) + time_second;
>   st->direction = sp->direction;
>   st->log = sp->log;
>   st->timeout = sp->timeout;
> @@ -603,6 +599,8 @@ pfsync_state_import(struct pfsync_state
>   st->anchor.ptr = NULL;
>   st->rt_kif = NULL;
>
> + st->expire = pfsync_expires(st, ntohl(sp->expire), sp->timeout);
> +
>   st->pfsync_time = time_uptime;
>   st->sync_state = PFSYNC_S_NONE;
>
> @@ -948,7 +946,8 @@ pfsync_in_upd(caddr_t buf, int len, int
>   if (sync < 2) {
>   pfsync_alloc_scrub_memory(&sp->dst, &st->dst);
>   pf_state_peer_ntoh(&sp->dst, &st->dst);
> - st->expire = ntohl(sp->expire) + time_second;
> + st->expire = pfsync_expires(st, ntohl(sp->expire),
> + sp->timeout);
>   st->timeout = sp->timeout;
>   }
>   st->pfsync_time = time_uptime;
> @@ -1019,10 +1018,12 @@ pfsync_in_upd_c(caddr_t buf, int len, in
>   else
>   pf_state_peer_ntoh(&up->dst, &st->dst);
>   }
> +
>   if (sync < 2) {
>   pfsync_alloc_scrub_memory(&up->dst, &st->dst);
>   pf_state_peer_ntoh(&up->dst, &st->dst);
> - st->expire = ntohl(up->expire) + time_second;
> + st->expire = pfsync_expires(st, ntohl(up->expire),
> + up->timeout);
>   st->timeout = up->timeout;
>   }
>   st->pfsync_time = time_uptime;
> @@ -2330,4 +2331,37 @@ pfsync_sysctl(int *name, u_int namelen,
>   d

Re: pfsync on more than 2 hosts

[Maxim Bourmistrov]

On 10/27/2011 03:16 PM, Laurent CARON wrote:

On Wed, Oct 19, 2011 at 12:46:49PM +0200, Laurent CARON wrote:

Hi,

I'm currently wondering what is the best way to run pfsync between 4 hosts.

If I'm not mistaken, pfsync only has one interface, aka pfsync0

If I use it in unicast mode, i'm then stuck to 2 nodes.

The option would then be to have those 4 hosts exchange their states
over multicast.

Is it the way to go ?

Hi,

Is my question too trivial, or nobody ever tried it maybe ?

Thanks



According to man page multicast is default. But I'm reading 5.0-current.

//maxim

Re: PFSYNC - pf.conf best practice

[Maxim Bourmistrov]

Well, it is idle so far as it is not able to take care of dhcp-clients - dhcpd
listens on CARP which is not available at the moment.
This box is a slave to the named too, but updates of zone are not so frequent
due to the LAN-side.

I'll try to boot back origin bsd, but as of my knowledge, lager updates should
not(if any) increase number of states on the other side,
rather than remove many as requested and update many as requested.

I had my thoughts about MCLBYTES affecting the rest of the code, but not
checked it out at all.

pf.conf is ALLWAYS in sync on both sides. This is even stated clearly in
comments, incase any should take over after me.

//maxim


On Oct 26, 2011, at 8:50 PM, Camiel Dobbelaar wrote:

> On 26-10-2011 20:32, Maxim Bourmistrov wrote:
>> The side question, after observing 'systat -s1 states', is WHY
"failover"-side
>> doubles exp. time??
>> I'm more expected to have it like a "copy" of the current state of the
>> master.
>
> Yes, the number of states should be roughly in sync on both firewalls.
> I'd keep pf.conf in sync too (including all settings).
>
> Is the backup firewall really idle on all interfaces?
>
> Does it happen without the pfsync mtu changes too?  What does "netstat
> -s -p pfsync" say?
>
> What do you see if you capture "pfctl -ss | sort" on both firewalls (at
> the same time) and diff the outputs?

PFSYNC - pf.conf best practice

[Maxim Bourmistrov]

Hi list,
I have faced an interesting problem in active-failover setup for two OpenBSD
firewalls with CARP.
I'm not sure if this is my fault or if there is something else I just miss.

Two 5.0-current in active-failover setup share the same pf.conf.
Both are setup with CARP ext/int.
pf.conf is setup according to the official documentation, eg. guide on the
web.

The problem: steady growing number of states on the "failover" side.

With the default settings (states limit 1) I'm faced with the "failover"
side just refusing to accept any new states.
According to the man page it should zero all states at 120% of states limit,
yet I don't see it - max. 5 states are discarded thus I'm able to "ssh in",
but they are NOT zeroed
and flushed. Then I check out number of fails, etc. I see 40k, eg. far beyond
the tiem then it is time to zero and flush states(120%).

Thus I have increased the limit of states to 50k and defined
adaptive.start/adaptive.end to create states with lower exp.time.
Yet, number of states are growing on the "failover" side. On the running
master it is 6k, while on the failover it is 20k, eg. a bit over double of
states.
Setting constraint values for start/end adaptive flushes legit states. Sure,
they cat be re-created(master re-populates the "failover"-side)
but this takes time and in case of real failover they are just not there.

The side question, after observing 'systat -s1 states', is WHY "failover"-side
doubles exp. time??
I'm more expected to have it like a "copy" of the current state of the
master.

The question is do I miss something or are there ppl to point me to the right
direction to solve this?

//maxim

Re: pfsync0 MTU

[Maxim Bourmistrov]

I rolled out those patches on my prod. boxes and it works fine so far.

On 10/24/2011 03:59 PM, Maxim Bourmistrov wrote:


It seems to work as long as BOTH sides have equal setup, eg

 syncdev and pfsync are set with MTU 9000.

carp: pfsync0 demoted group carp by 1 to 129 (pfsync bulk start)
carp: pfsync0 demoted group pfsync by 1 to 1 (pfsync bulk start)
carp: pfsync0 demoted group carp by -1 to 128 (pfsync bulk done)
carp: pfsync0 demoted group pfsync by -1 to 0 (pfsync bulk done)

pfsync0: flags=41 mtu 9000
priority: 0
pfsync: syncdev: em1 maxupd: 128 defer: off
groups: carp pfsync


//maxim

On 10/24/2011 01:12 PM, Mike Belopuhov wrote:

On Mon, Oct 24, 2011 at 12:18 PM, Maxim Bourmistrov
  wrote:

Hi,

I patched on side of this tandem

do you mean 'one'? then you should obviously patch both.
i mean, come on, you wanted to do some research on
your own, so do it.


and had following setup:

fw1: em0 mtu 9000, pfsync0 mtu 2048
fw2: em0 mtu 9000, pfsync0 mtu 9000

This produced "pfsync: failed to receive bulk update".
If I change back to mtu 2048 states get propagated.

I also changed hardmtu as dlg@ suggested.


it's not immediately clear if you have to change it so
you have to verify both situations.


//maxim

CARP failover and states expiration

[Maxim Bourmistrov]

Hi list,
I have a CARP setup in failover.
Is there any reason for ESTABLISHED states on the failover node to have 
double expiration time?
Eg. on master the exp. time is 5h (set optimisation aggressive), while 
on slave it is 10h.


Is there any way to control it?

Both machines are 5.0-current.


//maxim

Re: pfsync0 MTU

[Maxim Bourmistrov]

It seems to work as long as BOTH sides have equal setup, eg

 syncdev and pfsync are set with MTU 9000.

carp: pfsync0 demoted group carp by 1 to 129 (pfsync bulk start)
carp: pfsync0 demoted group pfsync by 1 to 1 (pfsync bulk start)
carp: pfsync0 demoted group carp by -1 to 128 (pfsync bulk done)
carp: pfsync0 demoted group pfsync by -1 to 0 (pfsync bulk done)

pfsync0: flags=41 mtu 9000
priority: 0
pfsync: syncdev: em1 maxupd: 128 defer: off
groups: carp pfsync


//maxim

On 10/24/2011 01:12 PM, Mike Belopuhov wrote:

On Mon, Oct 24, 2011 at 12:18 PM, Maxim Bourmistrov
  wrote:

Hi,

I patched on side of this tandem

do you mean 'one'? then you should obviously patch both.
i mean, come on, you wanted to do some research on
your own, so do it.


and had following setup:

fw1: em0 mtu 9000, pfsync0 mtu 2048
fw2: em0 mtu 9000, pfsync0 mtu 9000

This produced "pfsync: failed to receive bulk update".
If I change back to mtu 2048 states get propagated.

I also changed hardmtu as dlg@ suggested.


it's not immediately clear if you have to change it so
you have to verify both situations.


//maxim

Re: pfsync0 MTU

[Maxim Bourmistrov]

Hi,

I patched on side of this tandem
and had following setup:

fw1: em0 mtu 9000, pfsync0 mtu 2048
fw2: em0 mtu 9000, pfsync0 mtu 9000

This produced "pfsync: failed to receive bulk update".
If I change back to mtu 2048 states get propagated.

I also changed hardmtu as dlg@ suggested.


//maxim

On 10/23/2011 07:47 AM, David Gwynne wrote:

mike,

might have to tweak hardmtu in attach too. maybe.

dlg

On 23/10/2011, at 6:18 AM, Mike Belopuhov wrote:


On Sat, Oct 22, 2011 at 20:14 +0200, Maxim Bourmistrov wrote:

On both sides I use em(4) with MTU 9000.
Then tried to set the same value to the pfsync with success (ifconfig pfsync0 
mtu 9000), but the actual value I see is 2048.


ugh. i thought you've fixed up the source code.
i'm curious if it'll still work with a smaller mtu on the physical
interface :-)

Index: net/if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.169
diff -u -p -r1.169 if_pfsync.c
--- net/if_pfsync.c 20 Oct 2011 08:57:26 -  1.169
+++ net/if_pfsync.c 22 Oct 2011 18:17:44 -
@@ -1294,8 +1294,8 @@ pfsyncioctl(struct ifnet *ifp, u_long cm
s = splnet();
if (ifr->ifr_mtu<= PFSYNC_MINPKT)
return (EINVAL);
-   if (ifr->ifr_mtu>  MCLBYTES) /* XXX could be bigger */
-   ifr->ifr_mtu = MCLBYTES;
+   if (ifr->ifr_mtu>  65536)
+   ifr->ifr_mtu = 65536;
if (ifr->ifr_mtu<  ifp->if_mtu)
pfsync_sendout();
ifp->if_mtu = ifr->ifr_mtu;

Re: do not understand how to upgrade to-CURRENT

[Maxim Bourmistrov]

I see, you want it hard way.
Well, pulling in and installing -current is considered to be un-supported.
You have to think over it one more time. I myself been dealing with broken
installs and it is hard, and no one will ever answer to you questions...

... Because YOU SHOULD NOT INSTALL -current IF YOU DONT KNOW HOW TO SOLVE
PROBLEMS IF YOU GET A BROKEN INSTALL.

And clearly, you stating it your self to be a newbie, the you should wait with
-current.
Play around with stable and a working system first.


On Oct 23, 2011, at 5:14 PM, Zantgo wrote:

> You do not worry, I will literally what it says on the guide listed below,
if I have problems they notice.
>
> http://www.openbsd.org/faq/faq5.html
>
> PS: I did this for those who just want me off the list, understand that I am
not a lazy TROLL, I'm just a newbie in OpenBSD, as it is very true that a
Linux user, is that there are more than .
>
> PS2: give up, but I'm not that easy to expire, so I'm dealing with OpenBSD).
While it is true that this is becoming more difficult, the main problem I have
with being satisfied with the-release, I need to have the most current ports,
every 6 months is a lot to me, even if for example if you could update one
snapshot to another would.
>
> Zantgo
>
> El 23-10-2011, a las 12:03, Maxim Bourmistrov 
escribis:
>
>>
>> Try one more time, if no success - give up and stay on whatever you have
right now.
>>
>>
>>
>> On Oct 23, 2011, at 4:50 PM, Zantgo wrote:
>>
>>> !!I read the FAQ, becouse I don't understand this
>>>
>>> Zantgo
>>>
>>> El 23-10-2011, a las 10:33, Marcos Ariel Laufer 
>>> escribiC3:
>>>
>>>> This idiot, zantgo, has been bothering everybody on a mexican (spanish
>>>> speaking) openbsd list and refusing to read the faq or manuals.
>>>> Imagine that on that mailing list they tend to help everybody including
>>>> the least advanced users, and he's been kicked off anyway.

Re: do not understand how to upgrade to-CURRENT

[Maxim Bourmistrov]

Try one more time, if no success - give up and stay on whatever you have right
now.



On Oct 23, 2011, at 4:50 PM, Zantgo wrote:

> !!I read the FAQ, becouse I don't understand this
>
> Zantgo
>
> El 23-10-2011, a las 10:33, Marcos Ariel Laufer 
> escribiC3:
>
>> This idiot, zantgo, has been bothering everybody on a mexican (spanish
>> speaking) openbsd list and refusing to read the faq or manuals.
>> Imagine that on that mailing list they tend to help everybody including
>> the least advanced users, and he's been kicked off anyway.

Re: pfsync0 MTU

[Maxim Bourmistrov]

On both sides I use em(4) with MTU 9000.
Then tried to set the same value to the pfsync with success (ifconfig pfsync0
mtu 9000), but the actual value I see is 2048.

pfsync0: flags=41 mtu 2048
priority: 0
pfsync: syncdev: em0 maxupd: 128 defer: off
groups: carp pfsync


em0: flags=8843 mtu 9000
lladdr 00:1b:21:bb:7f:4b
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 10.10.10.10 netmask 0xff00 broadcast 10.10.10.255
inet6 fe80::21b:21ff:febb:7f4b%em0 prefixlen 64 scopeid 0x1

tcpdump output:

20:11:08.498241 10.10.10.10: PFSYNCv6 len 2012
act TDB UPD count 2
spi: 0e64afa5 rpl: 18271 cur_bytes: 213800
...
 (DF) [tos 0x10]
20:11:08.672741 10.10.10.10: PFSYNCv6 len 544
act UPD ST COMP count 3
...
 (DF) [tos 0x10]
20:11:09.348900 10.10.10.11: PFSYNCv6 len 124
act UPD ST COMP count 1
...
 (DF) [tos 0x10]
20:11:09.362771 10.10.10.10: PFSYNCv6 len 2024
act TDB UPD count 2
spi: 0e64afa5 rpl: 18273 cur_bytes: 214032



On Oct 22, 2011, at 5:36 PM, Mike Belopuhov wrote:

> On Thu, Oct 20, 2011 at 10:40 +0200, Maxim Bourmistrov wrote:
>> Hi list,
>> is there any reason for MTU on pfsync0 to be limited to 2048?
>
> yes, when pfsync(4) was written, there was only one mbuf cluster
> pool: MCLBYTES (2048) sized one.  now we have several.
>
>> Any benefit from having it lager, say up to 9000?
>>
>
> it should be possible to send out more updates at once therefore
> calling output routines less often.  there might be delay concerns
> though -- this should be investigated.
>
>> I enabled MTU 9000 on syncdev and tried on pfsync0.
>
> but does it work? are you getting state updates? you should have
> lots of states to verify that huge packets actually get sent out.
>
> btw, what's mtu size of your syncdev interface?
>
>> As seen in tcpdump now, sync pkts are large but not as large as
>> 9000(2048 limit).
>>
>> //maxim

pfsync0 MTU

[Maxim Bourmistrov]

Hi list,
is there any reason for MTU on pfsync0 to be limited to 2048?
Any benefit from having it lager, say up to 9000?

I enabled MTU 9000 on syncdev and tried on pfsync0.
As seen in tcpdump now, sync pkts are large but not as large as 
9000(2048 limit).


//maxim

Co-existens of iked and isakmpd on the same machine

[Maxim Bourmistrov]

Hi list,
is there a way?

I know isakmpd can be bound to a specific IP via isakmpd.conf,
but iked seems to bind to any, eg. there is no way to bind it like isakmpd(as
far as I know).


//maxim

Re: iked+CARP/ active,passive

[Maxim Bourmistrov]

Hi all,
I clearly have to pay attention what I put into pf.conf!
Tunnel works fine so far.

//maxim

On Oct 16, 2011, at 1:40 PM, Maxim Bourmistrov wrote:

>
> Both side are now 5.0-current, so this fix is already there.
>
> However, tunnel timeout is still there.
> In logs is see that almost exactly 3h later after tunnel is established it
dies.
> I see FLOW is still there, bud SAD is empty, then I run "ipsecctl -s all".
>
> According to the manpage, less than 3h is a default time for re-keying.
> I'm not sending that much traffic over the tunnel yet, so
> the traffic amount is not even near the default amount for re-keying.
>
> (Reminder:
> 10.1.1.1 - is an ext IP for home GW,
> 20.1.1.1 - CARP IP at the office GW,
> 20.1.1.2 - ext IP at the office GW1
> 20.1.1.3 - ext IP at the office GW2)
>
> NOTE: I dont have any other IKE-rules right now on none of those GW.
>
> Following I see on the home-gw:
>
> Oct 15 23:47:32 fw1 iked[8578]: sa_state: VALID -> ESTABLISHED from
20.1.1.2:59973 to 10.1.1.1:500 policy 'home_to_office'
>
> Oct 16 02:27:57 fw1 iked[8578]: ikev2_msg_send: CREATE_CHILD_SA from
10.1.1.1:500 to 20.1.1.2:59973, 240 bytes
> Oct 16 02:27:58 fw1 iked[8578]: ikev2_recv: CREATE_CHILD_SA from responder
20.1.1.2:55932 to 10.1.1.1:500 policy 'home_to_office', 240 bytes
> Oct 16 02:27:58 fw1 iked[8578]: ikev2_msg_send: INFORMATIONAL from
10.1.1.1:500 to 20.1.1.2:55932, 80 bytes
> Oct 16 02:27:58 fw1 iked[8578]: ikev2_recv: INFORMATIONAL from responder
20.1.1.2:55932 to 10.1.1.1:500 policy 'home_to_office', 80 bytes
> Oct 16 02:30:47 fw1 iked[8578]: ikev2_recv: CREATE_CHILD_SA from responder
20.1.1.2:55595 to 10.1.1.1:500 policy 'home_to_office', 240 bytes
> Oct 16 02:33:50 fw1 iked[8578]: ikev2_msg_send: CREATE_CHILD_SA from
10.1.1.1:500 to 20.1.1.2:59973, 240 bytes
>
> At the office:
>
> Oct 15 23:47:32 fw1 iked[16378]: sa_state: VALID -> ESTABLISHED from
10.1.1.1:500 to 20.1.1.2:500 policy 'mxb_to_office'
>
> Oct 16 02:27:58 fw1 iked[16378]: ikev2_msg_send: CREATE_CHILD_SA from
20.1.1.2:500 to 10.1.1.1:500, 240 bytes
> Oct 16 02:27:58 fw1 iked[16378]: ikev2_recv: INFORMATIONAL from initiator
10.1.1.1:500 to 20.1.1.2:500 policy 'mxb_to_office', 80 bytes
> Oct 16 02:27:58 fw1 iked[16378]: ikev2_pld_delete: deleted 1 spis
> Oct 16 02:27:58 fw1 iked[16378]: ikev2_msg_send: INFORMATIONAL from
20.1.1.2:500 to 10.1.1.1:500, 80 bytes
> Oct 16 02:30:47 fw1 iked[16378]: ikev2_msg_send: CREATE_CHILD_SA from
20.1.1.2:500 to 10.1.1.1:500, 240 bytes
>
> At this time it looks like I lose my tunnel.
> Trying to ping remote network produces
> Oct 16 13:08:11 fw1 iked[8578]: ikev2_msg_send: CREATE_CHILD_SA from
10.1.1.1:500 to 20.1.1.2:55932, 240 bytes
> But this only seen on the home GW.
>
> //maxim
>
>
> On Oct 15, 2011, at 1:03 PM, Joosep wrote:
>
>> On Sat, Oct 15, 2011 at 12:13 PM, Maxim Bourmistrov
>> wrote:
>>
>>> Thanks for your replay, Trevor!
>>>
>>> Yes, indeed, PF was the case here.
>>> Except "pass on enc0 from any to any keep state (if-bound)", I also
decided
>>> to
>>> pass all ESP traffic.
>>>
>>> Tunnel, however, sometimes times out. Not sure about the reason for this
>>> yet.
>>>
>>> //maxim
>>>
>>> Hi!
>>
>> There is a patch for 4.8 and 4.9 that probably fixes your timeouts
problem.
>> Please read this thread:
>> http://marc.info/?l=openbsd-misc&m=130959664208980&w=2
>> It's not a critical bugfix, so it's not on the errata page, but it is in
the
>> cvs.
>>
>> Joosep

Re: Traffic through default pf queue

[Maxim Bourmistrov]

Use "pass log" and "tag TAGGED" in pf rules,
then tcpdump -i pflog0

On 10/17/2011 02:40 PM, Claudiu Pruna wrote:

Hi everyone,

I have a question, could anyone give me an ideea how can I "see" (like
tcpdump or something) the traffic that is passing throught the default
queue of pf ?

Thanks for your ideeas.

Re: iked+CARP/ active,passive

[Maxim Bourmistrov]

Both side are now 5.0-current, so this fix is already there.

However, tunnel timeout is still there.
In logs is see that almost exactly 3h later after tunnel is established it
dies.
I see FLOW is still there, bud SAD is empty, then I run "ipsecctl -s all".

According to the manpage, less than 3h is a default time for re-keying.
I'm not sending that much traffic over the tunnel yet, so
the traffic amount is not even near the default amount for re-keying.

(Reminder:
10.1.1.1 - is an ext IP for home GW,
20.1.1.1 - CARP IP at the office GW,
20.1.1.2 - ext IP at the office GW1
20.1.1.3 - ext IP at the office GW2)

NOTE: I dont have any other IKE-rules right now on none of those GW.

Following I see on the home-gw:

Oct 15 23:47:32 fw1 iked[8578]: sa_state: VALID -> ESTABLISHED from
20.1.1.2:59973 to 10.1.1.1:500 policy 'home_to_office'

Oct 16 02:27:57 fw1 iked[8578]: ikev2_msg_send: CREATE_CHILD_SA from
10.1.1.1:500 to 20.1.1.2:59973, 240 bytes
Oct 16 02:27:58 fw1 iked[8578]: ikev2_recv: CREATE_CHILD_SA from responder
20.1.1.2:55932 to 10.1.1.1:500 policy 'home_to_office', 240 bytes
Oct 16 02:27:58 fw1 iked[8578]: ikev2_msg_send: INFORMATIONAL from
10.1.1.1:500 to 20.1.1.2:55932, 80 bytes
Oct 16 02:27:58 fw1 iked[8578]: ikev2_recv: INFORMATIONAL from responder
20.1.1.2:55932 to 10.1.1.1:500 policy 'home_to_office', 80 bytes
Oct 16 02:30:47 fw1 iked[8578]: ikev2_recv: CREATE_CHILD_SA from responder
20.1.1.2:55595 to 10.1.1.1:500 policy 'home_to_office', 240 bytes
Oct 16 02:33:50 fw1 iked[8578]: ikev2_msg_send: CREATE_CHILD_SA from
10.1.1.1:500 to 20.1.1.2:59973, 240 bytes

At the office:

Oct 15 23:47:32 fw1 iked[16378]: sa_state: VALID -> ESTABLISHED from
10.1.1.1:500 to 20.1.1.2:500 policy 'mxb_to_office'

Oct 16 02:27:58 fw1 iked[16378]: ikev2_msg_send: CREATE_CHILD_SA from
20.1.1.2:500 to 10.1.1.1:500, 240 bytes
Oct 16 02:27:58 fw1 iked[16378]: ikev2_recv: INFORMATIONAL from initiator
10.1.1.1:500 to 20.1.1.2:500 policy 'mxb_to_office', 80 bytes
Oct 16 02:27:58 fw1 iked[16378]: ikev2_pld_delete: deleted 1 spis
Oct 16 02:27:58 fw1 iked[16378]: ikev2_msg_send: INFORMATIONAL from
20.1.1.2:500 to 10.1.1.1:500, 80 bytes
Oct 16 02:30:47 fw1 iked[16378]: ikev2_msg_send: CREATE_CHILD_SA from
20.1.1.2:500 to 10.1.1.1:500, 240 bytes

At this time it looks like I lose my tunnel.
Trying to ping remote network produces
Oct 16 13:08:11 fw1 iked[8578]: ikev2_msg_send: CREATE_CHILD_SA from
10.1.1.1:500 to 20.1.1.2:55932, 240 bytes
But this only seen on the home GW.

//maxim


On Oct 15, 2011, at 1:03 PM, Joosep wrote:

> On Sat, Oct 15, 2011 at 12:13 PM, Maxim Bourmistrov
> wrote:
>
>> Thanks for your replay, Trevor!
>>
>> Yes, indeed, PF was the case here.
>> Except "pass on enc0 from any to any keep state (if-bound)", I also
decided
>> to
>> pass all ESP traffic.
>>
>> Tunnel, however, sometimes times out. Not sure about the reason for this
>> yet.
>>
>> //maxim
>>
>> Hi!
>
> There is a patch for 4.8 and 4.9 that probably fixes your timeouts problem.
> Please read this thread:
> http://marc.info/?l=openbsd-misc&m=130959664208980&w=2
> It's not a critical bugfix, so it's not on the errata page, but it is in
the
> cvs.
>
> Joosep

Re: iked+CARP/ active,passive

[Maxim Bourmistrov]

Thanks for your replay, Trevor!

Yes, indeed, PF was the case here.
Except "pass on enc0 from any to any keep state (if-bound)", I also decided to
pass all ESP traffic.

Tunnel, however, sometimes times out. Not sure about the reason for this yet.

//maxim

On Oct 14, 2011, at 9:24 PM, Trevor Benson wrote:

> On Oct 14, 2011, at 5:27 AM, Maxim Bourmistrov wrote:
>
>> Hi all,
>> problem is still there.
>>
>> Both sides are -current now (Oct 6 build).
>>
>> Any ideas what is wrong?
>>
>> //maxim
>>
>
> Have you looked at your pf ruleset on both sides of the tunnel?  Are you
using blanket allow rules for ipsec traffic? E.G. "pass on enc0 from any to
any"? or are you making more explicit rules to match your flows?  Almost
sounds like a state is not being created until a packet comes in from the
other side, which can easily be tied to pf rules regarding your VPN tunnels.
If you have explicit rulesets allowing traffic for VPN's my first guess is one
side is missing the new rules that match the flows, or the network was not
added to a macro or table being used in your pf ruleset.
>
> If you allow 'any to any' traffic via enc0 the next step I usually take is
to tcpdump traffic on the local firewall for the enc0 and egress interfaces.
have seen in the past pf rules not implemented properly for NAT & IPSec
relabel a packet that should go over a VPN tunnel which may cause the other
side to deny it, or to return traffic to the wrong IP, or to not match the
remote firewall ESP ruleset and be accepted and decrypted.  This causes what
looks like a failure in traffic between endpoints, however it is a failure in
rulesets causing problems with functional endpoints.  Sending traffic from the
reverse side could create a state that allows traffic to pass until the state
is cleared.  Much of this is from historic troubleshooting around OpenBSD
3.7-4.3, so changes in routing and handling encrypted traffic could make some
of what I said currently inaccurate.  Using tcpdump however on the egress,
enc0 and possibly the ingress interfaces should give you a much better
understanding of what is happening to the packets, and why the far side
appears to deny the traffic.
>
> Trevor

Re: iked+CARP/ active,passive

[Maxim Bourmistrov]

Hi all,
problem is still there.

Both sides are -current now (Oct 6 build).

Any ideas what is wrong?

//maxim

em1 - watchdog timeout

[Maxim Bourmistrov]

Hi,

I'm getting "em1 watchdog timeout" from bsd.rd while tried to snapshot 
already -current box.
However, manually moving in bsd from the same date and booting it does 
not produces those

messages.

bsd.rd triggering those:
OpenBSD 5.0-current (GENERIC) #81: Thu Oct  6 16:05:52 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

NOTE, this date is from running bsd I just moved in manually.
bsd.rd hopefully from the same date(?)

bsd.rd from prev. snapshot, which is currently running
and not seen to produce "watchdog timeout":

OpenBSD 5.0-beta (GENERIC.MP) #45: Sun Jul 31 17:10:30 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

dmesg(manually moved in bsd):

OpenBSD 5.0-current (GENERIC.MP) #96: Thu Oct  6 16:12:43 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4284039168 (4085MB)
avail mem = 4155875328 (3963MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeadc0 (105 entries)
bios0: vendor American Megatrends Inc. version "4.6.4" date 06/30/2011
bios0: Supermicro X9SCL/X9SCM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET SPMI EINJ ERST HEST BERT
acpi0: wakeup devices PS2K(S1) PS2M(S1) UAR1(S4) UAR2(S4) BR20(S1) 
EUSB(S4) USBE(S4) PEX0(S4) PEX4(S4) PEX6(S4) GBE_(S4) P0P1(S4) P0P2(S4) 
P0P3(S4) P0P4(S4) SLPB(S0) PWRB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.36 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.02 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG

cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.02 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG

cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E31220L @ 2.20GHz, 2195.02 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG

cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (BR20)
acpiprt2 at acpi0: bus 3 (PEX0)
acpiprt3 at acpi0: bus 4 (PEX4)
acpiprt4 at acpi0: bus -1 (PEX6)
acpiprt5 at acpi0: bus 1 (P0P1)
acpiprt6 at acpi0: bus 2 (P0P2)
acpiprt7 at acpi0: bus -1 (P0P3)
acpiprt8 at acpi0: bus -1 (P0P4)
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2195 MHz: speeds: 2201, 2200, 2100, 2000, 1900, 
1800, 1700, 1600 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x0108 
rev 0x09

ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 1 function 1 "Intel Core 2G PCIE" rev 0x09: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi, 
address 00:1b:21:bb:d2:6e
em1 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msi, address 
00:25:90:27:da:51

ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb2 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5: msi
pci4 at ppb3 bus 4
em2 at pci4 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi, 
address 00:25:90:27:da:50

ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xa5
pci5 at ppb4 bus 5
vga1 at pci5 dev 3 function 0 "Matrox MGA G200eW" rev 0x0a

Re: iked+CARP/ active,passive

[Maxim Bourmistrov]

As Johan suggested, I'd bring both side in sync first.
Looks like both iked and isakmpd got patched.

//maxim

On Oct 13, 2011, at 12:38 PM, Johan Ryberg wrote:

> 2011/10/13 Maxim Bourmistrov :
>> Hi misc@,
>>
>> I'm trying to understand why my IPSec tunnel not functioning as expected
and
>> especially
>> why packets start flow as soon as I start to ping from the opposite side.
>>
>> Hopefully someone can explain what is going on and why.
>>
>> Following setup:
>>
>> Network Home(1.1.1.0/25) connecting to the network office(2.2.2.0/21) via
an
>> IPSec tunnel.
>> Gw at Home-side is an OpenBSD 4.9-stable. Gw at Office OpenBSD 5.0-current
in
>> a CARP(failover) setup.
>>
>> gw at home IP: 10.1.1.1
>> gw at office IP: 20.1.1.1(CARP iface. gw1: 20.1.1.2 gw2: 20.1.1.3)
>>
>> CARP, eg. failover part, is working fine.
>>
>> Following iked.conf I have.
>>
>> Home gw:
>> local_gw="10.1.1.1"
>> remote_gw="20.1.1.1"
>>
>> ikev2 "homeNET_to_officeNET" active esp \
>>from $local_gw to $remote_gw \
>>from 1.1.1.0/25 to 2.2.2.0/21 \
>>local $local_gw peer $remote_gw \
>>srcid $local_gw \
>>dstid $remote_gw
>>
>> Office gw:
>> local_gw="20.1.1.1"
>> remote_gw="10.1.1.1"
>>
>> ikev2 "officeNET_to_homeNET" passive esp \
>>from $local_gw to $remote_gw \
>>from 2.2.2.0/21 to 1.1.1.0/25 \
>>local $local_gw peer $remote_gw \
>>srcid $local_gw \
>>dstid $remote_gw
>>
>>
>> Tunnel gets established.
>>
>> On office-gw I see
>> sa_state: VALID -> ESTABLISHED from 10.1.1.1:500 to 20.1.1.2:500 policy
>> 'officeNET_to_homeNET'
>> Note, that the IP-address is actually not one on CARP iface, but rather
from
>> physical iface.
>>
>> ipsecctl -s all gives:
>> FLOWS:
>> flow esp in from 10.1.1.1 to 20.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1
dstid
>> IPV4/10.1.1.1 type use
>> flow esp out from 20.1.1.1 to 10.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1
dstid
>> IPV4/10.1.1.1 type require
>> flow esp in from 1.1.1.0/25 to 2.2.2.0/21 peer 10.1.1.1 srcid
IPV4/20.1.1.1
>> dstid IPV4/10.1.1.1 type use
>> flow esp out from 2.2.2.0/21 to 1.1.1.0/25 peer 10.1.1.1 srcid
IPV4/20.1.1.1
>> dstid IPV4/10.1.1.1 type require
>>
>> SAD:
>> ---> esp tunnel from 20.1.1.2 to 10.1.1.1 spi 0x2d2a6151 auth
hmac-sha2-256
>> enc aes-256
>> esp tunnel from 10.1.1.1 to 20.1.1.2 spi 0x5152256e auth hmac-sha2-256 enc
>> aes-256
>>
>>
>> On home-gw I see
>> sa_state: VALID -> ESTABLISHED from 20.1.1.1:57185 to 10.1.1.1:500 policy
>> 'policy1'
>>
>> ipsecctl -s all gives:
>> FLOWS:
>> flow esp in from 2.2.2.0/21 to 1.1.1.0/25 peer 20.1.1.1 srcid
IPV4/10.1.1.1
>> dstid IPV4/20.1.1.1 type use
>> flow esp out from 1.1.1.0/25 to 2.2.2.0/21 peer 20.1.1.1 srcid
IPV4/10.1.1.1
>> dstid IPV4/20.1.1.1 type require
>> flow esp in from 20.1.1.1 to 10.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1
dstid
>> IPV4/20.1.1.1 type use
>> flow esp out from 10.1.1.1 to 20.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1
dstid
>> IPV4/20.1.1.1 type require
>>
>> SAD:
>> esp tunnel from 20.1.1.1 to 10.1.1.1 spi 0x2d2a6151 auth hmac-sha2-256 enc
>> aes-256
>> esp tunnel from 10.1.1.1 to 20.1.1.1 spi 0x5152256e auth hmac-sha2-256 enc
>> aes-256
>>
>>
>> The problem is that I can not ping Office-net from Home-net then tunnel is
>> established.
>> I can see packets on enc0 going from Home-net to Office-net while I'm
watching
>> on Home-gw, but nothing on enc0 on the Office-side.
>>
>> This is the state for tunnel until I start a ping from some machine on
>> Office-side, then suddenly tunnel functioning correctly
>> and I can ping internal machines from both sides and connect(ssh) from
both
>> sides.
>>
>> Question is why this strange behavior? I tried to switch from passive to
>> active on the Office-gw with the same result.
>> Or does it have to do with the CARP? PF rules are as they are described in
the
>> iked.conf manual.
>>
>> Anyone have an idea what is going on?
>>
>> Regards,
>> Maxim
>
> Have you patched isakmpd?
>
> Maybe that's one of the problems that was addressed.
>
> I made a quick script that patches isakmpd automatic, it's maybe ugly
> but it works for me.
>
> http://pastebin.com/CCV0PitV
>
> Best regards Johan

Re: iked+CARP/ active,passive

[Maxim Bourmistrov]

This is iked (IKEv2). No patches, plain from dist.

On Oct 13, 2011, at 12:38 PM, Johan Ryberg wrote:

> 2011/10/13 Maxim Bourmistrov :
>> Hi misc@,
>>
>> I'm trying to understand why my IPSec tunnel not functioning as expected
and
>> especially
>> why packets start flow as soon as I start to ping from the opposite side.
>>
>> Hopefully someone can explain what is going on and why.
>>
>> Following setup:
>>
>> Network Home(1.1.1.0/25) connecting to the network office(2.2.2.0/21) via
an
>> IPSec tunnel.
>> Gw at Home-side is an OpenBSD 4.9-stable. Gw at Office OpenBSD 5.0-current
in
>> a CARP(failover) setup.
>>
>> gw at home IP: 10.1.1.1
>> gw at office IP: 20.1.1.1(CARP iface. gw1: 20.1.1.2 gw2: 20.1.1.3)
>>
>> CARP, eg. failover part, is working fine.
>>
>> Following iked.conf I have.
>>
>> Home gw:
>> local_gw="10.1.1.1"
>> remote_gw="20.1.1.1"
>>
>> ikev2 "homeNET_to_officeNET" active esp \
>>from $local_gw to $remote_gw \
>>from 1.1.1.0/25 to 2.2.2.0/21 \
>>local $local_gw peer $remote_gw \
>>srcid $local_gw \
>>dstid $remote_gw
>>
>> Office gw:
>> local_gw="20.1.1.1"
>> remote_gw="10.1.1.1"
>>
>> ikev2 "officeNET_to_homeNET" passive esp \
>>from $local_gw to $remote_gw \
>>from 2.2.2.0/21 to 1.1.1.0/25 \
>>local $local_gw peer $remote_gw \
>>srcid $local_gw \
>>dstid $remote_gw
>>
>>
>> Tunnel gets established.
>>
>> On office-gw I see
>> sa_state: VALID -> ESTABLISHED from 10.1.1.1:500 to 20.1.1.2:500 policy
>> 'officeNET_to_homeNET'
>> Note, that the IP-address is actually not one on CARP iface, but rather
from
>> physical iface.
>>
>> ipsecctl -s all gives:
>> FLOWS:
>> flow esp in from 10.1.1.1 to 20.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1
dstid
>> IPV4/10.1.1.1 type use
>> flow esp out from 20.1.1.1 to 10.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1
dstid
>> IPV4/10.1.1.1 type require
>> flow esp in from 1.1.1.0/25 to 2.2.2.0/21 peer 10.1.1.1 srcid
IPV4/20.1.1.1
>> dstid IPV4/10.1.1.1 type use
>> flow esp out from 2.2.2.0/21 to 1.1.1.0/25 peer 10.1.1.1 srcid
IPV4/20.1.1.1
>> dstid IPV4/10.1.1.1 type require
>>
>> SAD:
>> ---> esp tunnel from 20.1.1.2 to 10.1.1.1 spi 0x2d2a6151 auth
hmac-sha2-256
>> enc aes-256
>> esp tunnel from 10.1.1.1 to 20.1.1.2 spi 0x5152256e auth hmac-sha2-256 enc
>> aes-256
>>
>>
>> On home-gw I see
>> sa_state: VALID -> ESTABLISHED from 20.1.1.1:57185 to 10.1.1.1:500 policy
>> 'policy1'
>>
>> ipsecctl -s all gives:
>> FLOWS:
>> flow esp in from 2.2.2.0/21 to 1.1.1.0/25 peer 20.1.1.1 srcid
IPV4/10.1.1.1
>> dstid IPV4/20.1.1.1 type use
>> flow esp out from 1.1.1.0/25 to 2.2.2.0/21 peer 20.1.1.1 srcid
IPV4/10.1.1.1
>> dstid IPV4/20.1.1.1 type require
>> flow esp in from 20.1.1.1 to 10.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1
dstid
>> IPV4/20.1.1.1 type use
>> flow esp out from 10.1.1.1 to 20.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1
dstid
>> IPV4/20.1.1.1 type require
>>
>> SAD:
>> esp tunnel from 20.1.1.1 to 10.1.1.1 spi 0x2d2a6151 auth hmac-sha2-256 enc
>> aes-256
>> esp tunnel from 10.1.1.1 to 20.1.1.1 spi 0x5152256e auth hmac-sha2-256 enc
>> aes-256
>>
>>
>> The problem is that I can not ping Office-net from Home-net then tunnel is
>> established.
>> I can see packets on enc0 going from Home-net to Office-net while I'm
watching
>> on Home-gw, but nothing on enc0 on the Office-side.
>>
>> This is the state for tunnel until I start a ping from some machine on
>> Office-side, then suddenly tunnel functioning correctly
>> and I can ping internal machines from both sides and connect(ssh) from
both
>> sides.
>>
>> Question is why this strange behavior? I tried to switch from passive to
>> active on the Office-gw with the same result.
>> Or does it have to do with the CARP? PF rules are as they are described in
the
>> iked.conf manual.
>>
>> Anyone have an idea what is going on?
>>
>> Regards,
>> Maxim
>
> Have you patched isakmpd?
>
> Maybe that's one of the problems that was addressed.
>
> I made a quick script that patches isakmpd automatic, it's maybe ugly
> but it works for me.
>
> http://pastebin.com/CCV0PitV
>
> Best regards Johan

iked+CARP/ active,passive

[Maxim Bourmistrov]

Hi misc@,

I'm trying to understand why my IPSec tunnel not functioning as expected and
especially
why packets start flow as soon as I start to ping from the opposite side.

Hopefully someone can explain what is going on and why.

Following setup:

Network Home(1.1.1.0/25) connecting to the network office(2.2.2.0/21) via an
IPSec tunnel.
Gw at Home-side is an OpenBSD 4.9-stable. Gw at Office OpenBSD 5.0-current in
a CARP(failover) setup.

gw at home IP: 10.1.1.1
gw at office IP: 20.1.1.1(CARP iface. gw1: 20.1.1.2 gw2: 20.1.1.3)

CARP, eg. failover part, is working fine.

Following iked.conf I have.

Home gw:
local_gw="10.1.1.1"
remote_gw="20.1.1.1"

ikev2 "homeNET_to_officeNET" active esp \
from $local_gw to $remote_gw \
from 1.1.1.0/25 to 2.2.2.0/21 \
local $local_gw peer $remote_gw \
srcid $local_gw \
dstid $remote_gw

Office gw:
local_gw="20.1.1.1"
remote_gw="10.1.1.1"

ikev2 "officeNET_to_homeNET" passive esp \
from $local_gw to $remote_gw \
from 2.2.2.0/21 to 1.1.1.0/25 \
local $local_gw peer $remote_gw \
srcid $local_gw \
dstid $remote_gw


Tunnel gets established.

On office-gw I see
sa_state: VALID -> ESTABLISHED from 10.1.1.1:500 to 20.1.1.2:500 policy
'officeNET_to_homeNET'
Note, that the IP-address is actually not one on CARP iface, but rather from
physical iface.

ipsecctl -s all gives:
FLOWS:
flow esp in from 10.1.1.1 to 20.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1 dstid
IPV4/10.1.1.1 type use
flow esp out from 20.1.1.1 to 10.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1 dstid
IPV4/10.1.1.1 type require
flow esp in from 1.1.1.0/25 to 2.2.2.0/21 peer 10.1.1.1 srcid IPV4/20.1.1.1
dstid IPV4/10.1.1.1 type use
flow esp out from 2.2.2.0/21 to 1.1.1.0/25 peer 10.1.1.1 srcid IPV4/20.1.1.1
dstid IPV4/10.1.1.1 type require

SAD:
---> esp tunnel from 20.1.1.2 to 10.1.1.1 spi 0x2d2a6151 auth hmac-sha2-256
enc aes-256
esp tunnel from 10.1.1.1 to 20.1.1.2 spi 0x5152256e auth hmac-sha2-256 enc
aes-256


On home-gw I see
sa_state: VALID -> ESTABLISHED from 20.1.1.1:57185 to 10.1.1.1:500 policy
'policy1'

ipsecctl -s all gives:
FLOWS:
flow esp in from 2.2.2.0/21 to 1.1.1.0/25 peer 20.1.1.1 srcid IPV4/10.1.1.1
dstid IPV4/20.1.1.1 type use
flow esp out from 1.1.1.0/25 to 2.2.2.0/21 peer 20.1.1.1 srcid IPV4/10.1.1.1
dstid IPV4/20.1.1.1 type require
flow esp in from 20.1.1.1 to 10.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1 dstid
IPV4/20.1.1.1 type use
flow esp out from 10.1.1.1 to 20.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1 dstid
IPV4/20.1.1.1 type require

SAD:
esp tunnel from 20.1.1.1 to 10.1.1.1 spi 0x2d2a6151 auth hmac-sha2-256 enc
aes-256
esp tunnel from 10.1.1.1 to 20.1.1.1 spi 0x5152256e auth hmac-sha2-256 enc
aes-256


The problem is that I can not ping Office-net from Home-net then tunnel is
established.
I can see packets on enc0 going from Home-net to Office-net while I'm watching
on Home-gw, but nothing on enc0 on the Office-side.

This is the state for tunnel until I start a ping from some machine on
Office-side, then suddenly tunnel functioning correctly
and I can ping internal machines from both sides and connect(ssh) from both
sides.

Question is why this strange behavior? I tried to switch from passive to
active on the Office-gw with the same result.
Or does it have to do with the CARP? PF rules are as they are described in the
iked.conf manual.

Anyone have an idea what is going on?

Regards,
Maxim

Broken src-tree in CVS or is it just me?

[Maxim Bourmistrov]

Hi,

trying to compile current on amd64 just checked out from
anoncvs.eu.openbsd.org.

Produces following below. Is it me or src?

# cd /usr/src/sys/arch/amd64/compile/GENERIC.MP/
# make clean && make depend && make
rm -f eddep *bsd *bsd.gdb tags *.[dio] [a-z]*.s  [Ee]rrs linterrs assym.h
cat ../../../../arch/amd64/amd64/genassym.cf
../../../../arch/amd64/amd64/genassym.cf |  sh ../../../../kern/genassym.sh cc
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes  -Wno-main
-Wno-uninitialized -Wno-format  -Wstack-larger-than-2047 -mcmodel=kernel
-mno-red-zone -mno-sse2 -mno-sse -mno-3dnow  -mno-mmx -msoft-float
-fno-omit-frame-pointer -fno-builtin-printf -fno-builtin-snprintf
-fno-builtin-vsnprintf -fno-builtin-log  -fno-builtin-log2 -fno-builtin-malloc
-O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC
-DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG
-DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DCOMPAT_43 -DLKM -DFFS -DFFS2
-DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER
-DCD9660 -DUDF -DMSDOSFS -DFIFO -DSOCKET_SPLICE -DTCP_SACK -DTCP_ECN
-DTCP_SIGNATURE -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE
-DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS
-DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD
-DWSDISPLAY_DEFAULTSCREENS="6" -DWSDISPLAY_COMPAT_PCVT -DX86EMU
-DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP -MF assym.P
> assym.h.tmp
sed '1s/.*/assym.h: \\/' assym.P > assym.d
sort -u assym.h.tmp > assym.h
cc -D_LOCORE -x assembler-with-cpp -mcmodel=kernel -mno-red-zone -mno-sse2
-mno-sse -mno-3dnow  -mno-mmx -msoft-float -fno-omit-frame-pointer
-fno-builtin-printf -fno-builtin-snprintf  -fno-builtin-vsnprintf
-fno-builtin-log  -fno-builtin-log2 -fno-builtin-malloc -nostdinc -I.
-I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING
-DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM
-DUVM_SWAP_ENCRYPT -DCOMPAT_43 -DLKM -DFFS -DFFS2 -DFFS_SOFTUPDATES
-DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF
-DMSDOSFS -DFIFO -DSOCKET_SPLICE -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DINET
-DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DMPLS
-DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS -DPCIVERBOSE
-DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD
-DWSDISPLAY_DEFAULTSCREENS="6" -DWSDISPLAY_COMPAT_PCVT -DX86EMU
-DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP -c
../../../../arch/amd64/amd64/locore.S
cc  -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes  -Wno-main
-Wno-uninitialized -Wno-format  -Wstack-larger-than-2047 -mcmodel=kernel
-mno-red-zone -mno-sse2 -mno-sse -mno-3dnow  -mno-mmx -msoft-float
-fno-omit-frame-pointer -fno-builtin-printf -fno-builtin-snprintf
-fno-builtin-vsnprintf -fno-builtin-log  -fno-builtin-log2 -fno-builtin-malloc
-O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC
-DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG
-DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DCOMPAT_43 -DLKM -DFFS -DFFS2
-DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER
-DCD9660 -DUDF -DMSDOSFS -DFIFO -DSOCKET_SPLICE -DTCP_SACK -DTCP_ECN
-DTCP_SIGNATURE -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE
-DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS
-DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD
-DWSDISPLAY_DEFAULTSCREENS="6" -DWSDISPLAY_COMPAT_PCVT -DX86EMU
-DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP  -c param.c
cc  -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes  -Wno-main
-Wno-uninitialized -Wno-format  -Wstack-larger-than-2047 -mcmodel=kernel
-mno-red-zone -mno-sse2 -mno-sse -mno-3dnow  -mno-mmx -msoft-float
-fno-omit-frame-pointer -fno-builtin-printf -fno-builtin-snprintf
-fno-builtin-vsnprintf -fno-builtin-log  -fno-builtin-log2 -fno-builtin-malloc
-O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC
-DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG
-DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DCOMPAT_43 -DLKM -DFFS -DFFS2
-DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER
-DCD9660 -DUDF -DMSDOSFS -DFIFO -DSOCKET_SPLICE -DTCP_SACK -DTCP_ECN
-DTCP_SIGNATURE -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE
-DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS
-DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD
-DWSDISPLAY_DEFAULTSCREENS="6" -DWSDISPLAY_COMPAT_PCVT -DX86EMU
-DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP  -c
ioconf.c
cc1: warnings being treated as errors
ioconf.c:821: warning: excess elements in struct initializer
ioconf.c:821: warning: (near initialization for 'cfdata[0]')
ioconf.c:823: warning: excess elements in struct initializer
ioco

Re: IPSEC/SSL accelerator

[Maxim Bourmistrov]

Yes,
it would be interesting to hear some devs on this topic.

A specially about drivers "on board":
1. What can be done and what is missing.
2. What hw is worth to spend money on and what kind of hw devs need to make it
worth to spend money on.


I'd like to see this kind on acceleration perform best in OpenBSD.

Regards
Maxim

On May 19, 2011, at 9:08 PM, Oeschger Patrick wrote:

> hi all
> still thinking about the diff between 2gbit in the specs and about 400mbit
in
> real world on a pretty new processor
> that's a *big* difference
> so we can say that every accelerator board - regardless if pci-e 16x or
> miniPCI - will not be able to perform at lets say 1gbit because of the need
of
> copying packets forth and back
> can anybody confirm hat most of the speed is lost by copying the packets
first
> TO the accelerator board and then BACK to process it further after
> decryption?
> just read some manuals (parts of) regarding the new tilera and cavium
octeon
> architecture
> ...part of their secret seems to be a kind of 'copyfree' processing of
packets
> (accelerators modify the paket 'in place')
> has anybody done some reasearch on this?
> thanks
> /pat
>
> On May 18, 2011, at 21:03, Joosep wrote:
>
>> Hi!
>>
>> ubsec0 at pci5 dev 0 function 0 "Broadcom 5862" rev 0x01: 3DES MD5 SHA1
AES
>> PK, apic 9 int 0 (irq 10)
>>
>> Joosep
>>
>> On Wed, May 18, 2011 at 8:56 PM, Maxim Bourmistrov
>> wrote:
>>
>>> How does it look in dmesg for this card?
>>>
>>> Sent from my iPhone
>>>
>>> On May 18, 2011, at 10:42, Joosep  wrote:
>>>
>>>> On Wed, May 18, 2011 at 10:06 AM, Patrick Oeschger <
>>>> patrick.oesch...@bluewin.ch> wrote:
>>>>
>>>>> thank you for your input
>>>>> why 'only' 400mbit?
>>>>> the specs say 2gbit for BCM5862 in a pci-e 4x slot...
>>>>> sounds like quite some overhead writing/ getting packets to/from the
>>> card -
>>>>> i would have expected it higher but i do not want to question your
tests
>>>>> *hmmm*
>>>>>
>>>>> Sent from Pat's iPhone
>>>>>
>>>>
>>>> Hi!
>>>>
>>>> There is of course a possibility, that the test doesn't simulate reality
>>> in
>>>> the best way.
>>>> The specs say 2gbit, but when doing 400mbps there isn't much power left
>>> on
>>>> machines main cpu (10% idle).
>>>> So i guess the limiting factor here is main cpu not the CA card.
>>>> I have done the same tests with 1,8 GHz opteron and in that case the
>>> result
>>>> was around 270mbps.
>>>>
>>>> Joosep

Re: IPSEC/SSL accelerator

[Maxim Bourmistrov]

How does it look in dmesg for this card?

Sent from my iPhone

On May 18, 2011, at 10:42, Joosep  wrote:

> On Wed, May 18, 2011 at 10:06 AM, Patrick Oeschger <
> patrick.oesch...@bluewin.ch> wrote:
>
>> thank you for your input
>> why 'only' 400mbit?
>> the specs say 2gbit for BCM5862 in a pci-e 4x slot...
>> sounds like quite some overhead writing/ getting packets to/from the card
-
>> i would have expected it higher but i do not want to question your tests
>> *hmmm*
>>
>> Sent from Pat's iPhone
>>
>
> Hi!
>
> There is of course a possibility, that the test doesn't simulate reality in
> the best way.
> The specs say 2gbit, but when doing 400mbps there isn't much power left on
> machines main cpu (10% idle).
> So i guess the limiting factor here is main cpu not the CA card.
> I have done the same tests with 1,8 GHz opteron and in that case the result
> was around 270mbps.
>
> Joosep

Re: another slow connection on openbsd 3.4

[Maxim Bourmistrov]

Indeed. Solved many problems many times.

//maxim

On Aug 24, 2010, at 20:27, Kenneth R Westerback 
wrote:

> On Wed, Aug 25, 2010 at 12:46:16AM +0700, Hendro Susanto wrote:
>> Hi, I just read the article from
>>
http://www.pubbs.net/201005/openbsd/14859-strangely-slow-openbsd-server-conne
ction.html
>>
>> However, my problem was just started since last week.
>> The system was fine and running smoothly for more 5 years! (PF and Squid
>> Cache).
>>
>> All the sudden the internet speed has been reduced by half - mine is 5Mbps
>> max and it only can get 2,5Mbps.
>> Have directly plugged into a laptop running Windows XP (instead of
OpenBSD)
>> and the speed was fine.
>>
>> Any suggestions?
>> Do you think the internet provider has changed on their side e.g autoneg
>> etc?
>>
>> -hendro-
>
> I think I can say without fear of contradiction, interest in 3.4
> problems can only be measured by instruments sensitive enough to
> measure pixie dust. Brandished by those rare birds, OpenBSD
> Software Archeologists.
>
> Seriously dude, you need to upgrade if you want OpenBSD help/suggestions!!
>
>  Ken

Re: pkg_delete

[Maxim Bourmistrov]

Yeah, stepping from 3.9 to 4.6 might be a big change, but
I still want this "-F force"-flag in place. :)

I'm already forcing it with my "rm -rf"-move allover the place.

//Stolichnaya - Smooth like an Alibi.

On Jan 29, 2010, at 10:45 PM, Philip Guenther wrote:

> On Fri, Jan 29, 2010 at 1:14 PM, Maxim Bourmistrov
>  wrote:
>> Sure, with swapped order too.
>> No luck.
> 
> Sounds like you should find a machine you can run on -current and give
> espie some feedback on his changes.  pkg_add now reads your mind and
> handles loops and cascading dependencies automatically.  pkg_delete
> appears to still have some issues, but perhaps there's time before
> release to get those ironed out...
> 
> 
> Philip Guenther

Re: pkg_delete

[Maxim Bourmistrov]

Sure, with swapped order too.
No luck.

"rm -rf" made me happy, but then "rm -rf /all/that/crap/which/is/left"

"If it works - don't touch it" is applicable to OpenBSD.
But then it is time - pain comes back.

I almost finished my Stolichnaya and I'm still not in the club. :(


On Jan 29, 2010, at 10:06 PM, Philip Guenther wrote:

> On Fri, Jan 29, 2010 at 11:35 AM, Maxim Bourmistrov
>  wrote:
>> However:
>>
>> # pkg_delete -F dependencies openldap-client
>> Can't remove openldap-client-2.3.11p4 without also removing:
>> cyrus-sasl-2.1.21p2-ldap
>> (removing them as well)
>> # pkg_info|grep ldap
>> cyrus-sasl-2.1.21p2-ldap RFC  SASL (Simple Authentication and Security
>> Layer)
>> openldap-client-2.3.11p4 Open source LDAP software (client)
>> #
>>
>> How the f* should I remove those two without completely scratching the
disk??
>> Any ideas?
>
> I can't test this right now, but have you tried naming them both on
> the pkg_delete command-line?
>
> (I suspect this is resolved in -current for 4.7 with espie's pkg work.)
>
>
> Philip Guenther

pkg_add/pkg_delete

[Maxim Bourmistrov]

Dobrij den , citizens of this ship.

While upgrading/updating my 3.6-old box to 4.6 I noticed some issues.

Here it comes:
I want "-F force"-flag for pkg_delete - I know what I'm dealing with and I
don't want to spend my evening in front of a laptop-screen with my bottle of
Stolichnaya.
I want to finish it and go to the club, not sitting and "rm -rf
/all/that/crap/pkg_delete/could/not/fix".
I want to overwrite files. I want pkg-tools to be able to remove all the crap
I DON'T WANT TO REMOVE MANUALLY.

Upgrade process for OpenBSD base is great! I wish  it was the same for pkges.
Each time I have to upgrade I hope pkg-tools got more intelligent, but not.

"-F"-flag is for force - give me force to remove and overwrite everything!
If I break - it's up to me.

//Peace, war and Hallelujah! Ze russian.

pkg_delete

[Maxim Bourmistrov]

Hi,
trying to update/upgrade pkges from 3.9 to 4.6.
Long time touching this box, yes.

However:

# pkg_delete -F dependencies openldap-client
Can't remove openldap-client-2.3.11p4 without also removing:
cyrus-sasl-2.1.21p2-ldap
(removing them as well)
# pkg_info|grep ldap
cyrus-sasl-2.1.21p2-ldap RFC  SASL (Simple Authentication and Security
Layer)
openldap-client-2.3.11p4 Open source LDAP software (client)
#

How the f* should I remove those two without completely scratching the disk??
Any ideas?

P.S.
The pkg_update process is ALWAYS the pain somewhere else, than root.

//me

Re: mbuf KPI

[Maxim Bourmistrov]

Thank you for the answer, Bret.

Best regards

Maxim Bourmistrov
mailto: maxim.bourmist...@unixconn.com
tfn.: +46735461332




On 1 aug 2009, at 10.35, Bret S. Lambert wrote:


On Sat, Aug 01, 2009 at 10:23:55AM +0200, Maxim Bourmistrov wrote:

Actually, I know what I'm asking for.
I want to manipulate and inject packets from kernel space. Not via
bpf and userland.


Congrats; you can do that already.


I want to load up an LKM and don't patch all over the src.


Then you can include a set of functions/defines/whatever that provides
those interfaces for you in your LKM

#if defined(__OpenBSD__)

#endif

To answer a question you asked in an off-list email: yes, there's been
some bitching between devs about how bad a set of functions exist for
mbuf manipulation. But there's been nothing concrete, AFAIK, so the
interface you're talking about hasn't really been considered for  
inclusion,
nor do we really know the direction that any future mbuf API should  
go.


So, long answer short: it's not included because it's not included.



Last I checked, OpenBSD lacked what I needed(OSX does not), so this
is why I'm asking.
I'm asking a clear interface to work with.


But I suspect you don't even know what you're asking for.

Don't ever talk to me like that, before you done your research.

//maxim

On 31 jul 2009, at 23.10, Chris Cappuccio wrote:


So, what are you asking for?

For OpenBSD to adopt the Mac OS X mbuf interface (or "KPI")?

What is the deficiency in the OpenBSD mbuf interface that you see?

What function do you need?  For what application?

Most of the Mac OS X "mbuf KPI" is the same as the OpenBSD mbuf
interface, just with different function names.  In some cases
there are new functions that OpenBSD doesn't have, and handles
differently.  But I suspect you don't even know what you're asking
for.

Maxim Bourmistrov [maxim.bourmist...@unixconn.com] wrote:

Hello,
Is  something "nice to have"/on TODO-list?
If not, what are the reasons for not having it?

//maxim


--
Trying to bring taste and skill into a branch of artistic endeavor
which had sunk to the lowest possible depths.

Re: mbuf KPI

[Maxim Bourmistrov]

Actually, I know what I'm asking for.
I want to manipulate and inject packets from kernel space. Not via bpf  
and userland.

I want to load up an LKM and don't patch all over the src.

Last I checked, OpenBSD lacked what I needed(OSX does not), so this is  
why I'm asking.

I'm asking a clear interface to work with.

> But I suspect you don't even know what you're asking for.
Don't ever talk to me like that, before you done your research.

//maxim

On 31 jul 2009, at 23.10, Chris Cappuccio wrote:


So, what are you asking for?

For OpenBSD to adopt the Mac OS X mbuf interface (or "KPI")?

What is the deficiency in the OpenBSD mbuf interface that you see?

What function do you need?  For what application?

Most of the Mac OS X "mbuf KPI" is the same as the OpenBSD mbuf  
interface, just with different function names.  In some cases there  
are new functions that OpenBSD doesn't have, and handles  
differently.  But I suspect you don't even know what you're asking  
for.


Maxim Bourmistrov [maxim.bourmist...@unixconn.com] wrote:

Hello,
Is  something "nice to have"/on TODO-list?
If not, what are the reasons for not having it?

//maxim


--
Trying to bring taste and skill into a branch of artistic endeavor  
which had sunk to the lowest possible depths.

mbuf KPI

[Maxim Bourmistrov]

Hello,
Is  something "nice to have"/on TODO-list?
If not, what are the reasons for not having it?

//maxim

Re: Troubles in using the VmWare Tools vmt driver

[Maxim Bourmistrov]

From vmt(4):

vmt provides access to the host machines clock as a timedelta sensor.

That's all it can do for you.

On 3 jul 2009, at 15.56, Alexandre Verriere wrote:


Hi list,


I'm using virtualization to make a lab testing environnement and i'm
trying to automate power operations on a VmWare guest running  
OpenBSD4.5

(dmesg at the bottom).
So i compiled a kernel with the vmt driver enabled but VmWare server  
2.00 doesn't

detect the vmware tools?

Could someone point me in the right direction to make this work?

-
OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
   dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ ("AuthenticAMD"
686-class, 512KB L2 cache) 2.31 GHz
cpu0:
FPU 
,V86 
,DE 
,PSE 
,TSC 
,MSR 
,PAE 
,MCE 
,CX8 
,APIC 
,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16

real mem  = 267939840 (255MB)
avail mem = 250789888 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/29/08, BIOS32 rev. 0 @  
0xfd780,

SMBIOS rev. 2.4 @ 0xe4010 (45 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 07/29/2008
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3)
S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3)  
Z00P(S3)
Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3)  
Z00X(S3)
Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3)  
Z015(S3)
Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) P2P1(S3)  
S1F0(S3)
S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3)  
S9F0(S3)
Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3)  
Z00W(S3)
Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3)  
Z014(S3)
Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3)  
P2P2(S3)
S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3)  
S8F0(S3)
S9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3)  
Z00V(S3)
Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3)  
Z013(S3)
Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3)  
Z01B(S3)
P2P3(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3)  
S7F0(S3)
S8F0(S3) S9F0(S3) Z00P(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3)  
Z00U(S3)
Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3)  
Z012(S3)
Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3)  
Z01A(S3)
Z01B(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) PE60(S3) S1F0(S3)  
PE70(S3)
S1F0(S3) PE80(S3) S1F0(S3) PE90(S3) S1F0(S3) PEA0(S3) S1F0(S3)  
PEB0(S3)
S1F0(S3) PEC0(S3) S1F0(S3) PED0(S3) S1F0(S3) PEE0(S3) S1F0(S3)  
PE41(S3)
S1F0(S3) PE42(S3) S1F0(S3) PE43(S3) S1F0(S3) PE44(S3) S1F0(S3)  
PE45(S3)
S1F0(S3) PE46(S3) S1F0(S3) PE47(S3) S1F0(S3) PE51(S3) S1F0(S3)  
PE52(S3)
S1F0(S3) PE53(S3) S1F0(S3) PE54(S3) S1F0(S3) PE55(S3) S1F0(S3)  
PE56(S3)
S1F0(S3) PE57(S3) S1F0(S3) PE61(S3) S1F0(S3) PE62(S3) S1F0(S3)  
PE63(S3)
S1F0(S3) PE64(S3) S1F0(S3) PE65(S3) S1F0(S3) PE66(S3) S1F0(S3)  
PE67(S3)
S1F0(S3) PE71(S3) S1F0(S3) PE72(S3) S1F0(S3) PE73(S3) S1F0(S3)  
PE74(S3)
S1F0(S3) PE75(S3) S1F0(S3) PE76(S3) S1F0(S3) PE77(S3) S1F0(S3)  
PE81(S3)
S1F0(S3) PE82(S3) S1F0(S3) PE83(S3) S1F0(S3) PE84(S3) S1F0(S3)  
PE85(S3)
S1F0(S3) PE86(S3) S1F0(S3) PE87(S3) S1F0(S3) PE91(S3) S1F0(S3)  
PE92(S3)
S1F0(S3) PE93(S3) S1F0(S3) PE94(S3) S1F0(S3) PE95(S3) S1F0(S3)  
PE96(S3)
S1F0(S3) PE97(S3) S1F0(S3) PEA1(S3) S1F0(S3) PEA2(S3) S1F0(S3)  
PEA3(S3)
S1F0(S3) PEA4(S3) S1F0(S3) PEA5(S3) S1F0(S3) PEA6(S3) S1F0(S3)  
PEA7(S3)
S1F0(S3) PEB1(S3) S1F0(S3) PEB2(S3) S1F0(S3) PEB3(S3) S1F0(S3)  
PEB4(S3)
S1F0(S3) PEB5(S3) S1F0(S3) PEB6(S3) S1F0(S3) PEB7(S3) S1F0(S3)  
SLPB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 66MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpibat0 at acpi0: BAT1 not present
acpibat1 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: SLPB
bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xdc000/0x4000!
0xe4000/0x4000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to  
compatibility

wd0 at pciide0 channel 0 drive 0: 
wd0: 64-sector PIO, LBA, 40960MB, 83886080 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-

Re: random crashes on a firewall with OpenBSD 4.5-stable

[Maxim Bourmistrov]

Overheating?

On 26 jun 2009, at 17.50, Michal wrote:

Well, you can check the Volt readings in the bios, most will give  
you a
reading, but I am sure there is some BSD software out there, maybe  
someone
in the list will know. On windows you can use Speedfan. Even if it's  
not
this, it's worth knowing how to check this as a simple check on  
servers


-Original Message-
From: Comhte [mailto:com...@daknet.org]
Sent: 26 June 2009 16:42
To: Michal
Subject: Re: random crashes on a firewall with OpenBSD 4.5-stable

Oh sorry :p
How could i test the power supply unit ?

Michal a icrit :
Other servers?? I don't mean PDU, I mean PSU...the power supply in  
the

server. If your shearing a power supply across 2 servers I would be

shocked

:)

-Original Message-
From: Comete [mailto:com...@daknet.org]
Sent: 26 June 2009 13:48
To: Michal
Subject: Re: random crashes on a firewall with OpenBSD 4.5-stable

No problem with the PSU and voltage limits. The PSU isn't used at its
full capacity and the other servers plugged on it work well.

Could it be a bad network interface ?

Michal a icrit :
Just stabbing the dark here, test your Voltage Rails on your PSU.  
Check

they
are within limits. I find unexplained crash's can be traced back  
to PSU's

quite often

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On  
Behalf Of

Comhte
Sent: 26 June 2009 12:22
To: Misc OpenBSD
Cc: Daniel Gracia Garallar
Subject: Re: random crashes on a firewall with OpenBSD 4.5-stable

Well i have tested the RAM with memtest, no error.

maybe another idea ?

Thanks

Daniel Gracia Garallar a C)crit :

Oh and maybe bad RAM; I've hit some nasty errors with these faulty
DIMMs... :/

ComC(te escribiC3:

Hi,

we are using the last OpenBSD 4.5-stable release on an old Compaq
Proliant ML350 as a firewall with spamd. But we encounter randomly
some system crashes (once a week or two weeks). The system always
displays the same message:

uvm_fault (0xd080d9e00x0,0,1) -> e

kernel: page fault trap, code=0

Stopped at cac_pci_l0_intr_pending+0xb
push 0x34 (%eax)

What do you think it could be ? I thought about maybe a hardware
problem but where exactly...

I join my dmesg below

Thanks for your advice !

OpenBSD 4.5-stable (GENERIC) #9: Sun May 17 22:59:17 CEST 2009
   r...@arwen.saintlo.fr:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) III CPU family 1266MHz ("GenuineIntel"
686-class) 1.27 GHz
cpu0:



FPU 
,V86 
,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,

FXSR,SSE

real mem  = 267988992 (255MB)
avail mem = 250839040 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @
0xf, SMBIOS rev. 2.3 @ 0xec000 (31 entries)
bios0: vendor Compaq version "D11" date 01/29/2002
bios0: Compaq ProLiant ML350 G2
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC SPCR
acpi0: wakeup devices PBTN(S5)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 3 (boot processor)
cpu0: apic clock running at 132MHz
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 11, 16 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
ioapic1 at mainbus0: apid 2 pa 0xfec01000, version 11, 16 pins
ioapic1: misconfigured as apic 0, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCI1)
acpicpu0 at acpi0
acpitz0 at acpi0: critical temperature 31 degC
acpibtn0 at acpi0: PBTN
bios0: ROM list: 0xc/0x8000 0xc8000/0x1800 0xc9800/0x1800
0xcb000/0x1800 0xcc800/0x4000! 0xd0800/0x1800 0xee000/0x2000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20LE Host" rev 0x06
pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20LE Host" rev 0x06
pci1 at pchb1 bus 2
em0 at pci1 dev 1 function 0 "Intel PRO/1000T (82544GC)" rev 0x02:
apic 2 int 0 (irq 5), address 00:02:b3:b9:0d:a4
em1 at pci1 dev 2 function 0 "Intel PRO/1000T (82544GC)" rev 0x02:
apic 2 int 2 (irq 15), address 00:02:b3:b9:0d:7d
re0 at pci1 dev 3 function 0 "D-Link Systems DGE-528T" rev 0x10:
RTL8169/8110SB (0x1000), apic 2 int 4 (irq 15), address

00:1c:f0:6f:38:7e

rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 3
cac0 at pci1 dev 4 function 0 "DEC Compaq SMART RAID 42xx" rev  
0x01:

apic 2 int 6 (irq 11), Smart Array 431
scsibus0 at cac0: 1 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI2 0/ 
direct

fixed
sd0: 34727MB, 512 bytes/sec, 71122560 sec total
re1 at pci1 dev 5 function 0 "D-Link Systems DGE-528T" rev 0x10:
RTL8169/8110SB (0x1000), apic 2 int 8 (irq 15), address

00:1c:f0:62:eb:12

rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 3
fxp0 at pci0 dev 1 function 0 "Intel 8255x" rev 0x08, i82559:  
apic 2

int 10 (irq 5), address 00:02:a5:44:33:f7
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
ahc0 at pci0 dev 2 function 0 "Adaptec AHA-3960D U160" rev 0x01:  
apic

2 int 11 (irq 11)
scsibus1 at ahc0: 16 targets, initiator 7
ahc1 at pci0 dev 2 function 1 "Adaptec AHA-3960D

Re: Error with red consoles

[Maxim Bourmistrov]

You'll probably have to run on VESA.
and as you are running OpenBSD as a virtual machine don't expect to
things work as they should.

Effects/problems you see are probably because of how Microsoft
Corporation Virtual Machine virtualizes hardware.

//maxim

On 11 maj 2009, at 13.30, dMITRIJ pA]ENKO wrote:


Hello! I am sorry for my english

I put a 4.5, but it has some bugs in the X11 VGA card chosen from a
database
in xorgconfig. when start X11, it says that
is not found the driver VGA. had to use VESA. X11 seems to work. But
in the
database have the same VGA driver

second error occurs after loading if switch to another console such
as ctrl
+ alt + F2 and then back to ctrl + alt + F2,
all consoles are red and white letters. after you restart again the
white
letters on a black background.
here: http://teran2.chat.ru/example.gif


Explain to me please what is the problem. It wants to deal


dmesg :

OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
   dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-
class) 898
MHz
cpu0: FPU,V86,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,ACPI,MMX,FXSR,SSE,SSE2
real mem  = 133722112 (127MB)
avail mem = 121028608 (115MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/22/06, SMBIOS rev. 2.3 @
0xf8cc0
(39 entries)
bios0: vendor American Megatrends Inc. version "080002" date
02/22/2006
bios0: Microsoft Corporation Virtual Machine
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios at bios0 function 0x1a not configured
bios0: ROM list: 0xc/0xc000! 0xcc000/0x800 0xcc800/0x800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x03
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel
0 wired to compatibility, channel 1 wired to
compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 128-sector PIO, LBA, 1023MB, 2096640 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02:
polling
iic0 at piixpm0
"eeprom" at iic0 addr 0x50 not configured
"eeprom" at iic0 addr 0x51 not configured
"eeprom" at iic0 addr 0x52 not configured
"eeprom" at iic0 addr 0x53 not configured
vga1 at pci0 dev 8 function 0 "S3 Trio32/64" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
de0 at pci0 dev 10 function 0 "DEC 21140" rev 0x20, 21140A pass 2.0:
irq 11,
address 00:03:ff:27:4d:8b
de1 at pci0 dev 10 function 1 "DEC 21140" rev 0x20, 21140A pass 2.0:
irq 11,
address 00:03:ff:24:4d:8b
isa0 at piixpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ti16750, 64 byte fifo
com0: probed fifo depth: 0 bytes
com1 at isa0 port 0x2f8/8 irq 3: ti16750, 64 byte fifo
com1: probed fifo depth: 0 bytes
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v4.13
midi0 at sb0: 
audio0 at sb0
opl0 at sb0: model OPL3
midi1 at opl0: 
pcppi0 at isa0 port 0x61
midi2 at pcppi0: 
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
isapnp0 at isa0 port 0x279: read port 0x203
"Sound Blaster 16, PNPB003, PNPB003, " at isapnp0 port
0x221/16,0x0/16 irq 0
drq 0,0 resource conflict
joy0 at isapnp0 "Game Port, PNPB02F, PNPB02F, " port 0x201/1
biomask e745 netmask ef45 ttymask ffdf
softraid0 at root
root on wd0a swap on wd0b dump on wd0b

swap(encrypt) vs. vnd

[Maxim Bourmistrov]

Hello misc@,
any one can answer the following question:

why codebase used to encrypt/decrypt swap is not used to replace/ 
complement vnd?
Complement, means skip the creation of encrypted image part and work  
directly with block device.


//maxim

Re: automaticaly mount/umount encrypted $HOME or ...

[Maxim Bourmistrov]

Well, it is up to you to chose complexity of the password and let the  
john to work harder. :)


Choosing bash was a quick solution for executing the job after I'v  
logged out, e.g. how else do you umount and vnconfig -u?
I'd like to use default ksh, but quick google-search gave me an answer  
- ksh can not exec after logout.
Here I hope someone can point me to the right direction. Using bash  
and shells at all isn't a clean solution, but the only I have found at  
the time.


Not tested with xdm. Really, non tests at all, only the setup described.

As stated, this is just a concept. Improvements always accepted :)

//maxim

On 28 apr 2009, at 20.25, Nick Guenther wrote:


Interesting. But if I steal your laptop and run jack the ripper on it
then I get your svnd password, don't I?

Using bash seems awkward. Does this work if you're using xdm?

Otherwise, this is very slick. The reason I haven't gotten around to
using encrypted homes is just that it's awkward to do it in .profile
because you'd have to remount your /home/$USER over top, but moving
the mounting code into login(1) avoids that

-Nick

On 28/04/2009, Maxim Bourmistrov   
wrote:

... yet another vnd-hack including modified login_passwd, sudo
and .bash_logout:

http://en.roolz.org/Blog/Entries/2009/4/27_Auto_mount_umount_of_encrypted_%24HOME_on_OpenBSD.html

Read first-line warning carefully before usage/flame :).

//maxim

automaticaly mount/umount encrypted $HOME or ...

[Maxim Bourmistrov]

... yet another vnd-hack including modified login_passwd, sudo  
and .bash_logout:


http://en.roolz.org/Blog/Entries/2009/4/27_Auto_mount_umount_of_encrypted_%24HOME_on_OpenBSD.html

Read first-line warning carefully before usage/flame :).

//maxim

European orders(Sweden) - nohup.se

[Maxim Bourmistrov]

Hello misc@,
it has been almost a week since I sent an invoice for OpenBSD 4.5 CD/t- 
shirt to nohup.se.
Well, there is no answer so far and the webpage is outdated and  
promoting old releases.


Any one from Sweden has ever successfully ordered anything from this  
site lately?

Any other (successful) paths available?

//maxim

Re: more information about PF BUG

[Maxim Bourmistrov]

It is a "one line"-addition to ping.c.

Then you use newly compiled ping like this: ping -D 
This scenario works for NAT and attacker sitting on the local network.

Tested on OpenBSD 4.3 acting as a NAT-box.

//maxim

On 12 apr 2009, at 22.05, Fernando Quintero wrote:


Hi list,
it's about: http://www.openbsd.org/errata45.html#002_pf

I'm trying to reproduce this bug, but i would like to get more  
information

about how the "kernel panic" is produced.

so, anyone has more information?
http://www.securitytracker.com/alerts/2009/Apr/1022032.html

I review the patchs, and I configurate some rules to test the bug,  
create

the icmp packets, but it does not work.


--
--

Fernando Quintero
http://nonroot.blogspot.com/
*Just a nonroot User*

Re: where to order now ?

[Maxim Bourmistrov]

Well,
until Wim speaks up, this look to me as a major misuse of TRUST I'v  
ever seen in "Open Source"-community.


Anyone considered Baltic inkasso? ;)



On 3 apr 2009, at 20.13, Theo de Raadt wrote:

I guess Wim would be more than happy to sell his stock of stickers  
and
T-Shirts, and especially those who believe in his sincerity, and  
others
who might be interested in selling these items, might want to  
extend a

hand, buying off his products, to help him rebuild lost trust


Wim can rebuild lost trust by paying the Computer Shop what he owes,
and also paying out the donations.

He can rebuild trust by showing us why the total donations ever passed
to the project comes to $3402.48, over more than 7 years.

I wish those people who -- added up -- have given him more than this
above value would speak up.