Re: spamd unnecessarily abrasive?
On Feb 20, 2007, at 1:51 PM, [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 12:57:54 -0800, "Brian Keefer" <[EMAIL PROTECTED]> said: Now they've evolved to using botnets and the vast majority of spam comes from such systems, so the bandwidth costs are gone and the hosting costs are pretty much limited to how much they have to pay the criminals for the botnet C&C passwords. It's not a matter of cost any more, it's a matter only of efficiency. If they make more money by spending some cycles to resend, they'll do it. Your average spammer might be pretty dumb, but the people who are writing their tools are usually pretty clever. I wouldn't underestimate them. OK, now please propose a solution. Obviously if anyone had that and cared to commercialize it, they would be a billionaire (judging by cisco's nearly $1bn acquisition of IronPort). I don't think there is any one, final solution for a problem that's allow to exist because of a flawed system. SMTP just wasn't designed for a hostile Internet and any fixes bolted on are prone to work- around or severe usability problems that limit adoption. There's always going to be a race between spammers and anti-spam techniques until enough people get sick of SMTP that they design a new way to send messages across the Internet. If your site cares a lot about blocking spammers and not legitimate e- mail, shell out for a top-of-the-line commercial solution and keep paying maintenance to get updates for fighting new spam techniques. If you don't have the budget, it isn't important, or you oppose spending money for such a thing, use off-the-shelf tools like what OpenBSD has available. There isn't one right answer, only varying degrees of suitable. If you're using something that works great, keep doing that for as long as it works. The main point is that you have to be prepared to adopt as spammers do. Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: Problem with Intel PRO/1000GT (82541GI) adaptors
On Nov 14, 2006, at 12:20 PM, Damian Wiest wrote: On Mon, Nov 13, 2006 at 03:03:55PM -0800, Joe wrote: I have 2 of these adaptors "Intel PRO/1000GT (82541GI)" rev 0x05 The 82541GI chipset is supported by em(4). Every day, the box "drops" of the network. The interfaces show themselves as active, but I can't ping, arp, or sniff any traffic. A reboot solves the problem. Is anyone else having this problem? For now, I had to remove the NICs because the box is a firewall and goes down at random times throughout the day. I didn't notice any particular traffic patterns. We've encountered similar problems in the past with that chip. I believe we resolved the issue by using a newer driver, but this was not under OpenBSD. Can you try a more recent version of the em(4) driver? Some commits were made very recently. -Damian FWIW I was having very similar problems with em(4) in OpenBSD 4.0- release under VMware (amd64 SMP). It would cease to recognize ARP replies and just flood the network with ARP requests endlessly. It was enough to bring VMware to it's knees and totally swamp my cheap switch. I upgraded to -current from this morning's snapshot and the issue hasn't resurfaced yet... Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: Problem with Intel PRO/1000GT (82541GI) adaptors
On Nov 15, 2006, at 9:25 AM, Kian Mohageri wrote: > > > On 11/14/06, Brian Keefer <[EMAIL PROTECTED]> wrote: > > FWIW I was having very similar problems with em(4) in OpenBSD 4.0- > release under VMware (amd64 SMP). It would cease to recognize ARP > replies and just flood the network with ARP requests endlessly. It > was enough to bring VMware to it's knees and totally swamp my cheap > switch. > > The same card too? > > -- > Kian Mohageri The physical chip is a Tigon3, I believe (bge), but I'm not talking about as a host OS, I'm talking about guest OS. VMware provides a virtual Intel PRO/1000MT (82545EM). I was under the assumption it was the driver itself that was quirky. The observed behavior was almost identical to what OP described. Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: Mac Mini (intel) status
On Dec 1, 2006, at 8:25 AM, J.C. Roberts wrote: On Thursday 30 November 2006 15:34, Tasmanian Devil wrote: Boot Camp: No, it's not required, it works fine with a usual OpenBSD-only configured internal harddisk, at least with Boot-ROM-Version MM11.0055.B05 and Boot-ROM-Version MM11.0055.B08. Of course you can only upgrade if you install a minimal OS X... :-/ I don't have a mini (or any reasonably current Apple hardware) but the issue you mentioned reminded me of this post by Brian Keefer: http://marc.theaimsgroup.com/?l=openbsd-sparc&m=116483175532387&w=2 It may be possible to do something similar with the mini? Kind Regards, JCR I'm skeptical of that working on the MacIntels. Looking in /Applications/Utilities/MacBook Pro EFI Firmware Update.app/Contents/ Resources I see the following interesting bits: EFIUpdaterApp.efi LOCKED_MBP11_0055_08B.fd LOCKED_MBP12_0061_03B.fd According to file(1) the first is a MSDOS executable, and the next two are data files. I vaguely recollect from my DOS days that flashing the BIOS on PC motherboards required a flash utility, and a data file (unlike Sun, where you just boot the flash updater in place of a kernel--in my weak understanding). Now there is a "Firmware Restoration CD" available from Apple that you can burn to a CD, but apparently this only works if: 1.) You have partially flashed the firmware and suffered a failure and 2.) You have to play their "power button + flashing lights" game of whack-a-mole. I profess to know nothing about low-level workings of machinery, but if these MacIntels have a somewhat PC-like boot process, perhaps you could make a DOS boot CD with the three files above, boot while holding down 'c', and run EFIUpdaterApp.efi from a DOS prompt? I'm sure there are all kinds of good reasons why that's impossible, but that's my wild-ass-guess. In any case, I highly doubt you could do this with a net boot since the firmware update does not appear to be a self-contained executable and might need a command interpreter to work. Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
OpenBSD/amd64 on VMware = sloooooow?
OK, so just to be clear I'm not a terribly clever person. I have no idea what I should be looking for to diagnose this issue. It's entirely possible that I have something configured stupidly/wrong, etc or that the answer is right in front of me, but I wouldn't know. I've done a little googling and all I came up with was: http://archives.neohapsis.com/archives/openbsd/2005-11/1349.html which went completely un-answered (at least on-list). The OP and I conversed off-list a few weeks ago and he mentioned that the situation is still the same for him (same as I'm seeing). Summary: - 64bit host OS (SLES 9) running on 2 dual-core Opteron 265s - VMware Server 1.0.1 build 29996 - OpenBSD/i386 works fine - OpenBSD/amd64 is slow as hell - MP/UP kernel makes no difference - one CPU or two CPUs makes no difference I've tried 4.0-release, then a snapshot from a few weeks ago, now running with -current GENERIC.MP kernel (as of last night). That kernel took about 22 hours to build, BTW--that's slower than my SPARCstation 5. Right now it's churning away on make depend for GENERIC (UP) and it's been doing so for over 128 minutes. Does anyone have *any* idea why compiling would be so slow on this setup? Services respond fairly quickly (ssh, etc) but running make or cc takes ages. Usually the load is around 1.3 or so when building something, but on occasion it spikes to 16 or more for no apparent reason. I'd love to collect any relevant information that could help diagnose the problem. What I got so far is some output from vmstat (system has been up for about 3hrs, most of that trying to make depend for amd64/GENERIC). I have no idea what I'm talking about, but should syscalls be over 174 million in 3 hrs? What about over 1 million interrupts? vmstat -i interrupt total rate irq0/clock2323579 198 irq0/ipi 659552 56 irq14/pciide098020 irq18/em075210 irq1/pckbc0 32740 Total 3003728 255 vmstat -s 4096 bytes per page 92994 pages managed 60024 pages free 12862 pages active 3646 pages inactive 0 pages being paged out 2 pages wired 0 pages zeroed 4 pages reserved for pagedaemon 6 pages reserved for kernel 131117 swap pages 0 swap pages in use 217870 total anon's in system 206486 free anon's 592955 page faults 625470 traps 14762 interrupts 177426 cpu context switches 17746 fpu context switches 1281121 software interrupts 174821427 syscalls 0 pagein operations 0 swap ins 0 swap outs 890 forks 9 forks where vmspace is shared 13 kernel map entries 0 number of times the pagedaemon woke up 0 revolutions of the clock hand 0 pages freed by pagedaemon 0 pages scanned by pagedaemon 0 pages reactivated by pagedaemon 0 busy pages found by pagedaemon 484013 total name lookups cache hits (87% pos + 9% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% 0 select collisions dmesg: OpenBSD 4.0-current (GENERIC.MP) #0: Tue Dec 12 19:00:05 PST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 401141760 (391740K) avail mem = 331026432 (323268K) using 9844 buffers containing 40321024 bytes (39376K) of memory mainbus0 (root) bios0 at mainbus0: SMBIOS rev. 2.31 @ 0xe0010 (45 entries) bios0: VMware, Inc. VMware Virtual Platform acpi at mainbus0 not configured mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual Core AMD Opteron(tm) Processor 265, 1985.19 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 66MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual Core AMD Opteron(tm) Processor 265, 1838.56 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative mpbios: bus 0 is type PCI mpbios: bus 1 is type PCI mpbios: bus 2 is type ISA ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins pci0 a
Re: OpenBSD/amd64 on VMware = sloooooow?
On Dec 12, 2006, at 11:46 PM, Brian Keefer wrote: OK, so just to be clear I'm not a terribly clever person. I have no idea what I should be looking for to diagnose this issue. It's entirely possible that I have something configured stupidly/wrong, etc or that the answer is right in front of me, but I wouldn't know. I've done a little googling and all I came up with was: http://archives.neohapsis.com/archives/openbsd/2005-11/1349.html which went completely un-answered (at least on-list). The OP and I conversed off-list a few weeks ago and he mentioned that the situation is still the same for him (same as I'm seeing). Summary: - 64bit host OS (SLES 9) running on 2 dual-core Opteron 265s - VMware Server 1.0.1 build 29996 - OpenBSD/i386 works fine - OpenBSD/amd64 is slow as hell - MP/UP kernel makes no difference - one CPU or two CPUs makes no difference I've tried 4.0-release, then a snapshot from a few weeks ago, now running with -current GENERIC.MP kernel (as of last night). That kernel took about 22 hours to build, BTW--that's slower than my SPARCstation 5. Right now it's churning away on make depend for GENERIC (UP) and it's been doing so for over 128 minutes. Does anyone have *any* idea why compiling would be so slow on this setup? Services respond fairly quickly (ssh, etc) but running make or cc takes ages. Usually the load is around 1.3 or so when building something, but on occasion it spikes to 16 or more for no apparent reason. I'd love to collect any relevant information that could help diagnose the problem. What I got so far is some output from vmstat (system has been up for about 3hrs, most of that trying to make depend for amd64/GENERIC). I have no idea what I'm talking about, but should syscalls be over 174 million in 3 hrs? What about over 1 million interrupts? vmstat -i interrupt total rate irq0/clock2323579 198 irq0/ipi 659552 56 irq14/pciide098020 irq18/em075210 irq1/pckbc0 32740 Total 3003728 255 vmstat -s 4096 bytes per page 92994 pages managed 60024 pages free 12862 pages active 3646 pages inactive 0 pages being paged out 2 pages wired 0 pages zeroed 4 pages reserved for pagedaemon 6 pages reserved for kernel 131117 swap pages 0 swap pages in use 217870 total anon's in system 206486 free anon's 592955 page faults 625470 traps 14762 interrupts 177426 cpu context switches 17746 fpu context switches 1281121 software interrupts 174821427 syscalls 0 pagein operations 0 swap ins 0 swap outs 890 forks 9 forks where vmspace is shared 13 kernel map entries 0 number of times the pagedaemon woke up 0 revolutions of the clock hand 0 pages freed by pagedaemon 0 pages scanned by pagedaemon 0 pages reactivated by pagedaemon 0 busy pages found by pagedaemon 484013 total name lookups cache hits (87% pos + 9% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% 0 select collisions dmesg: OpenBSD 4.0-current (GENERIC.MP) #0: Tue Dec 12 19:00:05 PST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 401141760 (391740K) avail mem = 331026432 (323268K) using 9844 buffers containing 40321024 bytes (39376K) of memory mainbus0 (root) bios0 at mainbus0: SMBIOS rev. 2.31 @ 0xe0010 (45 entries) bios0: VMware, Inc. VMware Virtual Platform acpi at mainbus0 not configured mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual Core AMD Opteron(tm) Processor 265, 1985.19 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3 6,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 66MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual Core AMD Opteron(tm) Processor 265, 1838.56 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3 6,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative mpbios: bus 0 is type P
OpenBSD on VMware fusion (dmesg) -- yes it works
nbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2600 @ 2.16GHz ("GenuineIntel" 686-class)
2.17 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH
,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3
mainbus0: bus 0 is type PCI
mainbus0: bus 1 is type PCI
mainbus0: bus 2 is type PCI
mainbus0: bus 3 is type ISA
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 64-sector PIO, LBA, 8192MB, 16777216 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:
SCSI0 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08:
SMBus disabled
vga1 at pci0 dev 15 function 0 "VMware Virtual SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
bha3 at pci0 dev 16 function 0 "BusLogic MultiMaster" rev 0x01: apic
2 int 17 (irq 11), BusLogic 9xxC SCSI
bha3: model BT-958, firmware 5.07B
bha3: sync, parity
scsibus1 at bha3: 8 targets
ppb1 at pci0 dev 17 function 0 vendor "VMware", unknown product
0x0790 rev 0x01
pci2 at ppb1 bus 2
pcn0 at pci2 dev 0 function 0 "AMD 79c970 PCnet-PCI" rev 0x10,
Am79c970A, rev 0: apic 2 int 18 (irq 9), address 00:0c:29:c9:d7:96
eap0 at pci2 dev 1 function 0 "Ensoniq AudioPCI97" rev 0x02: apic 2
int 19 (irq 10)
ac97: codec id 0x43525913 (Cirrus Logic CS4297A rev 3)
audio0 at eap0
midi0 at eap0:
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi1 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask 0 netmask 0 ttymask 0
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
apm0: disconnected
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
cpu1: unknown Core FSB_FREQ value 0 (0x0)
Brian Keefer
www.Tumbleweed.com
"The Experts in Secure Internet Communication"
Re: OpenBSD on VMware fusion (dmesg) -- yes it works
On Dec 22, 2006, at 3:09 AM, Reyk Floeter wrote: On Fri, Dec 22, 2006 at 02:35:00AM -0800, Brian Keefer wrote: Not sure if anyone else has noticed, but VMware finally released Fusion for public beta. It's the port to Macintel. Only caveat so far is that Fusion wouldn't mount the OpenBSD CDs. I think it might have a problem mounting volumes that have spaces in the path. I downloaded cd40.iso and did an FTP install and that worked fine (NAT for networking, choose dhcp during the install since it doesn't have any way that I could find to configure vmnet). Here're the dmesg's from RAMDISK_CD and GENERIC.MP on a MBP 15" CoreDuo 2.16GHz: can you try 4.0-current (or a recent snapshot)? it should use the new vic(4) driver instead of pcn(4). I added Ethernet0.virtualDev to "vmxnet" (wasn't present by default) and this is what I got with the latest i386 snap: vic0 at pci2 dev 0 function 0 "VMware Virtual NIC" rev 0x10: apic 2 int 18 (irq 9) vic0: VMXnet 864F, address 00:0c:29:c9:d7:96 Boots fine, but when it searches for DHCP lease I get: vic0: no link . giving up I tried to ifconfig vic0 down ; ifconfig vic0 up, but it still didn't get a link. I tried "e1000" instead of "vmxnet" and em0 was able to get a link just fine. Any other options I should try? Here's the .vmx: config.version = "8" virtualHW.version = "6" numvcpus = "2" scsi0.present = "TRUE" memsize = "256" MemAllowAutoScaleDown = "FALSE" ide0:0.present = "TRUE" ide0:0.fileName = "OpenBSD.vmdk" ide1:0.present = "TRUE" ide1:0.fileName = "/Users/chort/scratch/cd40.iso" ide1:0.deviceType = "cdrom-image" floppy0.present = "FALSE" ethernet0.present = "TRUE" ethernet0.connectionType = "nat" ethernet0.wakeOnPcktRcv = "FALSE" sound.present = "TRUE" sound.fileName = "-1" sound.autodetect = "TRUE" pciBridge0.present = "TRUE" isolation.tools.hgfs.disable = "TRUE" displayName = "OpenBSD" guestOS = "other" nvram = "OpenBSD.nvram" deploymentPlatform = "windows" virtualHW.productCompatibility = "hosted" RemoteDisplay.vnc.port = "0" tools.upgrade.policy = "useGlobal" powerType.powerOff = "soft" powerType.powerOn = "soft" powerType.suspend = "soft" powerType.reset = "soft" ethernet0.addressType = "generated" uuid.location = "56 4d b4 c8 87 f5 fa 58-c7 59 8e d7 8b c9 d7 96" uuid.bios = "56 4d b4 c8 87 f5 fa 58-c7 59 8e d7 8b c9 d7 96" ide0:0.redo = "" pciBridge0.pciSlotNumber = "17" scsi0.pciSlotNumber = "16" ethernet0.pciSlotNumber = "32" sound.pciSlotNumber = "33" vmi.pciSlotNumber = "34" ethernet0.generatedAddress = "00:0c:29:c9:d7:96" ethernet0.generatedAddressOffset = "0" tools.remindInstall = "TRUE" Ethernet0.virtualDev = "vmxnet" checkpoint.vmState = "" Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: OpenBSD on VMware fusion (dmesg) -- yes it works
On Dec 22, 2006, at 5:15 AM, Reyk Floeter wrote: On Fri, Dec 22, 2006 at 03:59:10AM -0800, Brian Keefer wrote: Here're the dmesg's from RAMDISK_CD and GENERIC.MP on a MBP 15" CoreDuo 2.16GHz: can you try 4.0-current (or a recent snapshot)? it should use the new vic(4) driver instead of pcn(4). I added Ethernet0.virtualDev to "vmxnet" (wasn't present by default) and this is what I got with the latest i386 snap: vic0 at pci2 dev 0 function 0 "VMware Virtual NIC" rev 0x10: apic 2 int 18 (irq 9) vic0: VMXnet 864F, address 00:0c:29:c9:d7:96 Boots fine, but when it searches for DHCP lease I get: vic0: no link . giving up hmmm, can you try it with GENERIC (without MP)? It didn't make a difference. I tried commenting out the virtualDev setting to see which one it would detect if no device type was specified in the .vmx, and it went back to pcn. Jason, what does your .vmx look like? Oddly, I also found a statement: deploymentPlatform = "windows", which I found rather odd since I choose other/other for the OS and type. I comment that out, but it didn't change anything. Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: OpenBSD on VMware fusion (dmesg) -- yes it works
On Dec 22, 2006, at 10:26 AM, Jason Dixon wrote: On Dec 22, 2006, at 12:31 PM, Brian Keefer wrote: Jason, what does your .vmx look like? Oddly, I also found a statement: deploymentPlatform = "windows", which I found rather odd since I choose other/other for the OS and type. I comment that out, but it didn't change anything. config.version = "8" ... tools.remindInstall = "TRUE" -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net It's the same, other than the MAC addresses of course. I'm running e.x.p. 36932, but I don't figure they did another in the 3 hours between when I downloaded it and when you posted. So the only difference we know of is that you have a Core Duo2-based system? Which version of OS X? I'm on 10.4.8 with all the patches (including EFI firmware update), except for the most recent Quartz & QuickTime security patch. It's strange that when you boot -current it loads vic w/o having to specify vmxnet as your dev, but when I boot the snapshot from 21st it loads pcn unless I specifically change the dev to vmxnet, then it's vic, but it has no link. Maybe I should cvsup and build from source? Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Poor performance with gem(4)? (reposted from ppc@)
(sorry for the repost, I guess there aren't many eyes on ppc@) Has anyone else noticed extremely poor performance with gem(4) devices, particularly on the Mac Mini G4? dmesg is below, but the summary is that I have a gem(4), and after finally being fed up with the poor performance I plugged in an old axe (4) that I had lying around: gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address 00:0d:93:60:bd:36 bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4 axe0 at uhub5 port 2 configuration 1 interface 0 axe0: Linksys USB 2.0 10/100 ethernet controller, rev 2.00/0.01, addr 2, AX88172, address 00:10:60:25:d0:17 rlphy0 at axe0 phy 3: RTL8201L 10/100 PHY, rev. 1 Using scp(1) on the local network I was seeing about 100KB/s transfer rates (according to scp(1)). I was also noticing that large images were taking a long time to load on the websites I am serving off this machine, even for machines directly connected to the same 100baseTX switch. I ruled out the hard drive as the performance problem by doing several scp operations to /dev/null. The transfer rate was exactly the same. I also noticed that if I had a long-running scp transfer that responses to keyboard input were sluggish, both on the directly attached keyboard & mouse, and through ssh sessions. So I plugged in the axe(4) and repeated the tests, and I was getting 2MB/s - 4MB/s. Still terrible, but much better than the built-in gem (4). All images on the website load *immediately* now, very, very noticeably faster than previous. There is also no sluggishness when the network is busy. Are there any known problems with gem(4) on Macs, or is this likely a case of bad hardware? The cable and switch are both fine. I'm using the same connections with the axe(4) and it's working fine (although at expected USB speeds). [ using 357352 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A]console in [keyboard] USB found using parent ATY,RockHopper2Paren:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: memtag 8000, iotag 8000: width 640 linebytes 768 height 480 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2006 OpenBSD. All rights reserved. http:// www.OpenBSD.org OpenBSD 4.0-stable (GENERIC) #0: Fri Nov 10 15:06:55 PST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 268435456 (262144K) avail mem = 235343872 (229828K) using 1254 buffers containing 13418496 bytes (13104K) of memory mainbus0 (root): model PowerMac10,1 cpu0 at mainbus0: 7447A (Revision 0x102): 1416 MHz: 512KB L2 cache memc0 at mainbus0: uni-n "hw-clock" at memc0 not configured ki2c0 at memc0 offset 0xf8001000 iic0 at ki2c0 mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 vgafb0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01, mmio wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x5 pci1 at mpcpcibr1 bus 0 pchb1 at pci1 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 macgpio0 at macobio0 offset 0x50 "modem-reset" at macgpio0 offset 0x1d not configured "modem-power" at macgpio0 offset 0x1c not configured macgpio1 at macgpio0 offset 0x9 irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zsc0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zsc0 channel 0 zstty1 at zsc0 channel 1 aoa0 at macobio0 offset 0x1: irq 30,1,2 audio0 at aoa0 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets apm0 at adb0: battery flags 0x0, 0% charged pi2c0 at adb0 iic1 at pi2c0 maxtmp0 at iic1 addr 0xc8: max6642 ki2c1 at macobio0 offset 0x18000 iic2 at ki2c1 wdc0 at macobio0 offset 0x2 irq 24: DMA ohci0 at pci1 dev 24 function 0 "Apple Intrepid USB" rev 0x00: irq 0, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: Apple OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1 at pci1 dev 25 function 0 "Apple Intrepid USB" rev 0x00: irq 0, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: Apple OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ohci2 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support usb2 at ohci2: USB revision 1.0 uhub2 at usb2 uhub2: Apple OHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ohci3 at pc
Re: Poor performance with gem(4)? (reposted from ppc@)
On Jan 21, 2007, at 6:36 AM, Mark Kettenis wrote: Getting quite decent performance on my Mac mini G4: gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address 00:0d:93:60:dd:1a bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4 With an msk(4) at the other end and a decent gigabit switch in between, iperf tells me I'm getting 92 Mbit/s in one direction and 85 Mbit/s in the other. OK, thanks for the feedback! I guess I must just have bad hardware, or it's something in the switch that doesn't get along well with gem (4) devices (it's a cheap TRENDnet TE100-S8P switch). The axe(4) has been working flawlessly, so at least I have a work-around. -- bk
Re: OT:
On Jan 21, 2007, at 5:30 AM, Tautvydas wrote: Hey List, Little off topic, but I need some help. For a week I'm working in a small company. (~250 workstations). Till 2008 there will be 400-600 workstations. So, they are planning to buy something for spam/mail filtering (http://www.barracudanetworks.com/ns/products/ spam_overview.php). I think the best would be to use openbsd+pf+spamd (with carp if necessary). But - I have quite stupid CEO and I need many arguments, why blackbox for many $$$ is bad (from corporate view). Please, help me with these arguments. Thanks. Regards, Tautvydas -- Hi, I'm a .signature virus! Copy me to your .signature file and help me propagate, thanks! Whether or not buying and off-the-shelf solution is better than building one in-house entirely depends on the relative cost of each solution. Off-the-shelf tends to cost more to acquire, but usually costs less in administration. Most of the cost of any software usually isn't what it costs up-front to purchase it, but rather what it costs to maintain it--how much do you have to pay people to make sure it keeps working and that you can upgrade it in the future? If someone very clever builds something from scratch, but then leaves, who is going to keep it running? How much do they need to pay to retain someone who understands the home-grown solution, vs. how much would they need to pay someone to just click buttons? How many hours will it take to maintain a home-grown solution vs. just clicking buttons? When there's a problem, how long will it take the staff to fix it vs. just calling tech support for the company you bought software from off-the-shelf? There's a lot more to cost than just the initial price tag, and the value in terms of cost-savings in other areas is something else to consider--would a commercial product block more malware, have less false-positives, be able to comply with government regulations, etc? Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: OT: Getting a premade box or doing it yourself (was "OT:")
On Jan 21, 2007, at 12:33 PM, bofh wrote: Which I don't understand - if you're going to sell a blackboz, why not use openbsd instead of some stinky redcrap or that piece of shit rhell? Centos is just an enabler, tyvm. On 1/21/07, Henning Brauer <[EMAIL PROTECTED]> wrote: * Tautvydas <[EMAIL PROTECTED]> [2007-01-21 20:33]: > What I know now - barracuda is a blackbox. I've read that there is > "simple web interface". IMHO, it sounds not very good at all. the barracuda boxes are rusty stinky old redhat with spamassassin and some web interface. at least, they used to be about a year or two ago -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam Because driver support for Linux is a lot better than for OpenBSD, and a lot of the Anti-Virus vendors supply Linux binaries, but no BSD binaries. Also, developers for Linux are cheaper (and more plentiful) than developers for BSD. The company I worked for considered switching our appliance OS to a *BSD from Linux, but in the end we decided that commercial support was too important to ignore. If you were building a firewall/proxy type of appliance, OpenBSD would probably be fine (actually preferable, since Netfilter/iptables is crap). If you're building something that needs to use a lot of third-party commercial software in addition to your own code, sadly Linux is currently a better choice. I personally cannot stand Linux, but even I consider Linux a safer choice for an embedded OS right now (safer as in: you won't have to struggle for weeks to get your software to even run on it). Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: OT: Getting a premade box or doing it yourself (was "OT:")
On Jan 21, 2007, at 4:34 PM, bofh wrote: On 1/21/07, Brian Keefer <[EMAIL PROTECTED]> wrote: Because driver support for Linux is a lot better than for OpenBSD, I'm not sure if I believe this to be as strong an argument since, as the blackbox maker, you have your choice of hardware. This means you can choose hardware that runs openbsd without issues, unless you need the most cuttng edge hardware. We have two of your Edge boxes at work, and from what I can see, you can get that, or equivalent hardware running openbsd without problems. It depends what hardware. We *could* find hardware that runs with whatever OS we choose, but the OS then dictates the hardware and we wouldn't be able to change easily. We rev our hardware from time to time and usually jump to something fairly recent and with a fair amount of embedded chips (we try to use what's already on the motherboard as much as possible). Using *BSD would lock us down to only chipsets that don't depend on blobs. Yes, we know blobs are bad but we're also trying to get hardware rev'd as quickly as possible with minimal amounts of tweaking. If we ever need to say, switch RAID controllers quickly because of shortages, or our motherboard supplier swaps in a new model with embedded 10GigE NICs or something like that, chances are there won't be an open-spec driver, but there will probably be a binary from the manufacturer pre-compiled for Linux. and a lot of the Anti-Virus vendors supply Linux binaries, but no BSD binaries. Now, this, I believe. But many of the smaller vendors have binaries for freebsd, and I'm also quite sure someone the size of Tumbleweed can get binaries for whatever platform you guys want. Maybe not as easily. I might be wrong too :) Ask CipherTrust (well, SecureComputing now) how they run their AV engines. IronMail is based on FreeBSD and uses Linux binary compatibility for their AV engines--I know this for a fact, because I worked for them. Most of my recommendation for sticking with Linux was due to my experience at CipherTrust. Messaging security companies might make 50-100M a year, but that's scratch to Symmantec, McAfee, Trend, etc. They're multi-billion dollar companies from direct AV sales alone. They don't *need* e- mail security companies for revenue. If they have something off the shelf, sure they'll sell it... they're not going to do a new build just for a single vendor (and if they would, they'd pass the cost on to us which would kill margins). Also, developers for Linux are cheaper (and more plentiful) than developers for BSD. This, I have to disagree with. Are you talking about kernel hackers? If so, I'd think they cost about the same. If you're talking about application developers, what really is the difference between someone who writes an application in openbsd, versus one who writes it in solaris or aix or linux?! And if you believe in java, openbsd 4.0 runs jdk 1.5 :) We do some limited kernel work, mostly around file system debugging. When you have something that causes the I/O loads of a high-end e- mail relay, you really rely on the file system a lot and interesting things happen when it goes wrong. The rest of it is user-land stuff, but we (and many companies like us) leverage Java heavily. We've found that performance-tuning Java can make a big difference for various things (mostly our other products, not so much for e-mail) so running it on a platform where a lot of other companies are doing the same thing gives us a shared pool of experience to tap into. Never underestimate the power of a few snippets of example code found through Google. Could we run Java and PHP on OpenBSD? Sure. The setup just wouldn't be quite the same and developers would have to relearn things. Also, as much as Sun would like us to believe that it works the same everywhere, that's just not true. There are platform-specific quirks and if developers already have a background with the quirks on Linux, it helps. The company I worked for considered switching our appliance OS to a *BSD from Linux, but in the end we decided that commercial support was too important to ignore. "Commercial support from large vendors?" Probably so. And I have no idea how good is the commercial support from the smaller vendors listed on openbsd's site either. Mostly on the hardware side. It's a lot easier to get a binary driver for Linux for some brand-new hardware than it is to get a source driver for *BSD. Other than the hardware, we actually get commercial support and can open bugs with our Linux supplier. It's not really a question of how technically competent the support is from OpenBSD consultants, it has a lot more to do with how available the support is, how likely it is that the support
Re: OT: Getting a premade box or doing it yourself (was "OT:")
On Jan 21, 2007, at 8:00 PM, L. V. Lammert wrote: On Sun, 21 Jan 2007, Brian Keefer wrote: The company I worked for considered switching our appliance OS to a *BSD from Linux, but in the end we decided that commercial support was too important to ignore. There ARE a number of vendors selling OBSD solutions, actually. One I remember running across is LOK Technologies. Drivers should NOT be an issue - you're building an appliance, it should be pretty simple to picl compatible s/w. Lee It's not to say there aren't vendors out there using non-Linux platforms for their appliances. I mentioned CipherTrust, but they also ran into some OS-specific issues when dealing with their DB vendor... IronPort is also based on FreeBSD, but their choice of AV engines is apparently pretty restricted. Why else would they still only have Sophos after all these years, while every other e-mail appliance vendor has multiple AV choices? My guess is they can't use Linux binary compatibility because of the extent they've hacked their kernel and FS. Maybe that's not true, but you have to wonder why they don't have McAfee or Kaspersky or Panda, etc. Borderware also uses a FreeBSD based platform, but they're a little different because they started with that for their firewall product (a reasonable choice) and extended it to e-mail later when they built a product for that. I might also point out that it took over 4 major revisions of their e-mail software to get it anywhere near stable on top of their OS. As for the drivers... like I said, it restricts options. Our entry- level box at one point had a built-in RAID controller that was one of those pseudo-hardware controllers that was really run by a binary blob. That wouldn't have worked on OpenBSD. The motherboards we currently use have built-in nForce ethernet chips, which only became supported in 3.9. We use them for secondary/tertiary interfaces (it's basically a "free" feature that customers get). Our other options would be to select a motherboard that didn't use "blob- dependent" chipsets, or put riser cards and separate PCI cards in, or just simply ship with less features. That would either be more expense, or less value for our customers. It would also add time to our release cycle by having to test more hardware before we settle on a final design. It might seem like a small amount of time, but a few extra combinations means a few extra weeks of QA time, and possibly engineering would have to delay coding while waiting on the final hardware config, etc... QA is actually a lengthy process in appliance design, so any added complexity in the test matrix has a negative impact on projects very quickly. It's not to say it couldn't be done: It absolutely could be. It's just that it wouldn't be zero cost, and why would we do that unless we had to? There are lots of ways to do anything. In the end it depends what goal you're trying to achieve. If your goal is to use your favorite operating system for the project, that's certainly doable. If your goal is, hypothetically say, minimizing time to market while keeping a lid on engineering and QA costs, your OS selection might look a little different. It's just simply a matter of using the right tool for the right job. If you're trying to do heavy-duty packet filtering VPN end-points, or routing (where most of the code is leveraging built-in tools), a *BSD is probably a good choice. If you just need a platform to load a bunch of software on top of, some of which is third-party commercial stuff, *BSD is not going to be your best choice. As an aside, it seems like there are a fair number of us OpenBSD users here in Silicon Valley. Lots of us have been individually lobbying various hardware manufactures, most of which are headquartered in this area, to release documentation for their products. I think it might be more effective if we combine efforts and started pressing to get in-person meetings with folks in product marketing at some of these companies. If we could get 2 or 3 of us who are pretty well versed in the business side of technology to present well-reasoned arguments for why it would benefit these companies to have their hardware more widely supported, we might begin to see some cracks in the blob armor. Is anyone else local here interested in starting an unofficial lobbying group to put together some position points as to why hardware vendors should release documentation and start trying to schedule some meetings with vendors? Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: named and dns cache
On Jan 21, 2007, at 6:48 PM, riwanlky wrote:
Hi All,
I want all my windows client behind OpenBSD 3.9 firewall to query
dns from the firewall. In the OpenBSD 3.9 I run named. This is
my named.conf
acl clients {
localnets;
::1;
};
options {
version ""; // remove this to allow version queries
listen-on{ any; };
listen-on-v6 { any; };
allow-recursion { clients; };
};
All my windows client will set the preferred dns server to OpenBSD
3.9.
However when I tried using nslookup:
> pop3.pacific.net.id
Server: UnKnown
Address: 10.10.10.33
Name:pop3.pacific.net.id
Served by:
- ns.net.id
net.id
- ns1.id
net.id
- ns1.rad.net.id
202.154.1.2
net.id
- ns1.iptek.net.id
net.id
- ns2.cbn.net.id
net.id
it didn't give the windows the ip address of the domain request.
I need to go to the OpenBSD and then do
dig pop3.pacific.net.id
# dig pop3.pacific.net.id
; <<>> DiG 9.3.1 <<>> pop3.pacific.net.id
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24809
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;pop3.pacific.net.id. IN A
;; ANSWER SECTION:
pop3.pacific.net.id.1800IN A 203.123.254.34
;; AUTHORITY SECTION:
pacific.net.id. 1800IN NS nm1.pacific.net.id.
pacific.net.id. 1800IN NS nm2.pacific.net.id.
;; Query time: 68 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 22 09:47:34 2007
;; MSG SIZE rcvd: 89
and then using nslookup I could get the ip address.
> pop3.pacific.net.id
Server: UnKnown
Address: 10.10.10.33
Non-authoritative answer:
Name:pop3.pacific.net.id
Address: 203.123.254.34
My problem is that how do I cache the entry so that I will
always get the ip address.
Thank in advance for the assistance.
Best regards,
Riwan
It seems like whatever IP you're making that query from originally
isn't in "localnets" (hence, no recursion). Try manually adding your
subnets to the ACL, for instance 192.168.0.0/16; (or whatever your
internal network is).
Brian Keefer
www.Tumbleweed.com
"The Experts in Secure Internet Communication"
Re: Friendly registrar
On Jan 19, 2007, at 10:58 AM, Tonnerre LOMBARD wrote: We chose Gandi for controversial web sites (like ffii.org) because they tend not to shut down the delegation whenever they receive a preliminary injunction. For any kind of Open Source movement, this might become crucial in the future... Tonnerre In light of what happened Wednesday, does anyone else have any additional suggestions for non-US registrars that won't yank your delegation just because a major corporation told them to (it seems GoDaddy would rather dump their customers than anger a major corporation)? -- bk
Re: spamd unnecessarily abrasive?
On Feb 20, 2007, at 10:00 AM, Woodchuck wrote: On Tue, 20 Feb 2007, Peter N. M. Hansteen wrote: J Moore <[EMAIL PROTECTED]> writes: Isn't this a bit "over the top"? Well, people don't read these strings at all unless they're looking at spamd source code or doing a "telnet yourhost.tld smtp" for debugging purposes. The message you quote here is essentially just a preserved version of the telnet to smtp case. In their present form, don't these messages provide a clear fingerprint for the next generation of spamware to read and then heed? I suppose that problem can be dealt with when it occurs, probably faster than spammers can follow. Dave I was thinking the exact same thing. A number of our customers use the ability to customize their SMTP banner via our products in order to avoid some very basic system identification by spammers (Cisco PIX does this too for instance, but in a very broken and disruptive way). It wouldn't escape detailed analysis, but if a spammer can't casually discover what type of anti- spam system they're connecting to, they're less likely to attempt any work-arounds. In the case of a greylisting type of solution, it seems that identification would be especially devastating since the work-around is so trivial. Unless my understanding is very wrong, the whole effectiveness of the solution depends on the spammers not realizing the difference between a "normal" MTA and one that greylists. Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: spamd unnecessarily abrasive?
On Feb 20, 2007, at 11:54 AM, Theo de Raadt wrote: In the case of a greylisting type of solution, it seems that identification would be especially devastating since the work-around is so trivial. Unless my understanding is very wrong, the whole effectiveness of the solution depends on the spammers not realizing the difference between a "normal" MTA and one that greylists. If a spammer knows I am running spamd because he can detect it, and then disconnects, no spam makes it througg -- no spam is delivered. There is no workaround for the spammer, except to act as a regular "follow the RFC, and retry", which most of the spammers don't do (and which we want them to do, since then they are easier to fight). In fact, there are spammers who ARE noticing that greylisting servers look (or behave) different, and they are disconnecting and not sending spam through them. Thus, no spam is delivered. But you don't get it, do you? Stopping spam from being delivered is the reason for doing all this in the first place! You have it entirely backwards. I think you had better book yourself into a course on logical thinking. To clarify a bit, I was referring to the greylisting portion. If the spammer attempts their delivery again, they're considered "proper MTA" and therefor "not a spammer", correct? True, once they're going to spamd it's too late (I guess this is the case if an DNSBL is being used to just skip the whole greylisting step?). I haven't looked at the implementation in OpenBSD extensively, but at a basic level there are two portions, the greylist function, and the "waste their time" function, yes? I'm talking about bypassing the first, not the second. Even in the second case, if the spammer notices they're connecting to something that will waste their (bot's) time, they can simply disconnect and use the bot's resources to do something else. Not the the spammers really care about wasting resources *that* much since they don't have to pay for them (or very little for a bot herd compared to "bulletproof hosting"), but it could make them a little more efficient. The history of fighting spam has tended to show that if any form of combating spam becomes too effective (and wide-spread), spammers will invest effort figuring out how to defeat it. Brian Keefer www.Tumbleweed.com "The Experts in Secure Internet Communication"
Re: spamd unnecessarily abrasive?
On Feb 20, 2007, at 12:36 PM, Darren Spruell wrote: On 2/20/07, Brian Keefer <[EMAIL PROTECTED]> wrote: In the case of a greylisting type of solution, it seems that identification would be especially devastating since the work-around is so trivial. Unless my understanding is very wrong, the whole effectiveness of the solution depends on the spammers not realizing the difference between a "normal" MTA and one that greylists. The reason that greylisting has been effective is because spammers apparently don't waste resources on maintaining queues and attempting redelivery later. Why worry about redelivery to 500 temporarily failed recipients when in the same time and processor cycles you can delivery to 500,000 more mailboxes? Historically true, but the tighter anti-spam defenses become, the more it's worth it to put a little extra effort into reaching "defended" mailboxes. Also, if the spammers can figure out the difference between an error because a mailbox is full, user doesn't exist, etc and the fact that they're talking to a greylisting daemon, it's worth it to make the effort if they can bypass a spam filter, where as it's really not worth retrying of a user's mailbox is full or they don't exist. Whether it's worth retrying depends on why the original delivery attempt failed. Right now it's probably still not worth doing, since there are so few greylisting systems deployed. Eventually it might be worth it. It (in practice, apparently) matters not to the spammer if they've got an antispam measure returning a 45x error or a legitimate MTA. If you were a spammer, and thought that working around 450s from spamd was worth wasting resources on to reattempt delivery, why wouldn't you just reattempt delivery on any temporary error under the hopes that it will succeed? See above. By definition a temporary error will go away at some point if you reattempt delivery. Depends what the error was. For every point that someone has brought up against greylisting (from since it was originally proposed by Harris in 2003), it continues to work effectively. So while people adopts this sky-is-falling-spammers-will-figure-it-out-soon mentality, the numbers don't lie. Greylisting has been, still is, and will continue to be for some time at least an effective measure. This is the part where I believe I'm being misunderstood. I'm not saying that greylisting is necessarily bad, and I'm not saying that it's ineffective. What I am saying is that I think it could be even more effective if it was more difficult for spammers to recognize a difference between unprotected and protected systems. How spammers are behaving right now doesn't necessarily predict how they're always going to behave. A particular technique for fighting spam has to be pretty wide-spread before spammers will spend the time to figure out the flaws. I've worked in e-mail for about 8 years, starting with a hosting company that had millions of e-mail boxes and hundreds of thousands of domains, then two different e-mail security companies. The one thing I've noticed is that no one method of fighting spam is a panacea. Originally when "Beysian filtering" was proposed, it was supposed to be the Final Ultimate Solution for Spam and everyone was gushing on all the usenet groups and mailing lists about how great it was and how they never got a single piece of spam any more. A lot of commercial solutions rushed to include Beysian-based techniques, but eventually spammers overwhelmed it and you don't hear much about it any more since it's just not effective as spam evolved. Recently spammers have taken to sending "image based spam". I'm sure anyone who follows spammers is familiar with it, but it's pretty sophisticate and is pretty successful at evading OCR-based systems. Any way, the point is that nothing is perfect and, in my experience, you have to keep evolving the techniques to stop spam as the spammers evolve their techniques to avoid being blocked. Obviously in the case of greylisting and spamd, the goal is to avoid being put on the blacklist in the first place, and one way to do that would be resending to avoid being assumed a spammer. When I first started fighting spam, all the spammers had to pay for their rackspace, DNS hosting, bandwidth, etc and usually they had to pay above average prices because of all the headaches they caused for their providers. Now they've evolved to using botnets and the vast majority of spam comes from such systems, so the bandwidth costs are gone and the hosting costs are pretty much limited to how much they have to pay the criminals for the botnet C&C passwords. It's not a matter of cost any more, it's a matter o
Re: pf log question
Make sure you're setting a state.
I had the same problem with gmail, and then I realized that I had
accidentally preempted the rule which was setting state on my DMZ
interface. Once I fixed that I didn't have any more problems.
--
chort
On Jun 24, 2008, at 10:56 AM, Monah Baki wrote:
Thanks all for all the help.
Reason I was asking is I have this strange issue.
First my pf.conf (sniped) is:
+
int_if="xl0"
ext_if="xl1"
external_addr="tun0"
tcp_services = "{ 22, 25, 53, 80, 110, 143, 443, 554, 6667, 1220,
1863, \
3128, 5060, 5061, 5190, 6667, 8000, 8021, 8080, 8085, 9090, 1 }"
udp_services = "{ 53, 113 }"
set loginterface $external_addr
set loginterface $ext_if
# set block-policy drop
scrub in all
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
pass quick on lo0 all
block in log
pass out keep state
antispoof quick for { lo $int_if }
pass out quick on $int_if proto tcp from any to $mail_srvr port 25
pass log quick on $external_addr
pass quick on $ext_if
++
If I change "pass log quick on $external_addr" to "pass in log
quick on
$external_addr from any to any port $tcp_services", I can no longer
receive email from certain domains (gmail.com, guru.com and
customers).
However I can receive email from my work and from hotmail. When I
issue
the tcpdump -i pflog, I do not see any (block), but I do not
receive the
mails at all.
Couple of days, google responds with:
"timeout after EHLO from yw-out-1718.google.com[74.125.46.157]"
and "timeout after EHLO from mail3.guru.com[216.151.125.108]"
If I switch back to "pass log quick on $external_addr" everything
works.
I'm using OpenBSD3.9 with PPPoE.
On Tue, Jun 24, 2008 at 11:06:04AM -0400, Monah Baki wrote:
| Hi all,
|
| Using tcpdump -i pflog0
|
| Jun 24 10:54:01.209701 rule 14/(match) pass in on tun0
|
| Is there a way to display what's rule 14?
BSD Networking, Microsoft Notworking
Re: PF and Binat
On Jul 14, 2008, at 10:28 PM, Parvinder Bhasin wrote: On Jul 14, 2008, at 10:00 PM, Ryan McBride wrote: On Mon, Jul 14, 2008 at 09:48:22PM -0700, Parvinder Bhasin wrote: what gives? Oh, I missed this before: pass in on $ext_if proto tcp from any to 75.36.44.22 port 80 pass in on $ext_if proto tcp from any to 75.36.44.23 port 25 Filtering happens AFTER translation, so you need to filter on the real addresses of the hosts, not the alias addresses. Hmm by real ip do you mean internal ips of the servers?? Yes. -- bk
Re: BIND and file descriptors
On Aug 11, 2008, at 8:34 AM, Steve Shockley wrote: Is anyone having issues between patched BIND and running out of file descriptors? If you run a nameserver that has any kind of significant traffic at all, I suggest you subscribe to [EMAIL PROTECTED] . There have been many discussions on these issues over the last several weeks. The normal caveat applies of course: OpenBSD named is not stock BIND, but it'll point you in the right direction. Brian Keefer Sr. Systems Engineer www.Proofpoint.com "Defend email. Protect data."
Re: Postfix race condition at boot
On Jul 20, 2008, at 1:48 AM, Uwe Dippel wrote: On Mon, 14 Jul 2008 12:47:40 -0500, Karl O. Pinc wrote: I've an OpenBSD box that's been running postfix for a few years, strictly as a "send-only" mta, and every night the box gets rebooted. Every couple of months postfix does not come up on reboot. All that shows up in the logs is: postfix/postfix-script[3005]: fatal: Postfix integrity check failed! Solution? Remove the sendmail-flags from rc.conf.local and put a 'postfix start' at the end of rc.local. That should help. Uwe I just saw the same thing after upgrading my Mac Mini G4 from 4.0 to 4.4-current and upgrading Postfix to 2.6.20080726. I have the sasl2 flavor installed, so perhaps it's a problem with that, as mentioned later in this thread? At your suggestion, I changed sendmail_flags to "NO" in /etc/ rc.conf.local and simply added a /usr/local/sbin/postfix start to/etc/ rc.local . All working fine now... -- bk
Re: Can one dd to /dev/rwd0c?
On Sep 20, 2008, at 10:02 PM, Sunnz wrote: OK I am trying to completely erase the data of a hard disk so I though I can just do `dd if=/dev/arandom of=/dev/rwd0c` as to my understanding that is the entire hard disk (slice c) of wd0 in 'raw' mode? But that dd refuse to do it. This is running off a OpenBSD 4.3 CD Coincidentally I just noticed this thread this afternoon as I was doing the exact same thing to a box at work. I booted a Sunfire V120 off a 4.4 snapshot CD and dd if=/dev/zero of=/ rsd0 was humming along quite nicely when I left this evening. -- bk
Re: Can one dd to /dev/rwd0c?
On Sep 23, 2008, at 8:49 PM, Ted Unangst wrote: On Tue, Sep 23, 2008 at 11:28 PM, Brian Keefer <[EMAIL PROTECTED]> wrote: I booted a Sunfire V120 off a 4.4 snapshot CD and dd if=/dev/zero of=/rsd0 was humming along quite nicely when I left this evening. You may want to go back and fix both your typos. That's what I get for not copying & pasting from the terminal. /sigh Of course it's dd if=/dev/zero of=/dev/rsd0c -- bk
Re: Can one dd to /dev/rwd0c?
On Sep 23, 2008, at 11:17 PM, Brian Keefer wrote: On Sep 23, 2008, at 8:49 PM, Ted Unangst wrote: On Tue, Sep 23, 2008 at 11:28 PM, Brian Keefer <[EMAIL PROTECTED]> wrote: I booted a Sunfire V120 off a 4.4 snapshot CD and dd if=/dev/zero of=/rsd0 was humming along quite nicely when I left this evening. You may want to go back and fix both your typos. That's what I get for not copying & pasting from the terminal. /sigh Of course it's dd if=/dev/zero of=/dev/rsd0c -- bk Final addendum: copying with the default block size was going to take about 90 hours on a 36GB SCSI disk. I added bs=10m and it finished in 70 minutes. -- bk
Re: New tcp stack attack
On Oct 1, 2008, at 11:11 AM, Peter J. Philipp wrote: Fernando Gont wrote: If the discoverers of this bug don't make their sockstress available to OpenBSD then I have a userland TCP/IP stack for OpenBSD developers (mail me), but it's only written to be a server, but I suspect it would be easy to make it a client, just have to dust it off from my CVS as it's quite old (2004 possibly). I haven't checked yet, but isn't it included with Unicornscan (www.unicornscan.org), the TCP/IP stack at least? They originally released this back in 2004 and tried to demo it at Toorcon 2004, but never quite got it working at that time. They said it compiled on OpenBSD then, but needed some testing and a maintainer. I've tried to look for it since then and this is the first I've seen it resurface. -- bk
Re: correct HELO behaviour in SMTP connections
On Mar 25, 2009, at 8:14 AM, frantisek holop wrote: hmm, on Wed, Mar 25, 2009 at 03:40:09PM +0100, Gilles Chehade said that Are you sure ? just because you demonstrated a smtp session with a questionably set up mail server it doesn't mean you are right. sendmail by default does not check helo. /etc/postfix/main.cf: smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_hostname reject_unknown_hostname reject_non_fqdn_hostname these settings save any server a ton of work by not allowing made up and incorrect helo's, one of the most reliable sign of spam and clueless admins in general. The amount of connections rejected by those settings will be pretty small as a percentage, and it's not even close to "reliable sign of spam". There are way more clueless admins than clued, but unfortunately a lot of them send completely legitimate mail. How do I know? I've worked at e-mail hosting and/or e-mail security companies for the last 10 years. You're wrong. -- bk
Re: correct HELO behaviour in SMTP connections
On Mar 25, 2009, at 9:41 AM, frantisek holop wrote: of course its true downside (just like greyfiltering's) is that it needs a considerable amount of babysitting. but it's worth it for me. So basically, it's not reliable and any "work saved" from the MTA is doubled by humans. You're failing to convince me this is a good idea. -- bk
Re: OpenBSD mta with postfix
On Mar 27, 2009, at 12:46 PM, John Brooks wrote: Their response: ... "my understanding of the security policy is not to acknowledge mistakes in email addresses as a best practice defense against phishing and other types of email delivered attacks." Anybody run into this kind of logic before? -- John Brooks j...@day-light.com It's somewhat common, and preferable to issuing 5xx _if_ you have no built-in DHA* protection. Most modern e-mail security products do have anti-DHA features though, in which case it's much better to issue the 5xx. *Directory Harvesting Attack. -- bk
Re: antispam common practice for dealing with removed users
On Apr 8, 2009, at 7:27 AM, Jose Fragoso wrote: The user account is open. The user starts to opt-in some mailing lists. He is added to some others with opt-out policy. Sometime later, the user is removed before he opts-out of the list he (was) subscribed. ... I would like to hear from members of the list how they are dealing with this sort of situation. If you don't need to read the mail going to that account (i.e. not a sales person or someone who had direct relationship with a vendor, etc) then just return a 5xx error in session for attempted deliveries to that user. Removed users don't make good spamtraps. Users who never existed though, can often be useful. -- bk
4.4 in California, USA
The t-shirt looks great. Thanks to everyone involved for another great release! -- bk
Recommend hardware for video surveillance system?
I'm finally getting around to starting my project to build a home- monitoring system. I'm going to need multiple capture devices inside the home, and at least one outside as well. I'm looking for recommendations on a video capture card, and wireless video cameras. I don't mind spending > $100 US per cam if it's worth it. Also, any software recommendations would be appreciated. I've searched the archives, and it looks like a few other people have started similar projects, but there aren't too many details about what anyone did. I'm planning on keeping track of the steps and hopefully documenting things well enough to submit to undeadly, assuming the project is a success. Thanks in advance for any suggestions. -- bk
Re: Recommend hardware for video surveillance system?
On Nov 1, 2008, at 10:21 PM, Duncan Patton a Campbell wrote: On Fri, 31 Oct 2008 20:28:34 -0700 Brian Keefer <[EMAIL PROTECTED]> wrote: I'm finally getting around to starting my project to build a home- monitoring system. I'm going to need multiple capture devices inside the home, and at least one outside as well. I'm looking for recommendations on a video capture card, and wireless video cameras. I don't mind spending > $100 US per cam if it's worth it. Unless you have a good reason not to, use "WebCams" that implement an http(s) server on camera. The use of a standard protocol makes life much easier. Dhu I was under the impression that the quality would be bad and/or they would require a proprietary client application that only runs on Windows, etc... Am I mistaken? If the cam has it's own webserver, is it simply serving static frames ever x seconds, or streams video as well? Sorry for the basic questions, but I hadn't even considered that approach. I was planning on using bktr(4) with capture cards and cameras with coax/rca/s-video out. -- bk
Re: Recommend hardware for video surveillance system?
On Nov 2, 2008, at 6:52 AM, Stuart Henderson wrote: On 2008-11-02, Brian Keefer <[EMAIL PROTECTED]> wrote: On Nov 1, 2008, at 10:21 PM, Duncan Patton a Campbell wrote: Unless you have a good reason not to, use "WebCams" that implement an http(s) server on camera. The use of a standard protocol makes life much easier. Dhu I was under the impression that the quality would be bad and/or they would require a proprietary client application that only runs on Windows, etc... Am I mistaken? If the cam has it's own webserver, is it simply serving static frames ever x seconds, or streams video as well? look at the Axis cameras. Sorry for the basic questions, but I hadn't even considered that approach. I was planning on using bktr(4) with capture cards and cameras with coax/rca/s-video out. that may also be possible, but afaik it's mostly used for watching tv, at least the manual page doesn't talk about the multi-input cards you'd probably want to use. Thanks for the tips! Hopefully I'll have something useful to report soon(tm). -- bk
Re: dhcpd problem on OpenBSD 4.4 with release / renew
On Nov 11, 2008, at 2:01 PM, Administrator wrote: Brian Keefer wrote: On Nov 11, 2008, at 12:42 PM, Administrator wrote: Nope, didn't help. There must be some other mistery. Now it stops at DHCPOFFER part. DHCPDISCOVER from 00:50:18:48:cb:3d via vlan51 DHCPOFFER on 192.168.51.3 to 00:50:18:48:cb:3d via vlan51 DHCPDISCOVER from 00:50:18:48:cb:3d via vlan51 DHCPOFFER on 192.168.51.3 to 00:50:18:48:cb:3d via vlan51 Any ideas? Do you have the ability to test on -current? You might try that. Also definitely post a follow-up to Misc@ and Cc: [EMAIL PROTECTED] to see if he has any ideas. I'm not a DHCP guru, unfortunately. He's probably going to need some tcpdump samples to see what options are getting passed. This is what was requested last time: please include "tcpdump -eni -Xvvs port 67 or port 68" Ok, I will try -current tomorrow. Do I have to recompile world or just dhcpd? Will this be enough? # cd /usr/src/usr.sbin/dhcpd # make obj && make && make install For -current you should install a snapshot and go from there. I believe you can't just update dhcpd because there have been library changes. Hopefully you have a box you can test on. I tend to use VMs for this kind of thing. -- bk
Re: sunfire v100 hardware
On Nov 24, 2008, at 9:32 AM, K H A I wrote: Hello, I receive sunfire V100 hardware wifh 512K RAM , IDE cdrom without hard disk. Does any one know it support regular ide hard drive? what bsd architecture support it? is it sparc 64 or sun ? if any one has experience helps to make it work is greatly appreciated since i have no ideas. Cheers, KD I have a Sunfire V120 sitting next to my desk here. I haven't got around to installing OpenBSD on the hard drive yet, but I did boot off the 4.4 CD to zero out the drive. The architecture is sparc64, and (on the v120 at least) the storage is SCSI, not IDE. All the crucial devices appeared to be supported by the ramdisk kernel. -- bk
vic(4) problems with Dec 11th snap
Has anyone else had problems with vic(4) in the Dec 11th i386 snap? I
have a guest on ESXi 3.5 that I upgraded from 4.3 to 4.4-release and
it was working fine, but then I upgraded to the latest i386 snap and I
no longer saw any traffic to/from the guest when viewing tcpdump, even
on other guest VMs on the same host. To clarify I only saw outgoing
ARP requests (from the guest itself), no incoming traffic what so
ever. No ARP replies, no broadcast, nothing... none of the other
guests saw the outbound traffic.
Disabling ACPI made no difference (was the only thing I could think of
based on a diff of the dmesgs).
I rolled back to the 4.4-release kernel and it worked fine.
OpenBSD 4.4-current (GENERIC) #1610: Thu Dec 11 19:55:57 MST 2008
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(TM) CPU 2.66GHz ("GenuineIntel" 686-class) 2.88 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
real mem = 402157568 (383MB)
avail mem = 380329984 (362MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/30/08, BIOS32 rev. 0 @
0xfd880, SMBIOS rev. 2.31 @ 0xe0010 (45 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 01/30/2008
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC BOOT
acpi0: wakeup devices USB_(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpibat0 at acpi0: BAT1 not present
acpibat1 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit online
bios0: ROM list: 0xc/0x8000 0xc8000/0x1e00! 0xca000/0x1000
0xdc000/0x4000! 0xe/0x4000!
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets, initiator 7
cd0 at scsibus0 targ 0 lun 0: ATAPI
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus
disabled
vga1 at pci0 dev 15 function 0 "VMware Virtual SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 16 function 0 "VMware Virtual PCI-PCI" rev 0x02
pci2 at ppb1 bus 2
mpi0 at pci2 dev 0 function 0 "Symbios Logic 53c1030" rev 0x01: irq 9
scsibus1 at mpi0: 16 targets, initiator 7
sd0 at scsibus1 targ 0 lun 0: SCSI2 0/
direct fixed
sd0: 8192MB, 512 bytes/sec, 16777216 sec total
mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1
vic0 at pci2 dev 1 function 0 "AMD 79c970 PCnet-PCI" rev 0x10: irq 11,
address 00:0c:29:72:b1:81
isa0 at piixpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask e765 netmask ef65 ttymask
mtrr: Pentium Pro MTRR support
softraid0 at root
root on sd0a swap on sd0b dump on sd0b
[ch...@suez scratch]$ diff 20080812-release-dmesg 20081211-snap-dmesg
1c1
< OpenBSD 4.4 (GENERIC) #1021: Tue Aug 12 17:16:55 MDT 2008
---
> OpenBSD 4.4-current (GENERIC) #1610: Thu Dec 11 19:55:57 MST 2008
3c3
< cpu0: Intel(R) Xeon(TM) CPU 2.66GHz ("GenuineIntel" 686-class) 2.74
GHz
---
> cpu0: Intel(R) Xeon(TM) CPU 2.66GHz ("GenuineIntel" 686-class) 2.88
GHz
6c6
< avail mem = 380170240 (362MB)
---
> avail mem = 380329984 (362MB)
11,17c11,19
< apm0 at bios0: Power Management spec V1.2
< apm0: AC on, battery charge unknown
< acpi at bios0 function 0x0 not configured
< pcibios0 at bios0: rev 2.1 @ 0xfd880/0x780
< pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/176 (9 entries)
< pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371FB ISA" rev
0x00)
< pcibios0: PCI bus #2 is the last bus
---
> acpi0 at bios0: rev 0
> acpi0: tables DSDT FACP APIC BOOT
> acpi0: wakeup devices USB_(S1)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0
> acpibat0 at acpi0: BAT1 not present
> acpibat1 at acpi0: BAT2 not present
> acpiac0 at acpi0: AC unit online
19
Re: vic(4) problems with Dec 11th snap
On Dec 13, 2008, at 2:14 AM, David Gwynne wrote: vic seems fickle with jumbos. ive backed them out very recently, so try building your own kernel or wait for a new snapshot. it should be working now. dlg On 13/12/2008, at 6:51 PM, Brian Keefer wrote: Has anyone else had problems with vic(4) in the Dec 11th i386 snap? I have a guest on ESXi 3.5 that I upgraded from 4.3 to 4.4- release and it was working fine, but then I upgraded to the latest i386 snap and I no longer saw any traffic to/from the guest when viewing tcpdump, even on other guest VMs on the same host. To clarify I only saw outgoing ARP requests (from the guest itself), no incoming traffic what so ever. No ARP replies, no broadcast, nothing... none of the other guests saw the outbound traffic. Disabling ACPI made no difference (was the only thing I could think of based on a diff of the dmesgs). I rolled back to the 4.4-release kernel and it worked fine. I built generic MP with vmt enabled this afternoon (-rHEAD)) and it worked fine. Thanks! -- bk
Re: Testing in a virtual environment
On Jan 3, 2009, at 7:41 AM, Daniel A. Ramaley wrote: > Hello. I have what is hopefully a quick question. Has anyone > successfully run OpenBSD 4.4 in a virtualized environment? If so, > which > one? It works great in VMware ESXi and VMware Fusion. No special magic, it Just Works(tm). -- bk [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Testing in a virtual environment
On Jan 4, 2009, at 9:36 AM, Daniel A. Ramaley wrote: Strangely enough, after asking my question, i reinstalled OpenBSD in VirtualBox with slightly different settings and now it is working just fine. I've managed to build a -stable release. I haven't tried running X, but just being able to compile is good enough for now. The settings i used that work on my machine are VirtualBox' defaults except for turning on VT-x/AMD-V, and within the VM i added softdep to the mount options in fstab. Enabling the VT instructions is recommended regardless of what hypervisor is being used (at least, among the commercial ones). It will result in noticeably better performance overall. At least, this has been my experience with VMware and comments from Microsoft seem to indicate the same of Hyper-V and other hypervisors in general. For those who don't follow VMware closely, ESXi (the VMware Infrastructure hypervisor) is now free. It comes with the VMware Infrastructure Client and the VMware Infrastructure Update utility. I would recommend it for anyone who is building a dedicated Virtualization Host. VMware Server is only necessary if you actually want to use the "host" OS and occasionally run guests. Of course, the hardware supported by ESXi is a little bit more limited, since it's geared for server platform hardware. You'll want to make sure the BIOS and firmware for all the underlying gadgets has been upgraded to the latest (RAID controllers, etc). -- bk
Is it possible to increase wscale multiplier?
I'm probably ignorant, but I can't seem to find a way to increase the window scaling multiplier on an OpenBSD client. It's always zero. It seems the only significantly value for net.inet.tcp.rfc1323 is 0 (disabled) vs. non-0 (ws=0). Am I missing something? -- bk
Re: Is it possible to increase wscale multiplier?
On Jan 30, 2009, at 6:29 PM, jared r r spiegel wrote: On Fri, Jan 30, 2009 at 05:55:48PM -0800, Philip Guenther wrote: It seems the only significantly value for net.inet.tcp.rfc1323 is 0 (disabled) vs. non-0 (ws=0). Am I missing something? You'll never see a scale size larger than zero unless the involved program sets a socket receive buffer size larger than 64KB before calling listen() or connect(), that being the value from which the receive window size is derived. so in other words, if you want wscale to be able to go to 1 but for things who don't support wscale you want to retain the same current functionality, add 65536 to the current value of whatever (send|recv)space you're talking about. wscale of 2? add 131072 from the baseline, etc. go too high and stuff won't work at all -- jared Great, thanks for the pointers! I'm trying to fiddle with iperf performance testing going to a Linux box. tcpbench works great on OpenBSD, but it seems iperf is the only thing readily available for Linux that is also on OpenBSD. I'm just trying to figure out how each variable influences the throughput. -- bk
Re: Net benchmarking (was: Is it possible to increase wscale multiplier?)
On Jan 31, 2009, at 4:57 AM, Stuart Henderson wrote: On 2009-01-31, Brian Keefer wrote: Great, thanks for the pointers! I'm trying to fiddle with iperf performance testing going to a Linux box. tcpbench works great on OpenBSD, but it seems iperf is the only thing readily available for Linux that is also on OpenBSD. I'm just trying to figure out how each variable influences the throughput. iperf performance on OpenBSD isn't all that great, it's not a good way to judge actual real-life performance. I've had problems with it on the Linux side as well. Are there any alternatives that would work on both OpenBSD and Linux (and for bonus points, OS X)? -- bk
Re: usr.sbin/wake removal
On Feb 8, 2009, at 9:31 PM, Thomas Pfaff wrote: On Sun, 8 Feb 2009 15:53:01 -0700 (MST) Marc Balmer wrote: CVSROOT:/cvs Module name:src Changes by: mbal...@cvs.openbsd.org 2009/02/08 15:53:01 Removed files: usr.sbin/wake : Makefile wake.8 wake.c Log message: Remove wake(8). The bin directories are full, no new commands to be added. I think this could use some explaining for those of us that are not intimately involved in development or have been around here for that long. Keeping it small and simple by saying no to adding one file at 7.2K? I'd really like to know the rationale on this one. Thanks. I'm curious about this as well. What sort of resource limitation is being hit here? -- bk
Re: SSI support for thttpd?
On Feb 10, 2009, at 12:05 PM, Jakob Schlyter wrote: actually, the ssi thingy is build but not included in the binary package. I've updated the port to include it. jakob I just wanted to let you know that I did a "make update" on the latest source and it worked great (macppc -current). I copied ssi to a cgi-bin directory inside my document root and added - c '/cgi-bin/*' to thttpd command line. It parses SSI statements intended for Apache just fine, with the slight nit that it expects the path to be relative to the cgi-bin when I use "virtual" as the include type. I just created hardlinks to the included files and that solved the problem. Thanks for the super-fast response!!! As a silly aside, thttpd saved my tunnelbroker.net account. They wanted me to put up a website to prove the tunnel belonged to me, and after hours of tweaking httpd.conf yielded only frustration, I installed thttpd and had it up and running in less than 10 minutes. -- bk
Re: dmesglog
On Feb 13, 2009, at 4:47 PM, Jordi Beltran Creix wrote: Hello, Forgive me, but wouldn't (echo "Subject: type of machine" ; dmesg ; sysctl hw.sensors) | sendmail -f$YOUR_EMAIL dm...@openbsd.org be better? Else, if the hostname is not a valid domain, the mail does not get through. Regards, I did get a bounce because my internal hostnames are not in external DNS. I guess I have to cut and paste :( -- bk
People send attachments, deal with it (was: A virus road map for GNOME and KDE?)
On Feb 20, 2009, at 8:37 AM, Lars Noodin wrote: E-Mail is not an acceptable surrogate for a networked filesystem. Regards -Lars All right, I've had enough of your tilting at windmills. This battle has been fought and lost already. E-mail is the de facto way to collaborate, and that includes collaborating with documents and files. If you weren't supposed to send or receive binary attachments, e-mail clients wouldn't allow it (nor MTAs, for that matter). Even UNIX command line e-mail clients have had this capability for... what, decades? Stop crying about your made-up rules that the protocol standards don't seem to agree with. There are a bunch of neat products out there that can strip _large_ attachments off and place them on a secure webserver, but these are not a reasonable way to send _every_ attachment. Some system administrators believe it's their place to tell entire companies how they should do everything. These administrators tend to not be very employable. -- bk
Re: Install 4.4 Sparc64 on SunFire V120
On Feb 25, 2009, at 12:18 PM, new_guy wrote: Hi guys. I'm helping a friend install 4.4 (Sparc64) on this SunFire V120 he got for free :) It's a very nice box with a working Solaris install. It boots the install.iso and proceeds to install, but when we get to the point of selecting a root disk... the only option we have is [done]. OpenBSD seems to detect both drives (sd0 and sd1) but not place them in the list to select from. That's weird. I have a nearly identical machine with almost the same configuration. The only difference without checking dmesg line-by- line is that mine has one disk drive rather than two. I'll check my dmesg when I get home. I was able to install a 4.5-beta snapshot on it without issue. I also booted it off a 4.4 snapshot a few months ago, but I didn't attempt an install (just zero'd the disk), so I couldn't tell you whether it gave me the option to install on disk or not. -- bk
Re: HP Proliant DL385 with Squid at a Gigabit-switch - bad network performance
On Feb 28, 2009, at 12:28 PM, Laurent CARON wrote: Steve Shockley wrote: On 2/27/2009 8:43 AM, Laurent CARON wrote: - Forcing speed on switch - Forcing speed on nic Why? This practice made sense when 10baseT gear from different vendors wasn't compatible, but not for the last 15-20 years. This practice still makes sense, at least with broadcom cards. I had spurious problems 2 years ago with a Gigabit Ethernet interface showing lots of error while using autoneg (hooked to a 3com switch or to a cisco one). Those problems did instantly disappear after forcing the speed on both, the card AND the switch. I always do force the speed on servers. I don't say it is the only way to go, but my way to handle it. Laurent I've had problems with bge(4)s in IBM xSeries machines that required forcing speed/duplex, else they would negotiate to 100/half. -- bk
Can't update some packages in -current due to library version
This is with 4.9 GENERIC#48 macppc snapshot from ftp.openbsd.org . I had originally updated from a 4.8 snapshot yesterday to 4.9-release, then a 4.9 snapshot from a few days prior (downloaded from ftp5.usa.openbsd.org). When I pointed PKG_PATH to ftp://ftp5.usa.openbsd.org/pub/OpenBSD/snapshots/packages/powerpc/ I had the below library errors, so this morning I noticed there was a more recent snapshot on ftp.openbsd.org and tried that, along with setting PKG_PATH to ftp.openbsd.org as well, but I'm having the same issue. I guess I missed a step in upgrading from 4.8 to 4.9, or from 4.9 to -current, but I can't seem to figure out what I missed from reading upgrade49.html or current.html. Can't install libiconv-1.13p2 because of libraries |library c.58.3 not found | /usr/lib/libc.so.34.1 (system): bad major | /usr/lib/libc.so.58.0 (system): minor is too small | /usr/lib/libc.so.34.2 (system): bad major | /usr/lib/libc.so.38.2 (system): bad major | /usr/lib/libc.so.39.0 (system): bad major | /usr/lib/libc.so.39.3 (system): bad major | /usr/lib/libc.so.40.3 (system): bad major | /usr/lib/libc.so.41.0 (system): bad major | /usr/lib/libc.so.43.0 (system): bad major | /usr/lib/libc.so.48.0 (system): bad major | /usr/lib/libc.so.50.0 (system): bad major | /usr/lib/libc.so.50.1 (system): bad major | /usr/lib/libc.so.51.0 (system): bad major | /usr/lib/libc.so.53.0 (system): bad major | /usr/lib/libc.so.56.0 (system): bad major | /usr/lib/libc.so.60.0 (system): bad major Can't install gettext-0.18.1p0 because of libraries |library m.5.3 not found | /usr/lib/libm.so.2.0 (system): bad major | /usr/lib/libm.so.2.1 (system): bad major | /usr/lib/libm.so.2.3 (system): bad major | /usr/lib/libm.so.3.0 (system): bad major | /usr/lib/libm.so.5.0 (system): minor is too small | /usr/lib/libm.so.5.2 (system): minor is too small | /usr/lib/libm.so.7.0 (system): bad major |library stdc++.51.0 not found | /usr/lib/libstdc++.so.33.0 (system): bad major | /usr/lib/libstdc++.so.34.0 (system): bad major | /usr/lib/libstdc++.so.40.0 (system): bad major | /usr/lib/libstdc++.so.42.0 (system): bad major | /usr/lib/libstdc++.so.44.0 (system): bad major | /usr/lib/libstdc++.so.45.0 (system): bad major | /usr/lib/libstdc++.so.46.0 (system): bad major | /usr/lib/libstdc++.so.47.0 (system): bad major | /usr/lib/libstdc++.so.49.0 (system): bad major | /usr/lib/libstdc++.so.50.0 (system): bad major | /usr/lib/libstdc++.so.52.0 (system): bad major Direct dependencies for .libs-gettext-0.10.40p1+.libs-gettext-0.16.1+.libs1-gettext-0.14.5p1+.libs1-g ettext-0.17p0+gettext-0.18.1p0->gettext-0.18.1p0 resolve to libiconv-1.13p2 Full dependency tree is libiconv-1.13p2 Can't install bash-4.2.10 because of libraries Direct dependencies for bash-4.1.9p0->bash-4.2.10 resolve to gettext-0.18.1p0 libiconv-1.13p2 Full dependency tree is gettext-0.18.1p0 libiconv-1.13p2 Can't install bzip2-1.0.6 because of libraries Can't install cdrtools-2.01p1 because of libraries Can't install cyrus-sasl-2.1.23p6 because of libraries Can't install dnstop-20110127 because of libraries Can't install dovecot-2.0.13p4 because of libraries Direct dependencies for dovecot-1.2.16p2->dovecot-2.0.13p4 resolve to bzip2-1.0.6 libiconv-1.13p2 Full dependency tree is bzip2-1.0.6 libiconv-1.13p2 Can't install pcre-8.12p0 because of libraries Can't install .libs-glib2-2.10.3+.libs-glib2-2.16.4p1+.libs-glib2-2.18.3p0+.libs-glib2-2.24 .1p2+.libs1-glib2-2.14.5+.libs1-glib2-2.22.3p1+glib2-2.26.1p0->glib2-2.28.8: can't resolve pcre-8.12p0 Can't install gamin-0.1.10p11 because of libraries |library glib-2.0.2800.0 not found | /usr/local/lib/libglib-2.0.so.2600.0 (glib2-2.26.1p0): bad major | /usr/local/lib/libglib-2.0.so.1800.1 (.libs-glib2-2.18.3p0): bad major | /usr/local/lib/libglib-2.0.so.1802.0 (.libs1-glib2-2.22.3p1): bad major | /usr/local/lib/libglib-2.0.so.1000.3 (.libs-glib2-2.10.3): bad major | /usr/local/lib/libglib-2.0.so.1600.1 (.libs-glib2-2.16.4p1): bad major | /usr/local/lib/libglib-2.0.so.1803.0 (.libs-glib2-2.24.1p2): bad major | /usr/local/lib/libglib-2.0.so.1400.3 (.libs1-glib2-2.14.5): bad major |library pcre.2.4 not found | /usr/local/lib/libpcre.so.2.3 (pcre-8.02p1): minor is too small Direct dependencies for gamin-0.1.10p9->gamin-0.1.10p11 resolve to glib2-2.26.1p0 gettext-0.18.1p0 libiconv-1.13p2 Full dependency tree is pcre-8.02p1 glib2-2.26.1p0 libgamin-0.1.10p4 gettext-0.18.1p0 libiconv-1.13p2 Can't install jpeg-8c because of libraries Can't install gd-2.0.35p0 because of libraries Direct dependencies for gd-2.0.35p0->gd-2.0.35p0 resolve to jpeg-8b png-1.2.44 libiconv-1.13p2 Full dependency tree is jpeg-8b png-1.2.44 libiconv-1.13p2 Can't install gmake-3.82 because of libraries Direct dependencies for gmake-3.81p1->gmake-3.82 resolve to gettext-0.18.1p0 libiconv-1.13p2 Full dependency tree is gettext-0.18.1p0 libiconv-1.13p2 Can't install hfsplus-1.0.4p4 because of libraries Can't install iperf-2.0.5 because of libraries Can't install irssi-0.8.15 because of li
Re: Can't update some packages in -current due to library version
On Jul 17, 2011, at 12:03 PM, Amit Kulkarni wrote: >> I guess I missed a step in upgrading from 4.8 to 4.9, or from 4.9 to -current, >> but I can't seem to figure out what I missed from reading upgrade49.html or >> current.html. >> >> >> Can't install libiconv-1.13p2 because of libraries >> |library c.58.3 not found >> | /usr/lib/libc.so.34.1 (system): bad major >> | /usr/lib/libc.so.58.0 (system): minor is too small >> | /usr/lib/libc.so.34.2 (system): bad major >> | /usr/lib/libc.so.38.2 (system): bad major >> | /usr/lib/libc.so.39.0 (system): bad major >> | /usr/lib/libc.so.39.3 (system): bad major >> | /usr/lib/libc.so.40.3 (system): bad major >> | /usr/lib/libc.so.41.0 (system): bad major >> | /usr/lib/libc.so.43.0 (system): bad major >> | /usr/lib/libc.so.48.0 (system): bad major >> | /usr/lib/libc.so.50.0 (system): bad major >> | /usr/lib/libc.so.50.1 (system): bad major >> | /usr/lib/libc.so.51.0 (system): bad major >> | /usr/lib/libc.so.53.0 (system): bad major >> | /usr/lib/libc.so.56.0 (system): bad major >> | /usr/lib/libc.so.60.0 (system): bad major >> Can't install gettext-0.18.1p0 because of libraries >> |library m.5.3 not found > > > simple libc.so.58.3 is not there, same for libm.so.5.3 on your system. > > I am running -current packages too and they are now linked to > libc.so.60.0 and libm.so.7.0, so are you upgrading by pkg_add > foo_package-SPECIFIC VERSION? or pkg_add -ui? > > Did you forget sysmerge also? > > I see python 2.6 also, which is gone from OpenBSD -current. > I was just doing pkg_add -ui. Individual packages might be attempting to upgrade to a specific version though, eh? I was looking for Python 2.7, but I don't see it anywhere. I had previously symlinked /usr/local/bin/python to the 2.6 version. Is Python in base now? I was told off-list that the powerpc packages simply aren't up to date with -current, which seems like a plausible explanation. I'm doing a cvs up to see if it's possible to build the packages by hand as ports. -- bk
Re: Can't update some packages in -current due to library version
On Jul 17, 2011, at 12:24 PM, Amit Kulkarni wrote: >> I was just doing pkg_add -ui. Individual packages might be attempting to > upgrade to a specific version though, eh? I was looking for Python 2.7, but I > don't see it anywhere. I had previously symlinked /usr/local/bin/python to > the 2.6 version. Is Python in base now? > > > Python is not in base, but python2.6 is gone. > http://www.undeadly.org/cgi?action=article&sid=20110614062504 Initially when I had tried to build from pots in lieu of doing pkg_add -ui I had run into errors. It turns out I had some inconsistencies in my local copy of the ports tree and I had misunderstood the warning about groff. After wiping /usr/ports and starting over from the snapshot of ports.tar.gz (and cvs up), I was able to build groff, then the rest of the packages I needed from ports. -- bk
Re: Thanks a lot to all devs of OpenBSD
On Aug 28, 2011, at 8:00 AM, Tomas Bodzar wrote: > Hi all, > > after reading this thread > http://mail-index.netbsd.org/netbsd-users/2011/08/22/msg008819.html > (and main link which caused that > http://lists.freebsd.org/pipermail/freebsd-arch/2011-August/011412.html) > I must really say thanks a lot for your SUPERB job in development of > such a great OS which OpenBSD is. > > Keep up the good work and focus which brings OpenBSD to us. > > Br, > Tomas Bodzar I don't care what the other BSDs or Linux are doing. I only care that I have an OS that's easy to install & maintain, very secure by default, documented well, and guided by a central vision that values quality. I dont' see any other OS project doing that better than OpenBSD in the near future. So consider this thanks to the OpenBSD team for a job well-done. -- bk
Re: cd arrived in Italy
On May 10, 2010, at 4:52 AM, matteo filippetto wrote: > Hi all, > > today cd arrived in Italy > > Thanks! > > -- > Matteo Filippetto > And California, USA. Thanks for another great release. -- bk
usr.bin/aucat fails to build on sparc64 -current
# make cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/aucat.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/abuf.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/aparams.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/aproc.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/dev.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/midi.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/file.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/headers.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/safile.c cc -O2 -pipe -DDEBUG -Wall -Wstrict-prototypes -Wundef -c /usr/src/ usr.bin/aucat/miofile.c /usr/src/usr.bin/aucat/miofile.c: In function `miofile_new': /usr/src/usr.bin/aucat/miofile.c:69: error: `MIO_IN' undeclared (first use in this function) /usr/src/usr.bin/aucat/miofile.c:69: error: (Each undeclared identifier is reported only once /usr/src/usr.bin/aucat/miofile.c:69: error: for each function it appears in.) /usr/src/usr.bin/aucat/miofile.c:71: error: `MIO_OUT' undeclared (first use in this function) /usr/src/usr.bin/aucat/miofile.c:72: warning: implicit declaration of function `mio_open' /usr/src/usr.bin/aucat/miofile.c:72: warning: assignment makes pointer from integer without a cast /usr/src/usr.bin/aucat/miofile.c:75: warning: implicit declaration of function `mio_nfds' /usr/src/usr.bin/aucat/miofile.c:81: warning: implicit declaration of function `mio_close' /usr/src/usr.bin/aucat/miofile.c: In function `miofile_read': /usr/src/usr.bin/aucat/miofile.c:91: warning: implicit declaration of function `mio_read' /usr/src/usr.bin/aucat/miofile.c:94: warning: implicit declaration of function `mio_eof' /usr/src/usr.bin/aucat/miofile.c: In function `miofile_write': /usr/src/usr.bin/aucat/miofile.c:113: warning: implicit declaration of function `mio_write' /usr/src/usr.bin/aucat/miofile.c: In function `miofile_pollfd': /usr/src/usr.bin/aucat/miofile.c:137: warning: implicit declaration of function `mio_pollfd' /usr/src/usr.bin/aucat/miofile.c: In function `miofile_revents': /usr/src/usr.bin/aucat/miofile.c:143: warning: implicit declaration of function `mio_revents' /usr/src/usr.bin/aucat/miofile.c: In function `miofile_close': /usr/src/usr.bin/aucat/miofile.c:149: warning: `return' with a value, in function returning void *** Error code 1 Stop in /usr/src/usr.bin/aucat (line 92 of /usr/share/mk/sys.mk). It's happening since yesterday. I tried cvs up'ing the changes from this morning and starting over--cleaned up /usr/obj, then did make obj && make cleandir && make depend && make. It's still failing. Using this snapshot: OpenBSD 4.6-current (GENERIC) #50: Wed Jul 22 20:24:47 MDT 2009 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/ GENERIC -- bk
Re: usr.bin/aucat fails to build on sparc64 -current
On Jul 26, 2009, at 11:17 PM, Alexandre Ratchov wrote: On Mon, Jul 27, 2009 at 07:57:58AM +0200, Alexandre Ratchov wrote: it seems that /usr/include/sndio.h is not up to date. Does the following help? cd /usr/src/include cvs update sndio.h sudo make install ^^^ it's ``sudo make includes'', of course -- Alexandre Your off-list instructions (below) fixed it. Thanks :) cd /usr/src cvs update include/sndio.h lib/libsndio usr.bin/aucat cd /usr/src/include make prereq && sudo make includes cd /usr/src/lib/libsndio make obj && make depend && make && sudo make install cd /usr/src/usr.bin/aucat make obj && make depend && make && sudo make install -- bk
Re: bind 9.x DoS
On Jul 28, 2009, at 7:57 PM, frantisek holop wrote: morning, https://www.isc.org/node/474 http://www.kb.cert.org/vuls/id/725188 -f -- if its stupid and it works - its not stupid Works great vs. this snapshot: OpenBSD 4.6-current (GENERIC) #46: Wed Jul 15 20:15:31 MDT 2009 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/ GENERIC It looks like none of the local patches mitigate it. -- bk
Re: bind 9.x DoS
On Jul 28, 2009, at 8:40 PM, Robert wrote: On Wed, 29 Jul 2009 04:57:29 +0200 frantisek holop wrote: morning, https://www.isc.org/node/474 http://www.kb.cert.org/vuls/id/725188 -f Hi, it's late/early so the following comes without warranty. Compiles, install and works for me on -current amd64/i386 both on master and slave servers. (Haven't gotten around to the 4.5 case yet, but should apply there, too.) - Robert Confirmed working on -current/sparc64 Jul 28 21:35:15 imhotep named[12351]: client 172.22.2.26#36681: view int: updating zone '0.0.127.in-addr.arpa/IN': update unsuccessful: 1.0.0.127.in-addr.arpa/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET) -- bk
Re: Workaround to recent Juniper Announcement?
On Jan 7, 2010, at 10:23 AM, James Records wrote: > Justin, > > The article doesn't say which option causes this, so its hard to tell, once > you do find this info though It's not like it's that difficult. Did you see the post on ptresearch? Just test sending the 256 possible packets at a lab machine and see which one crashes it. It's pretty silly for Juniper to "obfuscate" the details when it's so trivial for anyone with the know-how to write and exploit to figure it out from the information they did release to the public. -- bk
httpd segfaults since 4.6 upgrade (macppc)
No I'm not using PHP. The only thing I can think of different from stock httpd.conf is that I turned on Server Side Includes. I have some named-based virtual hosts, but I can't imagine that's uncommon... Oh, I think I had ExtendedStatus off before and it's on now. I'm actually running a snapshot right now, but the segfaults started when I upgraded to 4.6-release and has continued even after upgrading to snapshot. OpenBSD abydos.smtps.net 4.6 GENERIC#238 macppc Any clues? -- bk
Re: httpd segfaults since 4.6 upgrade (macppc)
On Jan 18, 2010, at 3:43 PM, Aaron Mason wrote: > On Tue, Jan 19, 2010 at 10:31 AM, Brian Keefer wrote: >> No I'm not using PHP. The only thing I can think of different from stock >> httpd.conf is that I turned on Server Side Includes. I have some > named-based >> virtual hosts, but I can't imagine that's uncommon... Oh, I think I had >> ExtendedStatus off before and it's on now. >> >> I'm actually running a snapshot right now, but the segfaults started when I >> upgraded to 4.6-release and has continued even after upgrading to snapshot. >> >> OpenBSD abydos.smtps.net 4.6 GENERIC#238 macppc >> >> Any clues? >> >> -- >> bk >> > > Secondly, does the server segfault with SSI and/or ExtendedStatus > turned off? And can we see a full dmesg? Still happens with ExtendedStatus off Hasn't happened yet with #LoadModule includes_module /usr/lib/apache/modules/mod_include.so Strangely though, it seems SSIs are still working on my site... [ using 447356 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A]console in [keyboard] , using USB using parent ATY,RockHopper2Paren:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: memtag 8000, iotag 8000: width 640 linebytes 768 height 480 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2010 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.6-current (GENERIC) #238: Tue Jan 5 15:20:37 MST 2010 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 268435456 (256MB) avail mem = 249266176 (237MB) mainbus0 at root: model PowerMac10,1 cpu0 at mainbus0: 7447A (Revision 0x102): 1416 MHz: 512KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 256MB DDR SDRAM non-parity PC3200CL3.0 memc0 at mainbus0: uni-n "hw-clock" at memc0 not configured kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 vgafb0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01, mmio wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x5 pci1 at mpcpcibr1 bus 0 pchb1 at pci1 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 little endian macgpio0 at macobio0 offset 0x50 "modem-reset" at macgpio0 offset 0x1d not configured "modem-power" at macgpio0 offset 0x1c not configured macgpio1 at macgpio0 offset 0x9 irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zsc0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zsc0 channel 0 zstty1 at zsc0 channel 1 aoa0 at macobio0 offset 0x1: irq 30,1,2 audio0 at aoa0 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets apm0 at adb0: battery flags 0x0, 0% charged piic0 at adb0 iic1 at piic0 maxtmp0 at iic1 addr 0xc8: max6642 kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x2 irq 24: DMA ohci0 at pci1 dev 24 function 0 "Apple Intrepid USB" rev 0x00: irq 0, version 1.0, legacy support ohci1 at pci1 dev 25 function 0 "Apple Intrepid USB" rev 0x00: irq 0, version 1.0, legacy support ohci2 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support ohci3 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 ohci4 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb4 at ohci3: USB revision 1.0 uhub4 at usb4 "NEC OHCI root hub" rev 1.00/1.00 addr 1 usb5 at ohci4: USB revision 1.0 uhub5 at usb5 "NEC OHCI root hub" rev 1.00/1.00 addr 1 mpcpcibr2 at mainbus0 pci: uni-north, Revision 0xff pci2 at mpcpcibr2 bus 0 pchb2 at pci2 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00 wdc
Options for graphing pf rule matches
Hello, I'm wondering what other folks are using to graph pf data beyond what is provided by pfstat. The aggregate values are useful and I'd also like to setup graphs of particular services, particular tables, etc. Is there a way for pfstat to graph labeled traffic that I have overlooked? I also looked briefly at NetFlow support, but as near as I can tell that's only for established flows, or am I wrong? -- bk
Re: Options for graphing pf rule matches
On Feb 15, 2010, at 3:29 PM, Jason Dixon wrote: > On Mon, Feb 15, 2010 at 03:00:59PM -0800, Brian Keefer wrote: >> Hello, >> >> I'm wondering what other folks are using to graph pf data beyond what is >> provided by pfstat. The aggregate values are useful and I'd also like to >> setup graphs of particular services, particular tables, etc. Is there a way >> for pfstat to graph labeled traffic that I have overlooked? > > There are lots of different ways to graph network data on pf firewalls. > I don't know that any (besides pfstat) are specifically designed for pf, > but it's not hard to retrofit them. Are there any tools that have built-in support to query pf label counters? Is there a MIB for pf? I'm guessing the answer to both is no, so I'd have to write a custom script to call pfctl -sl and parse it, then dump that into RRD or some such. Is there a better approach? >> I also looked briefly at NetFlow support, but as near as I can tell that's >> only for established flows, or am I wrong? > > If by "established" you mean finished, then yes. pfstat(4) exports > expired states into NetFlow datagrams. NetFlow is very handy for > looking at specific traffic events (or representative traffic of a large > event) but is not useful for trending or regression analysis. > I see. That doesn't sound like what I'm trying to do. -- bk
Possible to use UFQDN for peer in ipsec.conf?
Hello, I'm trying to do roadwarrior VPN between OSX (mobile) and OpenBSD (gateway) using certificates for peer identification. Is it possible to list a UFQDN as a peer? When I try something like this on the gateway: ike passive from any to any peer u...@host.tld \ main auth hmac-sha1 enc aes group modp2048 \ quick auth hmac-sha2-256 enc blowfish \ psk "super secret string" ipsecctl complains of a syntax error. If anyone has a link to an ipsec.conf that has an example of using UFQDNs to identify peers I would be eternally grateful. It seems nearly every example just uses PSK alone, or if a certificate is used it's by hostname. PS If I place the trusted certificates in /etc/isakmp/pubkeys/ufqdn do they absolutely have to have subjectAlternateName, or is having the email address in the CN sufficient (CN=u...@host.tld/emailAddress=u...@host.tld)? Any tips are immensely appreciated. -- chort
Bug with PF IPv6 subnet calculation, or my brain?
4.9 GENERIC#626 i386 I write a rule that says this: pass in on $ext_if inet6 proto ipv6-icmp from any to 2620:0100:900f:c9::/56 and pfctl shows this: pass in on em2 inet6 proto ipv6-icmp from any to 2620:100:900f::/56 keep state Maybe I'm crazy, but it seems 2620:100:900f:: would be /48 (assuming everything to the right is dynamic, no assumed zeros), and my original rule seems to have 56 bits to the left, unless I'm bad at counting, which is entirely possible. Is this a bug? -- bk
Re: Bug with PF IPv6 subnet calculation, or my brain?
On Feb 1, 2011, at 11:00 PM, Paul de Weerd wrote: > On Tue, Feb 01, 2011 at 10:51:00PM -0800, Brian Keefer wrote: > | 4.9 GENERIC#626 i386 > | > | I write a rule that says this: > | pass in on $ext_if inet6 proto ipv6-icmp from any to 2620:0100:900f:c9::/56 > | > | and pfctl shows this: > | pass in on em2 inet6 proto ipv6-icmp from any to 2620:100:900f::/56 keep > | state > | > | Maybe I'm crazy, but it seems 2620:100:900f:: would be /48 (assuming > | everything to the right is dynamic, no assumed zeros), and my original rule > | seems to have 56 bits to the left, unless I'm bad at counting, which is > | entirely possible. > | > | Is this a bug? > > No, you're bad at counting. "c9" is an 8 bit value, represented as a > 16-bit value you'd get "00c9". So the IPv6 network you're really using > is 2620:0100:900f:00c9::::/56 .. which is the same as > 2620:0100:900f:00__::::/56 (with random hexadecimal > numbers in the place of all those _'s). > > Either you meant 2620:0100:900f:c900::/56 or you really want to use > 2620:0100:900f:c9::/64. > > Paul 'WEiRD' de Weerd > > -- >> [<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/ I looked the first two sentences and got it. Sigh. Thanks for the fast response. -- bk
