Re: ucom(4)

2010-06-14 Thread Gregory Edigarov
On Sun, 13 Jun 2010 17:39:00 +0300
Gregory Edigarov  wrote:

> Hello,
> 
> Today I've bought myself Viewcon USB-to-RS232c adapter cable.
> Under OpenBSD it is identifies as:
> 
> uplcom0 at uhub1 port 6 "Prolific Technology Inc. USB-Serial
> Controller" rev 1.10/3.00 addr 3
> 
> however, when I try to connect to any device via the cable, and then
> access to it using cu -l /dev/cuaU0, it behaves strangely:
> I could see the device receiving  what I type, but I cannot see any
> response from the device.
> 
> If somebody had any success with this device please let me know.  

Forget about it, it's the cable itself. I've just exchanged it  and
the problem disapear. Sorry for the noise. 

Thank you. 

-- 
With best regards,
Gregory Edigarov



Re: X exiting after update (inteldrm error)

2010-06-14 Thread Anthony Bentley
> I am having the same problem on a Lenovo R60e running snapshots from
> May12th and May 22nd.
>
> Looks like it may be "fixed":
> http://marc.info/?l=openbsd-cvs&m=127457255931742&w=2 , will try the
> next snapshot.

I get the error on a new snapshot. (Last used 4.6, no idea if this occurred
in snapshots in between.)

Jun 13 13:20:48 pinetree /bsd: inteldrm0: gpu hung!
Jun 13 13:20:48 pinetree /bsd: no reset function for chipset.

Xorg.0.log, dmesg:

(--) checkDevMem: using aperture driver /dev/xf86
(--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32
)

X.Org X Server 1.6.5
Release Date: 2009-10-11
X Protocol Version 11, Revision 0
Build Operating System: OpenBSD 4.7 i386
Current Operating System: OpenBSD pinetree.gateway.2wire.net 4.7 GENERIC.MP#36
i386
Build Date: 02 June 2010  01:40:17AM

Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jun 13 13:20:06 2010
(II) Loader magic: 0x7ec0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 5.0
X.Org XInput driver : 4.0
X.Org Server Extension : 2.0
(II) Loader running on openbsd
(--) PCI:*(0:0:2:0) 8086:2572:1028:0151 Intel 82865G Video rev 2, Mem @ 0xe8000
000/134217728, 0xfeb8/524288, I/O @ 0xed98/8
(==) Using default built-in configuration (21 lines)
(==) --- Start of built-in configuration ---
Section "Device"
Identifier  "Builtin Default intel Device 0"
Driver  "intel"
EndSection
Section "Screen"
Identifier  "Builtin Default intel Screen 0"
Device  "Builtin Default intel Device 0"
EndSection
Section "Device"
Identifier  "Builtin Default vesa Device 0"
Driver  "vesa"
EndSection
Section "Screen"
Identifier  "Builtin Default vesa Screen 0"
Device  "Builtin Default vesa Device 0"
EndSection
Section "ServerLayout"
Identifier  "Builtin Default Layout"
Screen  "Builtin Default intel Screen 0"
Screen  "Builtin Default vesa Screen 0"
EndSection
(==) --- End of built-in configuration ---
(==) ServerLayout "Builtin Default Layout"
(**) |-->Screen "Builtin Default intel Screen 0" (0)
(**) |   |-->Monitor ""
(**) |   |-->Device "Builtin Default intel Device 0"
(==) No monitor specified for screen "Builtin Default intel Screen 0".
Using a default monitor configuration.
(**) |-->Screen "Builtin Default vesa Screen 0" (1)
(**) |   |-->Monitor ""
(**) |   |-->Device "Builtin Default vesa Device 0"
(==) No monitor specified for screen "Builtin Default vesa Screen 0".
Using a default monitor configuration.
(==) Not automatically adding devices
(==) Not automatically enabling devices
(==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
(==) ModulePath set to "/usr/X11R6/lib/modules"
(==) |-->Input Device ""
(==) |-->Input Device ""
(==) The core pointer device wasn't specified explicitly in the layout.
Using the default mouse configuration.
(==) The core keyboard device wasn't specified explicitly in the layout.
Using the default keyboard configuration.
(II) System resource ranges:
[0] -1  0   0x000f - 0x000f (0x1) MX[B]
[1] -1  0   0x000c - 0x000e (0x3) MX[B]
[2] -1  0   0x - 0x0009 (0xa) MX[B]
[3] -1  0   0x - 0x (0x1) IX[B]
[4] -1  0   0x - 0x00ff (0x100) IX[B]
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
compiled for 1.6.5, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
compiled for 1.6.5, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(II) Loading /

Re: audio recording levels

2010-06-14 Thread Paul M

On 14/06/2010, at 12:49 PM, Jacob Meuser wrote:


On Mon, Jun 14, 2010 at 11:37:52AM +1200, Paul M wrote:

I have a large amount of analog audio I need to digitize and
naturaly want to ensure best transfer quality. So I need to set
the analog level at the input to the adc as high as possible
without clipping. Ideally, I'll get the workstation hardware
set to certin defaults, then adjust the incomming audio as
required.
This leads to a couple of questions:
Are there (typicaly) any variable gain stages in the analog input
path in the computer.


varies depending on hardware, but often there is a gain
at the input and a gain at the ADC.


Looking at the mixerctl output again, this does appear to be the
case.



Mixerctl -av (full output below) shows a
node called 'record.adc'. It seems reasonable that this might
opperate on the analog input to the adc


generically speaking, yes.


However there is also
'record.volume', though I would assume this operates on the mixed
digital signals at the end of the chain.


no.  record.volume is essenially an alias.  on your hardware with the
configuration you've posted, it's a shortcut for setting both
record.adc and record.adc2.  this is explained in azalia(4) (though
maybe that info didn't make it into 4.6, the info in -current azalia(4)
is mostly relevant even for 4.6).


Also: a lot of the gain stages have defaults of 120.120. Would
it be reasonable to assume that this is the 0 gain setting?


no.  unfortunately, the mixer interface, like a lot of audio(4)
related stuff, is designed for "consumer usage".  so, we just have
a range that is essentially 0-100% - it has no relevance to anything
except the knob.  truly the  worst kind of knobs are those that
have no outside meaning, but apparently people like this.  *shrug*

http://marc.info/?l=openbsd-tech&m=123101323408867&w=2


Any thoughts appreciated.


if you really want to know how to do this right, your best bet is to
find the datasheet for your codec.

now, your codec is a Realtek, which is common for azalia(4), and
I happen to know them pretty well ...


inputs.line=85,85

this is a 0 (0), 10 (85), 20 (170), 30 (255) dB gain on the line-in
jack.  values in () are the corresponding mixerctl values.


record.adc=248,248

this is the ADC input gain.  0 dB should be around '88'.
0..255 here represents the hardware's -16.5 to 30 dB
in 1.5 dB steps.

these are the only gains on the recording path of your device.



Thanks Jacob, this is gold.
I'll try and find that datasheet, but what you've given me here is
probably enough for me to work out what I need.


Thanks again, and thanks to all who worked on giving the audio
subsystem the openBSD love.

paulm



Re: audio recording levels

2010-06-14 Thread Paul M

On 14/06/2010, at 6:54 PM, Jan Stary wrote:


On Jun 14 11:37:52, Paul M wrote:

I have a large amount of analog audio I need to digitize and
naturaly want to ensure best transfer quality. So I need to set
the analog level at the input to the adc as high as possible
without clipping.


It is good practice to leave a little headroom (say, 6dB)
for further processing. You might want to do some noise
reduction, compressing, whatever, and the effects will clip
if the signal already is saturated.


I'll leave enough headroom to allow for the highest peaks, but
I'm not planning on doing any additional processing during the
initial conversion. I can attenuate the signal later if I add
any post processing.



Also, "the input to the adc" is not all there is to it;
there are other mixer settings that affect the signal
that will eventually end in your file.wav


Ideally, I'll get the workstation hardware
set to certin defaults, then adjust the incomming audio as
required.


There are no "defaults". Your analog inputs can
(and most probably will) vary greatly.


I dont really want to futz with the audio hardware once it's set
up, so these 'defaults' would be such that a certain input signal
level will produce a clean digital file with no clipping and
good dynamic range. I'll then use a preamp with decent VU meters
to ensure the signal sent to the computer is optimal.



This leads to a couple of questions:
Are there (typicaly) any variable gain stages in the analog input
path in the computer.


Yes. 'mixerctl -a' will shouw you how the azalia 'widgets' are
interconnected on your codec.


Mixerctl -av (full output below) shows a
node called 'record.adc'. It seems reasonable that this might
opperate on the analog input to the adc. However there is also
'record.volume', though I would assume this operates on the mixed
digital signals at the end of the chain.


record.volume
Amplifier gain control for widgets listed in record.volume.slaves.


Thanks, I wondered about the slaves.



Also: a lot of the gain stages have defaults of 120.120. Would
it be reasonable to assume that this is the 0 gain setting?


What's a "0 gain setting"?


Unity gain, or 0dB gain. Signal level out = signal level in (for
that stage).



I believe Jacob Meuser has work going on to make the numbers
on the azalia knobs correspond to actual decibels,
but I don't know if it's current yet.


bios0: ASUSTeK Computer INC. P5QPL-AM
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01:
apic 2 int 21 (irq 5)
azalia0: codecs: Realtek/0x0887
audio0 at azalia0


It would be my guess that this is the audio chip that's integrated
with the Asus P5QPL-AM motherboard.  If you are really after "best
transfer quality", you might want to use something else in the
first place.


Good point, thanks for the reality check.
Most of what I have to do is not the best quality anyway, but that
doesn't mean I'm happy to introduce unnecessary generation loss by
being sloppy. There is some though that is very good, so that may well
need something better.


paulm



Taller Ley de Obras Públicas y Servicios Relacionados - 30 de Junio México DF

2010-06-14 Thread Denisse Quiñones
[IMAGE]

Ley de Obras PC:blicas y Servicios Relacionados

[IMAGE] 30 de Junio de 2010

[IMAGE] NH Liverpool - MC)xico DF

[IMAGE] 9:00 am 2:00 pm y 3:00 - 7:00 pm

El presente programa esta basado en el Decreto modificatorio (DOF
28/05/2009), por el que se reforman, adicionan y derogan diversas
disposiciones de la Ley de Obras PC:blicas y Servicios Relacionados con
las Mismas, y que entro en vigor el 27 de Junio del 2009, por lo que
proporciona las bases para el manejo practico, aplicaciC3n eficiente e
interpretaciC3n correcta de la C:ltima versiC3n de dicha Ley asC como de
las directrices complementarias a la misma.

OBJETIVOS:
El participante adquirirC! y actualizara los conocimientos necesarios
para la interpretaciC3n, manejo y aplicaciC3n de la bLey de Obras
PC:blicas y Servicios relacionados con la Mismab, segC:n las C:ltimas
modificaciones publicadas en 28 de Mayo del 2009, ( DOF 28-05-2009), que
incluyen la nueva estructura de TCtulos y CapCtulos, la definiciC3n de
ofertas subsecuentes de descuentos, las licitaciones a travC)s de medios
electrC3nicos generados mediante tecnologCas que resguarden su
confidencialidad, los beneficios y tratamiento a las PyMES, y el esquema
de integraciC3n de propuestas, contrataciC3n, y soluciC3n de
inconformidades. AdemC!s de las directrices establecidas para dicha Ley
por la Unidad de Normatividad de Contrataciones PC:blicas.

[IMAGE]

Lic. Fernanda Rivas
Sales Development Representative
Line 1: +52 (33) 1201-6898
Line 2: +52 (33) 1562-1784
Line 3: +52 (33) 3110-6502

[IMAGE]

PromociC3n Especial a Grupos

Copyright (C) 2010, Congress & Marketing Online S.C. Derechos reservados.
Congress & Marketing, El logo de Congress & Marketing, y Congress &
Marketing Online S.C. son marcas registradas y/o sus filiales en Estados
Unidos, Canada, Colombia, Brasil y Uruguay. ADVERTENCIA Congress &
Marketing no cuenta con alianzas estrategicas de ningun tipo dentro de la
republica mexicana. NO SE DEJE ENGACAR - DIGA NO A LA PIRATERIA. Todos
los logotipos, marcas comerciales e imC!genes son propiedad de sus
respectivas corporaciones y se utilizan con fines informativos solamente.

Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Congress
& Marketing o bien un usuario le refirio para recibir este newsletter.
Como usuario de Congress & Marketing, en este acto autoriza de manera
expresa que Congress & Marketing le puede contactar vCa correo
electrC3nico u otros medios. Si usted ha recibido este mensaje por error,
haga caso omiso de el y reporte su cuenta respondiendo este correo con el
subject BAJA CM000SCRMZ. Unsubscribe to this mailing list, reply a blank
message withe the subject UNSUBSCRIBE CM000SCRMZ Tenga en cuenta que la
gestiC3n de nuestras bases de datos es de suma importancia y no es
intenciC3n de la empresa la inconformidad del receptor.



Re: I-O Data WN-B11/CFZ support

2010-06-14 Thread Stuart Henderson
On 2010-06-13, ra1978  wrote:
> Hello,
>
> Could you please add support CF WiFi card "I-O Data WN-B11/CFZ" ?
>
> Lack of support for this card - it's the only reason because of which I can
> not use OpenBSD on my Sharp Zaurus C3200.
> I think it is needed not only to me, many people have the same problem.
>
> Thanks a lot
>
> Best regards,
> Alex
>
>

Looking at http://www.oesf.org/forum/lofiversion/index.php/t20116.html
it seems this card probably has no firmware onboard, in which case it's
very likely it has no EEPROM, which would mean you need some way to
load firmware into RAM after booting/resuming.

OpenBSD doesn't currently support loading firmware for PRISM devices.
And I think for most people it's of limited use to do this - most PRISM
cards do have firmware. So it would really need somebody who has the
hardware, who wants to make it work badly enough that they write support
for it, rather than just sell the card and buy a different one (e.g.
Senao, Canon, Ambicom, Pretec, etc).



hostname.if on 4.7 ignoring "-inet6"

2010-06-14 Thread rhsv6
Hello list,

I'm looking to explicitly disable IPv6 on interfaces where it is 
not used.  This includes link local addresses.

However, this :

# cat /etc/hostname.em0 
 
description "Some Port"
media 1000baseT
inet 172.16.176.166 255.255.255.252 NONE
-inet6
up


Does not have the desired effect :

em0: flags=8843 mtu 1500
lladdr 00:aa:bb:cc:dd:ee
description: Some Port
priority: 0
media: Ethernet 1000baseT (1000baseT full-
duplex,rxpause,txpause)
status: active
inet 172.16.176.166 netmask 0xfffc broadcast 
172.16.176.167
inet6 fe80:::::6273%em0 prefixlen 64 scopeid 0x1



pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread william dunand
Dear list,

I just noticed something strange with pf (4.7) and I wondered if
someone could help me to understand it.

Let's consider the following simple rule-set:


set skip on lo0
pass all
block out log on bge0 inet proto tcp from any to x.x.x.x port 80
match out on bge0 inet proto tcp from any to x.x.x.x port 80
<\pf.conf>

Then if I just try a simple hping on x.x.x.x on port 80, I expect to
see the packet blocked, and logged on pflog0, but I don't see it.
If I just add a "log" to the "match" rule, then my hping packet will
be logged twice on pflog0 (for the block and the match).
I observe analog behavior if I replace the block rule by a similar pass rule.

So it seems impossible to log specific traffic if this traffic is
matched somewhere by a simple "match" rule, one would need to add the
"log" directive to the latter, which might of course not be desirable.

Is this the expected behavior, or is there something I am overlooking?

Any help would be greatly appreciated.

Regards,
William



Re: hostname.if on 4.7 ignoring "-inet6"

2010-06-14 Thread Stuart Henderson
On 2010-06-14, rh...@hushmail.com  wrote:
> Hello list,
>
> I'm looking to explicitly disable IPv6 on interfaces where it is 
> not used.  This includes link local addresses.
>
> However, this :
>
> # cat /etc/hostname.em0 
>  
> description "Some Port"
> media 1000baseT
> inet 172.16.176.166 255.255.255.252 NONE
> -inet6
> up

Please try this diff.

Index: netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.129
diff -u -p -r1.129 netstart
--- netstart12 Jan 2010 07:43:41 -  1.129
+++ netstart14 Jun 2010 11:27:47 -
@@ -111,7 +111,7 @@ ifstart() {
dest)
cmd="$cmd $dtaddr"
;;
-   [a-z!]*)
+   [a-z!-]*)
cmd2="$dt $dtaddr"
;;
esac



Re: pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread Stuart Henderson
While this is wierd behaviour, I don't see what purpose this
match rule can serve, so it's not entirely surprising this hasn't
been noticed before... What are you trying to do with this?


On 2010-06-14, william dunand  wrote:
> Dear list,
>
> I just noticed something strange with pf (4.7) and I wondered if
> someone could help me to understand it.
>
> Let's consider the following simple rule-set:
>
>
> set skip on lo0
> pass all
> block out log on bge0 inet proto tcp from any to x.x.x.x port 80
> match out on bge0 inet proto tcp from any to x.x.x.x port 80
><\pf.conf>
>
> Then if I just try a simple hping on x.x.x.x on port 80, I expect to
> see the packet blocked, and logged on pflog0, but I don't see it.
> If I just add a "log" to the "match" rule, then my hping packet will
> be logged twice on pflog0 (for the block and the match).
> I observe analog behavior if I replace the block rule by a similar pass rule.
>
> So it seems impossible to log specific traffic if this traffic is
> matched somewhere by a simple "match" rule, one would need to add the
> "log" directive to the latter, which might of course not be desirable.
>
> Is this the expected behavior, or is there something I am overlooking?
>
> Any help would be greatly appreciated.
>
> Regards,
> William



Re: hostname.if on 4.7 ignoring "-inet6"

2010-06-14 Thread Reyk Floeter
On Mon, Jun 14, 2010 at 12:28:46PM +0100, Stuart Henderson wrote:
> > # cat /etc/hostname.em0 
> >  
> > description "Some Port"
> > media 1000baseT
> > inet 172.16.176.166 255.255.255.252 NONE
> > -inet6
> > up

you can also pass extra options after "up"

up -inet6

> 
> Please try this diff.
> 

or this...

reyk



Re: hostname.if on 4.7 ignoring "-inet6"

2010-06-14 Thread rhsv6
>you can also pass extra options after "up"
>
>up -inet6
>
>> 


Interesting.  Well, I've already had one reply telling me to RTFM, 
so perhaps I missed that little gem amongst all the text to be 
enjoyed !


>> Please try this diff.
>> 
>
>or this...
>

ack.  done.  worked. thanks again.



Re: hostname.if on 4.7 ignoring "-inet6"

2010-06-14 Thread rhsv6
>Please try this diff.
>
>Index: netstart
>===
>
>RCS file: /cvs/src/etc/netstart,v
>retrieving revision 1.129
>diff -u -p -r1.129 netstart
>--- netstart   12 Jan 2010 07:43:41 -  1.129
>+++ netstart   14 Jun 2010 11:27:47 -
>@@ -111,7 +111,7 @@ ifstart() {
>   dest)
>   cmd="$cmd $dtaddr"
>   ;;
>-  [a-z!]*)
>+  [a-z!-]*)
>   cmd2="$dt $dtaddr"
>   ;;
>   esac




Beautiful.  

Thank you Stuart !



Re: pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread william dunand
Hi Stuart,
Thanks for your answer.

Well this rule-set's purpose is just to illustrate the "problem".

In my actual rule-set, I use several match statements to set default
queuing policy for block of rules, and of course for nating outgoing
traffic.

I noticed ny the way that if the block (or pass) log rule is located
after the match rule, then it is properly logged (which seems in line
with the man page). Unfortunately, I don't think I can change the
order of the rules in my particular case.

Here is a condensed version of my rule-set:


ext_if = "bge0"
int_if = "em0"
cross_if = "bge1"

non_routable = "{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12,
10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4}"

...
bunch of aliases
...

set skip on {lo, $cross_if, em1}
set block-policy return
set optimization normal

altq on $ext_if priq bandwidth 46Mb queue {q_max, q_hig, q_def, q_low}
queue q_max priority 15
queue q_hig priority 10
queue q_def priority 5 priq(default)
queue q_low priority 0

antispoof for {$ext_if, $int_if}
block in quick on $ext_if from $non_routable to any
block out quick on $ext_if from any to $non_routable
block quick inet6
block all

pass quick on {$ext_if, $int_if} proto carp keep state (no-sync) queue q_hig

match on $ext_if all scrub (reassemble tcp random-id)

### Ext inbound ###
match in on $ext_if proto {tcp, udp} from any to $ext_if:network queue
(q_def, q_hig)
pass in on $ext_if proto icmp from any to $ext_if:network queue q_low
pass in on $ext_if proto tcp from $somewhere to self port 22 keep
state (no-sync) queue (q_low, q_max)
pass in on $ext_if proto tcp from $somewhere to self port 80 keep
state (no-sync) queue (q_low, q_max)
... bunch of pass in on $ext_if from something to something rdr-to something ...

### Ext outbound ###
match out on $ext_if from any to any queue (q_low, q_max)
... bunch of pass out on $ext_if from something to something ...
pass out on $ext_if proto tcp from {A, B} to any port 25
match out on $ext_if from $somewhere to any nat-to $something

### Int inbound ###
pass in on $int_if

### Int outbound ###
pass out on $int_if




So what I would like to do is simply to log blocked outgoing smtp
traffic (not coming from A or B), but I can't find a clean way (it is
in prod so I don't want to turn it upside down) to do it as long as my
nat-to rule has to be at the end of the "ext outbound" section, and my
block rules have to stay on top of everything.

Regards,
William

On Mon, Jun 14, 2010 at 8:35 PM, Stuart Henderson  wrote:
> While this is wierd behaviour, I don't see what purpose this
> match rule can serve, so it's not entirely surprising this hasn't
> been noticed before... What are you trying to do with this?
>
>
> On 2010-06-14, william dunand  wrote:
>> Dear list,
>>
>> I just noticed something strange with pf (4.7) and I wondered if
>> someone could help me to understand it.
>>
>> Let's consider the following simple rule-set:
>>
>>
>> set skip on lo0
>> pass all
>> block out log on bge0 inet proto tcp from any to x.x.x.x port 80
>> match out on bge0 inet proto tcp from any to x.x.x.x port 80
>><\pf.conf>
>>
>> Then if I just try a simple hping on x.x.x.x on port 80, I expect to
>> see the packet blocked, and logged on pflog0, but I don't see it.
>> If I just add a "log" to the "match" rule, then my hping packet will
>> be logged twice on pflog0 (for the block and the match).
>> I observe analog behavior if I replace the block rule by a similar pass rule.
>>
>> So it seems impossible to log specific traffic if this traffic is
>> matched somewhere by a simple "match" rule, one would need to add the
>> "log" directive to the latter, which might of course not be desirable.
>>
>> Is this the expected behavior, or is there something I am overlooking?
>>
>> Any help would be greatly appreciated.
>>
>> Regards,
>> William



Promociones de Junio: Vuvuzelas, Para Vientos e mucho más!

2010-06-14 Thread Brindouro
Si no ves correctamente este mensaje clica aqui

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

[IMAGE]

www.brindouro.com

Si has recibido este email es porque te has registrado en Brindouro.com o
has tenido una relacion comercial con Brindouro. Te recordamos que segun
la normativa vigente en materia de proteccion de datos y servicios de la
sociedad de la informacion (LSSI), tienes derecho a no recibir
informacion promocional de Brindouro.com. Si quieres darte de baja de
nuestro servicio de e-news, haz clic aqui.

[IMAGE]

[IMAGE]



em interfaces and altq percentages

2010-06-14 Thread rhsv6
Hi,

Could someone please clarify whether this is an expected behaviour 
on 4.7 ?

I copy pasted a working config from a machine with bge interfaces 
onto one with em interfaces (changing macro references where 
necessary, of course !) and find that VLAN interfaces do not 
inherit their parent bandwidth under an em environment ... i.e. 
"interface vlan10 does not know its bandwidth, please specify an 
absolute bandwidth"


To illustrate :

pf config line : 
altq on $external_port cbq bandwidth 100% queue {q_admin,q_other }
# Tthe macro refers to a VLAN device (e.g. vlan10)


1/ Under BGE it works fine...
# dmesg | grep bge1
bge1 at pci6 dev 2 function 1 "Broadcom BCM5704C" rev 0x10, BCM5704 
B0 (0x2100): apic 9 int 2 (irq 5), address 00::53
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
# cat /etc/hostname.bge1

description "External Port"
media 100baseTX mediaopt full-duplex
up -inet6
# cat /etc/hostname.vlan10 
description "Internet VLAN"
vlan 1486 vlandev bge1
inet 172.16.155.174 255.255.255.248 NONE
up -inet6
# pfctl -n -f /etc/pf.conf
#

2/ Under em it fails
# dmesg | grep em0
em0 at pci3 dev 0 function 0 "Intel PRO/1000 PT (82571EB)" rev 
0x06: apic 0 int 6 (irq 7), address 00::66
# cat /etc/hostname.em0
description "External Port"
media 100baseTX mediaopt full-duplex
up -inet6
# cat /etc/hostname.vlan10  


description "Internet VLAN"
vlan 101 vlandev em0
inet 172.16.65.242 255.255.254.0 NONE
up -inet6
# pfctl -n -f /etc/pf.conf
"interface vlan10 does not know its bandwidth, please specify an 
absolute bandwidth"



Re: audio recording levels

2010-06-14 Thread Ted Roby
On Mon, Jun 14, 2010 at 2:29 AM, Paul M  wrote:
> On 14/06/2010, at 6:54 PM, Jan Stary wrote:
>

>> It would be my guess that this is the audio chip that's integrated
>> with the Asus P5QPL-AM motherboard.  If you are really after "best
>> transfer quality", you might want to use something else in the
>> first place.
>
> Good point, thanks for the reality check.
> Most of what I have to do is not the best quality anyway, but that
> doesn't mean I'm happy to introduce unnecessary generation loss by
> being sloppy. There is some though that is very good, so that may well
> need something better.


I heard the Griffin iMic was to be discontinued, but mine is supported
under OpenBSD. Your best bet for clean audio is a USB-attached device.

Sound cards just get too much noise off the motherboard.



Re: OpenBSD sends RSTs for gratuitous traffic

2010-06-14 Thread Ted Unangst
On Mon, Jun 14, 2010 at 12:50 AM, Patrick Coleman  wrote:
> The strange thing is that occasionally, the OpenBSD box will reply to
> the gratuitous traffic with a spoofed TCP RST. For example, see [1] -
> a TCP connection was initiated from 203.135.184.10 (an OSX server) to
> 203.135.184.6 (a Linux server), which is on the same subnet. The
> connection is immediately closed, apparently by 203.135.184.6 - but if
> you look at the MAC addresses it's a spoofed packet from the OpenBSD
> box, which is normally 203.135.184.33.

> In my pf.conf I have "match in all scrub (reassemble tcp)" and
> "antispoof log for $interfaces" and nothing else that isn't a simple
> pass/block or NAT rule. I'm not ruling out some sort of config error
> here, because I'm pretty new to OpenBSD and pf, though my
> understanding is that the above won't cause RSTs to be sent for
> layer-two traffic not sent to the OpenBSD box in question.

What happens if you disable antispoof?  You're getting packets on an
interface that doesn't expect them, which is exactly what antispoof is
supposed to block.



Le mois de l'emailing : 5 campagnes pour le prix de 2.

2010-06-14 Thread Paul


Re: pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread Stuart Henderson
On 2010-06-14, william dunand  wrote:
> Well this rule-set's purpose is just to illustrate the "problem".

Ah, for that we can go simpler:

pass log
match

Now you would expect any outgoing traffic to be logged. It isn't.
I've sent a PR for this so it's not lost - it will probably be
kernel/6401.

You don't need it for your requirements though:

> ### Ext outbound ###
> match out on $ext_if from any to any queue (q_low, q_max)
> ... bunch of pass out on $ext_if from something to something ...

add "block out log on $ext_if proto tcp to port 25" here

> pass out on $ext_if proto tcp from {A, B} to any port 25
> match out on $ext_if from $somewhere to any nat-to $something

move this nat-to rule above the pass rule/s that it needs to apply
to.

in general (excepting the bug demonstrated above), match rules
don't affect preceding rules.



Re: pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread william dunand
Stuart,
Thanks for your answer, and for sending the PR.

> Ah, for that we can go simpler:
>
> pass log
> match

Indeed, sorry for the noise.

> move this nat-to rule above the pass rule/s that it needs to apply
> to.

Well, I'll have to test tomorrow, but according to pf.conf man page,
in the Translation section:

 Subsequent rules will see packets as they look after any addresses and
 ports have been translated.  These rules will therefore have to filter
 based on the translated address and port number.

So unless I am reading it wrong, I think one would expect the "match
... nat-to" rules to have to be after the related pass rules.

Thanks again for your help.
William


On Tue, Jun 15, 2010 at 12:28 AM, Stuart Henderson  wrote:
> On 2010-06-14, william dunand  wrote:
>> Well this rule-set's purpose is just to illustrate the "problem".
>
>
> Now you would expect any outgoing traffic to be logged. It isn't.
> I've sent a PR for this so it's not lost - it will probably be
> kernel/6401.
>
> You don't need it for your requirements though:
>
>> ### Ext outbound ###
>> match out on $ext_if from any to any queue (q_low, q_max)
>> ... bunch of pass out on $ext_if from something to something ...
>
> add "block out log on $ext_if proto tcp to port 25" here
>
>> pass out on $ext_if proto tcp from {A, B} to any port 25
>> match out on $ext_if from $somewhere to any nat-to $something
>
>
> in general (excepting the bug demonstrated above), match rules
> don't affect preceding rules.



Master y un de Año de Formacion Gratuita

2010-06-14 Thread Cooperacion Internacional
Si no puedes visualizar correctamente este mensaje, pulsa aquC

SI NO VE LA INFORMACISN, HAGA CLIC AQUM

DivulgaciC3n DinC!mica Informa:

PROMOCISN VALIDA HASTA: 29 de junio de 2010

Master 600 horas

[IMAGE]

!APROVECHA ESTA OPORTUNIDAD!

AHORA: 6.000 $
3 PLAZOS (1:: 3.000 $, 2:: 1.500 $ y 3:: 1.500 $)
OBTENDRAS LA TITULACISN:

- MASTER EN COOPERACISN INTERNACIONAL

Universidad Claustro de Sor Juana
TELIFONO DE INFORMACISN GRATUITA: 01 800 200 20 30

dm...@divulgaciondinamica.es

Solicite Informacisn Sin Compromiso

Envme Este Email a un Amigo/a

SI DESEA DARSE DE BAJA, CLIC AQUM

Conforme a la Ley de servicios de la sociedad de la informacisn y de
comercio electrsnico, y a la vigente Ley organica 15 13/12/1999 de
proteccisn de datos espaqola, le informamos que su direccisn de correo
esta incluida en nuestra base de datos, con la finalidad de enviarle
informacisn de su interis. Si no desea seguir recibiendo ningzn correo
futuro por nuestra parte o quiere modificar sus datos, por favor,
responda directamente a este email con su peticisn. En caso de que no
tengamos respuesta en este envmo, consideramos la autorizacisn para
posteriores envmos.

Pulsar aqui para darse de baja( misc@openbsd.org )
[IMAGE]



Re: [Bulk] ueagle0: initialized, but not syncing.

2010-06-14 Thread Kevin Chadwick
> And kernel prints the messages:
> 
> ueagle0: timeout waiting for operationnal state
> ueagle0: could not boot modem
> 

Sorry, probably too late now, but I have a modem I know works with 4.3
that I can send you.

My other connection was upgraded within days (without warning even
though I asked when it would happen) and I didn't get around to testing
it with 4.7 stable. I imagine it would give the same transfer error as
it did with the newer 4.7 snapshot though.



slow proxy (squid and tinyproxy)

2010-06-14 Thread Price, Joe
Hello, I'm going to summarize this..

Basically, I have the squid port running on 4.6 i386 GENERIC and it is
considerably slow. I have about 8 offices running similar configuration and
they all exhibit similar behavior. When I turn off the proxy I get mad
download speeds. When I turn the proxy on I get a fraction of my maximum
throughput. I have been running tests from speedtest.net and I get ~20M down
without proxy turned on, and ~5M down with it on.. My upload stays about the
same ~2.5M.  I've done these tests quite a few times and it seems very
consistent. This doesn't seem acceptable..

I also tried tinyproxy just to compare/contrast and I get the same speeds
through that as well. Both were installed from ports. I've done quite a bit of
trying different things and reading online, but I don't see any clues to
something where it's obviously not squid specific.

Any help is greatly appreciated.

Some specs from my primary test firewall:
cpu0: Intel(R) Xeon(TM) CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR
real mem  = 2146795520 (2047MB)
avail mem = 2067058688 (1971MB)


Squid.conf (from the machine I did the most testing from, and that has the
most bandwidth and users):
 http_port XXX.XXX.0.108:3128

hierarchy_stoplist cgi-bin ?

 cache_dir null /tmp

cache_access_log /var/squid/logs/access.log

cache_store_log none

dns_nameservers localhost

 redirect_children 10

redirect_rewrites_host_header off

refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern .   0   20% 4320

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

acl proxy_users_port myport 3128

http_access allow all

http_access deny all

http_reply_access allow all

icp_access allow all
tcp_outgoing_address XX.XXX.XX.81

cache_mgr info...@x.xxx

coredump_dir /var/squid/cache



Re: slow proxy (squid and tinyproxy)

2010-06-14 Thread Pete Vickers
I expect I'll get shot down for this, but this is what I run (after a good
deal of trail & error) on my squid boxes ( ~700 users). YMMV.


$ tail /etc/sysctl.conf

#net.inet.tcp.ecn=1
net.inet.ip.ifq.maxlen=512
#net.inet.tcp.ackonpush=1
#
net.inet.tcp.recvspace=262144
net.inet.tcp.sendspace=262144
net.inet.udp.recvspace=262144
net.inet.udp.sendspace=262144
#
kern.maxfiles=8192
#
kern.maxclusters=8192




and login.conf:

daemon:\
:ignorenologin:\
:datasize=infinity:\
:maxproc=infinity:\
:openfiles=5000:\
:stacksize=8M:\
:localcipher=blowfish,8:\
:tc=default:




/Pete


On 14. juni 2010, at 22.43, Price, Joe wrote:

> Hello, I'm going to summarize this..
>
> Basically, I have the squid port running on 4.6 i386 GENERIC and it is
> considerably slow. I have about 8 offices running similar configuration and
> they all exhibit similar behavior. When I turn off the proxy I get mad
> download speeds. When I turn the proxy on I get a fraction of my maximum
> throughput. I have been running tests from speedtest.net and I get ~20M
down
> without proxy turned on, and ~5M down with it on.. My upload stays about
the
> same ~2.5M.  I've done these tests quite a few times and it seems very
> consistent. This doesn't seem acceptable..
>
> I also tried tinyproxy just to compare/contrast and I get the same speeds
> through that as well. Both were installed from ports. I've done quite a bit
of
> trying different things and reading online, but I don't see any clues to
> something where it's obviously not squid specific.
>
> Any help is greatly appreciated.
>
> Some specs from my primary test firewall:
> cpu0: Intel(R) Xeon(TM) CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz
> cpu0:
>
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR
> real mem  = 2146795520 (2047MB)
> avail mem = 2067058688 (1971MB)
>
>
> Squid.conf (from the machine I did the most testing from, and that has the
> most bandwidth and users):
> http_port XXX.XXX.0.108:3128
>
> hierarchy_stoplist cgi-bin ?
>
> cache_dir null /tmp
>
> cache_access_log /var/squid/logs/access.log
>
> cache_store_log none
>
> dns_nameservers localhost
>
> redirect_children 10
>
> redirect_rewrites_host_header off
>
> refresh_pattern ^ftp:   144020% 10080
> refresh_pattern ^gopher:14400%  1440
> refresh_pattern .   0   20% 4320
>
> acl all src 0.0.0.0/0.0.0.0
> acl manager proto cache_object
> acl localhost src 127.0.0.1/255.255.255.255
> acl to_localhost dst 127.0.0.0/8
> acl SSL_ports port 443 563
> acl Safe_ports port 80  # http
> acl Safe_ports port 21  # ftp
> acl Safe_ports port 443 563 # https, snews
> acl Safe_ports port 70  # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535  # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
>
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>
> acl proxy_users_port myport 3128
>
> http_access allow all
>
> http_access deny all
>
> http_reply_access allow all
>
> icp_access allow all
> tcp_outgoing_address XX.XXX.XX.81
>
> cache_mgr info...@x.xxx
>
> coredump_dir /var/squid/cache
>

Pete Vickers

p...@systemnet.no |  +47 48 17 91 00

SystemNet AS



Re: audio recording levels

2010-06-14 Thread Paul M

On 15/06/2010, at 2:20 AM, Ted Roby wrote:


On Mon, Jun 14, 2010 at 2:29 AM, Paul M  wrote:

On 14/06/2010, at 6:54 PM, Jan Stary wrote:




It would be my guess that this is the audio chip that's integrated
with the Asus P5QPL-AM motherboard.  If you are really after "best
transfer quality", you might want to use something else in the
first place.


Good point, thanks for the reality check.
Most of what I have to do is not the best quality anyway, but that
doesn't mean I'm happy to introduce unnecessary generation loss by
being sloppy. There is some though that is very good, so that may well
need something better.



I heard the Griffin iMic was to be discontinued, but mine is supported
under OpenBSD. Your best bet for clean audio is a USB-attached device.

Sound cards just get too much noise off the motherboard.



Interesting.
I have one of those kicking around somewhere. I'll have to dig it out.
Thanks


paulm



etc/mtree/ missing in recent snapshot etc tarballs?

2010-06-14 Thread C. Bensend
Hey folks,

   I'm going through an upgrade cycle here at home, upgrading my
boxes from an older -CURRENT snapshot.  This is the second one in a
few days, and both of the snapshots I had downloaded were missing
etc/mtree in etc47.tgz.  The snapshots were downloaded from ftp3.usa
and from ftp.openbsd.org (just to verify).

   I checked current.html and the mailing list archives, but I'm not
seeing anything mentioning a change to the mtree stuff...  Am I just
missing something?  Or have recent snapshots escaped without mtree?

Thanks!

Benny


-- 
"I can do for you is - what can not no girl!"
-- Spam email subject, 2010-01-15



Re: etc/mtree/ missing in recent snapshot etc tarballs?

2010-06-14 Thread C. Bensend
>I checked current.html and the mailing list archives, but I'm not
> seeing anything mentioning a change to the mtree stuff...  Am I just
> missing something?  Or have recent snapshots escaped without mtree?

Sorry, these are i386, FYI.

Benny


-- 
"I can do for you is - what can not no girl!"
-- Spam email subject, 2010-01-15



Re: etc/mtree/ missing in recent snapshot etc tarballs?

2010-06-14 Thread Stuart Henderson
On 2010-06-14, C. Bensend  wrote:
> Hey folks,
>
>I'm going through an upgrade cycle here at home, upgrading my
> boxes from an older -CURRENT snapshot.  This is the second one in a
> few days, and both of the snapshots I had downloaded were missing
> etc/mtree in etc47.tgz.  The snapshots were downloaded from ftp3.usa
> and from ftp.openbsd.org (just to verify).
>
>I checked current.html and the mailing list archives, but I'm not
> seeing anything mentioning a change to the mtree stuff...  Am I just
> missing something?  Or have recent snapshots escaped without mtree?
>
> Thanks!
>
> Benny
>
>

they're in base not etc (as of src/distrib/sets/lists/base/mi r1.490).



Re: etc/mtree/ missing in recent snapshot etc tarballs?

2010-06-14 Thread C. Bensend
>>I'm going through an upgrade cycle here at home, upgrading my
>> boxes from an older -CURRENT snapshot.  This is the second one in a
>> few days, and both of the snapshots I had downloaded were missing
>> etc/mtree in etc47.tgz.  The snapshots were downloaded from ftp3.usa
>> and from ftp.openbsd.org (just to verify).
>>
>>I checked current.html and the mailing list archives, but I'm not
>> seeing anything mentioning a change to the mtree stuff...  Am I just
>> missing something?  Or have recent snapshots escaped without mtree?
>
> they're in base not etc (as of src/distrib/sets/lists/base/mi r1.490).

Ah ha...  Thank you, Stuart.

I seemed to have missed noticing that commit.

Benny


-- 
"I can do for you is - what can not no girl!"
-- Spam email subject, 2010-01-15



Re: slow proxy (squid and tinyproxy)

2010-06-14 Thread Stuart Henderson
On 2010-06-14, Pete Vickers  wrote:
> I expect I'll get shot down for this, but this is what I run (after a good
> deal of trail & error) on my squid boxes ( ~700 users). YMMV.

fairly sensible settings, and not just a blind copy-and-paste of
my least favourite page on calomel.org, I won't shoot this down (:

> net.inet.ip.ifq.maxlen=512

if you see an increase in net.inet.ip.ifq.drops you probably want to
increase this value, otherwise it's ok to leave alone.

> net.inet.tcp.recvspace=262144
> net.inet.tcp.sendspace=262144
> net.inet.udp.recvspace=262144
> net.inet.udp.sendspace=262144

udp probably not necessary for this, tcp recvspace probably yes (though
if you're busy, maybe this needs less than the full 256KB),

the ideal setting for tcp sendspace depends how distant the proxy's
clients are (if it's all LAN clients this probably won't need much
increase from defaults, but with more distant clients, increasing it
according to expected bandwidth*delay product can be helpful).

likewise for recvspace and the servers you're fetching from (though
this is usually less predictable than clients).

> kern.maxfiles=8192
> :openfiles=5000:\

maybe tweak according to what's actually used (see kern.nfiles / fstat).

> kern.maxclusters=8192

compare max and peak in netstat -m with the default value.

tcp.sendspace and especially tcp.recvspace likely have the biggest
effect out of these settings, but I think are also probably the most
dangerous on a very busy system because they're scaled by the number
of connections..

the other settings may help some, depending on the system.

increasing any of these will increase kernel memory use, use too much
and you crash, so it makes sense to only increase where needed.



Sierra Wireless MC5720 Modem

2010-06-14 Thread Marco Peereboom
Anyone got: 
umsm0 at uhub7 port 2 configuration 1 interface 0 "Sierra Wireless Sierra 
Wireless MC5720 Modem" rev 1.10/0.01 addr 2
ucom0 at umsm0
To work on OpenBSD?

I get basically no output from the modem using this in /etc/remote:
mobile:\
:at=hayes:dv=/dev/cuaU0:dv=/dev/ttya:tc=direct:tc=unixhost:

# sudo tip remote
connected

And then I can type AT all day long and get no response.  The modem
isn't activated but I don't want to go spend money on activating it
unless I know if that is what is causing it to not respond.

Something else weird is that if I fart enough with tip and stuff to get
to the modem and reboot with it on it hangs the IO subsytem.  Not sure
why a serial port is sitting on IPL_BIO but that is a different story.



Re: OpenBSD sends RSTs for gratuitous traffic

2010-06-14 Thread Patrick Coleman
On Mon, Jun 14, 2010 at 11:23 PM, Ted Unangst  wrote:
>> In my pf.conf I have "match in all scrub (reassemble tcp)" and
>> "antispoof log for $interfaces" and nothing else that isn't a simple
>> pass/block or NAT rule. I'm not ruling out some sort of config error
>> here, because I'm pretty new to OpenBSD and pf, though my
>> understanding is that the above won't cause RSTs to be sent for
>> layer-two traffic not sent to the OpenBSD box in question.
>
> What happens if you disable antispoof?  You're getting packets on an
> interface that doesn't expect them, which is exactly what antispoof is
> supposed to block.

No change, unfortunately. In any case, my understanding is that
antispoof will drop spoofed packets, not go out and actively kill the
TCP connection?

-Patrick

--
http://www.labyrinthdata.net.au - WA Backup, Web and VPS Hosting



Re: pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread Stuart Henderson
On 2010-06-14, william dunand  wrote:
> On Tue, Jun 15, 2010 at 12:28 AM, Stuart Henderson  
> wrote:
>> On 2010-06-14, william dunand  wrote:
>>> Well this rule-set's purpose is just to illustrate the "problem".
>>
>>
>> Now you would expect any outgoing traffic to be logged. It isn't.
>> I've sent a PR for this so it's not lost - it will probably be
>> kernel/6401.
>>
>> You don't need it for your requirements though:
>>
>>> ### Ext outbound ###
>>> match out on $ext_if from any to any queue (q_low, q_max)
>>> ... bunch of pass out on $ext_if from something to something ...
>>
>> add "block out log on $ext_if proto tcp to port 25" here
>>
>>> pass out on $ext_if proto tcp from {A, B} to any port 25
>>> match out on $ext_if from $somewhere to any nat-to $something
>>
>> move this nat-to rule above the pass rule/s that it needs to apply
>> to.
>
> Well, I'll have to test tomorrow, but according to pf.conf man page,
> in the Translation section:
>
>  Subsequent rules will see packets as they look after any addresses and
>  ports have been translated.  These rules will therefore have to filter
>  based on the translated address and port number.
>
> So unless I am reading it wrong, I think one would expect the "match
> ... nat-to" rules to have to be after the related pass rules.

ah, yes, I see what you mean, but this depends on the values chosen for
A, B, somewhere, something.

it might be simpler to combine the rules e.g.

pass out on $ext_if proto tcp from {A, B} to port 25 nat-to $something

each packet that doesn't match existing state passes through the ruleset.
if a 'match...nat-to' (or rdr-to, scrub, etc) is seen, the settings are
remembered and applied to the next matching pass/block rule. ruleset
processing stops at the first 'quick' rule, otherwise the last matching
rule (pass/block) is used, with the modifiers from previous match rules
being used.

if a rule which changes the address is traversed, following rules see
the new address. without this it would be impossible to use 'match...nat-to'
as a simple replacement for existing nat rules (otherwise you would need
widespread reordering to convert old rulesets).



Re: pf.conf: "match" seems to clean up previous "log" statements.

2010-06-14 Thread william dunand
> ah, yes, I see what you mean, but this depends on the values chosen for
> A, B, somewhere, something.

Yeah sorry for the vagueness :)
Anyway I tested it just in case and as expected it didn't work.

> it might be simpler to combine the rules e.g.
>
> pass out on $ext_if proto tcp from {A, B} to port 25 nat-to $something

Indeed, I guess having the nat-to on the pass rule is the only way
(until the PR get solved ;)
I just wanted to avoid having more than one nat rule, and block rules
not gathered altogether at the top.

Thanks again for your help.
William



Re: OpenBSD sends RSTs for gratuitous traffic

2010-06-14 Thread Patrick Coleman
On Tue, Jun 15, 2010 at 1:03 PM, LeviaComm Networks NOC
 wrote:
> It would be best if you had a working switch to test with, the switch may
be
> forwarding packets to the OpenBSD box because its MAC table is broken.  The
> switch may be the cause, please confirm that it isn't before making noise.
>  I am sure that no one wants to waste time casing down a bug and then
> finding out that it was the switch all along.

Sure, I acknowledge there may be something broken there. But tcpdump
on the OpenBSD box indicates the MAC addresses of the traffic received
do not match any MAC address on the OpenBSD box. In this case OpenBSD
should be simply discarding the packets, not transmitting spoofed RSTs
for TCP conversations it is not involved in.

The situation is basically the same as if OpenBSD was connected to a
hub, not a switch. In that case, it would be receiving every packet
traversing the local subnet.

I'm not denying I might have configured OpenBSD wrong somehow - if so,
any ideas as to where would be greatly appreciated.

Cheers,

Patrick

--
http://www.labyrinthdata.net.au - WA Backup, Web and VPS Hosting



Re: OpenBSD sends RSTs for gratuitous traffic

2010-06-14 Thread patrick keshishian
On Mon, Jun 14, 2010 at 10:20 PM, Patrick Coleman  wrote:
> On Tue, Jun 15, 2010 at 1:03 PM, LeviaComm Networks NOC
>  wrote:
>> It would be best if you had a working switch to test with, the switch may
> be
>> forwarding packets to the OpenBSD box because its MAC table is broken.
 The
>> switch may be the cause, please confirm that it isn't before making noise.
>>  I am sure that no one wants to waste time casing down a bug and then
>> finding out that it was the switch all along.
>
> Sure, I acknowledge there may be something broken there. But tcpdump
> on the OpenBSD box indicates the MAC addresses of the traffic received
> do not match any MAC address on the OpenBSD box. In this case OpenBSD
> should be simply discarding the packets, not transmitting spoofed RSTs
> for TCP conversations it is not involved in.
>
> The situation is basically the same as if OpenBSD was connected to a
> hub, not a switch. In that case, it would be receiving every packet
> traversing the local subnet.
>
> I'm not denying I might have configured OpenBSD wrong somehow - if so,
> any ideas as to where would be greatly appreciated.

This thread is of some interest to me. I have experienced a somewhat
similar condition. I don't wish to add noise to this thread, as I
don't have much data to contribute, but I thought I'd share the
following info/story. It may not be of much use I'm afraid.

I started using trunk(4) interface with my ibook (at work) in failover
mode with ethernet port and wifi ports; master port being the wired
ethernet port (gem0). What I noticed was that whenever I would unplug
the ibook, the adjacent PC would have all its TCP sessions dropped.
The PC and ibook in my office shared the same netgear switch (FS105).

First few times I thought it was just a fluke, but soon I correlated
it with I unplugging the ethernet cable from the ibook. IIRC, pflog
showed 'block in' rule on the ibook acting on traffic not indented for
the ibook.

Unfortunately, I didn't have much chance to debug this further as our
work wifi network was soon redone by $newcompany. The new wifi routers
were pretty much useless; $newcompanyIT blamed the building's
structure for reliability issues.

An initial assumption was an incorrect/invalid set-up on my part -- it
was my first attempt to play with trunk(4) -- also I couldn't find
anyone else reporting such problem on m...@.

Before playing with trunk(4), when I would disconnect the ibook and
hop on the wifi network I would manually `ifconfig gem0 delete; route
delete default; ifconfig bwi0 nwid $nwid ... up ; route add default
$gw`. This procedure never caused above described issue.

I'm going to lurk now,
--patrick



Re: OpenBSD sends RSTs for gratuitous traffic

2010-06-14 Thread LeviaComm Networks NOC

On 6/13/2010 9:50 PM, Patrick Coleman wrote:

For some reason however, on one particular VLAN the switch is
erroneously forwarding traffic from a particular host (203.135.184.10)
to the OpenBSD box. The traffic is forwarded even when the destination
MAC address is not that of the OpenBSD box. So there's something
broken on my switch, I need to fix it, fair enough.

It would be best if you had a working switch to test with, the switch 
may be forwarding packets to the OpenBSD box because its MAC table is 
broken.  The switch may be the cause, please confirm that it isn't 
before making noise.  I am sure that no one wants to waste time casing 
down a bug and then finding out that it was the switch all along.


-Christopher