Re: ucom(4)
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)
> 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
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
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
[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
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"
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.
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"
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.
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"
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"
>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"
>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.
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!
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
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
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
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.
Re: pf.conf: "match" seems to clean up previous "log" statements.
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.
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
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.
> 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)
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)
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
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?
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?
>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?
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?
>>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)
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
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
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.
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.
> 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
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
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
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