Re: 202 days Uptime in OpenBSD 3.6
Marc Balmer wrote: hmm, why are people so proud of their uptimes when it only show they don't care for their systems? I forgot to power it (a Sun IPC) down when I left the company: [draco:~]$ uname -a; uptime OpenBSD draco..com 2.6 GENERIC#287 sparc 11:55AM up 1538 days, 58 mins, 1 user, load averages: 0.22, 0.13, 0.09 Regards, Greg P.S. A current employee provided the uptime -- I didn't use a remote hole. ;) \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Speed of hardware accelerated IPSec VPNs
misc@: I've been asked by several users offlist about expected speeds of hardware accelerated IPSec VPNs. Rather than reply to each individually, I put together the following matrix. I created several VPNs on my 100Mb LAN, using a 2.4GHz Intel system[1] as the iperf server, and a 1.0GHz PadlockACE VIA[2] and a 266MHz net4801[3] as the clients. I also added a Soekris vpn1411 to the VIA[4] and net4801[5] systems. All systems were running OpenBSD 4.0-RELEASE, and all VPNs were host-to-host and manually-keyed. Only one VPN was running at a time. net4801 VIA VPN net4801 vpn1411 VIA vpn1411 None 32.1Mb/s32.1Mb/s92.7Mb/s 92.7Mb/s MD5/3DES 3.510.017.9 39.7 SHA1/AES 6.310.167.3 65.4 SHA2/AES 5.2 5.240.1 40.1 Regards, Greg [1] http://firewallworks.com/archive/misc/20061113/hp_dmesg.txt [2] http://firewallworks.com/archive/misc/20061113/via_dmesg.txt [3] http://firewallworks.com/archive/misc/20061113/net4801_dmesg.txt [4] http://firewallworks.com/archive/misc/20061113/via_vpn1411_dmesg.txt [5] http://firewallworks.com/archive/misc/20061113/net4801_vpn1411_dmesg.txt \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: Status of hardware encryption accelerators
On Sun, 5 Nov 2006, Darrin Chandler wrote: Can you say what the irrelevant i386 machine is? Lots of difference between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where those numbers fit in. The i386 results were sent to me off-list, so I don't know the processor details. It's fast will have to suffice. To put it in perspective, my fastest Intel systems report: Xeon 3.00GHz aes-128-cbc 56117.94k 59781.24k 62908.69k 63702.29k 63485.95k Xeon 3.40GHz aes-128-cbc 64935.33k 71725.72k 74294.15k 75431.37k 75419.89k Regards, Greg \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: Via C7 fully supported?
Rod.. Whitworth [EMAIL PROTECTED] wrote: On Tue, 31 Oct 2006 16:03:24 -0700 (MST), Diana Eichert wrote: And the commell only has 2 1Gb NICs instead of 4. Have a look at the LE565 with (IIRC) 4*1Gb ... It does (4 x Realtek 8169). The dmesg that I posted earlier is from a LE-565. ... and serial access to the BIOS (they say, I haven't seen one yet.) It does this, too. Regards, Greg \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: Via C7 fully supported?
On Wed, 1 Nov 2006, Dimitry Andric wrote: According to the Commell specs, those are actually 4x Realtek 8110S. I misspoke, and just quoted the dmesg. From reviewing Realtek's documentation, the 8169/8169S/8110S are all the same, but the 8110S is designed for system board use. If the chips weren't covered with glued-on heatsinks, I'd read off the model #s... Best regards, Greg \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: Via C7 fully supported?
Jean-Daniel Beaubien [EMAIL PROTECTED] wrote: Is there any company doing a ready-to-use board with this chip? It's a Commell LE-565[1], available from BWI[2]. Enclosures are hard to find, though (it's an EBX form factor). Regards, Greg [1] http://www.commell.com.tw/Product/SBC/LE-565.HTM [2] http://www.bwi.com/prodroot/495985 \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: Via C7 fully supported?
Is the VIA C7 cpu fully supported yet? C7-M dmesg below. The padlock feature designed to speed up crypto looks useful. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 31885.24k 118568.67k 312349.58k 535048.83k 649099.91k Regards, Greg OpenBSD 4.0-current (GENERIC) #1159: Tue Oct 17 18:24:33 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA Esther processor 1000MHz (CentaurHauls 686-class) 1 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MM X,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2 cpu0: unknown Enhanced SpeedStep CPU, msr 0x04090a0904000a09 cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 1000 MHz (844 mV): speeds: 1000, 400 MHz cpu0: RNG AES AES-CTR SHA1 SHA256 RSA real mem = 266825728 (260572K) avail mem = 235655168 (230132K) using 3287 buffers containing 13463552 bytes (13148K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(d2) BIOS, date 06/26/06, BIOS32 rev. 0 @ 0xf9ed0, SMBIOS rev. 2.3 @ 0xf (33 entries) apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xd274 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd180/224 (12 entries) pcibios0: bad IRQ table checksum pcibios0: PCI BIOS has 13 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 10 pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT8237 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc8000/0x1000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA CN700 Host rev 0x00 pchb1 at pci0 dev 0 function 1 VIA CN700 Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA CN700 Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA PT890 Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA CN700 Host rev 0x00 pchb5 at pci0 dev 0 function 7 VIA CN700 Host rev 0x00 ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00 pci1 at ppb0 bus 1 re0 at pci0 dev 11 function 0 Realtek 8169 rev 0x10: irq 10, address 00:03:1d:03:97:ad rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0 re1 at pci0 dev 12 function 0 Realtek 8169 rev 0x10: irq 10, address 00:03:1d:03:97:ae rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 0 re2 at pci0 dev 13 function 0 Realtek 8169 rev 0x10: irq 10, address 00:03:1d:03:97:af rgephy2 at re2 phy 7: RTL8169S/8110S PHY, rev. 0 re3 at pci0 dev 14 function 0 Realtek 8169 rev 0x10: irq 10, address 00:03:1d:03:97:b0 rgephy3 at re3 phy 7: RTL8169S/8110S PHY, rev. 0 pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA pciide0: using irq 10 for native-PCI interrupt pciide1 at pci0 dev 15 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility pciide1: channel 0 disabled (no drives) wd0 at pciide1 channel 1 drive 1: SanDisk SDCFH-512 wd0: 1-sector PIO, LBA, 488MB, 1000944 sectors wd0(pciide1:1:1): using PIO mode 4, DMA mode 2 uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81: irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 10 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 10 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 10 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 uhub3: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 10 usb4 at ehci0: USB revision 2.0 uhub4 at usb4 uhub4: VIA EHCI root hub, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 lm1 at iic0 addr 0x2f: W83782D auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x60: irq 10 ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0) audio0 at auvia0 isa0 at mainbus0 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 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: reported by CPUID; using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pccom2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask ff45 netmask ff45 ttymask ffc7 pctr: user-level cycle counter enabled dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0
Re: 3.7 panic: pool_get
On Wed, 28 Dec 2005, Jose Fragoso wrote: Since understanding this problem is way beyond my current level, I would like some help to find out what might be reason of this problem. Are you doing bridging with this box? If so, do you have any scrub rules in your pf.conf? The reason that I ask is that a colleague of mine experienced a similar problem (albeit with Intel 'fxp' network cards). We ended up removing said scrub rules until we figure out where the problem lies... Regards, Greg \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: VPN: solutions that interoperate with win xp
On Sun, 18 Dec 2005, [EMAIL PROTECTED] wrote: i would love a howto for the win xp boxes ... Charles Dietlein has written a document[1] detailing how to get WinXP's native IPSec talking with OpenBSD, using MMC and the IPSec snapin. (While it's focus is replacing WEP with IPSec, the information is relevant to your situation.) Regards, Greg [1] http://www.dietlein.com/requisites/ipsec/ \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: VIA fanless motherboard - NICS
On Sat, 17 Dec 2005, martin wrote: I'm looking at a VIA motherboard with the following NICS. 3 x INTEL 82551QM 1x 82540EM (Gigabit) Any issues with these ? (Commell LE-564 - Eden 533MHz) If you intend on using the fxp NICs to do bridging with pf + scrub rules, you'll get kernel panics[1]. It's unclear what's actually causing them, though[2]. Other than that, they're fast little boxes. Regards, Greg [1] http://marc.theaimsgroup.com/?l=openbsd-bugsm=113138720504668w=2 [2] http://marc.theaimsgroup.com/?l=openbsd-bugsm=113257636330953w=2 \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: VIA fanless motherboard - NICS
On Mon, 19 Dec 2005, RedShift wrote: Does it happen on *all* fxp cards? Even on other boxes using different motherboards/CPU's? I can confirm that it also occurs on a HP Kayak XU800 (x86) with fxp interfaces, from 3.6 onwards. Regards, Greg \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: OpenBSD T1 router hang
On Wed, 24 Aug 2005, Sean Knox wrote: On the other end, there is a log showing the T1 disconnecting and attempting to reconnect about 15 minutes prior to the above messages. One machine is running a 3.8-beta snapshot from 8-16-05 and the other is running a 3.7 snapshot from 4-12-05. Both are using Sangoma A101u T1/E1 cards. While I haven't had the same problem that you experienced, the san driver has become much more stable for me since canacar@ committed alex@'s if_san_te1.c diff (07/07/2005). You might want to try that on your 3.7 box... Regards, Greg \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: san Sangoma A102u cHDLC support/help
On Sun, 12 Jun 2005, steven n fettig wrote: I've taken a look at a few messages in the archives, but can't make heads or tails as to the current status of setting cHDLC on the A102u. I'm still going back and forth with Sangoma trying to get the A101 cards to work with the native drivers... How do I best go about setting the card to cHDLC (everything else for my T's are standard: B8ZS, ESF, all channels)? It appears that the cards will bring up the T's but I can't pass data or even ping my side of the interface. Anyone using these cards with 3.7 (if not, what are you using) and having luck? The native drivers default to cHDLC, so no options are necessary. While fractional T1s don't work right now (it's my current issue with Sangoma), an all channel setup should. You may have to do an explicit ifconfig san0 up and wait a little while, though (Look for Link connected! in your syslog). Regards, Greg \|/ ___ \|/ [EMAIL PROTECTED] +- 2048/83C90191 -+ @~./'O o`\.~@| 0B 65 E0 58 F3 F9 81 F5 | /__( \___/ )__\ | F0 72 75 FA 1E BD C9 66 | `\__`U_/' +-+
Re: san Sangoma A102u cHDLC support/help
On Mon, 13 Jun 2005, steven n fettig wrote: alas, it was 12 am here - so I couldn't see if they were seeing the link come up or not. (BTW, I waited around 5 min. to see a Link Connected message but never got it. Perhaps I didn't wait long enough? That doesn't make sense, though.) The following works for me, from the command-line, both between two A101s back-to-back and an A101 and a Cisco 2500: # ifconfig san0 down # ifconfig san0 media t1 timeslot all # ifconfig san0 192.168.1.1 192.168.1.2 # ifconfig san0 up You should see Link connected! within a minute or two. If you don't, try unplugging and plugging your T1 cable back in (the LED on the card should change, and you should see some alarms in your syslog). Next try I'm going to get complete dmesg, logs and anything else I can get my hands on...) I'm not at my box right now, but ifconfig san0 debug may yield more clues -- it does for PPP. Regards, Greg \|/ ___ \|/ [EMAIL PROTECTED] +- 2048/83C90191 -+ @~./'O o`\.~@| 0B 65 E0 58 F3 F9 81 F5 | /__( \___/ )__\ | F0 72 75 FA 1E BD C9 66 | `\__`U_/' +-+
