Re: 4.0 i386 MP/clock issue?
On Sat, 2 Sep 2006, Jason George wrote:
> I have an older dual P3-800 Compaq DL360 that I'm planning on using as a test
> platform for Anil's Xen work. It panicked earlier this week while booting the
> Aug 30 snapshot install kernel (first dmesg below).
>
> In private email, Theo gave me the standard PCIBIOS/MPBIOS rant and mentioned
> Portugal (enough said, you know who you are...)
>
> I ran the SmartStart CD and re-enabled the onboard SCSI (the ciss RAID card
> was removed before I got ahold of the machine) and was able to install the Sep
> 1 snapshot.
>
> Interestingly, the MP kernel does not see the second processor, even though
> the BIOS detects it on power up (second dmesg below).
>
> Given the closing window as we approach 4.0, I'm not expecting anything to be
> addressed in an immediate manner in regards to the multiprocessor end of
> things.
>
> What may be of more immediate interest are the clock adjustments below... note
> the jumps between ~13700s and ~2100s:
How large is the "real" offset? What happens if you set the time
yourself to a value reasonable close to the actual value?
-Otto
>
> $ cat /var/log/daemon
> Sep 2 12:33:47 dl360-800 ntpd[30690]: ntp engine ready
> Sep 2 12:33:48 dl360-800 savecore: no core dump
> Sep 2 12:34:09 dl360-800 ntpd[30690]: peer 24.130.207.189 now valid
> Sep 2 12:36:39 dl360-800 ntpd[12524]: ntp engine ready
> Sep 2 12:36:39 dl360-800 savecore: no core dump
> Sep 2 12:36:59 dl360-800 ntpd[12524]: peer 216.239.80.163 now valid
> Sep 2 12:37:55 dl360-800 ntpd[11652]: adjusting local clock by 13785.719230s
> Sep 2 12:41:16 dl360-800 ntpd[11652]: adjusting local clock by 2139.749345s
> Sep 2 12:42:21 dl360-800 ntpd[11652]: adjusting local clock by 13775.507384s
> Sep 2 12:44:04 dl360-800 ntpd[11652]: adjusting local clock by 2143.520959s
> Sep 2 12:46:53 dl360-800 ntpd[11652]: adjusting local clock by 13765.050606s
> Sep 2 12:47:28 dl360-800 ntpd[11652]: adjusting local clock by 2146.171145s
> Sep 2 12:49:08 dl360-800 ntpd[11652]: adjusting local clock by 13759.905097s
> Sep 2 12:52:59 dl360-800 ntpd[11652]: adjusting local clock by 13751.010840s
> Sep 2 12:54:09 dl360-800 ntpd[11652]: adjusting local clock by 2144.801233s
> Sep 2 12:54:44 dl360-800 ntpd[11652]: adjusting local clock by 13746.983945s
> Sep 2 12:58:31 dl360-800 ntpd[11652]: adjusting local clock by 13738.295899s
> Sep 2 13:01:19 dl360-800 ntpd[11652]: adjusting local clock by 2140.996292s
> Sep 2 13:02:28 dl360-800 ntpd[11652]: adjusting local clock by 13729.183509s
> Sep 2 13:06:55 dl360-800 ntpd[11652]: adjusting local clock by 13718.932625s
> Sep 2 13:09:11 dl360-800 ntpd[11652]: adjusting local clock by 2142.278127s
> Sep 2 13:10:17 dl360-800 ntpd[11652]: adjusting local clock by 13711.182821s
> Sep 2 13:14:43 dl360-800 ntpd[11652]: adjusting local clock by 13700.970419s
> Sep 2 13:16:59 dl360-800 ntpd[11652]: adjusting local clock by 13695.774769s
> $
>
>
> If any developers are interested in commenting or want more information, drop
> me a note. This isn't a priority or showstopper for me and I have enough to
> do with Real Life and 4.0 prep while Theo is out of town, but if anyone wants
> to take a stab, let me know...
>
> Thanks!
>
> --Jason
>
>
>
>
> dmesg #1:
>
> boot> boot /4.0/i386/bsd.rd
> booting cd0a:/4.0/i386/bsd.rd: 4692500+739940 [52+164128+149970]=0x57b114
> entry point at 0x200120
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright (c) 1995-2006 OpenBSD. All rights reserved. http://www.OpenBSD.org
>
> OpenBSD 4.0 (RAMDISK_CD) #33: Wed Aug 30 13:39:12 MDT 2006
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> cpu0: Intel Pentium III ("GenuineIntel" 686-class) 798 MHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,
> FXSR,SSE
> real mem = 402206720 (392780K)
> avail mem = 360169472 (351728K)
> using 4256 buffers containing 20213760 bytes (19740K) of memory
> mainbus0 (root)
> bios0 at mainbus0: AT/286+(00) BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xf,
> SMBIOS rev. 2.3 @ 0xf206c (23 entries)
> bios0: Compaq ProLiant DL360
> pcibios0 at bios0: rev 2.1 @ 0xf/0x2000
> pcibios0: PCI BIOS has 6 Interrupt Routing table entries
> pcibios0: PCI Interrupt Router at 000:15:0 ("ServerWorks OSB4" rev 0x00)
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xe8000/0x6000 0xee000/0x2000!
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20LE Host" rev 0x05
> pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20LE Host" rev 0x05
> pci1 at pchb1 bus 3
> fxp0 at pci1 dev 4 function 0 "Intel 8255x" rev 0x08, i82559: irq 10,
> address 00:50:8b:e0:36:4a
> inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
> fxp1 at pci1 dev 5 function 0 "Intel 8255x" rev 0x08, i82559: irq 11,
> address 00:50:8b:e0:45:e5
> inphy1 at
OT: Amarok Sound Device
Hiya, I decided to bite the bullet and test a 4.0 snapshot. Seems great so far. Seems the guys over at amarok have replaced gstreamer with xine to decode compressed formats. In the old gstreamer config section you could specify a new sound device, which I did because I use a USB audio device. However it seems this option does not exist for the new xine engine. Does anyone know how to change the device, Best Regards Edd
4.0 i386 MP/clock issue?
I have an older dual P3-800 Compaq DL360 that I'm planning on using as a
test platform for Anil's Xen work. It panicked earlier this week while booting
the Aug 30 snapshot install kernel (first dmesg below).
In private email, Theo gave me the standard PCIBIOS/MPBIOS rant and
mentioned Portugal (enough said, you know who you are...)
I ran the SmartStart CD and re-enabled the onboard SCSI (the ciss RAID
card was removed before I got ahold of the machine) and was able to
install the Sep 1 snapshot.
Interestingly, the MP kernel does not see the second processor, even
though the BIOS detects it on power up (second dmesg below).
Given the closing window as we approach 4.0, I'm not expecting anything to
be addressed in an immediate manner in regards to the multiprocessor end
of things.
What may be of more immediate interest are the clock adjustments below...
note the jumps between ~13700s and ~2100s:
$ cat /var/log/daemon
Sep 2 12:33:47 dl360-800 ntpd[30690]: ntp engine ready
Sep 2 12:33:48 dl360-800 savecore: no core dump
Sep 2 12:34:09 dl360-800 ntpd[30690]: peer 24.130.207.189 now valid
Sep 2 12:36:39 dl360-800 ntpd[12524]: ntp engine ready
Sep 2 12:36:39 dl360-800 savecore: no core dump
Sep 2 12:36:59 dl360-800 ntpd[12524]: peer 216.239.80.163 now valid
Sep 2 12:37:55 dl360-800 ntpd[11652]: adjusting local clock by
13785.719230s
Sep 2 12:41:16 dl360-800 ntpd[11652]: adjusting local clock by
2139.749345s
Sep 2 12:42:21 dl360-800 ntpd[11652]: adjusting local clock by
13775.507384s
Sep 2 12:44:04 dl360-800 ntpd[11652]: adjusting local clock by
2143.520959s
Sep 2 12:46:53 dl360-800 ntpd[11652]: adjusting local clock by
13765.050606s
Sep 2 12:47:28 dl360-800 ntpd[11652]: adjusting local clock by
2146.171145s
Sep 2 12:49:08 dl360-800 ntpd[11652]: adjusting local clock by
13759.905097s
Sep 2 12:52:59 dl360-800 ntpd[11652]: adjusting local clock by
13751.010840s
Sep 2 12:54:09 dl360-800 ntpd[11652]: adjusting local clock by
2144.801233s
Sep 2 12:54:44 dl360-800 ntpd[11652]: adjusting local clock by
13746.983945s
Sep 2 12:58:31 dl360-800 ntpd[11652]: adjusting local clock by
13738.295899s
Sep 2 13:01:19 dl360-800 ntpd[11652]: adjusting local clock by
2140.996292s
Sep 2 13:02:28 dl360-800 ntpd[11652]: adjusting local clock by
13729.183509s
Sep 2 13:06:55 dl360-800 ntpd[11652]: adjusting local clock by
13718.932625s
Sep 2 13:09:11 dl360-800 ntpd[11652]: adjusting local clock by
2142.278127s
Sep 2 13:10:17 dl360-800 ntpd[11652]: adjusting local clock by
13711.182821s
Sep 2 13:14:43 dl360-800 ntpd[11652]: adjusting local clock by
13700.970419s
Sep 2 13:16:59 dl360-800 ntpd[11652]: adjusting local clock by
13695.774769s
$
If any developers are interested in commenting or want more information,
drop me a note. This isn't a priority or showstopper for me and I have
enough to do with Real Life and 4.0 prep while Theo is out of town, but if
anyone wants to take a stab, let me know...
Thanks!
--Jason
dmesg #1:
boot> boot /4.0/i386/bsd.rd
booting cd0a:/4.0/i386/bsd.rd: 4692500+739940 [52+164128+149970]=0x57b114
entry point at 0x200120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved.
http://www.OpenBSD.org
OpenBSD 4.0 (RAMDISK_CD) #33: Wed Aug 30 13:39:12 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel Pentium III ("GenuineIntel" 686-class) 798 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,
FXSR,SSE
real mem = 402206720 (392780K)
avail mem = 360169472 (351728K)
using 4256 buffers containing 20213760 bytes (19740K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 12/31/99, BIOS32 rev. 0 @
0xf,
SMBIOS rev. 2.3 @ 0xf206c (23 entries)
bios0: Compaq ProLiant DL360
pcibios0 at bios0: rev 2.1 @ 0xf/0x2000
pcibios0: PCI BIOS has 6 Interrupt Routing table entries
pcibios0: PCI Interrupt Router at 000:15:0 ("ServerWorks OSB4" rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xe8000/0x6000 0xee000/0x2000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20LE Host" rev 0x05
pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20LE Host" rev 0x05
pci1 at pchb1 bus 3
fxp0 at pci1 dev 4 function 0 "Intel 8255x" rev 0x08, i82559: irq 10,
address 00:50:8b:e0:36:4a
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci1 dev 5 function 0 "Intel 8255x" rev 0x08, i82559: irq 11,
address 00:50:8b:e0:45:e5
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
siop0 at pci0 dev 1 function 0 "Symbios Logic 53c1510D" rev
0x02pci_intr_map: no mapping for pin A
: couldn't map interrupt
extent_free: start 0x1800, end 0x18ff
panic: extent_free: region not found
The operating system has halted.
Please press any key to reboot.
dmesg #2:
$ dmesg
OpenBS
Re: The future of NetBSD
Gilbert Fernandes wrote on Fri, Sep 01, 2006 at 11:59:57AM +0200: > I have a dream. A dream of unification. Having one BSD. > Merging the three projects and, why not, keeping incompatible > stuff as options that would be either one or another. Horrors! Options are mostly against the goals of OpenBSD. I, for one, want as little of them as possible. The less complicated something is, the easier it is to maintain. Correctness is too often sacrificed to complexity. That's exactly the main reason why i hate Debian GNU/Linux so much. Options abound, and at least 95% of them are completely useless. You can hardly imagine how much time i already lost digging through literally thousands of lines of completely useless script files, scripts that are advertised for option management - desperately trying to track down some problem in Debian that would have been completely trivial to solve when encountered while using OpenBSD. Some of the worst examples that come to mind look like /etc/cron.* /etc/logrotate.d /etc/alternatives /etc/init.d /etc/rc?.d, runlevels in general and the grub boot manager - and last not least that whole dpkg-query/dpkg-deb/dpkg/apt-cache/apt-get/dselect/aptitude jungle. Zillions of options - and you can not even decide to not use most of them, but are usually forced to learn at least a bit about nearly all of them. Besides, i don't want an option to compile a blob-free kernel, but i want a completely free operating system. Besides, i don't want security options but security by default. It is nice NetBSD, FreeBSD and OpenBSD developers have the option to freely copy code from each other whenever it fits the need at hand. It is also nice to have the option to run either. But stay away from me with any additional options... By the way, there are also a few corners in OpenBSD where options are overdone - if i understand correctly, mostly for historical reasons. The standard example of course is mailwrapper(8) - well, even the man page says so. But i would gladly trash securelevel(7), too, just to give one additional example.
Re: The future of NetBSD
On 9/1/06 9:38 PM, [EMAIL PROTECTED] wrote: Unfortunately, looking at it from the vendors' side, I can at least see their point: what is the business case in creating and maintaining good documentation? They basically need *financial* motivation for taking an engineer off a project to write the documentation (or hire a technical writer, but either way, it's "intellectual capital" that they perceive as not making money). I'm sure a business case could be made, but I'm sure these big vendors have pretty conservative cultures that discourages out-of-box thinking. In this industry parts and products without good documentation are completely clueless. OpenBSD for example is still alive largely because of the miraculous documentation. Companies can hold documentation for themselves but they cannot maintain software for hardware without good documentation. +++chefren
Re: fping & systrace
On Saturday 02 September 2006 12:14, Julien TOUCHE wrote: [cut] > > i don't get it ??? > > "native-getuid: permit as root" doesn't work in a systrace policy You should try "true then permit as root" > $ sudo /bin/systrace -a -c 556:556 /usr/local/sbin/fping localhost > syntax error > /etc/systrace/usr_local_sbin_fping:24: syntax error. > Segmentation fault > > and same for adding a return code to permit. > > nobody with systrace privilege evelation and fping ? The following policy works for me: Policy: /usr/local/sbin/fping, Emulation: native native-geteuid: true then permit as root native-getuid: true then permit as root native-socket: sockdom eq "AF_INET" and socktype eq "SOCK_RAW" then permit as root native-issetugid: permit native-mprotect: prot eq "PROT_READ" then permit native-mmap: prot eq "PROT_READ|PROT_WRITE" then permit native-fsread: filename eq "/var/run/ld.so.hints" then permit native-fstat: permit native-mmap: prot eq "PROT_READ" then permit native-close: permit native-fsread: filename eq "/usr/lib/libc.so.39.2" then permit native-read: permit native-mmap: prot eq "PROT_NONE" then permit native-mmap: prot eq "PROT_READ|PROT_EXEC" then permit native-mprotect: prot eq "PROT_READ|PROT_WRITE" then permit native-mprotect: prot eq "PROT_READ|PROT_WRITE|PROT_EXEC" then permit native-mprotect: prot eq "PROT_READ|PROT_EXEC" then permit native-munmap: permit native-sigprocmask: permit native-__sysctl: permit native-fsread: filename eq "/etc/protocols" then permit native-fsread: filename eq "/etc/malloc.conf" then permit native-seteuid: uid eq "0" and uname eq "root" then permit native-setuid: uid eq "0" and uname eq "root" then permit native-getpid: permit native-sigaction: permit native-gettimeofday: permit native-sendto: sockaddr match "inet-*:0" then permit native-select: permit native-recvfrom: permit native-ioctl: permit native-write: permit native-exit: permit
Re: MegaRAID 320-2x battery tests
On 2006/08/29 00:16, Clint Pachl wrote:
> >bsd.mp with battery installed and connected, write back, adaptive read,
> >direct I/O:
> >
> >[EMAIL PROTECTED]:/home/jross $ dd if=/dev/zero of=/backup/test_file bs=64k
> >count=102400
> >102400+0 records in
> >102400+0 records out
> >6710886400 bytes transferred in 132.209 secs (50759331 bytes/sec)
I've got an interesting variation. SATA 300-8X with a BBU,
writing 4GB file (I don't have a handy spare partition on that
box at the moment to test the raw device)...
sthen:26$ time (dd if=/dev/zero of=blah bs=256k count=16384;sync;sync;sync)
16384+0 records in
16384+0 records out
4294967296 bytes transferred in 29.120 secs (147488939 bytes/sec)
0m29.83s real 0m0.02s user 0m9.36s system
nice and quick (well, not quite the 230MB/s dlg@ reported in the
undeadly.org article about Areca but I'm pretty happy with it) -
then reading it back...
sthen:27$ time (dd if=blah of=/dev/null bs=256k)
16384+0 records in
16384+0 records out
4294967296 bytes transferred in 85.274 secs (50366361 bytes/sec)
1m25.31s real 0m0.02s user 0m4.65s system
can anyone offer a clue? (i386, non-MP, dmesg/bioctl below).
OpenBSD 4.0-beta (GENERIC) #1090: Fri Aug 25 13:14:24 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Opteron(tm) Processor 146 ("AuthenticAMD" 686-class, 1024KB L2 cache)
2 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3
cpu0: Cool`n'Quiet K8 1996 Mhz: speeds: 2000 1800 1000 Mhz
real mem = 1073246208 (1048092K)
avail mem = 917258240 (895760K)
using 4256 buffers containing 107532288 bytes (105012K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 02/21/06, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.3 @ 0xf8dc0 (60 entries)
bios0: Supermicro H8SSL
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4f50/160 (8 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x1166 product 0x0205
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x1600 0xc9800/0x1600 0xcb000/0x2200
0xcd800/0x1000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
ppb0 at pci0 dev 1 function 0 "ServerWorks HT-1000 PCI" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 13 function 0 "ServerWorks HT-1000 PCIX" rev 0xb2
pci2 at ppb1 bus 2
ppb2 at pci2 dev 1 function 0 "Intel IOP331 PCIX-PCIX" rev 0x07
pci3 at ppb2 bus 3
ami0 at pci3 dev 14 function 0 "Symbios Logic MegaRAID SATA 4x/8x" rev 0x07:
irq 9
ami0: LSI 3008, 32b, FW 814B, BIOS vH431, 128MB RAM
ami0: 1 channels, 0 FC loops, 1 logical drives
scsibus0 at ami0: 40 targets
sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct fixed
sd0: 1424784MB, 1424784 cyl, 64 head, 32 sec, 512 bytes/sec, 2917957632 sec
total
scsibus1 at ami0: 16 targets
bge0 at pci2 dev 3 function 0 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): irq 5, address 00:30:48:58:86:40
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci2 dev 3 function 1 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): irq 7, address 00:30:48:58:86:41
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
pciide0 at pci1 dev 14 function 0 "ServerWorks SATA" rev 0x00: DMA
pciide0: using irq 11 for native-PCI interrupt
pciide0: port 0: PHY offline
pciide0: port 1: PHY offline
pciide0: port 2: PHY offline
pciide0: port 3: PHY offline
pciide1 at pci1 dev 14 function 1 "ServerWorks SATA" rev 0x00
piixpm0 at pci0 dev 2 function 0 "ServerWorks HT-1000" rev 0x00: polling
iic0 at piixpm0
admcts0 at iic0 addr 0x2c
pciide2 at pci0 dev 2 function 1 "ServerWorks HT-1000 IDE" rev 0x00: DMA
atapiscsi0 at pciide2 channel 0 drive 0
scsibus2 at atapiscsi0: 2 targets
cd0 at scsibus2 targ 0 lun 0: SCSI0 5/cdrom
removable
cd0(pciide2:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 0
pcib0 at pci0 dev 2 function 2 "ServerWorks HT-1000 LPC" rev 0x00
ohci0 at pci0 dev 3 function 0 "ServerWorks HT-1000 USB" rev 0x01: irq 10,
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci0 dev 3 function 1 "ServerWorks HT-1000 USB" rev 0x01: irq 10,
version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 3 function 2 "ServerWorks HT-1000 USB" rev 0x01: irq 10
usb2 at ehci0: USB revision 2.0
uhub2 at usb2
uhub2: ServerWorks EHCI root hub, rev 2.00/1.00, addr 1
uhub2: 4 ports with 4 removable, self powered
vga1 at pci0 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)
puc0 at pci0 dev 8 function 0 "NetMos 2S1P" rev 0x01: com, com, lpt
pccom3 at puc0 port 0 irq 9 0 : ns16550a, 16 byte fifo
pccom4 at puc0 port 1 irq 9 0 :
IPsec Configuration Questions
Hoping someone can point me in the right direction to get isakmpd working. The scenario: - the router drops all traffic directed to it from the dmz net - the router drops all traffic destined for the lan from the dmz - the router drops all traffic destined for the dmz from the lan - vlan1 (dmz) has linux hosts - vlan2 (lan) has windows and linux hosts, for the purpose of this exercise, I am using a windows host The goals: - create a way by which hosts in the lan can connect to the dmz network using ipsec/isakmpd - starting off with simple auth, shared secret passphrase The problem: - I am unable to establish a SA between the router and the lan hosts isakmpd returns the following: 155359.461787 Default message_recv: cleartext phase 2 message 155359.462366 Default dropped message from 10.107.208.20 port 500 due to notification type INVALID_FLAGS Some background Info: My network is as follows: (trunking is next on my list, but for now, I have separate interfaces on the router for each vlan) | Internet (dynamic ip) |1.1.1.2 ++ | router/fw/isakmpd| ++ 10.180.16.1 | |10.107.208.1 dmz | | lan ++ ++ | | +-+ | switch| | vlan1 | vlan2 | +-+ || || +---+ +---+ | www server| | workstation 1 + | 10.180.16.250 | | 10.107.208.20 + +---+ +---+ - OpenBSD Router: - relavent ifconfig ** internet hme0: flags=8b63 mtu 1500 lladdr xxx groups: egress media: Ethernet 100baseTX full-duplex status: active inet6 xxx%hme0 prefixlen 64 scopeid 0x2 inet 1.1.1.2 netmask 0xe000 broadcast 1.1.1.255 ** lan hme1: flags=8363 mtu 1500 lladdr 08:00:20:ca:7d:c5 media: Ethernet 100baseTX status: active inet 10.107.208.1 netmask 0xff00 broadcast 10.107.208.255 inet6 fe80::a00:20ff:feca:7dc5%hme1 prefixlen 64 scopeid 0x3 ** dmz hme2: flags=8b63 mtu 1500 lladdr 08:00:20:ca:7d:c6 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.180.16.1 netmask 0xff00 broadcast 10.180.16.255 inet6 fe80::a00:20ff:feca:7dc6%hme2 prefixlen 64 scopeid 0x4 # cat isakmpd.policy KeyNote-Version: 2 Authorizer: "POLICY" Licensees: "passphrase:foobar" Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg == "3des" && esp_auth_alg == "hmac-md5" -> "true"; # isakmpd -d -4 -DA=10 155358.773509 Default log_debug_cmd: log level changed from 0 to 10 for class 0 [priv] 155358.775093 Default log_debug_cmd: log level changed from 0 to 10 for class 1 [priv] 155358.775757 Default log_debug_cmd: log level changed from 0 to 10 for class 2 [priv] 155358.776153 Default log_debug_cmd: log level changed from 0 to 10 for class 3 [priv] 155358.776672 Default log_debug_cmd: log level changed from 0 to 10 for class 4 [priv] 155358.777056 Default log_debug_cmd: log level changed from 0 to 10 for class 5 [priv] 155358.777524 Default log_debug_cmd: log level changed from 0 to 10 for class 6 [priv] 155358.777914 Default log_debug_cmd: log level changed from 0 to 10 for class 7 [priv] 155358.778416 Default log_debug_cmd: log level changed from 0 to 10 for class 8 [priv] 155358.778794 Default log_debug_cmd: log level changed from 0 to 10 for class 9 [priv] 155358.779267 Default log_debug_cmd: log level changed from 0 to 10 for class 10 [priv] 155358.788915 Misc 10 monitor_init: privileges dropped for child process 155359.444597 Timr 10 timer_add_event: event connection_checker(0x4fe41420) added last, expiration in 0s 155359.451947 Timr 10 timer_handle_expirations: event connection_checker(0x4fe41420) 155359.452947 Timr 10 timer_add_event: event connection_checker(0x4fe41420) added last, expiration in 60s 155359.453857 Timr 10 timer_add_event: event exchange_free_aux(0x44908c00) added last, expiration in 120s 155359.454632 Exch 10 exchange_establish_p1: 0x44908c00 ISAKMP-peer-west Default-phase-1-configuration policy initiator phase 1 doi 1 exchange 2 step 0 155359.455323 Exch 10 exchange_establish_p1: icookie 4d18594e523695f1 rcookie 155359.455748 Exch 10 exchange_establish_p1: msgid 155359.457524 Timr 10 timer_add_event: event message_send_expire(0x4d2dab00) added before connection_checker(0x4fe41420), expiration in 7s 155359.459672 Timr 10 timer_add_event: event exchange_free_aux(0x44909000) added last, expiration in 120s 155359.460277 Exch 10 exchange_setup_p2: 0x44909000 policy responder phase 2 doi 1 exchange 5 step 0 155359.460737 Exch 10 exchange_setup_p2: icookie 4d18594e523695f1 rcookie a6af81ffd3a2d153 1553
OpenBSD & PCI ADSL Cards
I'm currently in the position where I have an OpenBSD firewall (standard issue x86 affair), a Zyxel 660H-61 ADSL router, and two 3COM WLAN devices providing the necessary services. I'd very much like to consolidate and get one box doing the lot (avoiding the need for extra plug sockets, extra cabling etc.) I have been looking through the archives for info on what success people have had with various PCI ADSL cards with OpenBSD. I understand that in the past the Sangoma cards were used (albeit with binary drivers) but are now unsupported, same with a couple of other vendors' products. [FWIW, I have written to Sangoma to ask if they would be prepared to release the tech docs so a free driver can be written.] Are there *any* PCI ADSL cards which people have working properly with 3.9/4.0? Or am I stuck with needing external ADSL routers bridging to my OpenBSD box? Many thanks in advance... Nick _ The new Windows Live Toolbar helps you guard against viruses http://toolbar.live.com/?mkt=en-gb
Re: New system, couple of issues with amd64 MP kernel?
I just built a dual-core opteron system (some of you may recall my bad hardware last week that put a damper on my OpenBSD installation) and everything went very smoothly with the default amd64 /bsd kernel (installing from the v3.9 cd's). However, my understanding is that in order to take advantage of the dual-core properties of my cpu I need to use the /bsd.mp kernel (please correct me if that's wrong). The machine boots fine with the /bsd.mp kernel, however there are two problems: a) the keyboard is dead. b) the cdrom errors out and cannot be mounted. Both of these items function perfectly under the /bsd kernel. Here is a link to a dmesg that shows the /bsd.mp boot followed by the cdrom errors followed by the /bsd boot. http://members.cox.net/supra/dm.txt At this point, very close to release, you would be much better off trying a snapshot. If you can do this, it will help the project test for release, and you have a much better chance that the bug has been fixed in the meantime. Thanks for the suggestion Tom. I installed the latest amd64 4.0 snapshot and everything seems to be working fine now with both the bsd and bsd.mp kernels. I have submitted a new dmesg, let me know if there is something else useful (for the developers) that I could do to highlight what changed between 3.9 and the 4.0 snapshot. Thanks again, Jef
Laptop recommendation
Ahoy [EMAIL PROTECTED] Just a quick question. I had a look at the laptop page but I'm feeling uncertain at the information being provided, hence my question. I would need a laptop for some particular kind of work. Basically it would need to fit the following criteria: 1.a Contain 2 fully supported network cards of the Gigabit Ethernet kind (rather no slow Realtek stuff but something easy on the CPU) or 1.b Contain 2 fully supported Cardbus ports. 2. Contain a fully supported built-in wireless adapter. 3. Impeccable HDD performance, large drive (trivial). 4. Working USB2.0. Basically, the lappie would work as a sniffer machine, being set between 2 points to capture traffic. Sometimes this would be an ethernet<->wireless 'bridge', again to analyse traffic. I would imagine some people here have used it for this kind of work... On the other hand, any embedded boards that could pull this off? I originally wished to get some Soekris boards from Wim@ but the boards are almost all Fast Ethernet, not Gbit. Preferred to have X working but if not, no big deal. So far the Thinkpads seem to be the best choice given the reports. Any ideas? Thx, P
Changing WEP keys without resetting the NIC
I just hacked the FreeBSD backend of wpa_supplicant enough to connect my OpenBSD laptop to my university's wireless network (just Dynamic WEP, not TKIP or CCMP). I also had to add an ugly hack to dev/ic/rt2560.c to ignore ENETRESET when issuing a SIOCS80211NWKEY ioctl(2) (see below). The patch works for my needs, but I'm not familiar enough with 802.11 to know if there are any cases where changing a WEP key necessitates a reset. Would it be better if the no-reset behavior had to be explicitly requested in the ioctl(2)? (I was thinking perhaps adding an extra IEEE80211_C_DYNAMICWEP capability bit for devices to provide, and changing ieee80211_ioctl to check for this capability and to return a different value if i_wepon has a IEEE80211_NWKEY_DYNAMIC bit set.) Thanks. --- dev/ic/rt2560.c~Sat Sep 2 09:18:46 2006 +++ dev/ic/rt2560.c Sat Sep 2 09:19:13 2006 @@ -2153,6 +2153,13 @@ } break; + case SIOCS80211NWKEY: + /* Allow key changes without resetting. */ + error = ieee80211_ioctl(ifp, cmd, data); + if (error == ENETRESET) + error = 0; + break; + default: error = ieee80211_ioctl(ifp, cmd, data); }
Re: The future of NetBSD
thus Brett Lymn spake:
On Sat, Sep 02, 2006 at 01:47:59PM +0200, Timo Schoeler wrote:
it's one of the most important issues that ever came up in the recent
months on NetBSD MLs, and it's being ignored.
No, Timo, it's not being ignored.
not any longer, yes, as there come replies that back my opinion that
blobs are evil and do not comply with NetBSDs (former?) 'portability and
clean architecture listed as its goals' (quote).
but you do behave as if you as an individuum represent not only NetBSDs
core teams' opinion(s), but that of the whole developer community, and
claim your 'if my gaming station which runs Linux can take blobs without
exploding, NetBSD can do this, too'.
You just cannot accept the answer
is something different to what you want.
you certainly have not the smallest idea of 'what i want'. i am just
pointing to the above statement ('portability and clean architecture
listed as its goals', to remind you).
you are very presumptuous.
You'll probably be happier here.
as i told you, the company i work for and i myself used to run all
'three major BSDs' *as well as* a bunch of proprietary Unices on
professional hardware (read: non-PeeCee hardware; yes, even if you don't
know of such, it still exists).
the obvious death of NetBSD and the screaming of its degenerated
developers as soon as one reminds them of their 'project goals' show the
way to go: drop it.
please stop this thread. you're like a whining child that didn't win a
discussion because it has had only false and rotten arguments and now
complains it lost.
there is black and white. you can promote open source and demand open
documentation, or even open hardware (which would be best; projects of
this character do exist).
or you can start accepting blobs, closed this and that, and finally sell
you soul. it's up to you and i couldn't mind less about it. but the
question then is why did NetBSD ever exist? you can promote Linux or
even Windows with your opinion.
--
Timo Schoeler | http://riscworks.net/~tis | [EMAIL PROTECTED]
RISCworks -- Perfection is a powerful message
ISP | POWER & PowerPC afficinados | Networking, Security, BSD services
GPG Key fingerprint = B5F6 68A4 EC45 C309 6770 38C4 50E8 2740 9E0C F20A
Frankie says: Relax
Re: The future of NetBSD
On Sat, Sep 02, 2006 at 01:47:59PM +0200, Timo Schoeler wrote: > > it's one of the most important issues that ever came up in the recent > months on NetBSD MLs, and it's being ignored. > No, Timo, it's not being ignored. You just cannot accept the answer is something different to what you want. You'll probably be happier here. -- Brett Lymn
Re: The future of NetBSD
thus Marc Espie spake: On Fri, Sep 01, 2006 at 01:15:09PM -0700, Jon R H wrote: There is no way anybody can "win" from any of this! That's the worst part of it all! all BSD's will & are suffering! Nope. I don't see OpenBSD suffering from this, not for real. i back this :) The BSDs have always been about the code, not the organization. yes, and that's why (IMHO) NetBSD has really a problem; since a few days there's 'discussion' about whether or not use or accept blobs. i fully comply to OpenBSDs philosophy here. it's not only a technical thing, it's about (the projects) politics, metaphysics and more. it's one of the most important issues that ever came up in the recent months on NetBSD MLs, and it's being ignored. as a long year user of the three 'major' BSDs myself, i am now realizing (especially after Charles M. Hannums post) that there will be only two BSDs left in our portfolio from the week to come. that means switching a few dozen (!) servers at customers as well as our development of appliances. fortunately, our internal servers were switched some time ago to one of the two remaining BSDs, or commercial UNIX (non-x86/amd64). As long as there are people writing good code with a reasonable licence, who cares where they live ? Certainly not I. neither do i. two last sentences: every OS (or project building, maintaining, running an open source OS) deserves it's developers' politics. if NetBSD suffers that much from it's developers that it 'dies', well, then it be so. i appreciate the OpenBSDs community efforts in building and maintaining a *real* open source OS very much. thank you! cheers, -- Timo Schoeler | http://riscworks.net/~tis | [EMAIL PROTECTED] RISCworks -- Perfection is a powerful message ISP | POWER & PowerPC afficinados | Networking, Security, BSD services GPG Key fingerprint = B5F6 68A4 EC45 C309 6770 38C4 50E8 2740 9E0C F20A Frankie says: Relax
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 01:15:09PM -0700, Jon R H wrote: > There is no way anybody can "win" from any of this! > That's the worst part of it all! > > all BSD's will & are suffering! Nope. I don't see OpenBSD suffering from this, not for real. The BSDs have always been about the code, not the organization. As long as there are people writing good code with a reasonable licence, who cares where they live ? Certainly not I.
Re: fping & systrace
Ted Unangst wrote on 01/09/2006 23:54: >> isn't it limited to a deny (returning an errorcode) ? so how ? >> >> native-getuid: permit >> >> native-getuid: permit[0] => error >> native-getuid: permit as root => error > > yeah, actually i think you want "as root", but for geteuid or whatever > the right syscall is. > i don't get it ??? "native-getuid: permit as root" doesn't work in a systrace policy $ sudo /bin/systrace -a -c 556:556 /usr/local/sbin/fping localhost syntax error /etc/systrace/usr_local_sbin_fping:24: syntax error. Segmentation fault and same for adding a return code to permit. nobody with systrace privilege evelation and fping ? thanks Regards Julien
Re: iwi firmware
Use the link in the iwi(4) manual. Cheers, Andreas On 02/09/06, Tautvydas <[EMAIL PROTECTED]> wrote: Hello List, I've strange problem. My laptop has Intel(r) PRO/Wireless 2200BG network adapter, so I need firmware to work with iwi driver. I've upgraded my obsd system to snapshtop (Intel(r) PRO/Wireless 2200BG) and downloaded latest firmware: http://damien.bergamini.free.fr/ipw/download.html But system says, that I've need at least 3.0 firmware version. dmesg: iwi0: firmware image too old (need at least 3.0) Anyone had the same problem? -- Hi, I'm a .signature virus! Copy me to your .signature file and help me propagate, thanks! -- Andreas Kahari Somewhere in the general Cambridge area, UK
iwi firmware
Hello List, I've strange problem. My laptop has Intel(r) PRO/Wireless 2200BG network adapter, so I need firmware to work with iwi driver. I've upgraded my obsd system to snapshtop (Intel(r) PRO/Wireless 2200BG) and downloaded latest firmware: http://damien.bergamini.free.fr/ipw/download.html But system says, that I've need at least 3.0 firmware version. dmesg: iwi0: firmware image too old (need at least 3.0) Anyone had the same problem? -- Hi, I'm a .signature virus! Copy me to your .signature file and help me propagate, thanks!
New system, couple of issues with amd64 MP kernel?
I just built a dual-core opteron system (some of you may recall my bad hardware last week that put a damper on my OpenBSD installation) and everything went very smoothly with the default amd64 /bsd kernel (installing from the v3.9 cd's). However, my understanding is that in order to take advantage of the dual-core properties of my cpu I need to use the /bsd.mp kernel (please correct me if that's wrong). The machine boots fine with the /bsd.mp kernel, however there are two problems: a) the keyboard is dead. b) the cdrom errors out and cannot be mounted. Both of these items function perfectly under the /bsd kernel. Here is a link to a dmesg that shows the /bsd.mp boot followed by the cdrom errors followed by the /bsd boot. http://members.cox.net/supra/dm.txt Any ideas on what is going on? If there is some kind of issue with the amd64 MP kernel at this time (and I'm probably getting way, way ahead of myself) would I be better off performance wise on my particular CPU running the i386 MP kernel or the amd64 non-MP kernel? Thanks, Jeff
