Re: developing a backup strategy
On Mon, Jun 12, 2006 at 11:37:08PM +0530, Raja Subramanian wrote: Hi, On 6/12/06, prad [EMAIL PROTECTED] wrote: ... should i be thinking of incremental backups say with dump? does it make any sense to rsync the entire server drive? Check out rdiff-backup.sf.net. The website seems broken atm. I've use it to incrementally backup ~3TB of data on Linux boxen and am very happy with it. I can only backup this recommendation. rdiff-backup is a really nice tool that makes incremental backups as easy as scp, with all nice features like incremental transfers, complete history (what was that file again 2 months ago?), encrypted transfer, etc. Bernd
Re: wikipedia article
On Mon, 12 Jun 2006, Ted Mittelstaedt wrote: -Original Message- From: John Nemeth [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 1:15 PM To: Ted Mittelstaedt; Nikolas Britton; Ted Unangst Cc: Hamorszky Balazs; misc@openbsd.org; freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: RE: wikipedia article On Nov 1, 6:11pm, Ted Mittelstaedt wrote: } } Prior to the release of the 80386 the Intel processors didn't have } memory protection which was a requirement of any processor running } the BSD kernel. This is not entirely true. The 80286 had memory protection. However, its memory protection was completely based on segments (i.e. it could not do paging). Oh, yeah, your right about that. Me bad. Also, it was only a 16 bit processor. What was the bit size of the CPU's originally used to write UNIX in Bell Labs? What's more, iirc the MMU of the pdp11 isn't what we call a MMU today, it could not even do paging. -Otto
Re: wikipedia article
-Original Message- From: Thor Lancelot Simon [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 10:35 PM To: Ted Mittelstaedt Cc: misc@openbsd.org; freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: Re: wikipedia article On Mon, Jun 12, 2006 at 10:27:33PM -0700, Ted Mittelstaedt wrote: What was the bit size of the CPU's originally used to write UNIX in Bell Labs? Rather large. You can get all the details at http://en.wikipedia.org/wiki/Magnetic_core. That's a good one! :-) Ted
Re: wikipedia article
Various wrote: From: Otto Moerbeek [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] ... What was the bit size of the CPU's originally used to write UNIX in Bell Labs? What's more, iirc the MMU of the pdp11 isn't what we call a MMU today, it could not even do paging. The pdp-11 mmu could handle program relocation, segmentation (after a fashion) and memory protection. I'm not sure what more you could expect from an mmu. What you mean by paging is probably demand paging, which means the ability to run a program without requiring that it be entirely resident. The key feature you need for that is a guarantee that any instruction fault caused by missing memory can be either restarted or continued. In most architectures that's a question of cpu design not mmu. In the case of the pdp-11 that's mostly a moot point. The pdp-11 only provides for mapping the 64k of memory space into into 8 segments (addressable on 64-byte clicks) and there's just not much win to demand paging 8 pages. (actually 6 x 8 pages; there was kernel, user, and supervisor mode, each had separate instruction and data spaces, but supervisor mode was rarely used in Unix environments, and only a few large user mode programs ran using split I/D space.) For what it's worth, though, I *think* it was possible to restart most instructions on the /45 and /70, which were the big machines and the primary target of most later pdp-11 work. In fact, some use was made of this feature -- automatic stack growth. If you look through ancient Unix source, you'll find interesting bits of kernel code that manage this. There's actually a cheesy way to do demand paging with microprocessors that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instruction causing the fault so contains restartable machine state. Masscomp sold a machine like this once. -Marcus Watts
Re: ddos mail attack thwarted by spamd greylisting!
Luckily, spamd greylisting saved the day. If it wasn't for BASE/snort reporting of the portscan, I wouldn't have even bothered looking in my logs tonite, and probably would never have been aware of the thwarted attempt. Good thing they're only portscanning and mailbombing you then, and not exploiting one of the bazillions of snort overflows ;) -Bob
Pulled out an old song..
Hi all, I was just going through my OpenBSD cd's and came across the first cd with a song... Interestingly enough I didn't find an mp3 with it as combined with newer releases. Anyhow can anyone confirm this rmd160 checksum after the song is cdparanoia'd? # rmd160 track02.cdda.wav RMD160 (track02.cdda.wav) = 1053805b53962e22028768516285da1cba5e4454 Thanks OpenBSD; keep up the great work! -peter
Re: Extremely weird PF behaviour
On 2006/06/13 05:26, Alex Stamatis wrote: I have a veeeryyy veeeryyy weird problem !!! Not really... I have small network. The Openbsd box (3.7 generic) is my firewall. In 2 of my windows workstations I wont to have remote desktop. So I make a pass in rule for the ports 65500 and 65501 and a rdr of these 2 ports 65500 to 1 ip at 3389 internal port and the 65501 to another ip in 3389. It wont play from the outside world. Read the first couple of paragraphs of the TRANSLATION section of pf.conf(5), then you'll see that translation comes *before* filtering.
Re: SMP issue involving Dual Xeon
What are you trying to accomplish? AFAIK, HTT is not supported in OpenBSD. So re-enable it in BIOS - OS will ignore it anyway. On Tuesday 13 June 2006 06:01, Jesse Gumm wrote: Hello, I'm booting a Dual Xeon 2.4 Machine (just got it a few days ago), and having a bit of difficulty discerning of the 2nd CPU is actually being used by OpenBSD 3.9. Before posting the dmesg, I'll quick state what I've done so far, and why I don't actually think the 2nd cpu is taking. I started with FreeBSD (I'm traditionally an OpenBSD user, but I thought I'd give FreeBSD a try), and when FreeBSD booted with SMP support, it found 4 processors (2 Xeons each acting like 2 because of Hyperthreading, hence 4 processors). Which was fine, but after a bit I decided I didn't particularly like FreeBSD, and decided to go back to OpenBSD. When Booting OpenBSD from bsd.mp, however, I noticed that it only detected 2 CPUs. I thought that was odd, and that either 1) OpenBSD was ignoring Hyperthreading, or 2) OpenBSD recognized Hyperthreading but didn't give it it's own CPU, or 3) OpenBSD only recognized 1 processor, but gave the Virtual CPU it's own CPU. After reading a bit and determining that BSD doesn't like Hyperthreading, I disabled it in BIOS, and booted again, and the dmesg didn't change, which I found suspicious. It still says only 2 CPUs, however, the dmesg doesn't lookright, and I don't particularly want to take the processor off to test this, but I can, I figured maybe someone can give me a better answer. In short, the dmesg looks off. Notice how cpu0 lists a whole slew of bits FPU, MMC, SSE, etc while cpu1 lists 4 bits: FPU,CX8,APIC,CNXT-ID I tried compiling a fresh GENERIC.MP kernel to see if that'd resolve the situation, but it did nothing to help with this. My question, then, is: Is my 2nd CPU actually being recognized, and if not, why is OpenBSD still seeing the Hyperthreading processor when HT is disabled from BIOS, and what can I do to fix/troubleshoot this? Here's the dmesg below (I posted the whole thing instead of just the cpu and bus parts in case there might be something I'm missing): cpu0: Intel(R) Xeon(TM) CPU 2.40GHz (GenuineIntel 686-class) 2.40 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID real mem = 1073233920 (1048080K) avail mem = 972546048 (949752K) using 4278 buffers containing 53764096 bytes (52504K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(40) BIOS, date 09/17/03, BIOS32 rev. 0 @ 0xfd7d1 pcibios0 at bios0: rev 2.1 @ 0xf/0x pcibios0: PCI BIOS has 8 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 10 11 15 pcibios0: PCI Interrupt Router at 000:15:0 (ServerWorks CSB5 rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1800 0xc9800/0x4000 0xcd800/0x1800 mainbus0: Intel MP Specification (Version 1.4) (IBM ENSW TURQUIOSESMP) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99 MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 2.40GHz (GenuineIntel 686-class) cpu1: FPU,CX8,APIC,CNXT-ID 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 14 pa 0xfec0, version 11, 16 pins ioapic1 at mainbus0: apid 13 pa 0xfec01000, version 11, 16 pins ioapic2 at mainbus0: apid 12 pa 0xfec02000, version 11, 16 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 ServerWorks CMIC-WS Host (GC-LE) rev 0x13 pchb1 at pci0 dev 0 function 1 ServerWorks CMIC-WS Host (GC-LE) rev 0x00 pchb2 at pci0 dev 0 function 2 ServerWorks CMIC-LE rev 0x00 pci1 at pchb2 bus 1 mpt0 at pci1 dev 1 function 0 Symbios Logic 53c1030 rev 0x07: apic 13 int 6 (irq 9) scsibus0 at mpt0: 16 targets sd0 at scsibus0 targ 0 lun 0: LSILOGIC, 1030 IM, 1000 SCSI2 0/direct fixed sd0: 69878MB, 69879 cyl, 16 head, 127 sec, 512 bytes/sec, 143110145 sec total mpt0: target 0 Asynchronous at 0MHz width 8bit offset 0 QAS 0 DT 0 IU 0 fxp0 at pci1 dev 2 function 0 Intel 8255x rev 0x0c, i82550: apic 13 int 2 (irq 3), address 00:07:e9:0c:15:c7 inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 vga1 at pci0 dev 1 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) piixpm0 at pci0 dev 15 function 0 ServerWorks CSB5 rev 0x93 iic0 at piixpm0 pciide0 at pci0 dev 15 function 1 ServerWorks CSB5 IDE rev 0x93: DMA atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: LG, CD-ROM CRN-8245B, 1.16 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2 ohci0 at pci0 dev 15 function 2 ServerWorks OSB4/CSB5 USB rev 0x05ioapic0: conflicting map entries for pin 11 : irq 11, version
Re: wi: ifconfig txpower wrong for non 100mW wireless cards?
On Sat, 10 Jun 2006, Walter Haidinger wrote:
Replying to myself giving a short answer: yes, it is.
Any references (e.g. to some driver documentation) are appreciated!
FYI, I've found the following comments in the Linux Kernel source.
linux-2.6.16.17/drivers/net/wireless/hostap/hostap_ioctl.c:
...
/* Note! This TX power controlling is experimental and should not be used in
* production use. It just sets raw power register and does not use any kind of
* feedback information from the measured TX power (CR58). This is now
* commented out to make sure that it is not used by accident. TX power
* configuration will be enabled again after proper algorithm using feedback
* has been implemented. */
#ifdef RAW_TXPOWER_SETTING
/* Map HFA386x's CR31 to and from dBm with some sort of ad hoc mapping..
* This version assumes following mapping:
* CR31 is 7-bit value with -64 to +63 range.
* -64 is mapped into +20dBm and +63 into -43dBm.
* This is certainly not an exact mapping for every card, but at least
* increasing dBm value should correspond to increasing TX power.
*/
prism2_txpower_hfa386x_to_dBm()
{
...
}
prism2_txpower_dBm_to_hfa386x()
{
...
}
The code looks quite similar to the one in sys/dev/ic/if_wi.c.
Since I will not post GPL code to a BSD mailinglist, please get
the referenced file yourself and look for the given functions.
Walter
Re: wi: ifconfig txpower wrong for non 100mW wireless cards?
On 2006/06/13 11:24, Walter Haidinger wrote: /* Map HFA386x's CR31 to and from dBm with some sort of ad hoc mapping.. * This version assumes following mapping: * CR31 is 7-bit value with -64 to +63 range. * -64 is mapped into +20dBm and +63 into -43dBm. * This is certainly not an exact mapping for every card, but at least * increasing dBm value should correspond to increasing TX power. */ I think CR31 just maps over the whole range of the card, so for a card with a more powerful amp, a particular CR31 setting relates to higher power output than it would on an ordinary card. With some cards setting CR31 too high can give a distorted signal and increase out-of-channel radiation (some references if you google for WAP11 CR31 e.g. http://www.maokhian.com/wireless/wap11.html)
Re: SMP issue involving Dual Xeon
I'd like to know if the 2nd CPU is being used. I'm confused because of the lack of Flags on cpu1 while cpu0 is loaded with them. It looks like the 2nd CPU is actually a virtual CPU via Hyperthreading. If you look at the dmesg I posted, and compare the top with this dmesg ( http://www.nycbug.org/?NAV=dmesgd;f_dmesg=Xeon%20%20cpu1%20%20OpenBSD;f_bsd=;f_nick=;f_descr=;dmesgid=1787#1787 ), it's a little wierd that my dmesg lists all the flags for the first CPU and 4 for the 2nd, while this one that I just linked lists all the flags for both CPUs. I also did re-enable Hyperthreading, and the dmesg didn't change, but the whole lack of flags thing is what's throwing me off. -Jesse On 6/13/06, Maxim Bourmistrov [EMAIL PROTECTED] wrote: What are you trying to accomplish? AFAIK, HTT is not supported in OpenBSD. So re-enable it in BIOS - OS will ignore it anyway. On Tuesday 13 June 2006 06:01, Jesse Gumm wrote: Hello, I'm booting a Dual Xeon 2.4 Machine (just got it a few days ago), and having a bit of difficulty discerning of the 2nd CPU is actually being used by OpenBSD 3.9. Before posting the dmesg, I'll quick state what I've done so far, and why I don't actually think the 2nd cpu is taking. I started with FreeBSD (I'm traditionally an OpenBSD user, but I thought I'd give FreeBSD a try), and when FreeBSD booted with SMP support, it found 4 processors (2 Xeons each acting like 2 because of Hyperthreading, hence 4 processors). Which was fine, but after a bit I decided I didn't particularly like FreeBSD, and decided to go back to OpenBSD. When Booting OpenBSD from bsd.mp, however, I noticed that it only detected 2 CPUs. I thought that was odd, and that either 1) OpenBSD was ignoring Hyperthreading, or 2) OpenBSD recognized Hyperthreading but didn't give it it's own CPU, or 3) OpenBSD only recognized 1 processor, but gave the Virtual CPU it's own CPU. After reading a bit and determining that BSD doesn't like Hyperthreading, I disabled it in BIOS, and booted again, and the dmesg didn't change, which I found suspicious. It still says only 2 CPUs, however, the dmesg doesn't lookright, and I don't particularly want to take the processor off to test this, but I can, I figured maybe someone can give me a better answer. In short, the dmesg looks off. Notice how cpu0 lists a whole slew of bits FPU, MMC, SSE, etc while cpu1 lists 4 bits: FPU,CX8,APIC,CNXT-ID I tried compiling a fresh GENERIC.MP kernel to see if that'd resolve the situation, but it did nothing to help with this. My question, then, is: Is my 2nd CPU actually being recognized, and if not, why is OpenBSD still seeing the Hyperthreading processor when HT is disabled from BIOS, and what can I do to fix/troubleshoot this? Here's the dmesg below (I posted the whole thing instead of just the cpu and bus parts in case there might be something I'm missing): cpu0: Intel(R) Xeon(TM) CPU 2.40GHz (GenuineIntel 686-class) 2.40 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID real mem = 1073233920 (1048080K) avail mem = 972546048 (949752K) using 4278 buffers containing 53764096 bytes (52504K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(40) BIOS, date 09/17/03, BIOS32 rev. 0 @ 0xfd7d1 pcibios0 at bios0: rev 2.1 @ 0xf/0x pcibios0: PCI BIOS has 8 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 10 11 15 pcibios0: PCI Interrupt Router at 000:15:0 (ServerWorks CSB5 rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1800 0xc9800/0x4000 0xcd800/0x1800 mainbus0: Intel MP Specification (Version 1.4) (IBM ENSW TURQUIOSESMP) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99 MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 2.40GHz (GenuineIntel 686-class) cpu1: FPU,CX8,APIC,CNXT-ID 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 14 pa 0xfec0, version 11, 16 pins ioapic1 at mainbus0: apid 13 pa 0xfec01000, version 11, 16 pins ioapic2 at mainbus0: apid 12 pa 0xfec02000, version 11, 16 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 ServerWorks CMIC-WS Host (GC-LE) rev 0x13 pchb1 at pci0 dev 0 function 1 ServerWorks CMIC-WS Host (GC-LE) rev 0x00 pchb2 at pci0 dev 0 function 2 ServerWorks CMIC-LE rev 0x00 pci1 at pchb2 bus 1 mpt0 at pci1 dev 1 function 0 Symbios Logic 53c1030 rev 0x07: apic 13 int 6 (irq 9) scsibus0 at mpt0: 16 targets sd0 at scsibus0 targ 0 lun 0: LSILOGIC, 1030 IM, 1000 SCSI2 0/direct fixed sd0: 69878MB, 69879 cyl, 16 head, 127 sec, 512 bytes/sec, 143110145 sec total mpt0: target 0 Asynchronous at 0MHz width 8bit offset 0 QAS 0 DT 0 IU 0 fxp0 at pci1 dev 2 function 0 Intel 8255x rev 0x0c, i82550: apic 13 int 2 (irq 3), address
Re: Curious on NAT traversal possibility on PF
Spruell, Darren-Perot wrote: Maybe a better-designed application wouldn't have to make use of such a clusterbag of ports in the first place? The ports do not belong to a single application. I operate a gateway and want to give high priority to legitimate protocols and low priority to everything else. At the moment I have chosen this long list of legitimate ports: 21 (ftp, using ftp-proxy, needs special care), 22 (ssh), 25 (smtp), 53 (dns, tcp+udp), 80 (http), 110 (pop3), 119 (nntp), 123 (ntp, tcp+udp), 143 (imap2), 220 (imap3), 443 (https), 563 (nntps), 993 (imaps), 995 (pop3s), 1194 (openvpn, tcp+udp), 1863 (msn messenger im), 3128 (wwwproxy), 5050 (yahoo im), 5190 (icq im), 5222 (jabber im), 6667 (irc), 7000 (irc ssl). The list only serves to emphasize that I need to match a high number of ports :) To Daniel Quellet: Sorry for disturbing the topic of your thread. /Martin
Re: wikipedia article
On Mon, Jun 12, 2006 at 01:14:57PM -0700, John Nemeth wrote: The 80386 was the first x86 processor with paging (which all modern virtual memory systems are based around) and 32 bits. -is
Re: wikipedia article
Otto Moerbeek wrote: On Mon, 12 Jun 2006, Ted Mittelstaedt wrote: -Original Message- From: John Nemeth [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 1:15 PM To: Ted Mittelstaedt; Nikolas Britton; Ted Unangst Cc: Hamorszky Balazs; misc@openbsd.org; freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: RE: wikipedia article On Nov 1, 6:11pm, Ted Mittelstaedt wrote: } } Prior to the release of the 80386 the Intel processors didn't have } memory protection which was a requirement of any processor running } the BSD kernel. This is not entirely true. The 80286 had memory protection. However, its memory protection was completely based on segments (i.e. it could not do paging). Oh, yeah, your right about that. Me bad. Also, it was only a 16 bit processor. What was the bit size of the CPU's originally used to write UNIX in Bell Labs? The PDP-7 was/is an 18-bit machine. What's more, iirc the MMU of the pdp11 isn't what we call a MMU today, it could not even do paging. You're wrong. You could easily do paging on a PDP-11, if you wanted to. The main reasons this wasn't done are two. 1) Each page is 8K. At the time, that was considered way too large pages for a demand page system. 2) The address space is only 64 per process, which means you only have 8 pages. Not only is that perhaps a little little for meaningful paging (most programs tend to refer to all 8 pages most of the time). The main memory on a PDP-11 is furthermore 4 meg, so having a lot of processes full memory space in physical memory at the same time is not a problem. The PDP-11 MMU is a beatiful MMU. Nothing like the crap Intel spits out. ;-) Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: [EMAIL PROTECTED] || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: wikipedia article
On Tue, 13 Jun 2006, Johnny Billquist wrote: Otto Moerbeek wrote: On Mon, 12 Jun 2006, Ted Mittelstaedt wrote: -Original Message- From: John Nemeth [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 1:15 PM To: Ted Mittelstaedt; Nikolas Britton; Ted Unangst Cc: Hamorszky Balazs; misc@openbsd.org; freebsd-questions@freebsd.org; [EMAIL PROTECTED] Subject: RE: wikipedia article On Nov 1, 6:11pm, Ted Mittelstaedt wrote: } } Prior to the release of the 80386 the Intel processors didn't have } memory protection which was a requirement of any processor running } the BSD kernel. This is not entirely true. The 80286 had memory protection. However, its memory protection was completely based on segments (i.e. it could not do paging). Oh, yeah, your right about that. Me bad. Also, it was only a 16 bit processor. What was the bit size of the CPU's originally used to write UNIX in Bell Labs? The PDP-7 was/is an 18-bit machine. What's more, iirc the MMU of the pdp11 isn't what we call a MMU today, it could not even do paging. You're wrong. You could easily do paging on a PDP-11, if you wanted to. The main reasons this wasn't done are two. 1) Each page is 8K. At the time, that was considered way too large pages for a demand page system. 2) The address space is only 64 per process, which means you only have 8 pages. Not only is that perhaps a little little for meaningful paging (most programs tend to refer to all 8 pages most of the time). The main memory on a PDP-11 is furthermore 4 meg, so having a lot of processes full memory space in physical memory at the same time is not a problem. The PDP-11 MMU is a beatiful MMU. Nothing like the crap Intel spits out. ;-) I stand corrected. I always thought it coulnd't do paging, but I suppose it should be due to various restrictions, it couldn't do meaningful paging. -Otto
Re: Curious on NAT traversal possibility on PF
On 2006/06/13 12:26, Martin Toft wrote: Spruell, Darren-Perot wrote: Maybe a better-designed application wouldn't have to make use of such a clusterbag of ports in the first place? The ports do not belong to a single application. I operate a gateway and want to give high priority to legitimate protocols and low priority to everything else. At the moment I have chosen this long list of legitimate ports: Non-legitimate apps will also use these ports. You can't e.g. replicate what ellacoya boxes do just using PF.
Re: Curious on NAT traversal possibility on PF
On 6/13/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/06/13 12:26, Martin Toft wrote: Spruell, Darren-Perot wrote: Maybe a better-designed application wouldn't have to make use of such a clusterbag of ports in the first place? The ports do not belong to a single application. I operate a gateway and want to give high priority to legitimate protocols and low priority to everything else. At the moment I have chosen this long list of legitimate ports: Non-legitimate apps will also use these ports. You can't e.g. replicate what ellacoya boxes do just using PF. Maybe this can be shortened to the classical idea of ports 1024 being authoratative internet daemons, 1024 high priority 1024 low priority, except...
Re: Curious on NAT traversal possibility on PF
On 2006/06/13 08:26, Jeff Quast wrote: On 6/13/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/06/13 12:26, Martin Toft wrote: Spruell, Darren-Perot wrote: Maybe a better-designed application wouldn't have to make use of such a clusterbag of ports in the first place? The ports do not belong to a single application. I operate a gateway and want to give high priority to legitimate protocols and low priority to everything else. At the moment I have chosen this long list of legitimate ports: Non-legitimate apps will also use these ports. You can't e.g. replicate what ellacoya boxes do just using PF. Maybe this can be shortened to the classical idea of ports 1024 being authoratative internet daemons, 1024 high priority 1024 low priority, except... Depends what you're trying to do, but if it's e.g. throttling p2p users, that's only going to be of limited help. Relying on the side-behaviour of 'lots-of-connections' often seen with some protocols you might want to restrict, but not so often seen from a legitimate client, you have the option of using max-src-states and throttling hosts in the overload table. Care and attention is required though..
Re: wikipedia article
Johnny Billquist said: There's actually a cheesy way to do demand paging with microprocessors that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instruction causing the fault so contains restartable machine state. Masscomp sold a machine like this once. Didn't the first Apollos do this? And also the Sun 1. -- Rick Kelly [EMAIL PROTECTED] http://www.rmkhome.com/ http://rkba.rmkhome.com/
Xen domU for OpenBSD/amd64 demo
Hi, you can now download a beta version of the OpenBSD/amd64 port for Xen at http://cancel.adviseo.net/Open-BSD General notes: - It's a beta, don't expect it to be fully stable. It stills crashes for time to time. Feel free to report backtraces and conditions. (I'm thinking of hosting a debug kernel image) - The network driver is included, but still buggy. Most notable bug is that network demons don't work, no sshd or ftpd for now :( - Arithmetic coprocessor support is still missing, so some programs may crash/hang - It's an UP kernel. SMP is currently unsupported.. Kernel image (domU): http://cancel.adviseo.net/Open-BSD/bsd 3.9 default install image: http://cancel.adviseo.net/Open-BSD/disk (root password: adviseo) Xen-unstable hypervisor image with required patches for OpenBSD: http://cancel.adviseo.net/Open-BSD/xen.gz If you want to make your own image, you'll need to add the following: - Xen block device node (/dev/xbd*): block dev, major 20 - Xen block device node (/dev/rxbd*): char dev, major 85 - Xen virtual console device (/dev/xencons0): char dev, major 84, minor 0 - Set the root fs entry in /etc/fstab according to your image (most likely /dev/xbd0a) - Add '/dev/xencons0 0600/dev/console' to /etc/ftab - Add 'xencons0 /usr/libexec/getty Pc vt220 on secure' to /etc/ttys Sources are available too: Patches for OpenBSD 3.9 release kernel sources: http://cancel.adviseo.net/Open-BSD/amd64-xen.patch.gz (use the XENU config file in arch/amd64/conf) Full OpenBSD 3.9 release kernel sources with Xen pacthes: http://cancel.adviseo.net/Open-BSD/sys-amd64-xen.tar.gz Patches for Xen-unstable sources: http://cancel.adviseo.net/Open-BSD/xen-patches.tar.gz (make sure it's compiled with -DNDEBUG, else BSD won't work) Have fun! Mathieu
Hifn policy on documentation
Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. I hope that this clears the air. I would say: Bullshit... Docs are not interesting for the MOST customers and not everybody who reads the DOC is/or will become a Customer... So providing them via Torrent, anonymous FTP or HTTP WITHOUT Registration is possible for technical documentation. Otherwise most universities in the US shouldn`t provide ANY documentation (f.e. for any science project) either because they would have to care that the peoples who read it are customers (so, students..). I think you don`t understand the law you`ve mentioned correctly *my oppinion* Anyway.. I hope Theo will write a little statement if that policy is accaptable or not. Because such stuff influence my [hardware] decissions directly.. Kind regards, Sebastian -- Don't buy anything from YeongYang. Their Computercases are expensiv, they WTX-powersuplies start burning and their support refuse any RMA even there's still some warenty.
Re: Xen domU for OpenBSD/amd64 demo
you can now download a beta version of the OpenBSD/amd64 port for Xen at http://cancel.adviseo.net/Open-BSD Is this effort unique for amd64? Will i386 be supported too? Congratulations for the great job! Best Regards, -- Eduardo Alvarenga
Weird problem with PF and Load Balancing
Hi all, I'm willing to implement altq on my firewall but, right know, there is a problem that i didn't saw a solution for. I do have 2 ADSL links, and I'm doing load balancing for outgoing connections, using the round-robin option, and I'm also using the reply-to option to route back the packets that come in my secondary link (the one that isn't the default gateway of my firewall). Know to the problem. To implement altq in places with only one link, i do the following: set the bandwidth of the interface to it's maximum, in this case, 100Mb. Then, i set up 2 queues. One for deal with the traffic to firewall itself. Things as dhcp queries and ssh. This queue is configured with the max bandwidth minus the ADSL downstream bandwidth. So, there is one queue with 99.5MB, and other with 0.5Mb, for example. All traffic from internal network to the firewall itself, is put in the larger queue, and the traffic going to the internet is divided into another sub queues, but the point is that traffic not to the firewall is directed to another queue. I already had success with this kind of setup, with one link. Know to my problem. My 2 ADSL had different downstream bandwidth. And, as i'm using round-robin, i don't know where the connection is going. I don't kndow how to implement altq in this especific situation. I was thinking in something like: one queue for normal traffic to the firewall itself, with 99.2Mb. And two other queues with 0.5Mb and 0.3Mb respectively. But i don't know if this work, because i can assign only 1 queue per rule. And, with round-robin, i don't know where the packet is going. Thanks in advance, -- Giancarlo Razzolini Linux User 172199 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Snike Tecnologia em Informatica 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Partially functioning vlan
Stuart Henderson wrote: On 2006/06/12 06:26, John R. Shannon wrote: OpenBSD 3.9 stable NEXCOM EBSFL565 (dmesg at end of E-mail) I'm experiencing a problem with vlans on this device where intermittently, and occasionally the interface works, but mostly is inoperative. One minute I can ping a node, then I cannot. The interface works correctly without the vlan. OpenBSD 3.9-stable (NEXCOM) #0: Mon Jun 12 04:19:37 MDT 2006 I guess it's unlikely to make a difference, but just to be sure... it would be worth spending a little extra time to replicate this with a GENERIC kernel, ideally one downloaded from an openbsd mirror. It may also be worth checking a -current snapshot, since if it's a newer (C+) chip it may attach to a different driver, re(4) which may be better for you. Thanks. Switching to a CURRENT snapshot, with the re driver works. -- John R. Shannon
Re: What is the best way to read kernel memory into user memory?
add a new sysctl? On 6/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, What is the best way to read kernel memory into user memory? I want a simple array, eg int x[1024] and would like to read in it my programs. Thanks pn.
Re: Xen domU for OpenBSD/amd64 demo
Eduardo Alvarenga wrote: you can now download a beta version of the OpenBSD/amd64 port for Xen at http://cancel.adviseo.net/Open-BSD Is this effort unique for amd64? Will i386 be supported too? Congratulations for the great job! Best Regards, This one is currently working with amd64 arch, but i was told there is a google SoC project regarding i386 support. Some parts will need a cleanup to be fully arch-independent, but then, I think the i386 port will only be a matter of arch-dependent parts (eg: mostly pmap and interrupt/traps handling). Mathieu
Re: Xen domU for OpenBSD/amd64 demo
Eduardo Alvarenga wrote: you can now download a beta version of the OpenBSD/amd64 port for Xen at http://cancel.adviseo.net/Open-BSD Is this effort unique for amd64? Will i386 be supported too? Congratulations for the great job! Best Regards, This one is currently working with amd64 arch, but i was told there is a google SoC project regarding i386 support. Some parts will need a cleanup to be fully arch-independent, but then, I think the i386 port will only be a matter of arch-dependent parts (eg: mostly pmap and interrupt/traps handling). Mathieu
Re: Hifn policy on documentation
2006/6/13, Hank Cohen [EMAIL PROTECTED]: Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. If you guys would stop talking out of your ass and spend your time usefull (read: releasing FREE docs) you would see a increase of sales. Wijnand
Confirmar suscripcion y regalo.
Apreciado usuario: Nos encontramos en proceso de depuracion de nuestra lista de distribucion. Por favor seleccione: SI DESEA CONTINUAR RECIBIENDO UNA VEZ AL MES informacion de los ultimos desarrollos educativos en CD ROM y de la coleccion recetas de cocina; ademas de promociones y regalos, haga clic en el siguiente vinculo: Al hacer clic confirmara su suscripcion y obtendra un 20% de descuento en todos nuestros productos. (valido hasta el 15 de Julio de 2006, exceptuando promociones) http://www.vanguardiaeducativa.com/lista/[EMAIL PROTECTED] SI NO DESEA VOLVER A RECIBIR ESTA INFORMACION, haga clic en el siguiente vinculo: Al hacer clic se eliminara su correo de nuestra lista. http://www.vanguardiaeducativa.com/baja/[EMAIL PROTECTED] :::PROMOCION DEL MES :::GRATIS CD KARAOKE::: GRATIS Cd de KARAOKE por la compra del cd de juegos. Presentacion: Estuche doble para regalo. Contenido: CD 1 Juegos: Mas de 165 juegos de habilidad m! ental como el cubo de Rubic, crucigrama, estralandia; juegos clasicos como invasion extraterrestre, marcianitos, pacman, platillos voladores y juegos educativos para jovenes y ninos. CD 2: Karaoke: mas de 2. 160 pistas musicales de diferentes generos. Para ver detalle de cada cd y de otros productos haga clic en el siguiente vinculo: http://www.vanguardiaeducativa.com/formulario_cd_educativo.php Valor: $ 15.000 Incluido envio nacional SOLO HASTA EL 17 DE JUNIO O AGOTAR EXISTENCIAS. Vanguardia E-ducativa les desea a todos los padres felicidades en su dia. Saludos cordiales, Grupo Vanguardia educativa Telefono: 2506038 Medellmn - Colombia
Re: Hifn policy on documentation
On 13/06/06, Theo de Raadt [EMAIL PROTECTED] wrote: The simple fact is that anyone who wants access to Hifn's documentation need only log on to our extranet site (http://extranet.hifn.com/home/) to download as much as they like. That URL is not a place where you can download data sheets. That is a registration site that requires anyone who wants data sheets to enter approximately 50 personal questions. I can get documentation for pretty much 99% of the chips in the industry without supplying any private information. I don't TRUST you to keep my personal data private. As soon as one submits one's private information to Hifn, the submitted data indeed no longer could be considered private. Look at Hifn's HTML on the registration page: form action=http://extranet.hifn.com/home/anonymous/Default.asp; method=post name=userEdit onSubmit=return validate(this); Is Hifn running low on supplies of cryptography hardware accelerators? Or do these accelerators no longer work in recent operating systems due to the lack of documentation?
Re: wi: ifconfig txpower wrong for non 100mW wireless cards?
Thanks for the reply! On Tue, 13 Jun 2006, Stuart Henderson wrote: I think CR31 just maps over the whole range of the card, so for a card with a more powerful amp, a particular CR31 setting relates to higher power output than it would on an ordinary card. Yes, that is what I figured too from the source. I have a 200mW card here which I'd like to limit to 100mW (european limit) by setting the appropriate txpower after accounting for antenna gain/cable loss. However, I doubt that e.g. subtracting 3dBm is sufficient, say ifconfig wi0 txpower 17 won't give me the desired 100mW because the mapping is unlikely that linear or is it? The correct mapping is probably known only to the card manufacturer/ firmware vendor (for the curious: Senao NL-2511CD PLUS EXT2). While I'm at it an OT(?) question: Does somebody know how to _simply_ (using a multimeter or an old 20MHz scope) measure the power output of a wireless NIC? Just a rough (+-10mW) estimate would suffice. The antennae are external so I have access to the SMA. Then I could measure the mapping myself. With some cards setting CR31 too high can give a distorted signal and increase out-of-channel radiation (some references if you google for WAP11 CR31 e.g. http://www.maokhian.com/wireless/wap11.html) Thanks for the reference. I'm trying to lower txpower to a _certain_ level, though. Google will find ways to increase power but I'm interested in the actual txpower value. So I wondered if ifconfig displays txpower correctly. As it turned out, not for cards != 100mW. Regards, Walter
Re: Hifn policy on documentation
From: [EMAIL PROTECTED] There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. I'm not sure the explanation sets anything *straight*. Hifn wishes to try to open things up to be what they think is open enough for the open source community to use, but they can't commit to do it right. Is Hifn open or not? There is no mostly open or kind of open or open under conditions A B and C, and be sure to give us personal information. Software licenses are generally restricted in the disclosure or source code reproduction rights. Hifn reserves the right to keep our source code proprietary. This should not affect the hifn(4) driver since that driver is programmed directly to the hardware and does not use Hifn's enablement software library. Software license? Code? You, like many vendors before you, make the mistake of thinking that it is your source code that is wanted. NO ONE WANTS YOUR SOURCES. Specifications and documentation on how to interface with the hardware is what is useful. Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. Weak. Docs and specifications != product. Look. I am an example of somebody who purchased a Hifn product because at the time I had some idea that the card would be well supported by the OS that I would use it in. I've since lost that warm fuzzy. If the required documentation can't be opened up, correctly, to the developers who would write OS drivers for it, then I have no need to buy more (or even continue using my existing half-supported card.) I am an example of someone who could very well no longer purchase Hifn, nor recommend that others purchase it for their own use, based on the fact that my OS vendors of choice cannot adequately support it. I have other choices. DS
Re: Recommendations for an OpenBSD-based Backup Solution
On 3/20/06, Donald J. Ankney [EMAIL PROTECTED] wrote: I threw together a Perl script that uses tar and external firewire drives. Tar has flags that will let it backup over SMB (for the windows boxes) and one can always do use scp (via certificates) piped through tar for remote linux/BSD boxes. I've been using this solution across several platforms (all servers) for a year now, and it has worked well. Does firewire work under OpenBSD? According to http://www.openbsd.org/i386.html firewire is unsupported. What is the state of firewire support (for external discs)? I have an upcoming install for which I've written off OpenBSD due to this, and I'd very much like to be able to use it. Dag
Re: wikipedia article
On Tuesday 13 June 2006 14:23, Rick Kelly wrote: Johnny Billquist said: There's actually a cheesy way to do demand paging with microprocessors that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instruction causing the fault so contains restartable machine state. Masscomp sold a machine like this once. Didn't the first Apollos do this? And also the Sun 1. IIRC it was simpler than that. When the first cpu caused a 'miss' it was put in wait and cpu 2 handled the pagein and then released cpu 1. Keeping the two cpus synched, one instruction apart would have been too complicated if not impossible...
Re: wi: ifconfig txpower wrong for non 100mW wireless cards?
On 2006/06/13 17:59, Walter Haidinger wrote: I think CR31 just maps over the whole range of the card, so for a card with a more powerful amp, a particular CR31 setting relates to higher power output than it would on an ordinary card. Yes, that is what I figured too from the source. I have a 200mW card here which I'd like to limit to 100mW (european limit) by setting the appropriate txpower after accounting for antenna gain/cable loss. However, I doubt that e.g. subtracting 3dBm is sufficient, say ifconfig wi0 txpower 17 won't give me the desired 100mW because the mapping is unlikely that linear or is it? The correct mapping is probably known only to the card manufacturer/ firmware vendor (for the curious: Senao NL-2511CD PLUS EXT2). More than that, it's differs from card to card (and channel to channel). Manufacturers perform calibration before shipping the card, and preset the levels for each channel, I remember looking at a couple of WAP11 (with similar serial numbers and presumably from the same batch) and seeing quite different figures on each of them. While I'm at it an OT(?) question: Does somebody know how to _simply_ (using a multimeter or an old 20MHz scope) measure the power output of a wireless NIC? Just a rough (+-10mW) estimate would suffice. The antennae are external so I have access to the SMA. Then I could measure the mapping myself. Does anybody know if there are any cards with reasonably accurate signal strength indication? I've seen quite different figures for similar cards in similar situations so not sure if they're really believable... Thanks for the reference. I'm trying to lower txpower to a _certain_ level, though. Google will find ways to increase power but I'm interested in the actual txpower value. So I wondered if ifconfig displays txpower correctly. As it turned out, not for cards != 100mW. I think, even for 100mW prism cards, the display we have is only an approximation. I'm not sure there is a way to go from the unit-less figures to actual dBm with any degree of accuracy. Presumably this also changes according to temperature, age of the card, etc.
Re: Hifn policy on documentation
2006/6/13, Hank Cohen [EMAIL PROTECTED]: Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. For me it goes like this. I use OpenBSD because it is stable and secure and well documented. I don't need to register to read the wonderful man page and know how it work and what's supported or not. Adaptec got substantial sale drop last year and don't take my word for it. Just look at the public results they need to release for the stock market. They don't respect their possible users to make the documentations available to great developers to make sure their hardware works well on my OS of choice that is NOT Microsoft thank you! The results, simple, I have no more Adaptec what so ever in my business, NONE and trust me, I do have plenty of servers. See I have the choice like may here to buy of recommend hardware we see as good and well supported. I wouldn't recommend to any of my customers any hardware that is not working properly because a company do not see the light and restrict my choice by not allowing their chips to be well supported, so I go else where to get what I need and yes, I do look at specs and buy what I see as good and supported for me. Hifn's is not on my list and join the same dead beat, not look at list as Adaptec did. See, it's great out there, we have choice to pick what we want to use and my choice is to pick well supported hardware by MY OS of choice and the well supported come to no price to you what so ever, other then providing a place to download documentation to write good drivers for your hardware. You don't even have to write the code, even the cost of distributing your well written drive ( if it even come to that) is not even yours! So, I will return that to you and say, yes, That discussion lead to a great deal of uninformed speculation... you try to tell people that you respect their choice and you think they are allow to make their own choice. I guess not. Just learn from other mistakes and wins. Hardware buy goes to well open hardware makers and looks like most of them are not from the US these days, but they do see me as a valuable customers and they do want me to have well working servers as they make sure their product is well supported on my choice of hardware, not by writing BLOB, but by providing documentations and let the one that know best how to support their hardware do it on my OS of choice! Do you understand what I am saying and trying to make you understand!? And the bottom line is simple. If Theo said I don't TRUST you to keep my personal data private., nor do I. And as express to you, We are not your customers. YOU ARE OUR CUSTOMER.. So may be it's time you understand this and bring it up the food chain in your business too! Also, And if you continue baiting me, I will delete the driver from our source tree., I wouldn't push it really. He did remove Adaptec from OpenBSD last year and that was great as I didn't even have to question if it was working well or not. It wasn't there, so no time waisting to even try! So, you want sales, just make the documentation !!!FREELY!!! available and you would be surprise of what it does, plus you really have nothing to loose! It doesn't cost you anything! So, instead of hiring many more sales guys, or even PR guys to preach the good of Hifn, let us do it fro you! How, well simple... Open the documentation and then watch the list where everyone ready it and see your chips working well on OpenBSD and then working well on ALL other project over time! I think you forget the most important things here. All Open Source project do exchange with each other, some more then others, but they all know what they other is doing! Do the right thing and see everyone looks favorably to you in the end! ISn't it what you spend lots of money in marketing to have users look favorably to your chips so they use them? Plus see this as an improvement, you increase your sales and you reduce your costs! Yes you do. No more needs to have servers keeping all that private informations, and people looks at it and some more classifying it, and some more communicating it to others, etc. See, in the end, that increase your profit from day one! Don't you like it? Best, Daniel PS: I wish you the best in your future, what ever your choice might be. Your call if that's going to be UP or DOWN.
Re: Curious on NAT traversal possibility on PF
Martin Toft wrote: To Daniel Quellet: Sorry for disturbing the topic of your thread. That's cool! No worry, I guess your subject is way more interesting to many, or no one is using NAT traversal or have any needs for it. That's fair game. (; Daniel
Re: err packets on Intel PRO/1000T
Matt Wilkins wrote: hi, i just recently upgraded our firewall from 3.7 to 3.8 and am now seeing errors on our internal interface: fw:~ netstat -i -I em1 1 em1 inem1 out total in total out packets errs packets errs colls packets errs packets errs colls 868776781 9354286 861778095 0 0 3822691341 9354286 3782693933 0 0 149714 1500 0 0 593814 5631 0 0 160610 1743 0 0 613610 5822 0 0 161510 1685 0 0 585310 5605 0 0 1604 4 1642 0 0 4961 4 4988 0 0 I can't provide you an answer for sure other then. Go at 3.9, don't stop at 3.8: On a new box just turn up a few hours ago: 2:54PM up 12:36, 1 user, load averages: 0.44, 0.40, 0.34 # netstat -i -I em1 1 em1 inem1 out total in total out packets errs packets errs colls packets errs packets errs colls 506391 0 193934 0 0 1424366 0 1207081 0 0 When you spend time upgrade and that's a good thing, just don't stop half way, but go all the way. (; Hope this help you some anyway. Best, Daniel
Re: Hifn policy on documentation
Hank Cohen wrote: I hope that this clears the air. I was hopeful too, at the beginning of your message. As I neared the end I was becoming skeptical, and by the time I clicked through to the registration page I was fairly certain where this was heading. Several posts later and it looks like I was right. I'm not the only person who puts a great deal of value on personal data. Your company's personnel seems to do so as well - I have tried fairly hard over the last week to find contact information for your executives with no success. Hmmm, imagine that! I think that you may have misunderstood your target market, or at least a portion of it. Users of OpenBSD tend to be the most cynical type of person you are going to encounter. Many of us have gravitated towards OpenBSD because we have been burnt in the past. We tend to guard our data jealously. I haven't input my personal data on a website request form for years, and I am not about to start. And I'm nowhere near as hardcore as some of the people here. We have good reason not to trust corporations - look at Enron. If shareholders cannot trust their executives to fulfill the highest duty of a corporation - to maximize shareholder profit - then how can we trust any company (which we do not even have a financial interest in) to protect personal data which we supply? We might as well be done with it and just post it to a website for all the world to see. Why this should matter to you is that we (OpenBSD users) drive sales of your product. Hifn, on the other hand, does not drive sales of OpenBSD. The dynamic of this relationship puts the onus on Hifn to cater to OpenBSD's requirements if Hifn wishes to continue to benefit from the relationship. OpenBSD requires unrestricted access to documentation, which doesn't create a conflict with the export controls of the USA. Theo will pull Hifn from the source tree if push comes to shove, and at this point I could not care less. My Soekris vpn1411 is sitting on the shelf next to my machine rather than inside of it. This is due to the fact that it does not work the way it should. I would prefer to see something good come of all of this, but if I have to trash my vpn1411 then it really doesn't make the situation any worse than it already is. At least for me. It will definitely make it worse for Hifn. If this situation does not resolve itself for the better then I will not buy any further Hifn technology. But it gets even worse: I will not recommend Hifn technology. In fact, I will speak very openly and very negatively about the company and their products. This might not seem like a big loss until you look deeper at who I know. My friends all work in the IT industry. We talk about work all the time. Several of them work for the federal and provincial governments and crown corporations of Canada. They will certainly be seeing Hifn products in a new light. One of them works for one of Canada's largest cities in the emergency preparedness department. These guys take their security seriously because they are on the front line of terrorism prevention. He will definitely listen with great interest to what I have to say about Hifn, and he will be sure to pass it up the chain. My wife works for one of the big four global accounting firms. The national IT personnel will hear all about Hifn next month at the company BBQ. My uncle owns several oil and mining companies in Canada. My other uncle was in the military and is well connected. Other relatives and friends work in government, law, accounting, and engineering all across the country. The subject of Hifn is likely to come up the next time I see each of them, as well. Now multiply my contacts by the number of OpenBSD users who take this stuff seriously (which just so happens to be the majority of them). It's not a pretty picture. I'm behind Theo 100%. The average person might consider him to be over-reacting. I would counter that the average person will never be involved in the purchase of a Hifn product. I strongly suggest that you consider who you are about to alienate before you go and do it. There is still an opportunity to make this into a positive situation for Hifn and OpenBSD. Breen Ouellette
Re: Recommendations for an OpenBSD-based Backup Solution
The last time I looks there was no Firewire or Firewire disk support in the Kernel. Expect that if it is done at some stage that it is done correctly, you won't get Disk support without Firewire being supported as a bus type (no quick hacks here). -Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dag Wastberg Sent: 13 June 2006 18:48 To: Donald J. Ankney; misc@openbsd.org Subject: Re: Recommendations for an OpenBSD-based Backup Solution On 3/20/06, Donald J. Ankney [EMAIL PROTECTED] wrote: I threw together a Perl script that uses tar and external firewire drives. Tar has flags that will let it backup over SMB (for the windows boxes) and one can always do use scp (via certificates) piped through tar for remote linux/BSD boxes. I've been using this solution across several platforms (all servers) for a year now, and it has worked well. Does firewire work under OpenBSD? According to http://www.openbsd.org/i386.html firewire is unsupported. What is the state of firewire support (for external discs)? I have an upcoming install for which I've written off OpenBSD due to this, and I'd very much like to be able to use it. Dag
dd ... of=/dev/sd0 creates a file instead of writing to disk
I've having a problem understanding how to write data to a disk. I want to wipe an old hard drive before getting rid of it. I have attached the hard drive to my system via usb. Normally, this would work (in different OS's): # dd if=/dev/urandom of=/dev/sd0 However, this command creates a file /dev/sd0 and fills it with random data. I want to write this data to the disk instead. The same thing happens when I use /dev/rsd0. Any help would be appreciated. OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz (GenuineIntel 686-class) 3 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,CNXT-ID real mem = 2146140160 (2095840K) avail mem = 1952206848 (1906452K) using 4278 buffers containing 107409408 bytes (104892K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 01/21/04, BIOS32 rev. 0 @ 0xf0010 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3d40/208 (11 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801EB/ER LPC rev 0x00) pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0xf800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82875P Host rev 0x02 ppb0 at pci0 dev 1 function 0 Intel 82875P AGP rev 0x02 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 NVIDIA Quadro4 NVS rev 0xc1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at pci0 dev 3 function 0 Intel 82875P PCI-CSA rev 0x02 pci2 at ppb1 bus 2 em0 at pci2 dev 1 function 0 Intel PRO/1000CT (82547EI) rev 0x00: irq 10, address 00:11:11:b3:77:c6 uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: irq 11 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: irq 5 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: irq 10 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: irq 11 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: irq 9 usb4 at ehci0: USB revision 2.0 uhub4 at usb4 uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ppb2 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci3 at ppb2 bus 3 emu0 at pci3 dev 1 function 0 Creative Labs SoundBlaster Live rev 0x07: irq 11 ac97: codec id 0x83847608 (SigmaTel STAC9708/11) ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D audio0 at emu0 Creative Labs PCI Gameport Joystick rev 0x07 at pci3 dev 1 function 1 not configured ichpcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801EB/ER IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: ST3120022A wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SONY, CD-ROM CDU5212, 5YS1 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 pciide1 at pci0 dev 31 function 2 Intel 82801EB SATA rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using irq 10 for native-PCI interrupt wd1 at pciide1 channel 0 drive 0: Maxtor 6L300S0 wd1: 16-sector PIO, LBA48, 286188MB, 586114704 sectors wd1(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 ichiic0 at pci0 dev 31 function 3 Intel 82801EB/ER SMBus rev 0x02: irq 3 iic0 at ichiic0 adt0 at iic0 addr 0x2e: emc6d10x (ADT7460) rev 65 isa0 at ichpcib0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker 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 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask ff6d netmask ff6d ttymask ffef pctr: user-level cycle counter enabled uhub5 at
Re: dd ... of=/dev/sd0 creates a file instead of writing to disk
Normally, this would work (in different OS's): # dd if=/dev/urandom of=/dev/sd0 However, this command creates a file /dev/sd0 and fills it with random data. I want to write this data to the disk instead. The same thing happens when I use /dev/rsd0. You want sd0c or rsd0c (hint: man 4 sd, FILES section).
Re: Hifn policy on documentation
On 6/13/06, Breen Ouellette [EMAIL PROTECTED] wrote: I'm behind Theo 100%. The average person might consider him to be over-reacting. I would counter that the average person will never be involved in the purchase of a Hifn product. Adding to your statement: I would be what you call the average person, and heaven forbid, I would never purchase any hardware that the OpenBSD Gods did not bless. The simple reason behind it is that I'm totally reliant on the OpenBSD developers for support and whatever is good for them is the only thing that's good for me. - Raja
Re: dd ... of=/dev/sd0 creates a file instead of writing to disk
On Tue, Jun 13, 2006 at 12:14:21PM -0700, Joe wrote: I've having a problem understanding how to write data to a disk. I want to wipe an old hard drive before getting rid of it. I have attached the hard drive to my system via usb. Normally, this would work (in different OS's): # dd if=/dev/urandom of=/dev/sd0 However, this command creates a file /dev/sd0 and fills it with random data. I want to write this data to the disk instead. The same thing happens when I use /dev/rsd0. Any help would be appreciated. do you actually have a 'sd0' in /dev? fdisk/disklabel may take 'sd0' as a reserved meta keyword shortcut for device, but 'dd' has no special handling like that, afair, so when you say 'of=/dev/sd0' you are really asking it to put data in that literal file. perhaps try the 'c' partition if you intend to write to the entire disk. -- jared [ openbsd 3.9-current GENERIC ( may 1 ) // i386 ]
Re: dd ... of=/dev/sd0 creates a file instead of writing to disk
Miod Vallat wrote: Normally, this would work (in different OS's): # dd if=/dev/urandom of=/dev/sd0 However, this command creates a file /dev/sd0 and fills it with random data. I want to write this data to the disk instead. The same thing happens when I use /dev/rsd0. You want sd0c or rsd0c (hint: man 4 sd, FILES section). That worked. Thank you.
Re: dd ... of=/dev/sd0 creates a file instead of writing to disk
On Tue, Jun 13, 2006 at 12:14:21PM -0700, Joe wrote: I've having a problem understanding how to write data to a disk. I want to wipe an old hard drive before getting rid of it. I have attached the hard drive to my system via usb. Normally, this would work (in different OS's): # dd if=/dev/urandom of=/dev/sd0 Specify the slice (i.e. /dev/rsd0c to access the entire disk) However, this command creates a file /dev/sd0 and fills it with random data. I want to write this data to the disk instead. The same thing happens when I use /dev/rsd0. Any help would be appreciated. OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz (GenuineIntel 686-class) 3 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,CNXT-ID real mem = 2146140160 (2095840K) avail mem = 1952206848 (1906452K) using 4278 buffers containing 107409408 bytes (104892K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 01/21/04, BIOS32 rev. 0 @ 0xf0010 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3d40/208 (11 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801EB/ER LPC rev 0x00) pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0xf800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82875P Host rev 0x02 ppb0 at pci0 dev 1 function 0 Intel 82875P AGP rev 0x02 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 NVIDIA Quadro4 NVS rev 0xc1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at pci0 dev 3 function 0 Intel 82875P PCI-CSA rev 0x02 pci2 at ppb1 bus 2 em0 at pci2 dev 1 function 0 Intel PRO/1000CT (82547EI) rev 0x00: irq 10, address 00:11:11:b3:77:c6 uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: irq 11 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: irq 5 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: irq 10 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: irq 11 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: irq 9 usb4 at ehci0: USB revision 2.0 uhub4 at usb4 uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ppb2 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci3 at ppb2 bus 3 emu0 at pci3 dev 1 function 0 Creative Labs SoundBlaster Live rev 0x07: irq 11 ac97: codec id 0x83847608 (SigmaTel STAC9708/11) ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D audio0 at emu0 Creative Labs PCI Gameport Joystick rev 0x07 at pci3 dev 1 function 1 not configured ichpcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801EB/ER IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: ST3120022A wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SONY, CD-ROM CDU5212, 5YS1 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 pciide1 at pci0 dev 31 function 2 Intel 82801EB SATA rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using irq 10 for native-PCI interrupt wd1 at pciide1 channel 0 drive 0: Maxtor 6L300S0 wd1: 16-sector PIO, LBA48, 286188MB, 586114704 sectors wd1(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 ichiic0 at pci0 dev 31 function 3 Intel 82801EB/ER SMBus rev 0x02: irq 3 iic0 at ichiic0 adt0 at iic0 addr 0x2e: emc6d10x (ADT7460) rev 65 isa0 at ichpcib0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0
Re: Extremely weird PF behaviour
Dear Stuart. The translation is offcourse BEFORE the filtering ! Any other thoughts about the problem ? On 6/13/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/06/13 05:26, Alex Stamatis wrote: I have a veeeryyy veeeryyy weird problem !!! Not really... I have small network. The Openbsd box (3.7 generic) is my firewall. In 2 of my windows workstations I wont to have remote desktop. So I make a pass in rule for the ports 65500 and 65501 and a rdr of these 2 ports 65500 to 1 ip at 3389 internal port and the 65501 to another ip in 3389. It wont play from the outside world. Read the first couple of paragraphs of the TRANSLATION section of pf.conf(5), then you'll see that translation comes *before* filtering.
ichiic0: errors on MP (Sorry about the no subject post!)
As anyone seen this? No matter what I do I cant stop this from happing. I am at the point of being forced to use another OS that I DONT want to use. Any help would be very much appreciated. This only happens when running the MP kernel. The GENERIC kernel runs just fine. This sticks out to me, but I cant not find any reference in the archives about it other that netbsd stuff that doesnt track with the errors I am seeing. pci_intr_map: no MP mapping found Thanks Bill ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE This is a dual Xeon machine. OpenBSD 3.9 (GENERIC.MP) #598: Thu Mar 2 02:37:06 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Xeon(TM) CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,C NXT-ID real mem = 2146791424 (2096476K) avail mem = 1952743424 (1906976K) using 4278 buffers containing 107442176 bytes (104924K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 03/29/05, BIOS32 rev. 0 @ 0xf0010 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf51d0/336 (19 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801EB/ER LPC rev 0x00) pcibios0: PCI bus #4 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xc9000/0x1000 ipmi at mainbus0 not configured mainbus0: Intel MP Specification (Version 1.1) (INTELLINDENHURST ) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200 MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,C NXT-ID mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type PCI mainbus0: bus 3 is type PCI mainbus0: bus 4 is type PCI mainbus0: bus 5 is type ISA ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 8 pa 0xfec1, version 20, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel E7320 MCH rev 0x0c ppb0 at pci0 dev 2 function 0 Intel MCH PCIE rev 0x0c pci1 at ppb0 bus 1 ppb1 at pci0 dev 3 function 0 Intel MCH PCIE rev 0x0c pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 0 Intel 6300ESB PCIX rev 0x02 pci3 at ppb2 bus 3 em0 at pci3 dev 3 function 0 Intel PRO/1000MT (82541GI) rev 0x00: apic 8 int 2 (irq 5), address 00:30:48:56:fb:20 em1 at pci3 dev 4 function 0 Intel PRO/1000MT (82541GI) rev 0x00: apic 8 int 3 (irq 5), address 00:30:48:56:fb:21 ppb3 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0x0a pci4 at ppb3 bus 4 vga1 at pci4 dev 5 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ichpcib0 at pci0 dev 31 function 0 Intel 6300ESB LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 6300ESB IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to co mpatibility wd0 at pciide0 channel 0 drive 0: WDC WD800JB-00JJC0 wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) ichiic0 at pci0 dev 31 function 3 Intel 6300ESB SMBus rev 0x02pci_intr_map: bus 0 dev 31 func 3 pin 2; line 11 pci_intr_map: no MP mapping found : irq 11 iic0 at ichiic0 lm1 at iic0 addr 0x2c: W83627HF lm2 at iic0 addr 0x2f: W83782D rev D isa0 at ichpcib0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lm0 at isa0 port 0x290/8: W83627HF lm1 detached npx0 at isa0 port 0xf0/16: 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 0 netmask 0 ttymask 0 pctr: user-level cycle counter enabled apm0: disconnected dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0: transaction abort failed, status 0x42INTR,INUSE ichiic0: timeout, status 0x0 ichiic0:
Re: Hifn policy on documentation
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hank Cohen Sent: Monday, June 12, 2006 9:10 PM To: misc@openbsd.org Subject: Hifn policy on documentation Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. Mr. Cohen, Perhaps you can talk to your legal counsel and actually break out the documentation needed for these open source drivers into a separate and truly open to the general public anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations. Your customer's locations can be tracked through the distribution network of your chips and devices that you already have in place. OpenBSD is not selling, reselling, or modifying your products. Nor is OpenBSD asking to download drivers or other source code that you may provide to others. I understand it's very easy these days for attorneys to just say put everything behind your registration only access extranet to be safe. This is not acceptable and, in my opinion, is not open to the general public like you stated. It might take some effort on your part and that of your legal counsel and compliance officers to keep the open source community happy and the US Government off your back, but I think you'll find it will be worth it in the end. You obviously care how the people reading this list perceive your company and products or you wouldn't have written that letter; now please take it a step further in the right direction. Regards, Michael Scheliga
refund of 3.80
\ [IMAGE] After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of 3.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, please click here Regards, Internal Revenue Service ) Copyright 2006, Internal Revenue Service U.S.A. All rights reserved..
Re: Curious on NAT traversal possibility on PF
On 2006/06/13 14:58, Daniel Ouellet wrote: That's cool! No worry, I guess your subject is way more interesting to many, or no one is using NAT traversal or have any needs for it. I don't know much about H.323, but for SIP draft-biggs-sip-nat has some useful information, care needs to be taken not to break other nat- traversal mechanisms though (google: SIP ALG break), and there are a lot of strange UAs around... Another way for SIP is ser/openser and mediaproxy, but it definitely needs work to configure, it's nothing like how ftp-proxy/tftp-proxy work (which seems to be more the sort of thing you're looking for).
Re: Stunnel Connection Failure, undeadly.cgi
Was gonna write about this soon. Run into the same problem while upgrading a machine from 3.5 to 3.9. running an exec cmd not in a pty is broken in stunnel since they added --enable-ipv6 in OpenBSD 3.7. It fails in make_sockets() in client.c. I could make it work by not using --enable-ipv6. Was gonna try by undefining INET_SOCKET_PAIR in client.c to see if that worked but got sidetracked. I didn't debug the program to see what was wrong. This is what I figured from ktracing it. On Mon, Jun 12, 2006 at 04:02:57PM -0400, Seth Hanford wrote: -- The message below was posted to ports@ earlier this morning. I got some feedback, mostly encouraging me to post to [EMAIL PROTECTED] I've incorporated the client = no suggestion, and rerun my stunnel.log, still no success. I have also tried without the chroot, and appropriate path changes. I'm trying to use stunnel to run dhartmei's undeadly.org CGI on my personal web server. However, I can't get stunnel to connect to the https auth CGI. Is anyone else having connect problems with stunnel-4.14p0 under i386? Any ideas on why the connects are failing? Even running under debug level 7, I can't figure out what to do differently. Similar errors have been reported (i found 1 at least) to stunnel-users by OpenBSD users, but got no replies. I'm running thttpd-2.25b and stunnel-4.14p0 from packages. Stunnel is invoked from the command line, not currently running from inetd. What I've included below is a fresh log -- stunnel.log is removed after stunnel is kill'd. Then, I start stunnel and try a single https request to my server. I'm connecting primarily from Opera 9 on OS X, but have tried with lynx, safari and IE each with the same results. Thanks for any tips/assistance, Seth Hanford stunnel.conf # Modified for OpenBSD by Michael Schubert 2003 cert = /etc/ssl/server.crt key = /etc/ssl/private/server.key chroot = /var/www/htdocs/auth setuid = _stunnel setgid = _stunnel pid = /var/www/htdocs/auth/stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 output = /var/www/htdocs/auth/stunnel.log client = no [https] accept = 443 exec = /cgi execargs = cgi TIMEOUTclose = 0 TIMEOUTidle = 10 2006.06.12 15:58:15 LOG3[19137:2270484480]: connect: Invalid argument (22) -- Hugo Villeneuve [EMAIL PROTECTED] http://EINTR.net/
Re: Extremely weird PF behaviour
On 2006/06/13 22:57, Alex Stamatis wrote: The translation is offcourse BEFORE the filtering ! Any other thoughts about the problem ? I don't mean, being listed first in pf.conf. I'm talking about the order of actions on the packet. 1. Packets come into your box addressed to port 65500 2. NAT is carried out, port in packet is rewritten to 3389 3. Filter is carried out, port in packet says 3389: - does this match pass in...to port 65500? - no. - does this match pass in...to port 65501? - no. The pass in rule must be for the *rewritten* port, i.e. 3389 If this is hard to understand, forget the separate 'pass in' rules and just use 'rdr pass'.
Re: Curious on NAT traversal possibility on PF
Stuart Henderson wrote: On 2006/06/13 14:58, Daniel Ouellet wrote: That's cool! No worry, I guess your subject is way more interesting to many, or no one is using NAT traversal or have any needs for it. I don't know much about H.323, but for SIP draft-biggs-sip-nat has some useful information, care needs to be taken not to break other nat- traversal mechanisms though (google: SIP ALG break), and there are a lot of strange UAs around... Another way for SIP is ser/openser and mediaproxy, but it definitely needs work to configure, it's nothing like how ftp-proxy/tftp-proxy work (which seems to be more the sort of thing you're looking for). Actually I wasn't looking for ftp-proxy type, but really for SIP NAT traversal. Sorry if I didn't make that clear. Not going into any details, but in short, and very simplistically as well, connection are establish out to a phone behind NAT for example coming from 5060 to port 5060 on the CPE device as SIP defines it and the reply will be send back to port 5061 oppose to what would be expected to come back to 5060. So, the NAT traversal is use to really handle the traffic, but not looking at the reply to the port use for sending, but to the port+1 instead for SIP communications. This is a very simplistic description obviously, but I thought it would be best handle by PF instead of an other proxy, but I may well be wrong. Trying to keep it simple and I thought that may be a hook inside PF would accomplish this very well. Isn't it the case? I would welcome feedback or idea on this if I am thinking about it the wrong way. If best serve by yet an other proxy type of daemon, then may be I could try to break my teeth on it, but I really thought it was best inside PF. Thoughts?
Re: Extremely weird PF behaviour
Dear Stuart your reply is very much appriciated ! Thank you for sparing some
time to help me out.
I am pasting the rules so you can understand what I did. If I understand
correctly I did what you suggest allready!
Take a look :
Nat - Rdr Rules :
nat on $ext_if from { 192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.4
192.168.0.69 192.168.0.227 } to any - ($ext_if)
#
rdr on $ext_if proto tcp from any to ($ext_if) port 3389 - 192.168.0.1 port
3389
rdr on $ext_if proto tcp from any to ($ext_if) port 65500 -
192.168.0.2port 3389
Filtering Rules :
pass in on $ext_if proto tcp from any to any port 3389 keep state
pass in on $ext_if inet proto tcp from any to ($ext_if) port 65500 keep
state
Best Regards
Alex
On 6/13/06, Stuart Henderson [EMAIL PROTECTED] wrote:
On 2006/06/13 22:57, Alex Stamatis wrote:
The translation is offcourse BEFORE the filtering ! Any other thoughts
about
the problem ?
I don't mean, being listed first in pf.conf. I'm talking about
the order of actions on the packet.
1. Packets come into your box addressed to port 65500
2. NAT is carried out, port in packet is rewritten to 3389
3. Filter is carried out, port in packet says 3389:
- does this match pass in...to port 65500? - no.
- does this match pass in...to port 65501? - no.
The pass in rule must be for the *rewritten* port, i.e. 3389
If this is hard to understand, forget the separate 'pass in'
rules and just use 'rdr pass'.
Re: refund of 3.80
After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of 3.80. I sure hope they update their records so that OpenBSD 3.9 qualifies for a tax refund as well!
suspended zaurus doesn't wake up (-CURRENT)
Hi, when suspending the zaurus using a -CURRENT kernel or the latest snapshot (from june, 8th), it isn't possible to wake up the system. This happens both with power supply connected and with battery only, as well as with pressing the on/off button or invoking zzz(8). With a kernel from may, 19th still works. Could anyone please test and confirm this problem using a snapshot? Ciao, Kili dmesg from snapshot, followed by a diff from the last working version built from cvs HEAD I've on my disk: OpenBSD 3.9-current (GENERIC) #51: Thu Jun 8 14:52:46 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/zaurus/compile/GENERIC real mem = 67108864 (65536K) 64MB avail mem = 53313536 (52064K) using 844 buffers containing 3457024 bytes (3376K) of memory mainbus0 (root) cpu0 at mainbus0: PXA27x step C-0 (XScale core) cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled cpu0: 32KB(32b/l,32way) I-cache, 32KB(32b/l,32way) wr-back-lock D-cache pxaip0 at mainbus0: CPU clock = 416.000 MHz pxaintc0 at pxaip0 addr 0x40d0: Interrupt Controller pxagpio0 at pxaip0 addr 0x40e0: GPIO Controller pxadmac0 at pxaip0 addr 0x4000 intr 25: DMA Controller pxaost0 at pxaip0 addr 0x40a0 com0 at pxaip0 addr 0x4010 intr 22: pxa2x0, 32 byte fifo com1 at pxaip0 addr 0x4020 intr 21: pxa2x0, 32 byte fifo com2 at pxaip0 addr 0x4070 intr 20: pxa2x0, 32 byte fifo (SIR) pxaudc0 at pxaip0: USB Device Controller ohci0 at pxaip0, version 1.0 usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: PXA27x OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered lcd0 at pxaip0 wsdisplay0 at lcd0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1 added (std, vt100 emulation) zkbd0 at pxaip0 wskbd0 at zkbd0: console keyboard, using wsdisplay0 scoop0 at pxaip0: PCMCIA/GPIO controller scoop1 at pxaip0: PCMCIA/GPIO controller pxapcic0 at pxaip0: 2 slots pcmcia0 at pxapcic0 pcmcia1 at pxapcic0 zssp0 at pxaip0 apm0 at pxaip0 zts0 at pxaip0 wsmouse0 at zts0 mux 0 zaudio0 at pxaip0: I2C, I2S, WM8750 Audio audio0 at zaudio0 zrc0 at pxaip0: CE-RH2 remote control wskbd1 at zrc0 mux 1 wskbd1: connecting to wsdisplay0 clock: hz=100 stathz=64 wdc0 at pcmcia0 function 0 HITACHI, microdrive port 0x0/16: irq 138 wd0 at wdc0 channel 0 drive 0: HMS360404D5CF00 wd0: 32-sector PIO, LBA, 3906MB, 7999488 sectors wd0(wdc0:0:0): using BIOS timings aue0 at uhub0 port 2 aue0: USBs USB 10/100 Fast Ethernet, rev 1.10/1.01, addr 2 aue0: address 00:e0:98:9b:df:16 acphy0 at aue0 phy 1: AC_UNKNOWN 10/100 PHY, rev. 0 boot device: wd0. rootdev=0x1000 rrootdev=0x1000 rawdev=0x1002 --- dmesg.zaurus.oldTue Jun 13 23:48:47 2006 +++ dmesg.zaurus.snapshot Tue Jun 13 23:48:51 2006 @@ -1,5 +1,5 @@ -OpenBSD 3.9-current (GENERIC) #61: Fri May 19 20:39:55 CEST 2006 -[EMAIL PROTECTED]:/home/kili/GENERIC +OpenBSD 3.9-current (GENERIC) #51: Thu Jun 8 14:52:46 MDT 2006 +[EMAIL PROTECTED]:/usr/src/sys/arch/zaurus/compile/GENERIC real mem = 67108864 (65536K) 64MB avail mem = 53313536 (52064K) using 844 buffers containing 3457024 bytes (3376K) of memory @@ -21,8 +21,8 @@ uhub0 at usb0 uhub0: PXA27x OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered -lcd_pxaip0 at pxaip0 -wsdisplay0 at lcd_pxaip0 mux 1: console (std, vt100 emulation) +lcd0 at pxaip0 +wsdisplay0 at lcd0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1 added (std, vt100 emulation) zkbd0 at pxaip0 wskbd0 at zkbd0: console keyboard, using wsdisplay0
Re: Hifn policy on documentation
* Michael Scheliga wrote: truly open to the general public anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations. Your customer's locations I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations?
Re: [Fwd: Re: Hifn policy on documentation]
Marco Peereboom [EMAIL PROTECTED] writes: [EMAIL PROTECTED] [EMAIL PROTECTED] Some information will probably always require a non-disclosure agreement. Information that falls into that category is generally of a sensitive competitive nature, contains trade secrets or is related to unanounced or unreleased products. I've had access to that information in the past as a result of an NDA with a former employer. Datasheets for the -current- products are all that is required. Datasheets for products in the sampling stage would be cool, but only if accompanied by boards =) Software licenses are generally restricted in the disclosure or source code reproduction rights. Hifn reserves the right to keep our source code proprietary. This should not affect the hifn(4) driver since that driver is programmed directly to the hardware and does not use Hifn's enablement software library. I've seen hifn source code (previous employer NDA); nothing we could use anyway. I threw it away and used the datasheets. The only person talking about hifn's proprietary code is you. If you showed it to us, we would not bother looking at it. Well, actually, I tried looking at it and realized that the quality of the datasheets made them far more useful, and I downloaded them from hifn.com w/out as much as signing in. Btw, hifn datasheets are VERY good, especially in comparison with your competition. --Jason L. Wright
Help in Setting up Open-ended VPN connections
Hello Folks, I'm able to set up a VPN connection between two networks when I know my peer VPN gateway address. I need to set up our VPN gateway in such a way that our staff can access our internal network from any where in the world. What this means is that we don't know the IP address that they will be connecting from, but they know our VPN gateway's IP address. I tried setting up our isakmpd.conf in a similar manner, except that I put 0.0.0.0/0 for the peer gateway, but then isakmpd complains that it can't create a connection to the IP address 0.0.0.0. I've tried googling and searching on the 'Net for such a config, but I can't seem to find any. Could you help me out or point me in the right direction. Regards, g
Re: dd ... of=/dev/sd0 creates a file instead of writing to disk
On 6/13/06, Joe [EMAIL PROTECTED] wrote: Miod Vallat wrote: Normally, this would work (in different OS's): # dd if=/dev/urandom of=/dev/sd0 However, this command creates a file /dev/sd0 and fills it with random data. I want to write this data to the disk instead. The same thing happens when I use /dev/rsd0. You want sd0c or rsd0c (hint: man 4 sd, FILES section). That worked. Thank you. I'm glad you found your answer. But also, you should be careful: one pass will probably not be enough to completely wipe the disk. -Nick
Re: Curious on NAT traversal possibility on PF
(warning, a bit long and might not be of very general interest, but some of the points probably need getting down somewhere...) executive summary: passing some protocols through NAT can be pretty hairy. On 2006/06/13 16:47, Daniel Ouellet wrote: Stuart Henderson wrote: On 2006/06/13 14:58, Daniel Ouellet wrote: That's cool! No worry, I guess your subject is way more interesting to many, or no one is using NAT traversal or have any needs for it. I don't know much about H.323, but for SIP draft-biggs-sip-nat has some useful information, care needs to be taken not to break other nat- traversal mechanisms though (google: SIP ALG break), and there are a lot of strange UAs around... Another way for SIP is ser/openser and mediaproxy, but it definitely needs work to configure, it's nothing like how ftp-proxy/tftp-proxy work (which seems to be more the sort of thing you're looking for). Actually I wasn't looking for ftp-proxy type, but really for SIP NAT traversal. Sorry if I didn't make that clear. Not going into any details, but in short, and very simplistically as well, connection are establish out to a phone behind NAT for example coming from 5060 to port 5060 on the CPE device as SIP defines it and the reply will be send back to port 5061 oppose to what would be expected to come back to 5060. I'm trying to understand what you mean, but I don't understand about port+1, I haven't seen anything with SIP that explicitly uses port+1. Normally without NAT, packet from phone (UAC) to voip gw (UAS) looks like 81.168.a.b.2051 193.111.x.y.5060: udp - and a reply: 193.111.x.y.5060 81.168.a.b.2051: udp Where the phone has a private address, e.g. 10.0.0.1.2051 193.111.x.y.5060: udp - NAT rewrites, 81.168.c.d.55017 193.111.x.y.5060: udp - Reply from voip gw to NAT 193.111.x.y.5060 81.168.c.d254.55017: udp - NAT rewrites to phone 193.111.x.y.5060 10.0.0.1.2051: udp this is all ok, and as long as the UAC (phone) sends some packet (maybe empty 'OPTIONS' packet) as a keep-alive before the NAT mapping times-out, all is well for the actual SIP packets. the problem requiring assistance to bypass the nat comes when you setup the media stream because the SDP payload in the SIP INVITE includes the private address for the returning media stream to be sent to: Sent to udp:193.111.x.y:5060 at 13/6/2006 22:10:44:870 (1240 bytes): INVITE sip:[EMAIL PROTECTED];user=phone SIP/2.0 Via: SIP/2.0/UDP 10.0.0.1:2051;branch=z9hG4bK-by2gzy7jgtul;rport From: Stuart Henderson sip:[EMAIL PROTECTED];tag=ru8z7tg2c1 To: sip:[EMAIL PROTECTED];user=phone Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Max-Forwards: 70 Contact: sip:[EMAIL PROTECTED]:2051;line=aurpydus;flow-id=1 P-Key-Flags: resolution=31x13, keys=4 User-Agent: snom360/6.1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces, callerid Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 477 v=0 o=root 1540178600 1540178600 IN IP4 10.0.0.1 s=call c=IN IP4 10.0.0.1 t=0 0 m=audio 64376 RTP/AVP 0 8 9 2 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:TFrG383hHaidd8meTiYYe7tiO3Up+EICEEmeE/7H a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=encryption:optional a=sendrecv Of course this is quite like active-ftp, in that local IP addresses and ports for some remote machine to connect to are carried in the packets themselves (not the headers). - to get this particular packet sent so that media is directed correctly, the NAT would have to rewrite: Contact: sip:[EMAIL PROTECTED]:2051;line=aurpydus;flow-id=1 o=root 1540178600 1540178600 IN IP4 10.0.0.1 c=IN IP4 10.0.0.1 m=audio 64376 RTP/AVP 0 8 9 2 3 18 4 101 10.0.0.1 would be replaced with the NAT routers address; say 81.168.66.254 64376 would be replaced with an unused port number on the NAT router; say for this example 50172 Packet is then sent on to the UAS; a rdr would be added on the NAT so all incoming packets (i.e. the media stream) to 50172 get directed to 10.0.0.1:64376 This is all rather like /usr/sbin/ftp-proxy (working with anchors so that the data connections are handled in-kernel by PF, not like the old /usr/libexec/ftp-proxy). Though, with FTP, you can tell when the control connection is disconnected, but this isn't possible with SIP so you have no sure way to know when the RDR can be removed (so at least you need to watch the packet counter for the rdr rule and kill the connection some time after it stops increasing). N.B. the media-packets can come from anywhere; very often not the same host as you're passing SIP messages to. They can even change source mid-call. While ftp allows third-party transfers, it's little-used, and disabling it for security reasons
Re: suspended zaurus doesn't wake up (-CURRENT)
On Wed 2006.06.14 at 00:05 +0200, Matthias Kilian wrote: Hi, when suspending the zaurus using a -CURRENT kernel or the latest snapshot (from june, 8th), it isn't possible to wake up the system. This happens both with power supply connected and with battery only, as well as with pressing the on/off button or invoking zzz(8). With a kernel from may, 19th still works. Could anyone please test and confirm this problem using a snapshot? i can confirm this on a 3200. a few notes: - ensured battery was fully charged (using some of the suggestions previously posted on this list) - no cf cards or usb devices attached not running apmd - tapping the button on the front suspends and wakes the device running apmd with no flags, -A, or -C - tapping the button on the front suspends, but tapping again doesn't resume. - invoking zzz(8) suspends, but again, nothing resumes - pulling the battery is the only way to recover -current jun 5th snapshot. (i don't have a may 19th one to test, and i believe 3200 support was added post-3.9) i'd be willing to try one if someone can direct me to one. cheers, okan
Re: Hifn policy on documentation
Marc Balmer wrote: * Michael Scheliga wrote: truly open to the general public anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations. Your customer's locations I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations? Not care about US Export Regs? But that just means you want the terrorists to win. After all our President is your President right? Sleep, Consume, Follow Orders. It's the American way.
Re: suspended zaurus doesn't wake up (-CURRENT)
On 2006/06/14 00:05, Matthias Kilian wrote: when suspending the zaurus using a -CURRENT kernel or the latest snapshot (from june, 8th), it isn't possible to wake up the system. me too.
Re: Help in Setting up Open-ended VPN connections
From: [EMAIL PROTECTED] on Behalf Of Bharj, Gagan but they know our VPN gateway's IP address. I tried setting up our isakmpd.conf in a similar manner, except that I put 0.0.0.0/0 for the peer gateway, but then isakmpd complains that it can't create a connection to the IP address 0.0.0.0. I've tried googling and searching on the 'Net for such a config, but I can't seem to find any. Could you help me out or point me in the right direction. To follow that further, is it currently possible to do this kind of road-warrior setup using ipsecctl/ipsec.conf? Doesn't it require aggressive mode do to the unknown nature of the peer IP? DS
Re: Hifn policy on documentation
From: Marc Balmer [EMAIL PROTECTED] writes: Date: Wed, 14 Jun 2006 00:22:12 +0200 From: Marc Balmer [EMAIL PROTECTED] To: Michael Scheliga [EMAIL PROTECTED] Cc: Hank Cohen [EMAIL PROTECTED], misc@openbsd.org Subject: Re: Hifn policy on documentation * Michael Scheliga wrote: truly open to the general public anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations. Your customer's locations I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations? Clearly you don't. The vendor probably does. [ I do know somebody who once seriously inquired into the procedure to send in partial dead rat corpses to city hall. Seems the state had a bounty program on the books from a century ago ... ] In this case, the vendor appears to be talking about documentation, which means they're actually confused. EAR covers chips but not documentation. By US law they *have* to care about the chips. Otherwise they're not in business. However the same law and a bunch of court cases also makes a big thing about free speech. For quite a number of years, when cryptography was considered a munition and not allowed to be exported without special license, people were writing books and talking about cryptography almost entirely without problems. Somebody needs to point this out to them; there's simply no defensible US export legal reason for them to make people fill out web forms of any form to acquire human readable documentation. If the purpose of their web registration was to satisfy US export purposes, it would still be different. Such a form would mainly be concerned with issues like where do you live - can you prove you are a US citizen - and nothing more. The MIT folks distributed kerberos source via http with just such a registration system for a number of years. If they're asking 50 nosey personal questions, that's not US export law. That's business accounting and marketing think, 100% (or possibly a *really* bad lawyer.) They want to know where to send the next load of junk mail so they can spend their advertising dollars most effectively. They may want to resell that information to other people in similar businesses. Their sales people want to know if you call with questions after that whether you're going to buy enough of their product to make it worth their time to answer your questions. Maybe they're imagining they can reduce product liability claims - although I don't know of very many product liability cases that were won by failing to disclose problems. Seems like they're more likely to succeed at reducing product liability by reducing customer interest and usage. It's conceivable they think their competitors are actually stupid enough that this form will stop them from learning about what they're doing or coming up with better ways to do it. In any event, however justifiable they think they are in their business practices, it still stinks, and it bodes ill for their long-term business health. I wish their competition the best of luck. -Marcus Watts
Kernel Crash on OpenBSD_3_9
We have a Tyan S2882-D that has been having some problems. A previous
panic seemed to be related to the Broadcom chipset. Details at
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=5144
Since disabling the Broadcom on the 5/June no other problems have been
seen with the machine. The only major system configuration change that
has happened recently was the addition of a mfs:/tmp
Dmesg and trace/ps attached if anyone has a suggestion about what is going
on?
Thanks.
trace
phtree_SPLAY() at phtree_SPLAY+0x2a
pool_do_put() at pool_do_put+0x1d0
soreceive() at soreceive+0x77a
dofileread() at dofileread+0x7e
sys_read() at sys_read+0x61
syscall() at syscall+0x25c
--- syscall (number 3) ---
end of kernel
end trace frame: 0x49b49000, count: -6
mp_pdirpa+0x4118f3:
ddb{0}
phtree_SPLAY() at phtree_SPLAY+0x2a
end trace frame: 0x80006e0dcd00, count: 0
ddb{0} ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
*11243 14466 11082 2 7 0x204 dump
5164 14466 11082 2 7 0x4 dump
31547 14466 11082 2 2 0x4 dump
14466 18708 11082 2 3 0x284 netio dump
18708 21448 11082 2 3 0x2004084 wait dump
14688 21448 11082 2 3 0x284 netio sendbackup
21448 1 11082 2 3 0x2004084 piperd sendbackup
20568 1875 1875507 3 0x2004184 select pickup
18290 1 18290530 3 0x2000184 poll clamd
25611 8853 25611 0 3 0x2004086 kqread tail
15688 3592 3592530 3 0x2000184 lockf perl
24963 3592 3592530 3 0x2000184 netcon perl
3592 1 3592530 3 0x2000184 select perl
25742 27447 27447 0 3 0x284 select perl
29436 27447 27447 0 3 0x284 select perl
27447 1 27447 0 3 0x284 select perl
6948 1284 6948451 3 0x2004086 ttyin ksh
1284 23671 23671451 3 0x2000184 select sshd
23671 9135 23671 0 3 0x2004184 netio sshd
31295 12022 31295451 3 0x2004086 ttyin ksh
12022 29424 29424451 3 0x2000184 select sshd
20046 1875 1875507 3 0x2004184 select qmgr
8853 11385 8853451 3 0x2004086 pause ksh
11385 26965 26965451 3 0x2000184 select sshd
26965 9135 26965 0 3 0x2004184 netio sshd
16655 1 25187 0 3 0x284 select amd
9135 1 9135 0 3 0x284 select sshd
15299 32754 4630502 3 0x2004187 poll mysqld
32754 1 4630 0 3 0x2004086 pause sh
20274 26117 26117 67 3 0x2000184 netcon httpd
14437 26117 26117 67 3 0x2000184 netcon httpd
2647 26117 26117 67 3 0x2000184 netcon httpd
32494 26117 26117 67 3 0x2000184 netcon httpd
8490 26117 26117 67 3 0x2000184 netcon httpd
1236 26117 26117 67 3 0x2000184 netcon httpd
2614 26117 26117 67 3 0x2000184 netcon httpd
22963 26117 26117 67 3 0x2000184 netcon httpd
21714 26117 26117 67 3 0x2000184 netcon httpd
4147 26117 26117 67 3 0x2000184 netcon httpd
17379 1 17379 0 3 0x284 select cupsd
17676 8266 8266 0 3 0x284 nfsd nfsd
13584 8266 8266 0 3 0x284 nfsd nfsd
14893 8266 8266 0 3 0x284 nfsd nfsd
8266 1 8266 0 3 0x284 netcon nfsd
17002 1 17002 0 3 0x284 poll rpc.lockd
6010 1 6010 77 3 0x2000184 poll dhcpd
14814 1 14814 0 3 0x2004086 ttyin getty
7802 1 7802544 3 0x2000185 poll slapd
1875 1 1875 0 3 0x200418c select master
19037 1 19037 0 3 0x2004086 ttyin getty
27846 1 27846 0 3 0x2004086 ttyin getty
20382 1 20382 0 3 0x2004086 ttyin getty
31711 1 31711 0 3 0x2004086 ttyin getty
22768 1 22768 0 3 0x2004086 ttyin getty
125 1125 0 3 0x284 select cron
14655 1 14655 0 3 0x2080084 nanosleep sensorsd
26399 1 3189 0 3 0x284 select snmpd
27002 1 27002 0 3 0x284 pause ntpd
26402 1 26402 0 3 0x2000184 select inetd
26117 1 26117 0 3 0x284 select httpd
12383 0 0 0 3 0x2100204 acct acct
17240 0 0 0 3 0x2100284 nfsidl nfsio
4153 0 0 0 3 0x2100284 nfsidl nfsio
3529 0 0 0 3 0x2100284 nfsidl nfsio
908 0 0 0 3 0x2100284 nfsidl nfsio
15817 1 15817 28 3 0x2000184 poll portmap
13785 5283 5283 70 3 0x2000184
Re: Hifn policy on documentation
-Original Message- From: Michael Scheliga Sent: Tuesday, June 13, 2006 4:21 PM To: 'Dag Richards' Subject: RE: Hifn policy on documentation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dag Richards Sent: Tuesday, June 13, 2006 3:49 PM To: misc@openbsd.org Subject: Re: Hifn policy on documentation Marc Balmer wrote: * Michael Scheliga wrote: truly open to the general public anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations. Your customer's locations I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations? Not care about US Export Regs? But that just means you want the terrorists to win. After all our President is your President right? Sleep, Consume, Follow Orders. It's the American way. Sorry, but when the company is in America, these are the current laws. I don't see how hi-jacking the thread to show that you don't like America or it's laws is going to help with getting drivers for a Hifn card working better. And I don't recall being asked what country I wanted to be born into. Perhaps you were. Trying to get something changed for the better, not trying to push US laws down anybodies throat. If changing US law was as simple as bitching about it in here, you wouldn't be able to keep up with the volume of mail. Michael
Re: wikipedia article
Per Fogelstrvm wrote: On Tuesday 13 June 2006 14:23, Rick Kelly wrote: Johnny Billquist said: There's actually a cheesy way to do demand paging with microprocessors that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instruction causing the fault so contains restartable machine state. Masscomp sold a machine like this once. Didn't the first Apollos do this? And also the Sun 1. IIRC it was simpler than that. When the first cpu caused a 'miss' it was put in wait and cpu 2 handled the pagein and then released cpu 1. Keeping the two cpus synched, one instruction apart would have been too complicated if not impossible... Your idea will not work, as far as I can tell. If the first CPU instruction execution causes a miss, the end result in the CPU will be pretty undefined, and you cannot restart. That's the whole point in why you'd have a second CPU shadowing the first one. So that you'd be able to restore the state as it were before the illegal memory access. And that was the problem with the original 68000. On an illegal memory reference, you would not know what state the CPU was in before the instruction, so you could not back it up, and re-execute the instruction after a page fault. Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: [EMAIL PROTECTED] || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: Laptop recommendations
I'm still looking for a laptop. Does anybody know of a laptop that will do at least 1600x___ resolution and have rudimentary power management (ie., I can pull the AC plug and the laptop does not lock up)? Chris On 5/29/06, Theo de Raadt [EMAIL PROTECTED] wrote: On 5/26/06, Christopher Snell [EMAIL PROTECTED] wrote: It seems like every major laptop manufacturer is locked into Intel CPU, graphics, WiFi, and sound and that there's no chance in hell that Intel will release specs on these. What is the future of laptop support for free Unicies? Will SpeedStep ever be reverse engineered? Are we forever doomed to barely-working laptops? umm, the graphics and sound for intel chipsets are completely documented. the correct way to use speedstep (est) is through acpi, which is also documented, even though we should now pretty much support every est cpu at least basically. the situation with wifi could be better, but if you download the firmware it works. you have either misappraised the situation, or your defintion of barely working is very different than most people's. Intel is changing their ways. They got seriously hurt by NVidia and ATI taking over the video market, while simultaneously AMD hurt them on the processor side. The real enemy today is Nvidia (and ATI). Intel is trying to release documentation and open up as fast as they can to stay in the market. It's almost pathetic, but yes, it is benefiting us (as it should, and thus, us running on their machines benefits them, as it should).
Re: Hifn policy on documentation
On Tue, Jun 13, 2006 at 08:43:16AM -0600, Theo de Raadt wrote: [snip] And if you continue baiting me, I will delete the driver from our source tree. You may as well. By the time Hifn release the documentation the speed of cheap processors will have increased enough to make their current products marginal. I've had this happen with add-on DSP boards before. Regards, Andrew Dalgleish
Re: Hifn policy on documentation
On 6/13/06, Hank Cohen [EMAIL PROTECTED] wrote: Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. I agree with others, the tone was correct at this point. The simple fact is that anyone who wants access to Hifn's documentation need only log on to our extranet site (http://extranet.hifn.com/home/) The word simple implies no such thing in this instance. I went to the site and it asked for me to register. What is that about? to download as much as they like. This is true of the 795x Algorithm accelerator chips and the 7855 and 8155 HIPP chips. Some more restrictions may apply to our NP and flow through part documents. Specifically the documentation for 7954, 7955 and 7956 is available. The other chips that are supported by the Open BSD Crypto drivers hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851 and 7854) are legacy parts that are not recommended for new designs. The driver will also work for 7954 even though that is not listed. This does represent some liberalization of access in recent months. 'some liberalization' means that you must compromise personal information to gain access to docmentation used to sell your product? Do you realize hifn's target industry? Hifn is always monitoring its policy with respect to the confidentiality of documentation and other business information. Some information will probably always require a non-disclosure agreement. Information that falls into that category is generally of a sensitive competitive nature, contains trade secrets or is related to unanounced or unreleased products. Noone is asking for this information, why classify the other stuff like it is ultra-secretive? The only thing gained (lost) is a community that supports and sells your products for you. Software licenses are generally restricted in the disclosure or source code reproduction rights. Hifn reserves the right to keep our source code proprietary. This should not affect the hifn(4) driver since that driver is programmed directly to the hardware and does not use Hifn's enablement software library. Well, as you stated, it doesn't affect the hifn(4) driver, so why limit the disclosure of information? Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. What terms must be agreed upon when 'logging in' to this site or even for registration? It clearly asks when 'registering' for access 'Does your company currently have an NDA/CDA with Hifn?' No. Luckily, it's not required, or so it says. After logging in, guess what is shown: Welcome new user. It normally requires several hours for our staff to receive your new user registration and assign the appropriate permissions to you. You will be unable to browse folders or access files until we upgrade your access. You will be notified via email as soon as your permissions have been set. Thank you for your patience. Regards, Brian Sparks (408) 399-3520 [EMAIL PROTECTED] Is this the link that you refer to for the documentation? http://extranet.hifn.com/home/content/documents/?id=1736 If so, why not just make it publicly available? There was NO information submitted that is verified other than eMail address, nor any agreements signed that bind anyone to anything. If anything, why not PROVIDE these 7956 Reference kits to developers? Hifn owes THEM that much for all the hard work they do. This is 'available documentation'? Are you seriously defending this on a public mailing list? Yes, free available documentation. What else lurks under these proprietary PDF formats strewn about the site? And if they're accessible by normal means, sans agreement, why can't they just be posted without regard to registration or agreement? There is no purpose for the compromise of personal information. I hope that this clears the air. It doesn't. You're asking for the OpenBSD community, and especially developers, to compromise the very values that have made OpenBSD what it is today. I used to buy hifn products because they were supported..and they 'just worked'. Now, I have no choice but to look elsewhere. Don't think for a second that for ever person who posts a complaint, there won't be a hundred thousand others who will read this thread at some point and wonder if hifn is really the right choice for their application. Hank, did you really think that the legalese was in hifn's
Re: Laptop recommendations
dell inspiron 8100 On 6/14/06, Christopher Snell [EMAIL PROTECTED] wrote: I'm still looking for a laptop. Does anybody know of a laptop that will do at least 1600x___ resolution and have rudimentary power management (ie., I can pull the AC plug and the laptop does not lock up)? Chris On 5/29/06, Theo de Raadt [EMAIL PROTECTED] wrote: On 5/26/06, Christopher Snell [EMAIL PROTECTED] wrote: It seems like every major laptop manufacturer is locked into Intel CPU, graphics, WiFi, and sound and that there's no chance in hell that Intel will release specs on these. What is the future of laptop support for free Unicies? Will SpeedStep ever be reverse engineered? Are we forever doomed to barely-working laptops? umm, the graphics and sound for intel chipsets are completely documented. the correct way to use speedstep (est) is through acpi, which is also documented, even though we should now pretty much support every est cpu at least basically. the situation with wifi could be better, but if you download the firmware it works. you have either misappraised the situation, or your defintion of barely working is very different than most people's. Intel is changing their ways. They got seriously hurt by NVidia and ATI taking over the video market, while simultaneously AMD hurt them on the processor side. The real enemy today is Nvidia (and ATI). Intel is trying to release documentation and open up as fast as they can to stay in the market. It's almost pathetic, but yes, it is benefiting us (as it should, and thus, us running on their machines benefits them, as it should).
Re: wikipedia article
Various wrote: Message-ID: [EMAIL PROTECTED] Date: Wed, 14 Jun 2006 00:50:53 +0200 From: Johnny Billquist [EMAIL PROTECTED] Organization: Update Computer Club User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Per_Fogelstr=F6m?= [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Marcus Watts [EMAIL PROTECTED], Otto Moerbeek [EMAIL PROTECTED], Ted Mittelstaedt [EMAIL PROTECTED], John Nemeth [EMAIL PROTECTED], Nikolas Britton [EMAIL PROTECTED], Ted Unangst [EMAIL PROTECTED], =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= [EMAIL PROTECTED], misc@openbsd.org, freebsd-questions@freebsd.org, [EMAIL PROTECTED] Subject: Re: wikipedia article Per Fogelstr=F6m wrote: On Tuesday 13 June 2006 14:23, Rick Kelly wrote: =20 Johnny Billquist said: There's actually a cheesy way to do demand paging with microprocessor= s that don't support demand paging (such as the original 68000--another 16 bit machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instructi= on causing the fault so contains restartable machine state. Masscomp so= ld a machine like this once. Didn't the first Apollos do this? And also the Sun 1. =20 =20 IIRC it was simpler than that. When the first cpu caused a 'miss' it wa= s put in wait and cpu 2 handled the pagein and then released cpu 1. Keeping t= he two cpus synched, one instruction apart would have been too complicated if = not impossible... Your idea will not work, as far as I can tell. If the first CPU instruction execution causes a miss, the end result in=20 the CPU will be pretty undefined, and you cannot restart. That's the=20 whole point in why you'd have a second CPU shadowing the first one. So=20 that you'd be able to restore the state as it were before the illegal=20 memory access. And that was the problem with the original 68000. On an illegal memory=20 reference, you would not know what state the CPU was in before the=20 instruction, so you could not back it up, and re-execute the instruction=20 after a page fault. Johnny Several clarifications. The sun-1 did not have a dual CPU page fault arrangement. It used a slightly higher clock speed version of the same CPU board used previously used by codata 4 other vendors, originally designed by stanford university. Instead of using the motorola MMU which was late to market, expensive, slow, or industry standard MMU cache logic (TLB), they used a very clever generic chip implementation that used the CPU alternate space instructions to manage dedicated high speed RAM which provided all the mapping. This managed a page addressed space, but did NOT do demand paging. Another exciting low-cost feature of the sun-1 CPU was software dynamic ram refresh- every 2 ms, the CPU was interrupted by the refresh interrupt and would execute 127 nop instructions. The sun-2 was very similiar to the sun-1, but upgraded the 68000 to a 68010 (which could do instruction restarts and hence demand paging), deleted the onboard RAM, and instead added the ability to use DMA via an IOMMU to private bus RAM. The sun-1 ran unisoft version 7 unix, complete with swapping. The sun-2 ran 4.2bsd. I've got an actual physical codata processor manual (complete with schematics) but I believe I've seen a sun-1 processor manual in pdf somewhere on the web recently. I'm not 100% sure how masscomp or apollo handled page faults. The impression I had is that the first CPU got reset, and the second was interrupted on the instruction boundary and saved its CPU state first thing in the interrupt handler. While the user register state in the first is undefined, the CPU itself is still good - it can take an interrupt, transition into kernel mode and recover machine state from somewhere else (like the 2nd CPU) just fine. That seems to me to be the most sane way it could have been handled. I suppose it's possible the 2nd CPU could have been instead paused, while the first CPU processed the segmentation violation, trashed its non-recoverable machine state, handled the exception, and ?somehow? reloaded machine state from the 2nd paused CPU. Switching to a different process while the 2nd CPU was paused waiting for a page to come in off disk might have been a bit awkward. So while I think this might have been made to work, I doubt it could have performed as well. So far as the 2 cpu synchronization logic goes - either of these would have required such a beast. The 68000 used address spaces to distinguish between instruction and data references, so instruction synchronization was no problem. It might have been necessary to decode instructions to sort out operands other instruction stream references, including logic to sort out page faults in the middle of an
Re: Hifn policy on documentation
Dag Richards wrote: Marc Balmer wrote: I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations? Not care about US Export Regs? But that just means you want the terrorists to win. After all our President is your President right? I think nearly everyone here is fully aware of how American influence affects the rest of the world. Using American laws as a scape goat to try and pump personal information out of developers steps right into the deep end of unreasonable legal wrangling. Hifn should realize that their target market is interested in keeping information safe and private, rather than exploiting developers for private information and using inapplicable law as a sort of defacto shield against trouble with their government. It only diminishes their reputation and perceived trustworthiness in the eyes of customers, many of whom are making or influencing the purchasing decisions for large foreign or multinational organizations. This is just another symptom of the US slide towards isolationism. External competitive pressures are increasing every year and many American institutions, both in government and private sector, are seeking to restrict the trade of goods and ideas as a band aid to fix the problem. The terrorist attacks of 2001 merely provided the powers that be the excuse they needed to push isolationism further down the throats of the American people. Anyone who has been paying attention to China in the last ten years will have a very good idea of where this type of policy is going to lead the US economy. The sickest part is how China uses it's excess foreign currency to buy American debt instruments, thereby encouraging low interest rates in the US so that the American people can buy more Chinese goods at Wal-Mart. We may soon see the last remaining super power of the previous century decline into obscurity. Another decade will tell us for sure. Ahem. Sorry about that. Slightly off topic. :) Breeno
Re: Hifn policy on documentation
This is just another symptom of the US slide towards isolationism. External competitive pressures are increasing every year and many American institutions, both in government and private sector, are seeking to restrict the trade of goods and ideas as a band aid to fix the problem. i have wondered why companies like hifn want to keep their device design under an NDA on many occasions. it seems to me to be mostly about a company's lack of confidence in its competitive edge and their ability to maintain it. if you're opening your drivers up, you had best be ready to raise your skills, something many amUricans are unwilling to do. the whole idea of keeping the device docs under an NDA is silly to me. if anyone REALLY wants those specs, e.g. your competitor, they can certainly get them without too much additional trouble.
Re: Curious on NAT traversal possibility on PF
On 6/13/06, Stuart Henderson [EMAIL PROTECTED] wrote: (warning, a bit long and might not be of very general interest, but some of the points probably need getting down somewhere...) executive summary: passing some protocols through NAT can be pretty hairy. Of course this is quite like active-ftp, in that local IP addresses and ports for some remote machine to connect to are carried in the packets themselves (not the headers). - to get this particular packet sent so that media is directed correctly, the NAT would have to rewrite: Contact: sip:[EMAIL PROTECTED]:2051;line=aurpydus;flow-id=1 o=root 1540178600 1540178600 IN IP4 10.0.0.1 c=IN IP4 10.0.0.1 m=audio 64376 RTP/AVP 0 8 9 2 3 18 4 101 10.0.0.1 would be replaced with the NAT routers address; say 81.168.66.254 64376 would be replaced with an unused port number on the NAT router; say for this example 50172 If you're following this, you'll notice that some host sending an unauthenticated UDP packet can ask the NAT to open a UDP port from the outside world to any host behind the same NAT... So, I think this definitely needs to be handled outside of PF, and accompanied by a reasonably large warning (-: ((Please don't take too much offense to this if it's a really obvious thing)) What is the prefered method for NAT-traversal these days? The options I know are: UPnP a proxy having the in-kernel NAT code do the work itself designing protocols to assume NATs and get around them. It seems to me like it would be helpful if PF provided some sort of hooks that let you write plugins that understand a particular protocol and are able to change the neccessary parts at will. Is this completely bonkers and/or has it been tried and/or is it good? -Nick
Re: Hifn policy on documentation
On 6/13/06, Marcus Watts wrote: In this case, the vendor appears to be talking about documentation, which means they're actually confused. EAR covers chips but not documentation. By US law they *have* to care about the chips. Otherwise they're not in business. However the same law and a bunch of court cases also makes a big thing about free speech. For quite a number of years, when cryptography was considered a munition and not allowed to be exported without special license, people were writing books and talking about cryptography almost entirely without problems. Somebody needs to point this out to them; there's simply no defensible US export legal reason for them to make people fill out web forms of any form to acquire human readable documentation. As one example, Phil Zimmerman was not permitted to export the source code to PGP electronically, so he published a print book containing it in a character set particularly conducive to OCR (in the state of that technology at that time). The issue there was that people in the NSA and other anti-public-crypto goons in the US government were comfortable and secure in their authority to obtain censorship of electronic communications, but it was totally out of their league (at least in that particular instance) to extend the censorious regulations to the print medium. So that issue is very real, but it is totally separate from what is going on here, because: (1) the materials in question are being distributed in an electronic form (2) the materials in question are not actually subject to any US export restrictions of any kind, and Mr. Cohen is either lying to us or is quite misled. The issue of the US government not being permitted to restrict speech does not appear to me to be the applicable one here, because the only organization that is acting against the interests of freedom in this case is Hifn. They can blame the US government all they want--they're lying (or severely and inexcusably mistaken). -Eliah
Re: Curious on NAT traversal possibility on PF
On 2006/06/13 22:07, Nick Guenther wrote: What is the prefered method for NAT-traversal these days? The options I know are: UPnP a proxy having the in-kernel NAT code do the work itself Look at how /usr/sbin/ftp-proxy works with anchors - it's a nice hybrid, keeping L7 work out of the kernel, and bulk-packet-shifting out of userland. designing protocols to assume NATs and get around them. Doesn't seem to happen too often for complicated standard protocols. More likely to get bolted-on afterwards.
Re: Laptop recommendations
On Tue, Jun 13, 2006 at 05:40:47PM -0600, Christopher Snell wrote: I'm still looking for a laptop. Does anybody know of a laptop that will do at least 1600x___ resolution and have rudimentary power management (ie., I can pull the AC plug and the laptop does not lock up)? If you want a big, wide screen and don't mind something that weighs as much as a small car: http://www.stilyagin.com/OpenBSD/Clevo-D900T.php I need to update that, since more stuff works in 3.9, and yet more in -current (Azalia, etc.) You can pull the plug or have a power outage and it keeps going. Sleep and suspend won't work, but if acpi gets far enough along... There's also an AMD64 version for more $$$. -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Hifn policy on documentation
On 6/13/06, Theo de Raadt [EMAIL PROTECTED] wrote: There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. snip I know that our hifn driver has some problems. But because I cannot get data sheets without giving you private information, I will not spend even one moment more of my time to improve support for your products. Jason and I spent a lot of time writing that code in the past, but because your policies are privacy invasive towards us, and thus completely thankless for the sales that we have given you in the past -- we will not spend any more time on your crummy products. And if you continue baiting me, I will delete the driver from our source tree. I stand by my statement that HIFN is not open. I don't use crypto accelerators, and none of this discussion applies to me, so this is just noise... but I have to say this: this is _AWESOME_. The project has not only scared the execs at this corporation, now they are being torn to pieces by their previous customers. I especially like Breen's response. A lot of other communities would just be excited to be noticed, but not you guys. I am not an OpenBSDer because I've been burned (not enough experience for that) but because I recognized the philosophy as the only one that is going to save humanity from itself. Now, Hank Cohen, please come back and respond to some of these replies. Stand up for your tribe. For the ones you missed, here's the full thread (hosted somewhere that provides information for free, perhaps you could learn from them): http://marc.theaimsgroup.com/?l=openbsd-miscm=115017551512719w=2 -Nick
Re: Curious on NAT traversal possibility on PF
On 6/13/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/06/13 22:07, Nick Guenther wrote: What is the prefered method for NAT-traversal these days? The options I know are: UPnP I suppose this one doesn't work unless the protocol bends well to it, and both ends support it too, which means running clunky XML and HTTP code. a proxy having the in-kernel NAT code do the work itself Look at how /usr/sbin/ftp-proxy works with anchors - it's a nice hybrid, keeping L7 work out of the kernel, and bulk-packet-shifting out of userland. Ah, thank you! That makes for a lot of reading up to do. Skimming the code it seems that there's a lot of framework-code shoved in alongside the proxying, is that right? -Nick
Re: Hifn policy on documentation
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hank Cohen Sent: Tuesday, June 13, 2006 12:10 AM To: misc@openbsd.org Subject: Hifn policy on documentation Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. The simple fact is that anyone who wants access to Hifn's documentation need only log on to our extranet site (http://extranet.hifn.com/home/) to download as much as they like. This is true of the 795x Algorithm accelerator chips and the 7855 and 8155 HIPP chips. Some more restrictions may apply to our NP and flow through part documents. Specifically the documentation for 7954, 7955 and 7956 is available. The other chips that are supported by the Open BSD Crypto drivers hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851 and 7854) are legacy parts that are not recommended for new designs. The driver will also work for 7954 even though that is not listed. This does represent some liberalization of access in recent months. Hifn is always monitoring its policy with respect to the confidentiality of documentation and other business information. Some information will probably always require a non-disclosure agreement. Information that falls into that category is generally of a sensitive competitive nature, contains trade secrets or is related to unanounced or unreleased products. Software licenses are generally restricted in the disclosure or source code reproduction rights. Hifn reserves the right to keep our source code proprietary. This should not affect the hifn(4) driver since that driver is programmed directly to the hardware and does not use Hifn's enablement software library. Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. I hope that this clears the air. Best regards, Hank Cohen Product Line Manager Hifn Inc. 750 University Ave Los Gatos Ca. 95032 408-399-3593 Actually, it's just ignorance on Hifn Marketing's part. It's really that simple. Ignorance and stubborn misunderstanding, and it's incredibly frustrating. It's not stupidity - there's a difference. Ya don't know what ya don't know... They simply do not understand. Hank, certainly you can see the relationship between driver support on more platforms and increased product sales. It's just logical. More chips sold, and you get a bigger bonus! You can also understand the need for security and privacy - hence your product. Security is one of the main reasons people gravitate toward OpenBSD. You really have a lot in common. Check it out - OpenBSD people are writing code to support your products, and not only is it not costing your company a penny, but it is actively increasing the sale of your product. It's a total Win-Win. Do the numbers. When you look at the security minded bent of the OpenBSD community, what I would say is a fierce loyalty to those vendors that 'get it', and the fact that this thread will be available for all the World to see when they Google 'hifn openbsd', and you should start seeing that by stubbornly adhering to your policy, you are really just shooting yourself in the foot. What you *could* be doing is running as fast and hard as you can in the *other* direction - by actively helping Open Source developers as much as possible - and that means support with docs, dev kits, test hardware, and maybe even a little financial support. That's the savvy, New World MBA thing to do. I see this all the time, most big vendors are clueless, and frankly my company is guilty of it. What your company - and mine - need is to employ the perspective and wisdom of those deeply into open source to help them leverage the energy of those committed to providing quality, free software. For hardware vendors, there is no better way. But doing that correctly requires a real understanding of the culture, respect for why these developers do what they do, and a cultivation of trust in the community. I hope that decrypts the air a bit more. Regards, -C
Re: developing a backup strategy
On Mon, 12 Jun 2006 10:41:55 -0700 prad [EMAIL PROTECTED] wrote: i've gone through the threads: Recommendations for an OpenBSD-based Backup Solution remote data backup and am contemplating the ideas as they apply to my rather simple setup - 2 webservers (one does email as well). not too much changes on them and not a lot of stuff on them either (under 5G combined including OpenBSD). what i've done in the past is just scp the etc and a few other directories that contain data with the intention of reinstalling OpenBSD and putting those directories back in (if disaster strikes). is this too simplistic and inefficient a solution? should i be thinking of incremental backups say with dump? does it make any sense to rsync the entire server drive? What Bob Beck said is all good stuff. Made me chuckle. This mostly applies to data that is changing on the box ( like e-mail spools ) rather than configs: My favorite solution is rsnapshot in ports. It beats rsync and scp because not only does it allow you to specify what and when to backup, but it uses hard links. What's that got to do with anything? Well it rsyncs everything on the first backup, and only the differences there after. But it makes every backup look like a full backup (every file) because it hard-links the unchanged stuff into the latest backup dir. So you get a complete backup dir every time sans lots of file transfers and space taken up on the backup storage box. Travers
Re: SMP issue involving Dual Xeon
After doing more research, I've concluded that the 2nd cpu is indeed running properly, but I still don't know why exactly the bit flags are different for the 2nd as for the 1st. That's a mystery. But reading information on APIC IDs on Intel's site yielded some answers http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/knowledgebase/43851.htm Oh well... On 6/13/06, Jesse Gumm [EMAIL PROTECTED] wrote: I'd like to know if the 2nd CPU is being used. I'm confused because of the lack of Flags on cpu1 while cpu0 is loaded with them. It looks like the 2nd CPU is actually a virtual CPU via Hyperthreading. If you look at the dmesg I posted, and compare the top with this dmesg ( http://www.nycbug.org/?NAV=dmesgd;f_dmesg=Xeon%20%20cpu1%20%20OpenBSD;f_bsd=;f_nick=;f_descr=;dmesgid=1787#1787 ), it's a little wierd that my dmesg lists all the flags for the first CPU and 4 for the 2nd, while this one that I just linked lists all the flags for both CPUs. I also did re-enable Hyperthreading, and the dmesg didn't change, but the whole lack of flags thing is what's throwing me off. -Jesse On 6/13/06, Maxim Bourmistrov [EMAIL PROTECTED] wrote: What are you trying to accomplish? AFAIK, HTT is not supported in OpenBSD. So re-enable it in BIOS - OS will ignore it anyway. On Tuesday 13 June 2006 06:01, Jesse Gumm wrote: Hello, I'm booting a Dual Xeon 2.4 Machine (just got it a few days ago), and having a bit of difficulty discerning of the 2nd CPU is actually being used by OpenBSD 3.9. Before posting the dmesg, I'll quick state what I've done so far, and why I don't actually think the 2nd cpu is taking. I started with FreeBSD (I'm traditionally an OpenBSD user, but I thought I'd give FreeBSD a try), and when FreeBSD booted with SMP support, it found 4 processors (2 Xeons each acting like 2 because of Hyperthreading, hence 4 processors). Which was fine, but after a bit I decided I didn't particularly like FreeBSD, and decided to go back to OpenBSD. When Booting OpenBSD from bsd.mp, however, I noticed that it only detected 2 CPUs. I thought that was odd, and that either 1) OpenBSD was ignoring Hyperthreading, or 2) OpenBSD recognized Hyperthreading but didn't give it it's own CPU, or 3) OpenBSD only recognized 1 processor, but gave the Virtual CPU it's own CPU. After reading a bit and determining that BSD doesn't like Hyperthreading, I disabled it in BIOS, and booted again, and the dmesg didn't change, which I found suspicious. It still says only 2 CPUs, however, the dmesg doesn't lookright, and I don't particularly want to take the processor off to test this, but I can, I figured maybe someone can give me a better answer. In short, the dmesg looks off. Notice how cpu0 lists a whole slew of bits FPU, MMC, SSE, etc while cpu1 lists 4 bits: FPU,CX8,APIC,CNXT-ID I tried compiling a fresh GENERIC.MP kernel to see if that'd resolve the situation, but it did nothing to help with this. My question, then, is: Is my 2nd CPU actually being recognized, and if not, why is OpenBSD still seeing the Hyperthreading processor when HT is disabled from BIOS, and what can I do to fix/troubleshoot this? Here's the dmesg below (I posted the whole thing instead of just the cpu and bus parts in case there might be something I'm missing): cpu0: Intel(R) Xeon(TM) CPU 2.40GHz (GenuineIntel 686-class) 2.40 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID real mem = 1073233920 (1048080K) avail mem = 972546048 (949752K) using 4278 buffers containing 53764096 bytes (52504K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(40) BIOS, date 09/17/03, BIOS32 rev. 0 @ 0xfd7d1 pcibios0 at bios0: rev 2.1 @ 0xf/0x pcibios0: PCI BIOS has 8 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 10 11 15 pcibios0: PCI Interrupt Router at 000:15:0 (ServerWorks CSB5 rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1800 0xc9800/0x4000 0xcd800/0x1800 mainbus0: Intel MP Specification (Version 1.4) (IBM ENSW TURQUIOSESMP) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99 MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 2.40GHz (GenuineIntel 686-class) cpu1: FPU,CX8,APIC,CNXT-ID 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 14 pa 0xfec0, version 11, 16 pins ioapic1 at mainbus0: apid 13 pa 0xfec01000, version 11, 16 pins ioapic2 at mainbus0: apid 12 pa 0xfec02000, version 11, 16 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 ServerWorks CMIC-WS Host (GC-LE) rev 0x13 pchb1 at pci0 dev 0 function 1 ServerWorks CMIC-WS Host (GC-LE) rev 0x00 pchb2 at pci0 dev 0
IP Routing Question.
Dear All. I have one simple question. If my ISP assign one point to point ip address and one full subnet mask address (/28), can i have those in one my ethernet interface ? If it's possible, is there any network routing problem ? FYI , i have one private network and DMZ . regards Beastie
Re: Hifn policy on documentation
On Mon, 12 Jun 2006 21:10:13 -0700 Hank Cohen [EMAIL PROTECTED] wrote: Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. etc... Hank Cohen, You really ought to consider what _you_ want, which, I guess is a job at hifn. That's made possible by selling hardware. Despite how reasonable your process seems to be, de Raadt threatened to remove hifn from the tree. Though unlikely, Theo may be wrong. But that should be none of your concern. This is not about who is right. Your concern is making your customers happy. Unhappy customers buy elsewhere. Prospective customers who can't run your hardware buy elsewhere. I'd personally like to be able to select the best hardware around and be able to run it too. I like selection. Make the best chips and see they're supported--then you will be able to fire the advertising department. Think of your money, Mr. Cohen. Think of mine. Travers Buda
Re: Hifn policy on documentation
Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. *cough*bullshit*cough* I hope that this clears the air. Hope in one hand --Bryan
Re: Hifn policy on documentation
Travers Buda wrote: On Mon, 12 Jun 2006 21:10:13 -0700 Hank Cohen [EMAIL PROTECTED] wrote: Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. etc... Hank Cohen, You really ought to consider what _you_ want, which, I guess is a job at hifn. That's made possible by selling hardware. Despite how reasonable your process seems to be, de Raadt threatened to remove hifn from the tree. Though unlikely, Theo may be wrong. But that should be none of your concern. This is not about who is right. Your concern is making your customers happy. Unhappy customers buy elsewhere. Prospective customers who can't run your hardware buy elsewhere. I'd personally like to be able to select the best hardware around and be able to run it too. I like selection. Make the best chips and see they're supported--then you will be able to fire the advertising department. Think of your money, Mr. Cohen. Think of mine. Travers Buda That gets a bit close to why I lurk on misc@ (and I doubt that I'm alone). The people at OpenBSD understand hardware. They like to support hardware. (I've run OpenBSD because the Linux driver of a SCSI card couldn't work with the SCSI BIOS and I didn't want to boot from floppy). If something is giving OpenBSD trouble, regardless of why, I do not expect the trouble to stay confined to OpenBSD. If something, for whatever reason (including unreasonable whims), is giving OpenBSD trouble, watch for it to give trouble to Windows and Linux. ... somewhere, somehow ... (It's like water has this tendency to more or less move downhill) As to questionaires, as soon as something starts looking like spam-harvesting I'm outa there. (I am NOT security-conscious, but I am also not THAT stupid.)
Re: Hifn policy on documentation
On 6/13/06, Theo de Raadt [EMAIL PROTECTED] wrote: There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. The simple fact is that anyone who wants access to Hifn's documentation need only log on to our extranet site (http://extranet.hifn.com/home/) to download as much as they like. That URL is not a place where you can download data sheets. That is a registration site that requires anyone who wants data sheets to enter approximately 50 personal questions. Phew! I can get documentation for pretty much 99% of the chips in the industry without supplying any private information. I don't TRUST you to keep my personal data private. Same case with many like me! Specifically the documentation for 7954, 7955 and 7956 is available. The other chips that are supported by the Open BSD Crypto drivers hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851 and 7854) are legacy parts that are not recommended for new designs. The driver will also work for 7954 even though that is not listed. All of this is irrelevant. You require people to register. Do you understand what you are asking people to do? You are saying Please give us all your private information, and then use the data sheets to write code that will help sell our product. This does represent some liberalization of access in recent months. No it does not. 8 years ago all the above data sheets were fully available for download without any registration. Then about 5 years ago hifn closed up completely, and documentation was totally unavailable. About 2 years ago hifn went to this new model of answer 50 personal questions. 50 personal questions is not open access. Please don't lie about it. Other crypto chip vendors make their data much more easily available. Hifn is always monitoring its policy with respect to the confidentiality of documentation and other business information. No, hifn is not monitoring the effects of their policy at all. Over the last few years I have had extensive email conversations with hifn employees (including you) on this issue, and absolutely nothing has changed. You still think it is OK to get this personal information from people. You tried to pacify me in private mail. And now after all that he wants to cheat the rest of us with this innocent looking email. And he even dares to send these lies to a public mailing list with no regard to the consequences. Some information will probably always require a non-disclosure agreement. Information that falls into that category is generally of a sensitive competitive nature, contains trade secrets or is related to unanounced or unreleased products. But we don't care about that information. We simply care about completely unfettered access to data sheets that were freely available without registration 8 years ago. Software licenses are generally restricted in the disclosure or source code reproduction rights. Hifn reserves the right to keep our source code proprietary. This should not affect the hifn(4) driver since that driver is programmed directly to the hardware and does not use Hifn's enablement software library. The only person talking about hifn's proprietary code is you. If you showed it to us, we would not bother looking at it. Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. So the personal information you ask for in the registration process will be given to the US government if they ask? Without court documents demanding the information? We are not your customers. YOU ARE OUR CUSTOMER. Our driver sells your chips. I know that our hifn driver has some problems. But because I cannot get data sheets without giving you private information, I will not spend even one moment more of my time to improve support for your products. Jason and I spent a lot of time writing that code in the past, but because your policies are privacy invasive towards us, and thus completely thankless for the sales that we have given you in the past -- we will not spend any more time on your crummy products. And if you continue baiting me, I will delete the driver from our source tree. I stand by my statement that HIFN is not open. Mr Cohen, I take recommendations for the hardware I use and recommend to my clients from 1) developers of OpenBSD, 2) manual pages and 3) this mailing list to which you sent your mail.
Re: developing a backup strategy
On 6/13/06, Bob Beck [EMAIL PROTECTED] wrote: * prad [EMAIL PROTECTED] [2006-06-12 11:54]: i've gone through the threads: Recommendations for an OpenBSD-based Backup Solution remote data backup and am contemplating the ideas as they apply to my rather simple setup - 2 webservers (one does email as well). not too much changes on them and not a lot of stuff on them either (under 5G combined including OpenBSD). what i've done in the past is just scp the etc and a few other directories that contain data with the intention of reinstalling OpenBSD and putting those directories back in (if disaster strikes). is this too simplistic and inefficient a solution? should i be thinking of incremental backups say with dump? does it make any sense to rsync the entire server drive? It depends. decide how long you could be down for which situations, and test it. (I.e. are you comfortable recovering your machiens that way). Take your backed up /etc and data files, install a new box and see how long it takes you to get the world back. If that time is reasonable, you've got a pretty good solution, and I'd stick with it. The *VAST* majority of my systems here rely on exactly that for the system config, or frequently they are clones of each other so I have to lose all 10 to not be able to rebuild one trivially. OTOH, if you need to do stuff like recover data files user stupidity, etc, you may want to have some incrementals to find out what state that file was in a week ago. we do incremental type backups for this stuff. I use backuppc for this. http://backuppc.sourceforge.net/ It is not in 3.9 ports. It was sent to me by the maintainer a while back and it runs well on my OpenBSD 3.9/amd64 backupserver. It has a webinterface and the maintainer has done a good job to run it under the present apache chroot setup :-) . I could mail it to you if you need it. You can get things restored on to a differrent machine just with the click of a button. For Linux/Unix systems you can use rsync via SSH and keep your data secure over the internet. I also use Subversion ( available in ports ) for incremental backup. Kind Regards Siju
