Re: A slight twist on the OpenBSD laptop question
it's not relevant because these aren't stand alone gpus... here in venezuela they're still selling clarkdales... i know because i just bought two. can someone else in a developing country offer their observations? i don't see the need to upgrade to sandy bridge ++ because my system can handle 1080p... even if it could handle more, broadband is 128K/12K really this whole obsd sucks for video thing is out of proportion On Wed, Mar 6, 2013 at 11:25 PM, Brad Smith b...@comstyle.com wrote: On Wed, Mar 06, 2013 at 12:10:18PM -0430, Andres Perera wrote: i don't think it's as drastic as that if you buy a Clarkdale cpu you're good to go these came out ~2010, they are still modern The issue isn't the CPU but the GPU and the GPUs in question come with Sandy Bridge/Ivy Bridge based systems and anything newer. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: altq: upsteam and downstream
On 03/04/2013 10:17 PM, Martin Pelikan wrote:
Hello. Thanks for your reply.
I need to guaranty bandwidth for selected host (abu, ali) and
pass all other traffic to bulk queue, but I have a lot of filter rules
and don't know how to do it. I have applied queues to some pass rules
and lost connection to Internet and to ssh (22555)
Follow notes inline, in the config.
My biggest advice (I've done the same mistake so many times myself) in
building a firewall ruleset is to go one step at a time. Don't try to
write the whole ruleset all at once, and then loading it and expecting
it to work right away.
The same applies to queueing. Add two queues, default one big enough,
start using them both and observe systat queues 1. If it worked, go
and add another one, and so forth.
If you've lost your connectivity to ssh, first find out which step in
the process did it. pflog(4) is quite handy (match ... log ...).
tabletlv_qnap { 192.168.2.200 }
tabletlk_proxmox { 192.168.5.201 }
tabletlv_proxmox { 192.168.2.201 }
tabletlv_mentor { 192.168.2.205 }
tabletlv_bugzilla { 192.168.2.206 }
tablemacintosh { 192.168.5.73 }
tableogo { 192.168.5.36 }
tablemsn { 192.168.5.44 }
tablesma { 192.168.5.210 }
tablepresentation { 192.168.5.13 }
Actually, I believe creating tables for just one host can be wasteful of
resources (if you're planning to add hosts dynamically to them, then it
is okay). pfctl(8) automatically creates tables when one rule appears
seven or more times but just with one address changed. In cases of a
single host, macros are better, because the kernel sees directly that
one IP adddress and doesn't have to look it up in a table (which is a
different memory location that doesn't have to be present in CPU caches
and therefore consuming more CPU time).
But on 20 Mbit/s gateway CPU power shouldn't bother you.
tableprivate { 0.0.0.0/8, 10.0.0.0/8, 14.0.0.0/8, \
127.0.0.0/8, 128.0.0.0/16, 169.254.0.0/16, \
172.16.0.0/12, 191.255.0.0/16, 192.0.2.0/24, \
192.168.0.0/16, 240.0.0.0/4, 255.255.255.0/24 }
One, you're missing 100.64/10, which is the new CGN private range.
Two, such a table be better marked const, so you accidentally don't add
something unexpected in it.
Three, 128.0/16 has some allocated bits in it. There are lots of books
suggesting people block martian IPv4 ranges (the valid ones being
0.0.0.0/8 and few others), but some of them have been allocated since
the books were released.
You may want to read http://tools.ietf.org/html/rfc5735 .
block quick proto tcp flags /S
block quick proto tcp flags A/A
I've seen people being told that playing with rules to various TCP flag
combinations usually leads to the firewall misbehaving and that pf(4) is
doing most of the sanity checks already by itself. Are you sure you
really need these rules for anything in particular?
Did your internet connection work without them?
altq on $ext_if hfsc bandwidth $upstream queue { root_out }
queue root_out on $ext_if bandwidth 100% hfsc {ack, dns, manager, bulk}
queue dns on $ext_if priority 7 bandwidth 5% qlimit 500 hfsc (realtime 5%)
queue ack on $ext_if priority 6 bandwidth 10% qlimit 500 hfsc (realtime 10%)
queue manager on $ext_if priority 5 bandwidth 20% qlimit 500 hfsc
(realtime 10% upperlimit 95%)
queue bulk on $ext_if priority 1 bandwidth 40% qlimit 500 hfsc (default,
red realtime 20% upperlimit 95%)
altq on $int_if hfsc bandwidth $downstream queue { root_in}
queue root_in on $int_if bandwidth 100% hfsc {ack, dns, manager, bulk}
queue dns on $int_if priority 7 bandwidth 5% qlimit 500 hfsc (realtime 5%)
queue ack on $int_if priority 6 bandwidth 10% qlimit 500 hfsc (realtime 10%)
queue manager on $int_if priority 5 bandwidth 20% qlimit 500 hfsc
(realtime 10% upperlimit 95%)
queue bulk on $int_if priority 1 bandwidth 40% qlimit 500 hfsc (default,
red realtime 20% upperlimit 95%)
It occurs to me these two are exactly the same. I think you can make it
a lot shorter by writing it at once, like so:
altq on $ext_if hfsc bandwidth $upstream queue { ack dns manager bulk }
altq on $int_if hfsc bandwidth $downstream queue { ack dns manager bulk }
queue ack bandwidth 10% qlimit 500 priority 6 hfsc(realtime 10%)
queue dns bandwidth 5% qlimit 500 priority 7 hfsc(realtime 5%)
queue manager bandwidth 20% qlimit 500 priority 5 hfsc(...)
...
And it will create two of each of them automatically (you can check
pfctl -vvsq if it matched your expectations). You can always
differentiate them per interface if you want. But keeping the file
minimal in size is good for readability after a time period when you
forget about what you did. Also qlimit of 500 is a little too high
(I use 150 on 200+ Mbit/s 50kpps gateways and it is more than enough).
#in
pass in on $ext_if inet proto tcp from any to em1 port 22555
This alone should match every time you connect. Also note the rule is
to em1 port 22555, which means you can only
Re: em(4) watchdog timeouts on 5.0-release
On 11/09/2011 10:27 PM, Jussi Peltola wrote:
You can ignore the clueless parts in my previous message :)
I can set up remote access to one of these machines if needed.
This made the ems work again:
--- if_em.c.origWed Nov 9 21:37:39 2011
+++ if_em.c Wed Nov 9 21:39:01 2011
@@ -331,6 +331,2 @@
- /* Only use MSI on the newer PCIe parts */
- if (sc-hw.mac_type em_82571)
- sc-osdep.em_pa.pa_flags= ~PCI_FLAGS_MSI_ENABLED;
-
/* Parameters (to be read from user) */
@@ -1621,3 +1617,3 @@
- if (pci_intr_map_msi(pa,ih) pci_intr_map(pa,ih)) {
+ if (pci_intr_map(pa,ih)) {
printf(: couldn't map interrupt\n);
.
I had no problem with this box until strange network behaviour occur.
It comes and leaves unexpectedly but cause trouble with access network
behind em0.
# dmesg
OpenBSD 5.0 (GENERIC.MP) #59: Wed Aug 17 10:19:44 MDT 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (GenuineIntel
686-class) 2 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
real mem = 1064431616 (1015MB)
avail mem = 1036947456 (988MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/12/08, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.5 @ 0x9f800 (28 entries)
bios0: vendor American Megatrends Inc. version 080014 date 08/12/2008
bios0: ICP / iEi KINO-9652
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB ASF! SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4)
USB1(S4) USB2(S4) USB3(S4) EUSB(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4)
P0P8(S4) P0P9(S4) HDAC(S4) USB4(S4) USB5(S4) USBE(S4) GBEC(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (GenuineIntel
686-class) 2 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 1 (P0P1)
acpiprt3 at acpi0: bus 2 (P0P4)
acpiprt4 at acpi0: bus 3 (P0P5)
acpiprt5 at acpi0: bus -1 (P0P6)
acpiprt6 at acpi0: bus -1 (P0P7)
acpiprt7 at acpi0: bus -1 (P0P8)
acpiprt8 at acpi0: bus -1 (P0P9)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1994 MHz: speeds: 2000, 1600, 1200 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel GME965 Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel GME965 Video rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 2 int 16
drm0 at inteldrm0
Intel GME965 Video rev 0x03 at pci0 dev 2 function 1 not configured
Intel GME965 HECI rev 0x03 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 Intel ICH8 IGP M AMT rev 0x04: msi,
address 00:18:7d:1a:37:d6
uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x04: apic 2 int 16
uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x04: apic 2 int 21
ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x04: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x04: msi
azalia0: codecs: Realtek ALC883
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x04: apic 2 int 22
pci1 at ppb0 bus 2
ral0 at pci1 dev 0 function 0 Ralink RT3090 rev 0x00: apic 2 int 16,
address 00:12:0e:b1:6e:c7
ral0: MAC/BBP RT3071 (rev 0x0213), RF RT3020 (MIMO 1T1R)
ppb1 at pci0 dev 28 function 1 Intel 82801H PCIE rev 0x04: apic 2 int 23
pci2 at ppb1 bus 3
em1 at pci2 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: msi,
address 00:18:7d:1a:37:d8
uhci2 at pci0 dev 29 function 0 Intel 82801H USB rev 0x04: apic 2 int 23
uhci3 at pci0 dev 29 function 1 Intel 82801H USB rev 0x04: apic 2 int 19
uhci4 at pci0 dev 29 function 2 Intel 82801H USB rev 0x04: apic 2 int 18
ehci1 at pci0 dev 29 function 7 Intel 82801H USB rev 0x04: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xf4
pci3 at ppb2 bus 1
pcib0 at pci0 dev 31 function 0 Intel 82801HEM LPC rev 0x04
pciide0 at pci0 dev 31 function 1
Re: em(4) watchdog timeouts on 5.0-release
What about 5.2? Same issues?
//mxb
On 7 mar 2013, at 11:36, lilit-aibolit lilit-aibo...@mail.ru wrote:
On 11/09/2011 10:27 PM, Jussi Peltola wrote:
You can ignore the clueless parts in my previous message :)
I can set up remote access to one of these machines if needed.
This made the ems work again:
--- if_em.c.origWed Nov 9 21:37:39 2011
+++ if_em.c Wed Nov 9 21:39:01 2011
@@ -331,6 +331,2 @@
- /* Only use MSI on the newer PCIe parts */
- if (sc-hw.mac_type em_82571)
- sc-osdep.em_pa.pa_flags= ~PCI_FLAGS_MSI_ENABLED;
-
/* Parameters (to be read from user) */
@@ -1621,3 +1617,3 @@
- if (pci_intr_map_msi(pa,ih) pci_intr_map(pa,ih)) {
+ if (pci_intr_map(pa,ih)) {
printf(: couldn't map interrupt\n);
.
I had no problem with this box until strange network behaviour occur.
It comes and leaves unexpectedly but cause trouble with access network
behind em0.
# dmesg
OpenBSD 5.0 (GENERIC.MP) #59: Wed Aug 17 10:19:44 MDT 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (GenuineIntel 686-class) 2
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
real mem = 1064431616 (1015MB)
avail mem = 1036947456 (988MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/12/08, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.5 @ 0x9f800 (28 entries)
bios0: vendor American Megatrends Inc. version 080014 date 08/12/2008
bios0: ICP / iEi KINO-9652
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB ASF! SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4)
USB2(S4) USB3(S4) EUSB(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4)
P0P9(S4) HDAC(S4) USB4(S4) USB5(S4) USBE(S4) GBEC(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (GenuineIntel 686-class) 2
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 1 (P0P1)
acpiprt3 at acpi0: bus 2 (P0P4)
acpiprt4 at acpi0: bus 3 (P0P5)
acpiprt5 at acpi0: bus -1 (P0P6)
acpiprt6 at acpi0: bus -1 (P0P7)
acpiprt7 at acpi0: bus -1 (P0P8)
acpiprt8 at acpi0: bus -1 (P0P9)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1994 MHz: speeds: 2000, 1600, 1200 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel GME965 Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel GME965 Video rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 2 int 16
drm0 at inteldrm0
Intel GME965 Video rev 0x03 at pci0 dev 2 function 1 not configured
Intel GME965 HECI rev 0x03 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 Intel ICH8 IGP M AMT rev 0x04: msi, address
00:18:7d:1a:37:d6
uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x04: apic 2 int 16
uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x04: apic 2 int 21
ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x04: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x04: msi
azalia0: codecs: Realtek ALC883
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x04: apic 2 int 22
pci1 at ppb0 bus 2
ral0 at pci1 dev 0 function 0 Ralink RT3090 rev 0x00: apic 2 int 16,
address 00:12:0e:b1:6e:c7
ral0: MAC/BBP RT3071 (rev 0x0213), RF RT3020 (MIMO 1T1R)
ppb1 at pci0 dev 28 function 1 Intel 82801H PCIE rev 0x04: apic 2 int 23
pci2 at ppb1 bus 3
em1 at pci2 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: msi,
address 00:18:7d:1a:37:d8
uhci2 at pci0 dev 29 function 0 Intel 82801H USB rev 0x04: apic 2 int 23
uhci3 at pci0 dev 29 function 1 Intel 82801H USB rev 0x04: apic 2 int 19
uhci4 at pci0 dev 29 function 2 Intel 82801H USB rev 0x04: apic 2 int 18
ehci1 at pci0 dev 29 function 7 Intel 82801H USB rev 0x04: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub
Re: em(4) watchdog timeouts on 5.0-release
On 03/07/2013 01:10 PM, mxb wrote: What about 5.2? Same issues? //mxb I don't know. This is remote host1 and it holds IPSec with another host2. When issue come - network behind host2 can't reach resources behind host1.
Re: em(4) watchdog timeouts on 5.0-release
On Thu, Mar 07, 2013 at 12:10:08PM +0100, mxb wrote: What about 5.2? Same issues? Even better, what about -current or 5.3 snaps? Ken
Re: em(4) watchdog timeouts on 5.0-release
Yes, it's much better. I currently have several 5.2-current (post 5.2-rel ) machines with em(4) without any problems regarding em(4). 5.0 is EOL. On 7 mar 2013, at 13:09, Kenneth R Westerback kwesterb...@rogers.com wrote: On Thu, Mar 07, 2013 at 12:10:08PM +0100, mxb wrote: What about 5.2? Same issues? Even better, what about -current or 5.3 snaps? Ken
Logitech Webcam Support
Hi My desktop is a Lenovo Think centre, and i' stuck a logitech hd 720p webcam in it. I wondered if anyone has had success with these - do they work on OpenBSD and what packages might I need/consider to use it. I ran sudo fw_update and it installed uvideo-firmware-1.2p0. The webcam has a built-in microphone, would that work as well? I haven't tried using a webcam on OpenBSD to-date so just thought i'd ask here about others' experiences with this. Cheers, Jamie
Re: Logitech Webcam Support
On Thu, 7 Mar 2013 13:32:59 + James Griffin j...@kontrol.kode5.net wrote: Hi My desktop is a Lenovo Think centre, and i' stuck a logitech hd 720p webcam in it. I wondered if anyone has had success with these - do they work on OpenBSD and what packages might I need/consider to use it. I ran sudo fw_update and it installed uvideo-firmware-1.2p0. The webcam has a built-in microphone, would that work as well? I haven't tried using a webcam on OpenBSD to-date so just thought i'd ask here about others' experiences with this. Cheers, Jamie I have a Logitech C270 (HD 720p), video works fine with the uvideo driver. I did not test the built-in microphone though -- Met vriendelijke groet, Erwin Geerdink
ospf and multiple areas
Hi,
I've having trouble configuring multiple areas in ospfd.
System is current.
If I put vlan12 interface in area 0.0.0.7, then vlan12:network is not
announced at all.
If I put it on area 0.0.0.0 then it is announced, but I don't see it as
inter area in remote routers.
How can I add it in area 7?
regards,
Giannis
pf disabled
# cat /etc/ospfd.conf
router-id 192.168.0.5
fib-update yes
stub router no
redistribute connected
redistribute static
area 0.0.0.0 {
interface bge0 {
auth-type crypt
auth-md XX
auth-md-keyid XX
}
}
area 0.0.0.7 {
stub
interface vlan12 {passive}
}
bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:0a:e4:84:41:a5
description: External
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::20a:e4ff:fe84:41a5%bge0 prefixlen 64 scopeid 0x1
inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255
bge1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:0a:e4:84:41:a4
description: Internal
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::20a:e4ff:fe84:41a4%bge1 prefixlen 64 scopeid 0x2
vlan12: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:0a:e4:84:41:a4
description: TEST
priority: 0
vlan: 12 parent interface: bge1
groups: vlan
status: active
inet6 fe80::20a:e4ff:fe84:41a4%vlan12 prefixlen 64 scopeid 0x6
inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
# ospfctl s n
ID Pri StateDeadTime Address Iface Uptime
192.168.0.21 FULL/BCKUP 00:00:30 192.168.0.2 bge0 00:00:25
10.0.1.4 1 FULL/DR 00:00:37 192.168.0.1 bge0 00:00:30
# ospfctl s r
10.0.1.4/32 192.168.0.1 Intra-Area Network 11 00:01:13
# ospfctl s f
*S8 0.0.0.0/0192.168.0.1
*O 32 10.0.1.4/32 192.168.0.1
*C4 10.0.0.0/24link#6
*C0 127.0.0.0/8 link#0
*S8 127.0.0.0/8 127.0.0.1
* 4 127.0.0.1/32 127.0.0.1
*C4 192.168.0.0/24 link#1
*O 32 192.168.0.0/24 192.168.0.5
*S8 224.0.0.0/4 127.0.0.1
# ospfctl s d|grep 10.0.0
nothing
installer - moving sets location right after network for automated installation
Hi, I was thinking that if we would move part in the installer which let the user locate installation sets right after setting networking, we could introduce some install.site alternative which could feed installer with configuration for setting disks etc... Or is there any (semi)official idea how should automated/configurable OpenBSD installer look like in the future? jirib
Re: installer - moving sets location right after network for automated installation
I was thinking that if we would move part in the installer which let the user locate installation sets right after setting networking, we could introduce some install.site alternative which could feed installer with configuration for setting disks etc... Or is there any (semi)official idea how should automated/configurable OpenBSD installer look like in the future? There are hints in your email to suggest you've not read and understood the install script code.
Re: installer - moving sets location right after network for automated installation
On Thu, Mar 07, 2013 at 12:19:22PM -0500, Jiri B wrote: Hi, I was thinking that if we would move part in the installer which let the user locate installation sets right after setting networking, we could introduce some install.site alternative which could feed installer with configuration for setting disks etc... Or is there any (semi)official idea how should automated/configurable OpenBSD installer look like in the future? Several people have talked about and even implemented such systems. No official idea's currently exist. Ken jirib
Re: snort inline
FYI This patch has corrected my issues with snort inline and NAT http://marc.info/?l=openbsd-techm=136245826921904w=2 -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Mayes Sent: Wednesday, December 19, 2012 3:10 PM To: misc@openbsd.org Subject: Re: snort inline Another update in case there is any interest in running divert-packet along with NATing. I ditched snort and wrote a little divert program based on the man page to test easier. I can now see that with nat as well as divert-packet on egress rule on external interface the packet will get NATed and go out. A reply will come back to external interface and then get diverted again and never make it to the client. I am as sure as I can be at this point that you cannot divert packets from a NATed client. Justin -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Sunday, November 25, 2012 4:37 PM To: misc@openbsd.org Subject: Re: snort inline Quick update. It seems to be a nat problem. If I just test by pinging either the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and snort sees the packets. Its only when the traffic is NATed that it fails. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Saturday, November 24, 2012 2:21 PM To: misc@openbsd.org Subject: snort inline Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From what I read it's possible with pf divert functionality. This is what I'm doing for testing in pf using simple ping Gateway info internal interface fxp0 - 192.168.1.32 external interface bce0 - 192.168.0.13 Running snort via this cmd line snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v Internal interface is in the skip list hence no active rules for it Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) This works as expected, I can ping 8.8.8.8 and since no diverting is active snort sees nothing I change rules to this to start diverting to snort Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port 8000 nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) Now internal interface sees outgoing ping tcpdump -n -i fxp0 -n host 8.8.8.8 192.168.1.32 8.8.8.8: icmp: request: External interface shows it going out and coming back 192.168.0.13 8.8.8.8: icmp: request: 8.8.8.8 192.168.0.13: icmp: reply: Snort sees it twice, external interface first 192.168.0.13 - 8.8.8.8 ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF Type:8 Code:0 ID:64870 Seq:2 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 8.8.8.8 - 192.168.1.32 ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84 Type:0 Code:0 ID:52297 Seq:2 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Client @ 192.168.1.32 never sees reply. Any comments or suggestions? Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: snort inline
This works. Thank you very much. I'll let you know if I run into any issues but I am able to run snort inline now along with NAT. Justin -Original Message- From: Lawrence Teo [mailto:l...@openbsd.org] Sent: Wednesday, March 06, 2013 8:55 AM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: snort inline Hi Justin, Not sure if you still need to use divert-packet with NAT, but if you do, could you please try the diff at http://marc.info/?l=openbsd-techm=136245826921904w=2 to see if it works for you? The easiest way to get the diff is: ftp -o divert-checksum.diff \ 'http://marc.info/?l=openbsd-techm=136245826921904q=raw' If you do try it, please let me know if it works for you. Thanks, Lawrence On Wed, Dec 19, 2012 at 03:09:47PM -0600, Justin Mayes wrote: Another update in case there is any interest in running divert-packet along with NATing. I ditched snort and wrote a little divert program based on the man page to test easier. I can now see that with nat as well as divert-packet on egress rule on external interface the packet will get NATed and go out. A reply will come back to external interface and then get diverted again and never make it to the client. I am as sure as I can be at this point that you cannot divert packets from a NATed client. Justin -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Sunday, November 25, 2012 4:37 PM To: misc@openbsd.org Subject: Re: snort inline Quick update. It seems to be a nat problem. If I just test by pinging either the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and snort sees the packets. Its only when the traffic is NATed that it fails. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Saturday, November 24, 2012 2:21 PM To: misc@openbsd.org Subject: snort inline Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From what I read it's possible with pf divert functionality. This is what I'm doing for testing in pf using simple ping Gateway info internal interface fxp0 - 192.168.1.32 external interface bce0 - 192.168.0.13 Running snort via this cmd line snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v Internal interface is in the skip list hence no active rules for it Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) This works as expected, I can ping 8.8.8.8 and since no diverting is active snort sees nothing I change rules to this to start diverting to snort Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port 8000 nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) Now internal interface sees outgoing ping tcpdump -n -i fxp0 -n host 8.8.8.8 192.168.1.32 8.8.8.8: icmp: request: External interface shows it going out and coming back 192.168.0.13 8.8.8.8: icmp: request: 8.8.8.8 192.168.0.13: icmp: reply: Snort sees it twice, external interface first 192.168.0.13 - 8.8.8.8 ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF Type:8 Code:0 ID:64870 Seq:2 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+ 8.8.8.8 - 192.168.1.32 ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84 Type:0 Code:0 ID:52297 Seq:2 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+ Client @ 192.168.1.32 never sees reply. Any comments or suggestions? Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: installer - moving sets location right after network for automated installation
On Thu, Mar 07, 2013 at 10:23:41AM -0700, Theo de Raadt wrote: I was thinking that if we would move part in the installer which let the user locate installation sets right after setting networking, we could introduce some install.site alternative which could feed installer with configuration for setting disks etc... Or is there any (semi)official idea how should automated/configurable OpenBSD installer look like in the future? There are hints in your email to suggest you've not read and understood the install script code. Yes, you were right. But thank you for directing me clearly. For archives, install.sub defines couple of variables and functions which can be defined/overriden via install.md to customize installation. The disadvantage here is one has to rebuild ramdisk manually. jirib
Re: installer - moving sets location right after network for automated installation
On Thu, Mar 07, 2013 at 10:23:41AM -0700, Theo de Raadt wrote: I was thinking that if we would move part in the installer which let the user locate installation sets right after setting networking, we could introduce some install.site alternative which could feed installer with configuration for setting disks etc... Or is there any (semi)official idea how should automated/configurable OpenBSD installer look like in the future? There are hints in your email to suggest you've not read and understood the install script code. Yes, you were right. But thank you for directing me clearly. I am not directing you. For archives, install.sub defines couple of variables and functions which can be defined/overriden via install.md to customize installation. That is irrelevant to what you suggested. The disadvantage here is one has to rebuild ramdisk manually. So change it, as you suggested above. Do you not understand what you said that is so disruptive?? You are suggesting changing the entire *order* of operations that the scripts do. It is not as simple as you suggest. The 5th word in your original email is we, and what you really mean to use there is the plural you.
Re: ZTE mf626 USB modem support
Here is my output of lsusb -v, hope it helps Bus 000 Device 001: ID 8086: Intel Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize064 idVendor 0x8086 Intel Corp. idProduct 0x bcdDevice1.00 iManufacturer 1 Intel iProduct2 EHCI root hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 (Missing must-be-set bit!) Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 255 Hub Descriptor: bLength 11 bDescriptorType 41 nNbrPorts 8 wHubCharacteristic 0x0002 No power switching (usb 1.0) Ganged overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 200 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 0x00 PortPwrCtrlMask0x00 0x00 Hub Port Status: Port 1: .0500 highspeed power Port 2: .0500 highspeed power Port 3: .0503 highspeed power enable connect Port 4: .0500 highspeed power Port 5: .0500 highspeed power Port 6: .0500 highspeed power Port 7: .0500 highspeed power Port 8: .0500 highspeed power Device Status: 0x0001 Self Powered Bus 000 Device 002: ID 19d2:0117 ZTE WCDMA Technologies MSM Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x19d2 ZTE WCDMA Technologies MSM idProduct 0x0117 bcdDevice0.00 iManufacturer 3 ZTE,Incorporated iProduct2 ZTE HSPA Technologies MSM iSerial 4 P680A1ZTED01 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 108 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 1 ZTE Configuration bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None
Re: installer - moving sets location right after network for automated installation
Theo de Raadt dera...@cvs.openbsd.org writes: [...] The 5th word in your original email is we, and what you really mean to use there is the plural you. Is that a new theo.c entry? -- Jérémie Courrèges-Anglas GPG Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Intel hyperthreading w/ Atom E6xx OpenBSD 5.2?
I've been using OpenBsd for 8+ years on my main router/firewall (4 NICs). Time to upgrade (I'm back on v3.8, yikes). Past time, really. Solots to learn / re-learn here. Have patience. First question: I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris net6501). That chip has two Hyperthreading cores. Several net-references (esp. calomel.org ) advocate turning off HTT in the bios when using OpenBSD for faster interrupt servicing / task switching latency. Butperhaps that advice is pre-5.2, when we got pthreads(3) support? What's the best current advice for that kind of one-cpu, multi-logical-thread system? 1) Single processor kernel or multi-processor (smp) kernel? 2) If the latter, HTT turned on or off? Thanks. Bonnie
Re: Intel hyperthreading w/ Atom E6xx OpenBSD 5.2?
On 7 Mar 2013 at 20:24, David Ruggiero wrote: I've been using OpenBsd for 8+ years on my main router/firewall (4 NICs). Time to upgrade (I'm back on v3.8, yikes). Past time, really. Solots to learn / re-learn here. Have patience. First question: I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris net6501). That chip has two Hyperthreading cores. Several net-references (esp. ca**mel.org ) advocate turning off HTT in the bios when using OpenBSD for faster interrupt servicing / task switching latency. Butperhaps that advice is pre-5.2, when we got pthreads(3) support? What's the best current advice for that kind of one-cpu, multi-logical-thread system? 1) Single processor kernel or multi-processor (smp) kernel? 2) If the latter, HTT turned on or off? Thanks. Bonnie First thing first, read, read, and re-read the official documentation. Many things changed in the intervening years, in particular, PF configuration syntax has changed a fair bit. Do note that unlike the Linux world where you have to dig for third party how-tos, OpenBSD official documentation is very complete and up to date. Which is one of the reasons the website you referenced is frowned upon as most of its information is either out of date or simply wrong. That said, the particular point you bring up may still be valid -- much depends on your specific situation. Whether or not to use hyperthreading and multiprocessor (MP) kernel depends on the workload of your firewall. The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. However, if your firewall is also going to be running a fair amount of userland processes (e.g. your website with db backend) then you may well benefit from multiprocessor support.
Re: Intel hyperthreading w/ Atom E6xx OpenBSD 5.2?
The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. Thanks. That's the piece of info I needed, as (at least per current plans) 95% of the machine's time will be in PF-land, with few or no userland programs besides the occasional log-muncher. I do understand the ruleset for PF has changed, and then changed again, in the intervening years. I planned to start from scratch with my rules, not try to port anything from the old system except as a don't forget to allow this kind of reminder. thx D On Thu, Mar 7, 2013 at 8:51 PM, System Administrator ad...@bitwise.netwrote: On 7 Mar 2013 at 20:24, David Ruggiero wrote: I've been using OpenBsd for 8+ years on my main router/firewall (4 NICs). Time to upgrade (I'm back on v3.8, yikes). Past time, really. Solots to learn / re-learn here. Have patience. First question: I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris net6501). That chip has two Hyperthreading cores. Several net-references (esp. ca**mel.org ) advocate turning off HTT in the bios when using OpenBSD for faster interrupt servicing / task switching latency. Butperhaps that advice is pre-5.2, when we got pthreads(3) support? What's the best current advice for that kind of one-cpu, multi-logical-thread system? 1) Single processor kernel or multi-processor (smp) kernel? 2) If the latter, HTT turned on or off? Thanks. Bonnie First thing first, read, read, and re-read the official documentation. Many things changed in the intervening years, in particular, PF configuration syntax has changed a fair bit. Do note that unlike the Linux world where you have to dig for third party how-tos, OpenBSD official documentation is very complete and up to date. Which is one of the reasons the website you referenced is frowned upon as most of its information is either out of date or simply wrong. That said, the particular point you bring up may still be valid -- much depends on your specific situation. Whether or not to use hyperthreading and multiprocessor (MP) kernel depends on the workload of your firewall. The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. However, if your firewall is also going to be running a fair amount of userland processes (e.g. your website with db backend) then you may well benefit from multiprocessor support.
Re: Intel hyperthreading w/ Atom E6xx OpenBSD 5.2?
wait wait ~ can someone comment on this http://www.daemonology.net/hyperthreading-considered-harmful/ ? is it still in vogue? On Fri, Mar 8, 2013 at 12:31 AM, David Ruggiero thatseattle...@gmail.com wrote: The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. Thanks. That's the piece of info I needed, as (at least per current plans) 95% of the machine's time will be in PF-land, with few or no userland programs besides the occasional log-muncher. I do understand the ruleset for PF has changed, and then changed again, in the intervening years. I planned to start from scratch with my rules, not try to port anything from the old system except as a don't forget to allow this kind of reminder. thx D On Thu, Mar 7, 2013 at 8:51 PM, System Administrator ad...@bitwise.netwrote: On 7 Mar 2013 at 20:24, David Ruggiero wrote: I've been using OpenBsd for 8+ years on my main router/firewall (4 NICs). Time to upgrade (I'm back on v3.8, yikes). Past time, really. Solots to learn / re-learn here. Have patience. First question: I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris net6501). That chip has two Hyperthreading cores. Several net-references (esp. ca**mel.org ) advocate turning off HTT in the bios when using OpenBSD for faster interrupt servicing / task switching latency. Butperhaps that advice is pre-5.2, when we got pthreads(3) support? What's the best current advice for that kind of one-cpu, multi-logical-thread system? 1) Single processor kernel or multi-processor (smp) kernel? 2) If the latter, HTT turned on or off? Thanks. Bonnie First thing first, read, read, and re-read the official documentation. Many things changed in the intervening years, in particular, PF configuration syntax has changed a fair bit. Do note that unlike the Linux world where you have to dig for third party how-tos, OpenBSD official documentation is very complete and up to date. Which is one of the reasons the website you referenced is frowned upon as most of its information is either out of date or simply wrong. That said, the particular point you bring up may still be valid -- much depends on your specific situation. Whether or not to use hyperthreading and multiprocessor (MP) kernel depends on the workload of your firewall. The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. However, if your firewall is also going to be running a fair amount of userland processes (e.g. your website with db backend) then you may well benefit from multiprocessor support.
Re: installer - moving sets location right after network for automated installation
On Thu, Mar 7, 2013 at 10:17 PM, Jérémie Courrèges-Anglas jca+o...@wxcvbn.org wrote: Theo de Raadt dera...@cvs.openbsd.org writes: [...] The 5th word in your original email is we, and what you really mean to use there is the plural you. Is that a new theo.c entry? +1
