Re: queueing/hfsc question

[Gabor Berczi]

On Dec 4, 2013, at 12:44 AM, andy wrote:


As Josh and the other guys said, you can use the same queue name on
different interfaces but they must be children.


Nope, they don't have to be, but thanks to your working example I  
could deduce what's the deciding factor.


=== Every queue must have the interface defined. ===

And of course it makes sense (dammit), since there is no relation  
between "altq" and "queue" statements otherwise, despite any fancy  
user-specified tabulations in pf.conf :) They actually make this  
issue harder to spot.


So this works:

queue _local on $ext bandwidth 2% priority 4 hfsc(upperlimit 100Mb)
queue _local on $int bandwidth 2% priority 4 hfsc(upperlimit 100Mb)

But this does not:

queue _local bandwidth 2% priority 4 hfsc(upperlimit 100Mb)
queue _local bandwidth 2% priority 4 hfsc(upperlimit 100Mb)

Thx all for the help!

--
G

ssh and relayd

[Predrag Punosevac]

Hi Misc,

This is trivial question but I am having a hard time wrapping my head
around the possible use of relayd for ssh traffic redirecting. Namely I
have a situation where I have multiple hosts behind firewall which I
would like to make available for ssh loggin. 

In the past I was using different port numbers to accomplish this 

pass in on egress inet proto tcp to (egress) port 1671 rdr-to $mpi
pass in on egress inet proto tcp to (egress) port 1672 rdr-to $gpu
pass in on egress inet proto tcp to (egress) port 1673 rdr-to $hammer

However I was wondering if I could use relayd in conjunction with PF to 
avoid different port numbers. 

I would like to have something like

ssh u...@mpi.mylab.org going to mpi machine 
ssh u...@mpi.mylab.org going to gpu machine
ssh u...@hammer.mylab.org going to hammer machine

on the default port 22. The reason is ridiculous of course. I prefer to
use something like relayd than to explain to 20 people how to change the
port on their putty clients. 

It looks to me that the very least that can be accomplished is to have
some kind load balancing where ssh traffic is redirected to one of three
available hosts mpi, gpu, and hammer but how do I force redirection to a
particular host just based on the name of ssh request. Note that ssh
host have no routable  addresses and the only DNS record is the one I
keep in my Unbound (caching only server).

Most Kind Regards,
Predrag 

Re: queueing/hfsc question

[Gabor Berczi]

On Dec 3, 2013, at 9:43 PM, Ryan Freeman wrote:


try:
queue extpribandwidth 10% priority 7qlimit 500 hfsc 
(realtime 5% ecn red)
queue intpribandwidth 10% priority 7qlimit 500 hfsc 
(realtime 5% ecn red)


Yes, but as I said, only one of these can be used (can't pass into  
two queues). I'd like to shape both up-, and downstream sides of TCP  
connections.


--
G

Re: 10G with Intel card - GBIC options

[Stuart Henderson]

On 2013-12-02, Kapetanakis Giannis  wrote:
> I would love to go for the SFP+ path but we cannot afford it,

flexoptix do a xenpak-sfp+ converter (and lots of other interesting things)

Re: ipsec or iked to deploy under openbsd carp fws

[Stuart Henderson]

On 2013-12-02, C. L. Martinez  wrote:
> Hi all,
>
>  I need to deploy IPSec tunnels (lan-to-lan and roadwarriors clients
> like linux and windows) under two openbsd carp firewalls.
>
..
>
>  What option can be best to deploy in these firewalls: ipsec
> (ipsec.conf and isakmpd) or iked?

This depends which protocols your clients support and whether you
want to pay attention to the warning at the bottom of the iked manual.

>  Searching in google and reading some docs, I have several doubts
> about which one to choose. If I am not wrong, iked doesn't supports
> sasyncd, is it correct??

I am *much* happier with my use of isakmpd since I got rid of sasyncd
and just rely on dead peer detection (DPD), I use ifstated to kill
isakmpd and flush ipsec if the state of the carp interface changes to
backup, or start isakmpd and load ipsec rules when the state changes
to master. When I used sasyncd I got into various situations where
things wouldn't work until I disabled it and rebooted both vpn
gateways.. Obviously this only works if your clients support DPD.

Re: queueing/hfsc question

[Stuart Henderson]

On 2013-12-03, Gabor Berczi  wrote:
> On Dec 3, 2013, at 7:15 PM, Andy wrote:
>
>> Including http://www.openbsd.org/faq/pf/queueing.html
>
> This page doesn't even mention neither HFSC nor any new scheduler...
>

The FAQ does not cover -current, it covers the last release.
(Feel free to ask about this again when 5.5 is out if the faq isn't
updated though. ;)

Re: queueing/hfsc question

[Stuart Henderson]

On 2013-12-03, Ryan Freeman  wrote:
> On Tue, Dec 03, 2013 at 09:10:32PM +0100, Gabor Berczi wrote:
>> On Dec 3, 2013, at 8:57 PM, josh Grosse wrote:
>> 
>> >The new scheduler will be included in 5.5-release.  Users of -
>> >current now, or of 5.5 when it is released, who wish to continue
>> >using altq syntax and an altq scheduler may do so during a
>> >transition period, as described in the link above.
>> 
>> Okay. But what you just described ("Child queues are able to use the
>> same name") doesn't work with ALTQ either. Are you certain it does
>> with the new sched? (that would mean that it was impossible to do
>> before)
>> 
>> altq on {$extif} bandwidth 600Kb hfsc queue { pri,http,warez }
>> 
>> queue pri   bandwidth 10% priority 7qlimit 500 hfsc(realtime
>> 5% ecn red)
>> queue http  bandwidth 70% priority 5qlimit 500 hfsc(realtime
>> 50% ecn red)
>> queue warez bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit
>> 90% ecn red)
>> 
>> altq on {$intif} bandwidth 10Kb hfsc queue { local,down }
>> 
>> queue local bandwidth 90% priority 7qlimit 500 hfsc(realtime
>> 5% ecn red)
>> queue down  bandwidth 10% { pri,http,default,warez }
>>  queue pri  bandwidth 10% priority 7qlimit 500 hfsc(realtime
>> 5% ecn red)
>>  queue http bandwidth 70% priority 5qlimit 500 hfsc(realtime
>> 50% ecn red)
>>  queue default  bandwidth 10% priority 4qlimit 500 hfsc(realtime
>> 5% ecn red)
>>  queue warezbandwidth 1% priority 0 qlimit 500 hfsc(upperlimit
>> 90% ecn red)
>> 
>> queue pri already exists on interface pppoe0
>> /etc/pf.conf.dual:71: errors in queue definition
>> queue http already exists on interface pppoe0
>> /etc/pf.conf.dual:72: errors in queue definition
>> queue warez already exists on interface pppoe0
>
> try:
>
> altq on {$extif} bandwidth 600Kb hfsc queue { pri,http,warez }
>
> queue extpribandwidth 10% priority 7qlimit 500 hfsc(realtime 5% 
> ecn red)
> queue exthttp   bandwidth 70% priority 5qlimit 500 hfsc(realtime 50% 
> ecn red)
> queue extwarez  bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit 90% ecn 
> red)
>
> altq on {$intif} bandwidth 10Kb hfsc queue { local,down }
>
> queue local bandwidth 90% priority 7qlimit 500 hfsc(realtime 5% 
> ecn red)
> queue down  bandwidth 10% { pri,http,default,warez }
> queue intpribandwidth 10% priority 7qlimit 500 hfsc(realtime 5% 
> ecn red)
> queue inthttp   bandwidth 70% priority 5qlimit 500 hfsc(realtime 50% 
> ecn red)
> queue default   bandwidth 10% priority 4qlimit 500 hfsc(realtime 5% 
> ecn red)
> queue intwarez  bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit 90% ecn 
> red)
>
> the only thing i noticed is you're defining pri, http, and warez twice and 
> confusing pf.

This does not confuse PF at all, but you have to be explicity about
which interfaces they relate to.

Re: AnonCVS server data

[Stuart Henderson]

On 2013-11-30, Jordan Earls  wrote:
> I've been looking at trying to convert the CVS repository to a git
> repository. My goal with this is to allow for more people to easily take a
> glance at the source code of OpenBSD.

This already exists at http://anoncvs.estpak.ee/cgi-bin/cgit/ -
there have been other attempts too but this one is still up and running
and converting new commits. If I'm looking for a commit which has broken
something in a known timeframe, often this is my first port of call,
looking through the log there and clicking to see the diff for a commit
is usually a lot quicker than running cvsps (and far quicker than many
other methods).

>   I just want for people to be able to easily play with the source
> code without spending hours pulling things down.

An anoncvs checkout should be nothing like "hours".. over ADSL it takes
me a touch over 4 minutes to checkout all of src (and unlike git, if I'm
only interested in a certain subdirectory, I can pull that individually..)

Re: queueing/hfsc question

[andy]

On Tue, 3 Dec 2013 21:10:32 +0100, Gabor Berczi 
wrote:
> On Dec 3, 2013, at 8:57 PM, josh Grosse wrote:
> 
>> The new scheduler will be included in 5.5-release.  Users of - 
>> current now, or of 5.5 when it is released, who wish to continue  
>> using altq syntax and an altq scheduler may do so during a  
>> transition period, as described in the link above.
> 
> Okay. But what you just described ("Child queues are able to use the  
> same name") doesn't work with ALTQ either. Are you certain it does  
> with the new sched? (that would mean that it was impossible to do  
> before)
> 
> altq on {$extif} bandwidth 600Kb hfsc queue { pri,http,warez }
> 
> queue pri   bandwidth 10% priority 7qlimit 500 hfsc 
> (realtime 5% ecn red)
> queue http  bandwidth 70% priority 5qlimit 500 hfsc 
> (realtime 50% ecn red)
> queue warez bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit  
> 90% ecn red)
> 
> altq on {$intif} bandwidth 10Kb hfsc queue { local,down }
> 
> queue local bandwidth 90% priority 7qlimit 500 hfsc 
> (realtime 5% ecn red)
> queue down  bandwidth 10% { pri,http,default,warez }
>   queue pri  bandwidth 10% priority 7qlimit 500 hfsc 
> (realtime 5% ecn red)
>   queue http bandwidth 70% priority 5qlimit 500 hfsc 
> (realtime 50% ecn red)
>   queue default  bandwidth 10% priority 4qlimit 500 hfsc 
> (realtime 5% ecn red)
>   queue warezbandwidth 1% priority 0 qlimit 500 hfsc(upperlimit  
> 90% ecn red)
> 
> queue pri already exists on interface pppoe0
> /etc/pf.conf.dual:71: errors in queue definition
> queue http already exists on interface pppoe0
> /etc/pf.conf.dual:72: errors in queue definition
> queue warez already exists on interface pppoe0

As Josh and the other guys said, you can use the same queue name on
different interfaces but they must be children. Here's the queues from one
of my firewalls;

# WAN egress Queues
altq on $if_vpls bandwidth 1500Mb hfsc queue { _local, _wan }
queue _local on $if_vpls bandwidth 2% priority 4 hfsc(upperlimit
100Mb) { _local_kernel, _local_data }
queue _local_kernel on $if_vpls bandwidth 1% priority 6
hfsc(realtime 1%, linkshare 10%)
queue _local_data on $if_vpls bandwidth 99% priority 0
hfsc(linkshare 80%)
queue _wan on $if_vpls bandwidth 98% priority 15 hfsc(linkshare 98%) {
_wan_pri, _wan_int, _wan_web, _wan_dflt }
queue _wan_pri on $if_vpls bandwidth 20% priority 6 qlimit 100
hfsc(realtime 20%, linkshare 20%)
queue _wan_int on $if_vpls bandwidth 5% priority 5 qlimit 100
hfsc(realtime 5%, linkshare 5%)
queue _wan_web on $if_vpls bandwidth 50% priority 4 qlimit 100
hfsc(realtime(10%, 1000, 1%), linkshare 50%, ecn)
queue _wan_dflt on $if_vpls bandwidth 5% priority 2 qlimit 100
hfsc(realtime(10%, 1000, 1%), linkshare 5%, ecn, default)
# LAN egress Queues
altq on $if_lan bandwidth 1500Mb hfsc queue { _local, _wan }
queue _local on $if_lan bandwidth 2% priority 4 hfsc(upperlimit 100Mb)
{ _local_kernel, _local_data }
queue _local_kernel on $if_lan bandwidth 1% priority 6
hfsc(realtime 1%, linkshare 10%)
queue _local_data on $if_lan bandwidth 99% priority 0
hfsc(linkshare 80%)
queue _wan on $if_lan bandwidth 98% priority 15 hfsc(linkshare 98%) {
_wan_pri, _wan_int, _wan_web, _wan_dflt }
queue _wan_pri on $if_lan bandwidth 10% priority 6 qlimit 100
hfsc(realtime 10%, linkshare 10%)
queue _wan_int on $if_lan bandwidth 5% priority 5 qlimit 100
hfsc(realtime 5%, linkshare 5%)
queue _wan_web on $if_lan bandwidth 60% priority 4 qlimit 100
hfsc(realtime(10%, 1000, 1%), linkshare 60%, ecn)
queue _wan_dflt on $if_lan bandwidth 5% priority 2 qlimit 100
hfsc(realtime(10%, 1000, 1%), linkshare 5%, ecn, default)

pass quick proto { tcp } from { $int_net } to any port { 80, 443 } keep
state (pflow) queue (_wan_web,_wan_pri) set prio (4,6)

WARNING; Don't set your qlimit to 500 unless you really know what you are
doing. 500 is huge!
The bugger your buckets, the longer you'll just store packets for until
their is bandwidth available to send them. This means the packet delay
variance on sessions in queues with high qlimits will be very high.
You control TCP by dropping packets, so dropping packets is not a bad
thing. ECN is much better though.. I.e. Dropping makes the sender stop
sending you so much traffic to allow your queues to clear and find the
balanced max throughput whilst keeping latency at a min..
I use qlimit 100 here as this firewall has a cluster of web crawlers
behind it and so the jitter doesn't matter. Office firewalls however which
have VoIP queues have qlimit set to 30...

Another tip, the sum of the first property to realtime cannot be greater
than 80% of the interface parent..

Anyway, learn the new queue stuff.. I still need to read all the man pages
and notes on it myself yet.

Andy

5.4-stable kernel panic with bioctl mfi0 (was: Re: uvm_fault with OpenBSD 5.4)

[Kor son of Rynar]

Hi,

It happened again with another machine, a R420, also running 5.4-stable.  I
can reproduce the problem giving a sequence of bioctl mfi0 commands:

(Please, do not try this on production servers)

# for foo in `jot 1000`; do bioctl mfi0; sleep 1; done

The kernel panics with:

uvm_fault(0x81c96be0, 0x803e2000, 0, 2) -> e
fatal page fault in supervisor mode
trap type 6 code 2 rip 8136f566 cs 8 rflags 10206 cr2
803e2000 cpl 0 rsp 8000221d8a38
panic: trap type 6, code=2, pc=8136f566
Starting stack trace...
panic() at panic+0xf5
trap() at trap+0x7f1
--- trap (number 6) ---
memmove() at memmove+0x16
mfi_mgmt() at mfi_mgmt+0x6a
mfi_bio_getitall() at mfi_bio_getitall+0x22e
mfi_ioctl_vol() at mfi_ioctl_vol+0x1f
mfi_refresh_sensors() at mfi_refresh_sensors+0xbf
sensor_task_work() at sensor_task_work+0x21
workq_thread() at workq_thread+0x33
end trace frame: 0x0, count: 248
End of stack trace.

ps output:

USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
root 1  0.0  0.0   512 0 ??  Is 6:39PM0:01.01 (init)
root  8415  0.0  0.0   640 0 ??  Is 6:39PM0:00.08 (syslogd)
_syslogd  6650  0.0  0.0   640 0 ??  R  6:39PM0:00.07 (syslogd)
root 28315  0.0  0.0   700 0 ??  Is 6:39PM0:00.07 (pflogd)
_pflogd  27132  0.0  0.0   764 0 ??  R  6:39PM0:00.06 (pflogd)
_ntp 16749  0.0  0.0   800 0 ??  Rs 6:39PM0:00.12 (ntpd)
_ntp  2570  0.0  0.0   732 0 ??  Is 6:39PM0:00.00 (ntpd)
root   306  0.0  0.0   844 0 ??  Is 6:39PM0:00.01 (ntpd)
root 13586  0.0  0.0   856 0 ??  Is 6:41PM0:00.10 (sshd)
root 30264  0.0  0.0   768 0 ??  Is 6:41PM0:00.08 (master)
_postfix 12225  0.0  0.0   984 0 ??  I  6:41PM2:38.84 (qmgr)
_postfix  6445  0.0  0.0   996 0 ??  I  6:41PM0:00.46 (pickup)
root  8660  0.0  0.0   584 0 ??  Ss 6:41PM0:00.03 (sensorsd)
root  2429  0.0  0.0   612 0 ??  Ss 6:41PM0:00.05 (cron)
_postfix 29725  0.0  0.0  1076 0 ??  I  6:42PM0:00.07 (tlsmgr)
root 14374  0.0  0.0  3536 0 ??  Ss 6:47PM0:04.37 (sshd)
root 30897  0.0  0.0   668 0 p0  Ss 6:47PM0:04.43 (ksh)
root  7488  0.0  0.0   348 0 p0  R+ 7:01PM0:00.02 (bioctl)
root 29346  0.0  0.0   308 0 C0  Is+6:41PM0:00.12 (getty)
root  5325  0.0  0.0   396 0 C1  Is+6:41PM0:00.01 (getty)
root 18672  0.0  0.0   488 0 C2  Is+6:41PM0:00.30 (getty)
root 32223  0.0  0.0   516 0 C3  Is+6:41PM0:00.01 (getty)
root  4731  0.0  0.0   476 0 C5  Is+6:41PM0:00.01 (getty)

Anyone else seeing this with OpenBSD 5.4-stable on Dell servers with PERC
RAID controllers? (PERC H700, H310 Mini, etc?)

Thanks,
--Kor

On Mon, Dec 2, 2013 at 1:30 PM, Kor son of Rynar
wrote:

> Hey guys,
>
> I have just upgraded two Dell servers (a PowerEdge R410 and a R320) to
> OpenBSD 5.4-stable -- before the upgrade, these machines were running
> 5.3-stable without a problem.
>
> After the upgrade to 5.4, both machines started to panic with a
> uvm_fault.  (3 panics so far...) The panic messages are included below,
> extracted with a dmesg -M bsd.0.core -N bsd.0:
>
> --
> hw.machine=amd64
> hw.model=Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80GHz
> hw.product=PowerEdge R320
>
> uvm_fault(0x81c96be0, 0x804c2000, 0, 2) -> e
> fatal page fault in supervisor mode
> trap type 6 code 2 rip 8136f636 cs 8 rflags 10206 cr2
> 804c2000
> cpl 0 rsp 80002215fa38
> panic: trap type 6, code=2, pc=8136f636
> Starting stack trace...
> panic() at panic+0xf5
> trap() at trap+0x7f1
> --- trap (number 6) ---
> memmove() at memmove+0x16
> mfi_mgmt() at mfi_mgmt+0x6a
> mfi_bio_getitall() at mfi_bio_getitall+0x22e
> mfi_ioctl_vol() at mfi_ioctl_vol+0x1f
> mfi_refresh_sensors() at mfi_refresh_sensors+0xbf
> sensor_task_work() at sensor_task_work+0x21
> workq_thread() at workq_thread+0x33
> end trace frame: 0x0, count: 248
> End of stack trace.
>
> --
> hw.machine=amd64
> hw.model=Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
> hw.product=PowerEdge R410
>
> uvm_fault(0x81c96be0, 0x80766000, 0, 2) -> e
> fatal page fault in supervisor mode
> trap type 6 code 2 rip 8136f636 cs 8 rflags 10206 cr2
> 80766000
> cpl 0 rsp 80002614fa38
> panic: trap type 6, code=2, pc=8136f636
> Starting stack trace...
> panic() at panic+0xf5
> trap() at trap+0x7f1
> --- trap (number 6) ---
> memmove() at memmove+0x16
> mfi_mgmt() at mfi_mgmt+0x6a
> mfi_bio_getitall() at mfi_bio_getitall+0x22e
> mfi_ioctl_vol() at mfi_ioctl_vol+0x1f
> mfi_refresh_sensors() at mfi_refresh_sensors+0xbf
> sensor_task_work() at sensor_task_work+0x21
> workq_thread() at workq_thread+0x33
> end trace frame: 0x0, count: 248
> End of stack trace.
>
> --
>
> Anybody else having similar problems?
>
> Thanks,
> -- Kor

Re: OpenBSD and Compute Engine

[Jiri B]

On Tue, Dec 03, 2013 at 04:45:28PM -0500, Bryan Horstmann-Allen wrote:
> I used OpenBSD on SmartOS a couple years ago. There was a bug in KVM that 
> would
> kill the host, but that's been fixed for a while...

I saw when a VM with virtio devices killed RHEL host too. Funny :)
Baf, it was secured with SELinux, haha :)

jirib

Re: OpenBSD and Compute Engine

[Matthew Dempsky]

On Tue, Dec 3, 2013 at 1:35 PM, Jiri B  wrote:
> Aha, big brother grows up :-) I will try to test virtio-scsi on RHEVM
> which also exposes this to VMs.

Cool, let me know if you run into any issues.  I'm sure there's still
some bugs in the driver so I wouldn't put it into production yet, but
it should at least let you mount a virtio-scsi disk.

> Have you tried OpenBSD on SmartOS? Some people say it would need
> some love (some storage issue).

Nope, haven't tried that, and probably won't to be honest.  I don't
really have a need for running OpenBSD on Compute Engine even, just
thought it would be a fun weekend project when I heard about it. :)

Re: OpenBSD and Compute Engine

[Bryan Horstmann-Allen]

+--
| On 2013-12-03 16:35:45, Jiri B wrote:
| 
| Have you tried OpenBSD on SmartOS? Some people say it would need
| some love (some storage issue).

I used OpenBSD on SmartOS a couple years ago. There was a bug in KVM that would
kill the host, but that's been fixed for a while...

Storage works "fine" if you use IDE. :-)
-- 
bdha
cyberpunk is dead. long live cyberpunk.

Re: OpenBSD and Compute Engine

[Jiri B]

On Tue, Dec 03, 2013 at 12:12:09PM -0800, Matthew Dempsky wrote:
> Compute Engine now supports custom OSes [1], so I've been working on
> getting OpenBSD working on it.  I thought I'd share a status update.
> 
> [1] 
> http://googlecloudplatform.blogspot.com/2013/12/google-compute-engine-is-now-generally-available.html
> 
> ** virtio-scsi
> 
> Compute Engine exposes disks as virtio-scsi devices, whereas OpenBSD
> currently only supports virtio-blk disks.  I've got a mostly working
> virtio-scsi driver (WIP: https://codereview.appspot.com/33540044), but
> I still need to polish it a bit.

Aha, big brother grows up :-) I will try to test virtio-scsi on RHEVM
which also exposes this to VMs.

Have you tried OpenBSD on SmartOS? Some people say it would need
some love (some storage issue).

jirib

Re: creating a VPN tunnel with an iPhone client

[Giancarlo Razzolini]

Em 03-12-2013 11:43, Anders Berggren escreveu:
>> I'm looking for a way to connect an iPhone to the local subnet for VOIP 
>> usage through VPN.
>> Has anyone succeeded in creating a VPN tunnel from an iPhone to OpenBSD?
> Yes. npppd's L2TP http://www.openbsd.org/cgi-bin/man.cgi?query=npppd, or 
> OpenVPN is what I have used.
>
I've had success in the past with both. I currently use OpenVPN. It
has iOS and Android clients, and pretty much every other OS. Anyway,
it's up to you. Using npppd has the benefit of being in OpenBSD base
system, also the l2tp/ipsec integration is native on the iOS, so no need
for an app.

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: queueing/hfsc question

[josh Grosse]

On 2013-12-03 15:10, Gabor Berczi wrote:


Okay. But what you just described ("Child queues are able to use the
same name") doesn't work with ALTQ either. Are you certain it does
with the new sched? (that would mean that it was impossible to do
before)


The PF User's guide shows a cbq example where the queue name "bulk" is 
assigned twice.  Stuart Henderson mentioned the technique here:  
http://marc.info/?l=openbsd-pf&m=129478585825865&w=2


I used cbq with this method until switching to the new scheduler.  The 
example rules that I posted in this thread (where the child queues are 
defined with multiple interfaces) are rules that I'm using with the new 
scheduler.

Re: queueing/hfsc question

[Ryan Freeman]

On Tue, Dec 03, 2013 at 09:10:32PM +0100, Gabor Berczi wrote:
> On Dec 3, 2013, at 8:57 PM, josh Grosse wrote:
> 
> >The new scheduler will be included in 5.5-release.  Users of -
> >current now, or of 5.5 when it is released, who wish to continue
> >using altq syntax and an altq scheduler may do so during a
> >transition period, as described in the link above.
> 
> Okay. But what you just described ("Child queues are able to use the
> same name") doesn't work with ALTQ either. Are you certain it does
> with the new sched? (that would mean that it was impossible to do
> before)
> 
> altq on {$extif} bandwidth 600Kb hfsc queue { pri,http,warez }
> 
> queue pri   bandwidth 10% priority 7qlimit 500 hfsc(realtime
> 5% ecn red)
> queue http  bandwidth 70% priority 5qlimit 500 hfsc(realtime
> 50% ecn red)
> queue warez bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit
> 90% ecn red)
> 
> altq on {$intif} bandwidth 10Kb hfsc queue { local,down }
> 
> queue local bandwidth 90% priority 7qlimit 500 hfsc(realtime
> 5% ecn red)
> queue down  bandwidth 10% { pri,http,default,warez }
>  queue pri  bandwidth 10% priority 7qlimit 500 hfsc(realtime
> 5% ecn red)
>  queue http bandwidth 70% priority 5qlimit 500 hfsc(realtime
> 50% ecn red)
>  queue default  bandwidth 10% priority 4qlimit 500 hfsc(realtime
> 5% ecn red)
>  queue warezbandwidth 1% priority 0 qlimit 500 hfsc(upperlimit
> 90% ecn red)
> 
> queue pri already exists on interface pppoe0
> /etc/pf.conf.dual:71: errors in queue definition
> queue http already exists on interface pppoe0
> /etc/pf.conf.dual:72: errors in queue definition
> queue warez already exists on interface pppoe0

try:

altq on {$extif} bandwidth 600Kb hfsc queue { pri,http,warez }

queue extpribandwidth 10% priority 7qlimit 500 hfsc(realtime 5% ecn 
red)
queue exthttp   bandwidth 70% priority 5qlimit 500 hfsc(realtime 50% 
ecn red)
queue extwarez  bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit 90% ecn red)

altq on {$intif} bandwidth 10Kb hfsc queue { local,down }

queue local bandwidth 90% priority 7qlimit 500 hfsc(realtime 5% ecn 
red)
queue down  bandwidth 10% { pri,http,default,warez }
queue intpribandwidth 10% priority 7qlimit 500 hfsc(realtime 5% ecn 
red)
queue inthttp   bandwidth 70% priority 5qlimit 500 hfsc(realtime 50% 
ecn red)
queue default   bandwidth 10% priority 4qlimit 500 hfsc(realtime 5% ecn 
red)
queue intwarez  bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit 90% ecn red)

the only thing i noticed is you're defining pri, http, and warez twice and 
confusing pf.

-ryan

> 
> -- 
> G

OpenBSD and Compute Engine

[Matthew Dempsky]

Compute Engine now supports custom OSes [1], so I've been working on
getting OpenBSD working on it.  I thought I'd share a status update.

[1] 
http://googlecloudplatform.blogspot.com/2013/12/google-compute-engine-is-now-generally-available.html

** virtio-scsi

Compute Engine exposes disks as virtio-scsi devices, whereas OpenBSD
currently only supports virtio-blk disks.  I've got a mostly working
virtio-scsi driver (WIP: https://codereview.appspot.com/33540044), but
I still need to polish it a bit.

One complication is Compute Engine advertises excessively large virtio
queues: e.g., 32k CCBs for virtio-scsi and 16k deep tx and rx queues
for virtio-net.  This seems to push the limit of how many dmamaps we
can pre-allocate, so for now I'm still pre-allocating DMA memory for
all the virtio-scsi CCBs but lazily allocating dmamaps as needed.
This allows things to work, but it seems fragile.

** networking

The network environment is a bit goofy: the DHCP server will assign an
IP and netmask like 10.240.93.65/255.255.255.255, and then specify the
default gateway as 10.240.0.1.  On Linux, ISC's DHCP client special
cases the netmask==255.255.255.255 case by adding a direct route like
"route add 10.240.0.1 dev eth0" before running "route add default
10.240.0.1".

However, I can't seem to reproduce this behavior on OpenBSD.  I'd
expect something like "route add 10.240.0.1 -iface 10.240.93.65" to
work, but the network stack never ARP resolves 10.240.0.1 so packets
just drop instead.

My current workaround is to instead override the netmask as
255.255.0.0 so the network stack realizes it can directly contact
10.240.0.1, and then I add additional routes so that other 10.240/16
addresses (e.g., other VM instances) are still routed via 10.240.0.1.


So with those two hacky workarounds in place, I've successfully
started OpenBSD on Compute Engine (dmesg below) and been able to SSH
into it.


OpenBSD 5.4-current (GENERIC.MP) #43: Wed Nov 27 22:36:26 PST 2013
matt...@bento.dempsky.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4009746432 (3823MB)
avail mem = 3894853632 (3714MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd990 (12 entries)
bios0: vendor Google version "Google" date 01/01/2011
bios0: Google Google
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpiprt0 at acpi0: bus 0 (PCI0)
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU @ 2.60GHz, 2600.35 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,NXE,LONG,LAHF
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 1000MHz
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type ISA
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
pci0 at mainbus0 bus 0
pcib0 at pci0 dev 1 function 0 "Intel 82371AB PIIX4 ISA" rev 0x03
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: SMBus disabled
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio SCSI" rev 0x00:
Virtio SCSI host Device
vioscsi0 at virtio0: qsize 32768
scsibus0 at vioscsi0: 253 targets
sd0 at scsibus0 targ 1 lun 0:  SCSI4 0/direct fixed
sd0(vioscsi0:1:0): Check Condition (error 0x70) on opcode 0x1b
SENSE KEY: No Additional Sense
sd0: 10240MB, 512 bytes/sector, 20971520 sectors
sd0(vioscsi0:1:0): Check Condition (error 0x70) on opcode 0xa0
SENSE KEY: No Additional Sense
virtio0: apic 0 int 11
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Network" rev 0x00:
Virtio Network Device
vio0 at virtio1: address 42:01:0a:f0:5d:41
virtio1: apic 0 int 11
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nvram: invalid checksum
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
sd0(vioscsi0:1:0): Check Condition (error 0x70) on opcode 0x1b
SENSE KEY: No Additional Sense
root on sd0a (bd2b1320d2a54646.a) swap on sd0b dump on sd0b
sd0(vioscsi0:1:0): Check Condition (error 0x70) on opcode 0x1b
SENSE KEY: No Additional Sense
sd0(vioscsi0:1:0): Check Condition (error 0x70) on opcode 0x1b
SENSE KEY: No Additional Sense
sd0(vioscsi0:1:0): Check Condition (error 0x70) on opcode 0x1b
SENSE KEY: No Additional Sense
clock: unknown CMOS layout

Re: queueing/hfsc question

[Gabor Berczi]

On Dec 3, 2013, at 8:57 PM, josh Grosse wrote:

The new scheduler will be included in 5.5-release.  Users of - 
current now, or of 5.5 when it is released, who wish to continue  
using altq syntax and an altq scheduler may do so during a  
transition period, as described in the link above.


Okay. But what you just described ("Child queues are able to use the  
same name") doesn't work with ALTQ either. Are you certain it does  
with the new sched? (that would mean that it was impossible to do  
before)


altq on {$extif} bandwidth 600Kb hfsc queue { pri,http,warez }

queue pri   bandwidth 10% priority 7qlimit 500 hfsc 
(realtime 5% ecn red)
queue http  bandwidth 70% priority 5qlimit 500 hfsc 
(realtime 50% ecn red)
queue warez bandwidth 1% priority 0 qlimit 500 hfsc(upperlimit  
90% ecn red)


altq on {$intif} bandwidth 10Kb hfsc queue { local,down }

queue local bandwidth 90% priority 7qlimit 500 hfsc 
(realtime 5% ecn red)

queue down  bandwidth 10% { pri,http,default,warez }
 queue pri  bandwidth 10% priority 7qlimit 500 hfsc 
(realtime 5% ecn red)
 queue http bandwidth 70% priority 5qlimit 500 hfsc 
(realtime 50% ecn red)
 queue default  bandwidth 10% priority 4qlimit 500 hfsc 
(realtime 5% ecn red)
 queue warezbandwidth 1% priority 0 qlimit 500 hfsc(upperlimit  
90% ecn red)


queue pri already exists on interface pppoe0
/etc/pf.conf.dual:71: errors in queue definition
queue http already exists on interface pppoe0
/etc/pf.conf.dual:72: errors in queue definition
queue warez already exists on interface pppoe0

--
G

Re: queueing/hfsc question

[josh Grosse]

On 2013-12-03 14:40, Gabor Berczi wrote:


This page doesn't even mention neither HFSC nor any new scheduler...


The new queueing system is HFSC, with a simpler syntax.

It became available to -current users in October, per
http://www.openbsd.org/faq/current.html#20131012

The new scheduler will be included in 5.5-release.  Users of -current 
now, or of 5.5 when it is released, who wish to continue using altq 
syntax and an altq scheduler may do so during a transition period, as 
described in the link above.

Re: queueing/hfsc question

[Norman Golisz]

On Tue Dec  3 2013 20:40, Gabor Berczi wrote:
> On Dec 3, 2013, at 7:15 PM, Andy wrote:
> 
> >Including http://www.openbsd.org/faq/pf/queueing.html
> 
> This page doesn't even mention neither HFSC nor any new scheduler...

Please watch the video record of Henning's talk on the new queueing
subsystem. And yes, the new queueing subsystem is not yet included in
one of the releases. This will be the case with 5.5. It's in -current,
though.

Re: NPPPD and IPSec

[Or Elimelech]

Thanks, I fixed it using the same config I wrote
The problem is my npppd server is behind NAT and my windows needed registry
modification AssumeUDP
Thank you again

Sent from my iPhone

> On Dec 3, 2013, at 12:28 AM, Frans Haarman  wrote:
>
> I have used this with windows 7 and osx:
>
> ike passive esp transport \
> proto udp from $public_ip to any port 1701 \
> main auth "hmac-sha1" enc "3des" group modp1024 \
> quick auth "hmac-sha1" enc "aes" \
> psk ""
>
>
> 2013/12/2 Or Elimelech 
>> Hi,
>>
>> I'm having trouble configuring Windows clients with l2tp over ipsec,
>> This config works great on OSX/iOS/Android/Linux
>>
>> I do not know which type of auth/enc/group I should use for Windows
clients
>>
>> I currently use OpenBSD 5.4 with the following
>>
>> ike passive esp transport \
>> proto udp from 1.2.3.4 to any port 1701 \
>> main auth hmac-sha1 enc aes group modp1024 \
>> quick auth hmac-sha1 enc aes group modp1024 \
>> psk "secret"
>>
>> Thank you so much and keep up the good work I love the OpenBSD project
>>
>>
_
__
>> The sender of this email is not authorized to bind XWise Marketing or any
of its affiliate companies (hereby: the "Companies")
>> or to make any representations, contracts, or commitments on behalf of the
Companies.
>>
>> The information contained in this communication is intended solely for the
use of the individual or entity to whom it is addressed and others
>> authorized to receive it.
>> It may contain confidential or legally privileged information. If you are
not the intended recipient you are hereby notified that any disclosure,
>> copying, distribution or taking any action in reliance on the contents of
this information is strictly prohibited and may be unlawful.
>> If you have received this communication in error, please notify us
immediately by forwarding this email to le...@xwise.com and then delete
>> it from your system.
>>
>> The Companies are neither liable for the proper and complete transmission
of the information contained in this communication nor for any delay in its
receipt.
>

_
__
The sender of this email is not authorized
to bind XWise Marketing or any of its affiliate companies (hereby: the
"Companies")
or to make any representations, contracts, or commitments on
behalf of the Companies.

The information contained in this communication is
intended solely for the use of the individual or entity to whom it is
addressed and others 
authorized to receive it.   
It may contain confidential
or legally privileged information. If you are not the intended recipient you
are hereby notified that any disclosure, 
copying, distribution or taking any
action in reliance on the contents of this information is strictly prohibited
and may be unlawful. 
If you have received this communication in error, please
notify us immediately by forwarding this email to le...@xwise.com and then
delete 
it from your system.

The Companies are neither
  liable
 for the proper and complete transmission of the information contained in this
communication nor for any delay in its receipt.

Re: queueing/hfsc question

[Norman Golisz]

On Tue Dec  3 2013 20:32, Gabor Berczi wrote:
> On Dec 3, 2013, at 8:03 PM, josh Grosse wrote:
> 
> >On 2013-12-03 13:46, Gabor Berczi wrote:
> >>On Dec 3, 2013, at 7:15 PM, Andy wrote:
> >>> queue ack on $extinterface bandwidth 10% priority 6 hfsc  ( realtime
> >>>10% )
> >>> queue ack on $intinterface bandwidth 10% priority 6 hfsc  ( realtime
> >>>10% )
> >>One queue can't be on two interfaces.
> >>"queue XYZ already exists on interface pppoe0"
> >
> >Child queues are able to use the same name.  Here's an example, using the
> >new queuing syntax, where the "std" and "pig" queue names are assigned to
> >queues on different interfaces with different settings:
> 
> /etc/pf.conf.test:4: unknown unit M
> /etc/pf.conf.test:5: queue pig has no parent
> /etc/pf.conf.test:5: errors in queue definition
> /etc/pf.conf.test:6: queue std has no parent
> /etc/pf.conf.test:6: errors in queue definition
> /etc/pf.conf.test:8: unknown unit M
> /etc/pf.conf.test:9: queue local has no parent
> /etc/pf.conf.test:9: errors in queue definition
> /etc/pf.conf.test:10: queue down has no parent
> /etc/pf.conf.test:10: errors in queue definition
> /etc/pf.conf.test:11: queue pig has no parent
> /etc/pf.conf.test:11: errors in queue definition
> /etc/pf.conf.test:12: queue std has no parent
> /etc/pf.conf.test:12: errors in queue definition

You need to run -current for this.

Re: queueing/hfsc question

[Gabor Berczi]

On Dec 3, 2013, at 7:15 PM, Andy wrote:


Including http://www.openbsd.org/faq/pf/queueing.html


This page doesn't even mention neither HFSC nor any new scheduler...

--
G

Re: queueing/hfsc question

[Gabor Berczi]

On Dec 3, 2013, at 8:03 PM, josh Grosse wrote:


On 2013-12-03 13:46, Gabor Berczi wrote:

On Dec 3, 2013, at 7:15 PM, Andy wrote:
 queue ack on $extinterface bandwidth 10% priority 6 hfsc   
( realtime 10% )
 queue ack on $intinterface bandwidth 10% priority 6 hfsc   
( realtime 10% )

One queue can't be on two interfaces.
"queue XYZ already exists on interface pppoe0"


Child queues are able to use the same name.  Here's an example,  
using the new queuing syntax, where the "std" and "pig" queue names  
are assigned to queues on different interfaces with different  
settings:


/etc/pf.conf.test:4: unknown unit M
/etc/pf.conf.test:5: queue pig has no parent
/etc/pf.conf.test:5: errors in queue definition
/etc/pf.conf.test:6: queue std has no parent
/etc/pf.conf.test:6: errors in queue definition
/etc/pf.conf.test:8: unknown unit M
/etc/pf.conf.test:9: queue local has no parent
/etc/pf.conf.test:9: errors in queue definition
/etc/pf.conf.test:10: queue down has no parent
/etc/pf.conf.test:10: errors in queue definition
/etc/pf.conf.test:11: queue pig has no parent
/etc/pf.conf.test:11: errors in queue definition
/etc/pf.conf.test:12: queue std has no parent
/etc/pf.conf.test:12: errors in queue definition

Re: queueing/hfsc question

[josh Grosse]

On 2013-12-03 13:46, Gabor Berczi wrote:

On Dec 3, 2013, at 7:15 PM, Andy wrote:

 queue ack on $extinterface bandwidth 10% priority 6 hfsc  ( realtime 
10% )
 queue ack on $intinterface bandwidth 10% priority 6 hfsc  ( realtime 
10% )


One queue can't be on two interfaces.
"queue XYZ already exists on interface pppoe0"


Child queues are able to use the same name.  Here's an example, using 
the new queuing syntax, where the "std" and "pig" queue names are 
assigned to queues on different interfaces with different settings:


queue up on $external_nic bandwidth 5M burst 100M for 800ms
   queue pig parent up bandwidth 2500K
   queue std parent up bandwidth 2500K default

queue internal on $internal_nic bandwidth 100M
   queue local parent internal bandwidth 75M
   queue down parent internal bandwidth 25M burst 100M for 1600ms
  queue pig parent down bandwidth 12500K
  queue std parent down bandwidth 12500K default

Re: queueing/hfsc question

[Gabor Berczi]

On Dec 3, 2013, at 7:15 PM, Andy wrote:

 queue ack on $extinterface bandwidth 10% priority 6 hfsc  
( realtime 10% )
 queue ack on $intinterface bandwidth 10% priority 6 hfsc  
( realtime 10% )


One queue can't be on two interfaces.
"queue XYZ already exists on interface pppoe0"


Google for more...


I use duckduckgo, and don't condone using product names or companies  
as verbs, sorry :)


--
G

Re: [OpenBGPd <=> Cisco] error in OPEN message, unknown subcode 8

[Laurent CARON]

On 03/12/2013 19:20, Andy wrote:

Can you provide an example of what you did/fixed in bgpd.conf so when
others google for this error they will have a pointer of what to do :)


Here it is.

** Note for future readers, don't copy and paste this config snippet as 
it does *NOT* work as you would expect it. **


$PEERv6="dead:beef::1"
$MEv6="dead:beef::2"

neighbor $PEERv6 {
remote-as   3549
descr   ev6_gw-001_to_L3
local-address   $MEv6
announce IPv6   none
announce IPv4   unicast
}

Re: [OpenBGPd <=> Cisco] error in OPEN message, unknown subcode 8

[Andy]

On Tue 03 Dec 2013 18:15:23 GMT, Laurent CARON wrote:

On Mon, Nov 25, 2013 at 10:53:24PM +0100, Laurent CARON wrote:

I added a new transit to my network (Level3) and this issue is back
(runnning OpenBSD 5.4 but tried current also).

Nov 25 22:43:55 bgpgw-002 bgpd[24271]: neighbor 2001:450:2001:1001::45
(ev6_gw-002_to_L3): received notification: error in OPEN message,
unknown subcode 8

Do any of you experience the same behavior ?


Nevermind, it was just a config mistake on my side (announcing ipv4
unicast over the ipv6 session).

Cheers,

Laurent



Can you provide an example of what you did/fixed in bgpd.conf so when 
others google for this error they will have a pointer of what to do :)

Re: queueing/hfsc question

[Andy]

On Tue 03 Dec 2013 16:06:39 GMT, Gabor Berczi wrote:

On Dec 3, 2013, at 4:48 PM, indiunix wrote:


I would do it like this.
"
altq on $INTERFACE bandwidth $INMbp/s hfsc queue { http, torrent }
  queue http bandwidth 70% priority 8 hsfc ( realtime 60% )
  queue torrent bandwidth 50% priority 1 hsfc ( upperlimit 95% )

Just apply these rules to appropriate statements in your pf.conf



Yes, but how would you specify the pass/match rules? One TCP
connection can go into only one queue, therefore the other queue will
not take effect.



Google will find lots of examples if you look..
Including http://www.openbsd.org/faq/pf/queueing.html

To add a bit more detail to Indiunix;

altq on $extinterface bandwidth $UpMb hfsc queue { ack, http, torrent }
 queue ack on $extinterface bandwidth 10% priority 6 hfsc ( realtime 
10% )
 queue http on $extinterface bandwidth 80% priority 4 hsfc ( realtime 
60% )
 queue torrent on $extinterface bandwidth 10% priority 1 hsfc ( 
linkshare 10%,  upperlimit 95%, ecn, default )
altq on $intinterface bandwidth $DownMb hfsc queue { ack, http, torrent 
}
 queue ack on $intinterface bandwidth 10% priority 6 hfsc ( realtime 
10% )
 queue http on $intinterface bandwidth 80% priority 4 hsfc ( realtime 
60% )
 queue torrent on $intinterface bandwidth 10% priority 1 hsfc ( 
linkshare 10%,  upperlimit 95%, ecn, default )


pass quick proto { tcp } from { 10.0.0.0/8 } to { !10.0.0.0/8 } port { 
80, 443 } queue (http,ack) set prio (4,6)


pass quick proto { tcp } from {  } to {  
} port { ssh } queue (torrent,ack) set prio (2,5)


pass quick from { 10.0.0.0/8 } to { !10.0.0.0/8 } queue (torrent,ack)

BUT, this is using 'altq' which you shouldn't use anymore (will die in 
next release). Instead you should be using the new queue structure;

http://quigon.bsws.de/papers/2012/eurobsdcon/
http://www.youtube.com/watch?v=CMv90lDHhB8

PS; This altq example is of the top of my head so will have errors but 
should get you a bit further..

Google for more...

Andy

Re: [OpenBGPd <=> Cisco] error in OPEN message, unknown subcode 8

[Laurent CARON]

On Mon, Nov 25, 2013 at 10:53:24PM +0100, Laurent CARON wrote:
> I added a new transit to my network (Level3) and this issue is back
> (runnning OpenBSD 5.4 but tried current also).
> 
> Nov 25 22:43:55 bgpgw-002 bgpd[24271]: neighbor 2001:450:2001:1001::45
> (ev6_gw-002_to_L3): received notification: error in OPEN message,
> unknown subcode 8
> 
> Do any of you experience the same behavior ?

Nevermind, it was just a config mistake on my side (announcing ipv4
unicast over the ipv6 session).

Cheers,

Laurent

Re: OpenBSD and NetFlow

[Peter N. M. Hansteen]

Alexis VACHETTE  writes:

> - uname -a
>
> OpenBSD casa-vpn01.my.domain 4.8 GENERIC.MP#335 amd6

It's been a while since 4.8. It's not guaranteed that running outdated
software is your problem, but it's easier for everyone trying to help
if you're reasonably up to date (which these days means 5.3 or better).


> - dmesg output
>
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
> lm2 at wbsio0 port 0xa00/8: W83627HF
> mtrr: Pentium Pro MTRR support
> softraid0 at root
> root on wd0a swap on wd0b dump on wd0b
> WARNING: / was not properly unmounted

That is *not* complete dmesg output, but then again I suspect the
problem is not really hardware related.

>>> # ifconfig pflow0
>>> pflow0: flags=41 mtu 1492
>>>  priority: 0
>>>  pflow: sender: 192.168.1.251 receiver: 192.168.1.19:9995
>>>  groups: pflow

Looks reasonable, but what's the netmask? What does your routing table
look like?  And what is the configuration of any other network
interfaces?

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: OpenBSD and NetFlow

[Alexis VACHETTE]

Hi Josh,

First of all thanks for the welcome to the misc list !

I don't get a failure when I tried to destroy and re-create the pflow
interface indeed.

You will find the information requested below :

- uname -a

OpenBSD casa-vpn01.my.domain 4.8 GENERIC.MP#335 amd6

- dmesg output

wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
lm2 at wbsio0 port 0xa00/8: W83627HF
mtrr: Pentium Pro MTRR support
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
WARNING: / was not properly unmounted

I just posted one line because the packet filter configuration is very
permissive :

pass out log (all) all keep state (pflow)

The tcpdump output of pflog interface don't report any block lines with
the src and dst ip of the netflow configuration.

Using "nc" command always give me a correct answer :

# nc -zvu 192.168.1.19 9995
Connection to 192.168.1.19 9995 port [udp/*] succeeded!

If you need anything else don't hesitate.

Right now, I'm stuck because I don't see anything wrong.

*Alexis VACHETTE | Network and System Engineer
* Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
www.sisteer.com 
Le 03/12/2013 17:51, josh Grosse a écrit :
> On 2013-12-03 11:05, Alexis VACHETTE wrote:
>> Hi everyone,
>
> Hey there!  Welcome to misc@ (if you haven't posted to the list
> before).  I use NfSen to monitor a pair of small OpeNBSD firewalls,
> and pflow(4) between them.
>
>> set state-defaults pflow
>
> I use this, too.
>
>> # ifconfig pflow0
>> pflow0: flags=41 mtu 1492
>>  priority: 0
>>  pflow: sender: 192.168.1.251 receiver: 192.168.1.19:9995
>>  groups: pflow
>
> My output looks similar, except the protocol I use (5, the default),
> is shown on my ifconfig(8) output.  I am
> running -current, so I suspect you are running an earlier -release or
> -stable, or -release+errata.  You didn't post your dmesg, nor mention
> flavor of the OpenBSD.  There has been recent work in pflow(4), and
> there is a patch for 5.3-release and 5.4-release for a bug when a
> pflow interface is destroyed.  You didn't mention a failure on
> destroy/recreate so I assume you must have applied it.
>
>> I don't see anything going out of the em2 interface.
>
> I would suspect your PF configuration, since you only posted a single
> line from it.  I use a crossover cable between the firewalls, and one
> reports to the other for data collection, so my rule is simple:
>
> pass log quick on $private_nic proto udp from any to any port 9995
>
> I hope that helps.  If my Email was valueless, I'm sorry.
>
>   -Josh-



*
*
Ce message et toutes les pieces jointes sont confidentiels et etablis à
l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration.
SISTEER decline toute responsabilite au titre de ce message s'il a ete altere,
deforme ou falsifie.
Si vous n'etes pas le destinataire de ce message, merci de le detruire et
d'informer l'expediteur.
*
*
This message and any attachments are confidential and intended solely for the
addressee(s).
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration.
SISTEER shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
*
*

Re: BGP changes to support CARP better

[Andy]

Hi, I've got something really interesting to show, which shows this 
clearly and should help point to the root cause.


In short, it seems that the desired nexthop is not applied by the CARP 
master when it is in state 'nexthop 180.25.32.20 now valid: via 
180.25.32.20'. I.e. when it is 'via' even though it is a local IP..


From the perspective of the 'backup' the CARP IP is a directly 
connected IP which it can reach 'nexthop 180.25.32.20 now valid: 
directly connected'.


NB; I haven't had a chance to test IPv6 or iBGP but from this 
observation it looks like the same problem will be seen, unless there 
is a way of telling OpenBGPd to use nexthops which are 'via' something..



THE SETUP;

- Two OpenBSD boxes with CARP on their BGP and LAN Interfaces.
- One or two upstream Cisco routers on BGP interface via switch (both 
show same problem).

- PF disabled (just for this testing).
- 180.25.32.1 = iBGP Cisco Router
- 180.25.32.20 = CARP IP
- 180.25.32.21 = OBSD1
- 180.25.32.22 = OBSD2
- Neighbors are eBGP

OpenBSD Host 1 (master) /etc/bgpd.conf;
AS 66868
router-id 180.25.32.21
log updates
network 180.25.32.0/22
network 2a00:7ee0::/32
neighbor 180.25.32.1 {
   remote-as 66868
   announce self
   local-address 180.25.32.21
   tcp md5sig password secret
   descr "THN"
}
match to 180.25.32.1 set nexthop 180.25.32.20
allow from any inet prefixlen 8 - 26
allow from any inet6 prefixlen 16 - 48
allow to any


OpenBSD Host 1 (backup) /etc/bgpd.conf;
AS 66868
router-id 180.25.32.22
log updates
network 180.25.32.0/22
network 2a00:7ee0::/32
neighbor 180.25.32.1 {
   remote-as 66868
   announce self
   local-address 180.25.32.22
   tcp md5sig password secret
   descr "THN"
}
match to 180.25.32.1 set nexthop 180.25.32.20
allow from any inet prefixlen 8 - 26
allow from any inet6 prefixlen 16 - 48
allow to any


Cisco Host;
router bgp 12345
bgp router-id 180.25.32.1
bgp log-neighbor-changes
neighbor 180.25.32.21 remote-as 66868
neighbor 180.25.32.21 password secret
neighbor 180.25.32.22 remote-as 66868
neighbor 180.25.32.22 password secret
!
address-family ipv4
 neighbor 180.25.32.21 activate
 neighbor 180.25.32.22 activate
exit-address-family
!
!



TEST 1 - Start BGP on master then backup;

BGP Process is already running on the Cisco..
THN(config)#do show ip bgp
THN(config)#


OpenBSD Host 1 (MASTER) bgpd -dv;
[LIVE]root@OpenBSD1:~# bgpd -dv
startup
rereading config
route decision engine ready
session engine ready
new ktable rdomain_0 for rtableid 0
nexthop 180.25.32.20 now valid: via 180.25.32.20
listening on 0.0.0.0
listening on ::
SE reconfigured
neighbor 180.25.32.1 (THN): state change None -> Idle, reason: None
neighbor 180.25.32.1 (THN): state change Idle -> Connect, reason: Start
RDE reconfigured
neighbor 180.25.32.1 (THN): state change Connect -> OpenSent, reason: 
Connection opened
neighbor 180.25.32.1 (THN): state change OpenSent -> OpenConfirm, 
reason: OPEN message received
neighbor 180.25.32.1 (THN): state change OpenConfirm -> Established, 
reason: KEEPALIVE message received



THN(config)#do show ip bgp
BGP table version is 8, local router ID is 180.25.32.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - 
internal,
 r RIB-failure, S Stale, m multipath, b backup-path, f 
RT-Filter,

 x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network  Next HopMetric LocPrf Weight Path
*>  180.25.32.0/22   180.25.32.21   0 66868 i


NOTICE THIS IS THE WRONG NEXTHOP! :(


OpenBSD Host 2 (BACKUP) bgpd -dv;
[LIVE]root@OpenBSD2:~# bgpd -dv
startup
rereading config
route decision engine ready
session engine ready
new ktable rdomain_0 for rtableid 0
nexthop 180.25.32.20 now valid: directly connected
listening on 0.0.0.0
listening on ::
SE reconfigured
neighbor 180.25.32.1 (THN): state change None -> Idle, reason: None
neighbor 180.25.32.1 (THN): state change Idle -> Connect, reason: Start
RDE reconfigured
neighbor 180.25.32.1 (THN): state change Connect -> OpenSent, reason: 
Connection opened
neighbor 180.25.32.1 (THN): state change OpenSent -> OpenConfirm, 
reason: OPEN message received
neighbor 180.25.32.1 (THN): state change OpenConfirm -> Established, 
reason: KEEPALIVE message received
Rib Loc-RIB: neighbor 180.25.32.1 (THN) AS12345: update 180.25.32.0/22 
via 180.25.32.1

nexthop 180.25.32.1 now valid: directly connected

(^ Why do these last two lines not show on the master?)


THN(config)#do show ip bgp
BGP table version is 8, local router ID is 180.25.32.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - 
internal,
 r RIB-failure, S Stale, m multipath, b backup-path, f 
RT-Filter,

 x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network  Next Hop  

Re: queueing/hfsc question

[Gabor Berczi]

On Dec 3, 2013, at 4:48 PM, indiunix wrote:


I would do it like this.
"
altq on $INTERFACE bandwidth $INMbp/s hfsc queue { http, torrent }
  queue http bandwidth 70% priority 8 hsfc ( realtime 60% )
  queue torrent bandwidth 50% priority 1 hsfc ( upperlimit 95% )

Just apply these rules to appropriate statements in your pf.conf



Yes, but how would you specify the pass/match rules? One TCP  
connection can go into only one queue, therefore the other queue will  
not take effect.


--
G

OpenBSD and NetFlow

[Alexis VACHETTE]

Hi everyone,

I would like to share an issue with one of my OpenBSD Firewall which is
present in my company.

Everything was working fine until a server crash this last week-end.

We have setup the netflow protocol with the pseudo device pflow0.

You can find the relevant files for the netflow configuration below.

/etc/pf.conf :

set state-defaults pflow

/etc/hostname.pflow :

flowsrc 192.168.1.251 flowdst 192.168.1.19:9995

The output of ifconfig for the pflow0 interface :

# ifconfig pflow0
pflow0: flags=41 mtu 1492
 priority: 0
 pflow: sender: 192.168.1.251 receiver: 192.168.1.19:9995
 groups: pflow

Three tcpdump sample :

- From the netflow interface :

# tcpdump -nettti pflow0
tcpdump: listening on pflow0, link-type RAW
Dec 03 15:53:31.817647 ip: 192.168.1.251.49904 > 192.168.1.19.9995: udp
1464 (DF) [tos 0x10]
Dec 03 15:53:40.247888 ip: 192.168.1.251.49904 > 192.168.1.19.9995: udp
1464 (DF) [tos 0x10]
Dec 03 15:53:50.623061 ip: 192.168.1.251.49904 > 192.168.1.19.9995: udp
1464 (DF) [tos 0x10]
Dec 03 15:53:57.428342 ip: 192.168.1.251.49904 > 192.168.1.19.9995: udp
1464 (DF) [tos 0x10]

- From the pflog inteface :

# tcpdump -nettti pflog0 host 192.168.1.19 and port 9995
tcpdump: listening on pflog0, link-type PFLOG
Dec 03 15:55:37.643985 rule def/(match) pass out on em2:
192.168.1.251.49904 > 192.168.1.19.9995: udp 1464 (DF) [tos 0x10]
Dec 03 15:55:42.644029 rule def/(match) pass out on em2:
192.168.1.251.49904 > 192.168.1.19.9995: udp 1464 (DF) [tos 0x10]
Dec 03 15:55:48.644243 rule def/(match) pass out on em2:
192.168.1.251.49904 > 192.168.1.19.9995: udp 1464 (DF) [tos 0x10]

- From the sender interface :

# tcpdump -nettti em2 host 192.168.1.19 and port 9995
tcpdump: listening on em2, link-type EN10MB

I don't see anything going out of the em2 interface.

On a lab environment with GNS3, I clearly see the UDP packets going out
of the sender interface.

Is there a best way to troubleshoot this issue ?

I don't know how to fix this behaviour, I tried to destroy and recreate
the pflow0 interface but still no luck.

--
*Alexis VACHETTE | Network and System Engineer
* Sisteer France: 43 rue Pierre Valette, 92240 Malakoff -- France
Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
www.sisteer.com 


*
*
Ce message et toutes les pieces jointes sont confidentiels et etablis à
l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration.
SISTEER decline toute responsabilite au titre de ce message s'il a ete altere,
deforme ou falsifie.
Si vous n'etes pas le destinataire de ce message, merci de le detruire et
d'informer l'expediteur.
*
*
This message and any attachments are confidential and intended solely for the
addressee(s).
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration.
SISTEER shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
*
*

Re: queueing/hfsc question

[indiunix]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/03, Gabor Berczi wrote:
> Greets dudez,
> 
> Help.
> 
> How can one properly share (on the firewall, not at application
> level) the _downstream_ bandwidth between for example a HTTP
> download (should get the most bandwidth) and a torrent queue (should
> be reduced to the bare minimum except when no HTTP transfer is in
> progress)? And at the same time, there must also be an _upstream_
> queue too (the usual stuff).
> 
I would do it like this.
"
altq on $INTERFACE bandwidth $INMbp/s hfsc queue { http, torrent }
  queue http bandwidth 70% priority 8 hsfc ( realtime 60% )
  queue torrent bandwidth 50% priority 1 hsfc ( upperlimit 95% )

Just apply these rules to appropriate statements in your pf.conf
"
> I can manage the first with a fuckin' ugly hack, coincidentally
> reducing the upstream bandwidth to less than a tenth of what it
> should be (I don't want to do this). Can do the second, neat and
> clean obviously. But can't do both...
> 
> -- 
> G
iQEcBAEBAgAGBQJSnf1eAAoJEBdTBdbEk9xoTq8H/1Ai+vGJZIl0plzKU7ns4uWE
YFw7WJ2WJ3Hp5sR2uSVeijv9dT6Zxjoe5f6QdBGXIAIDVypWsIL210LboKbtjCyC
aAk+yBbviKHEp/hOBYnFf2KfzoyWZtD6g1f7ccSKT3h1awND26H2JvDtknU/J/Ig
LpjVIOme3hH76mODJdUO1VKhFEUTPZXGWM3BkCgh1t1gYeg4mWVEUW+cXSi+dHHf
bF/xKM145Rosawi7hQJmqC89JDDKITU2NgfYglPyEyYf6GRcrJ59ZowsB0Yyfj+2
S7+lMmdjyaR4PJw2GbnlrCHt/DfGXeTY+1gytQ1uE5VWbjcZA97bmngrldRtUzQ=
=Ti/N
-END PGP SIGNATURE-

queueing/hfsc question

[Gabor Berczi]

Greets dudez,

Help.

How can one properly share (on the firewall, not at application  
level) the _downstream_ bandwidth between for example a HTTP download  
(should get the most bandwidth) and a torrent queue (should be  
reduced to the bare minimum except when no HTTP transfer is in  
progress)? And at the same time, there must also be an _upstream_  
queue too (the usual stuff).


I can manage the first with a fuckin' ugly hack, coincidentally  
reducing the upstream bandwidth to less than a tenth of what it  
should be (I don't want to do this). Can do the second, neat and  
clean obviously. But can't do both...


--
G

Re: creating a VPN tunnel with an iPhone client

[Anders Berggren]

> I'm looking for a way to connect an iPhone to the local subnet for VOIP usage 
> through VPN.
> Has anyone succeeded in creating a VPN tunnel from an iPhone to OpenBSD?

Yes. npppd's L2TP http://www.openbsd.org/cgi-bin/man.cgi?query=npppd, or 
OpenVPN is what I have used.

creating a VPN tunnel with an iPhone client

[Stanley van Dijk]

Hi,
I'm looking for a way to connect an iPhone to the local subnet for VOIP 
usage through VPN.

Has anyone succeeded in creating a VPN tunnel from an iPhone to OpenBSD?

Re: alix2d3 "entry point at 0x200120" after PXE installation

[Aurelien Martin]

Hi all,
I would like to thanks all to your fast feedback and support

I'm moving my flat so I cannot test for these days. On Thursday I'll
receive a new USB -> DB9 Null modem cable and a flash card reader.
So the next days I'll update this feed with my observation, tests and steps
to achieve it through PXE. As mentioned if it doesn't work I'll put
directly OBSD 5.4 on the flash.

Have a good day
Aurelien



2013/11/30 Eike Lantzsch 

> On Friday 29 November 2013 17:12:45 Erling Westenvik wrote:
> > On Fri, Nov 29, 2013 at 01:10:24PM +0100, Aurelien Martin wrote:
> > > stty com0 57600
> >
> > I too would try with a lower baudrate.
> >
> > >From the FAQ (http://www.openbsd.org/faq/faq7.html#SerCon)
> >
> > "Resist the urge to crank the baud rate up to the maximum your
> > hardware can support, as you are more likely to create problems
> > than benefit. Most systems have a "default" speed (supported by
> > default by the boot ROM and/or the boot loader, often 9600), use
> > this unless you have real reason to use something different."
>
> Huh? My ALIX 2D13 works fine with 115200 - no quirks.
> 38400 is default but I don't think that a wrong baudrate would output
> anything at all except house numbers and grzmrf, especially not at
> high baudrates.
>
> Did you, Aurelien use a quality CF-card? That is very important.
> Is the power supply sound?
> Even the 2D3 may be defective (rarely) and e.g. PC-Engines swaps them
> on warranty free.
>
> Sorry I didn't upgrade to 5.4 yet.
> I installed OpenBSD 5.3 onto the CF-card while it was connected to a
> MACbook Air via a USB-adaptor and used the network install. Then I
> inserted the CF-card into the ALIX 2D13 and booted. No problems.
> See OBSD FAQ 14.17.3.
>
> Maybe Aurelien, you want to try this before you send the board back to
> the supplier.
>
> Good luck
> Eike
> --
> Eike Lantzsch ZP6CGE
> Casilla de Correo 1519
> 1209 Asuncion / Paraguay

Re: Lenovo L420 ACPI, kernel panic

[Cyril Andreichuk]

> From: cyril.andreic...@hotmail.com
> To: misc@openbsd.org
> Subject: Lenovo L420 ACPI, kernel panic
> Date: Tue, 3 Dec 2013 10:09:56 +0300
>
> hi
> there is always a kernel panic when booting with enabled acpi on my Lenovo
> ThinkPad L420 (7854RP1). here are pics of it and trace
> http://imgur.com/KPW4972http://imgur.com/gUAV1Gy
> any suggestions?
> thanks
>
correct pics links:

http://imgur.com/KPW4972

--

http://imgur.com/gUAV1Gy

Re: Lenovo L420 ACPI, kernel panic

[Cyril Andreichuk]

> From: cyril.andreic...@hotmail.com
> To: misc@openbsd.org
> Subject: Lenovo L420 ACPI, kernel panic
> Date: Tue, 3 Dec 2013 10:09:56 +0300
>
> hi
> there is always a kernel panic when booting with enabled acpi on my Lenovo
> ThinkPad L420 (7854RP1). here are pics of it and trace
> http://imgur.com/KPW4972http://imgur.com/gUAV1Gy
> any suggestions?
> thanks
>
forgot to add:release OpenBSD 5.4 / amd64
on i386 i have the same problem