OpenBSD 5.2 Tos / AckPri
Hi,
In OpenBSD 5.2, does this line : pass all tos lowdelay do the same
job that using altq/priq (see below)?
ext_if=kue0
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)
pass out on $ext_if proto tcp from $ext_if to any flags S/SA \
keep state queue (q_def, q_pri)
from this : http://www.benzedrine.cx/ackpri.html
Thank you very much for your replies.
Cheers,
Wesley.
Re: boot(8) on amd64 asks for passphrase but keydisk...?
On Sun, Nov 04, 2012 at 02:46:55PM -0600, Aaron Poffenberger wrote: Theo de Raadt dera...@cvs.openbsd.org writes: Well I moved to position that booting with a passphrase and then concatenate strong passphrase from an Yubikey configured with static passphrase would be better solution than keydisk and passphrase. Although I don't have an Yubikey token now but as an Yubikey token is simulatin usb keyboard it should work. Has anybody tested Yubikey with new boot(8) asking for passphrase? Then you had better start work on the usb stack for the bootcode. The Yubikey presents itself to the system as a standard USB keyboard. It has two slots for passwords. You can program either slot (or both) to hold a static value or as an OTP generator. When you touch the button on the Yubikey it types out slot one's value. If you touch and hold for 2-3 seconds it types out slot two's value. I just tried mine. At the /boot prompt I plugged it in and touched the type button and it typed out my OTP. I also tried the static password. No problem. Obviously the OTP wouldn't be useful since it requires custom code in the receiver but the static password seems like a viable option. I was thinking the same as Jiri except I'd prepend the system-specific value before letting the Yubikey type the password since it types a carriage return at the end. OTP would be nice but probably one would not get anything as it would need access to something like /var/db/yubikey which could not be secured enough for boot(8)... This was exactly was I meant with '...then concatenate strong passphrase from an Yubikey...'. Thanks for info! jirib
would boot(8) now face an attack as truecrypt evil maid?
I suppose boot(8) supporting now crypto volumes would face same attack as truecrypt - Evil Mail[1] Could be some easy _workaround_ for this? Such as copying boot loader from fixed disks to an usb stick to prevent this kind of physical hardware attack? jirib [1] http://theinvisiblethings.blogspot.cz/2009/10/evil-maid-goes-after-truecrypt.html
Re: OpenBSD 5.2 Tos / AckPri
On Mon Nov 5 2012 12:15, Wesley wrote:
Hi,
In OpenBSD 5.2, does this line : pass all tos lowdelay do the same
job that using altq/priq (see below)?
No.
ext_if=kue0
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)
pass out on $ext_if proto tcp from $ext_if to any flags S/SA \
keep state queue (q_def, q_pri)
The above pass rule says pass all packets with lowdelay TOS flag set,
the other says pass packets leaving the interface and put them into
queue q_def, and if they have the lowdelay TOS flag set, put them into
queue q_pri, instead.
Re: spammers getting less stupid?
On Mon, 5 Nov 2012 07:52:50 +0100, Joakim Aronius wrote: * Kurt Mosiejczuk (kurt-openbsd-m...@se.rit.edu) wrote: Jan Stary wrote: Strangely, the only occurence of 2.139.201.210 in the last month's maillog is just this; that's half an hour after it got WHITE. What happend at Mon Oct 29 14:49:24 CET 2012 that made it WHITE? Anyway, it seems (some) spambots got less demented and actually do resend, getting themselves whitelisted - thus working themselves around the whole premise of greylisting. Are people seeing something similar? I'm seeing it. I recently tweaked my greyscanner settings to pick up some spammers getting through who shouldn't (they were staying just under the threshold for further scrutiny). But I've still been getting a couple a day, and they only just got themselves whitelisted. So, you are not alone... --Kurt Hi, I see it too. I also use greyscanner to catch spammers and I see a lot of spam to random numbers and letters@mydomains. So I trap all hosts sending to addresses with numbers in them (as I don't have any legit accounts with numbers). This catches almost all spam. But I also see some backscatter from legit mail servers sending delivery failure notifications to mails where my domains was used as sender. This then resulting in me blocking these legit servers in case they were not already whitelisted (not good..). Strangely enough it seems like I also get delivery failure notifications from nodes on e.g. xDSL networks, not sure if its 'real' mail servers or bot nodes, some of these retries delivery according to RFC. Needs looking into.. /Joakim I have had a stack of both sides of the invalid address email stuff for some time. I make all the ficticious addresses into spam traps. That way I punish the fools whose servers return mail whence it came not. They just get tarpitted and I don't care as they should be refusing to accept incoming mail which they cannot deliver. Google generates a smaller number now than they were doing a month ago but they are whitelisted and just end up with a 550 NSN rejection. I suspect that the idea is to spread spam/malware by tempting whoever accepts the mail or the returned mail but I don't have time to play with that and they go on getting nowhere on my servers either way. If they really start bothering me in heaps I just may have to launch a few missiles Here's a bit of the output from my spamd database: SPAMTRAP|a3d2...@witworx.com SPAMTRAP|a7c85e...@witworx.com SPAMTRAP|abd3...@witworx.com SPAMTRAP|cc705...@witworx.com SPAMTRAP|cde50...@witworx.com SPAMTRAP|d00a6d...@witworx.com SPAMTRAP|d3a259...@witworx.com SPAMTRAP|dabee8...@witworx.com SPAMTRAP|e0c94...@witworx.com SPAMTRAP|f08b2b...@witworx.com SPAMTRAP|f3dc87...@witworx.com SPAMTRAP|f7ae30...@witworx.com SPAMTRAP|fc53...@witworx.com SPAMTRAP|ff70...@witworx.com I clean out the traps every few days with a script and back they come with new tries. I just wish that backscatter monkeys would get their act into gear because the other ones would simply get nowhere except the tarpit. Don't lose any sleep over it. /R/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: [5.1] pflow(4) flow with starttime *after* endtime
Le Fri, 27 Jul 2012 11:13:21 +0200, Hrvoje Popovski hrv...@srce.hr a écrit : On 26.7.2012. 18:31, Patrick Lamaiziere wrote: Hello, We have just noticed that pflow (v5) sometime (but often) uses a StartTime value which is later than the EndTime. So the duration is interpreted 4294966.29600 secondes. This confuses our collector (nfsen). For the record, that should be fixed in current (r1.21). http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_pflow.c Thanks, regards.
Re: eGalax touchscreen for Exopc
On Mon, 5 Nov 2012 05:39:00 +0100 Tomas Bodzar tomas.bod...@gmail.com wrote: Can you post pcidump -v for vga as well? Curious why dmesg shows not configured (as Pineview devices are supported in system) and X is able to choose driver. Maybe some different revision of device or something like that. These devices don't have a VGA output, only a mini-hdmi. Anyway, below is pcidump -v. I don't know much about X except that I usually end up with a headache when dealing with it. Could it be the touchscreen inputs are being fed to pipe A below, and that is why the mouse cursor is not responding to my finger? [19.280] (II) intel(0): Pipe A is off [19.280] (II) intel(0): Display plane A is now disabled and connected to pipe A. [19.280] (II) intel(0): Pipe B is on [19.280] (II) intel(0): Display plane B is now enabled and connected to pipe B. [19.280] (II) intel(0): Output VGA is connected to pipe none [19.280] (II) intel(0): Output LVDS is connected to pipe B Domain /dev/pci0: 0:0:0: Intel Pineview DMI 0x: Vendor ID: 8086 Product ID: a010 0x0004: Command: 0006 Status ID: 2090 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1b0a Product ID: 00c7 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel Pineview Video 0x: Vendor ID: 8086 Product ID: a011 0x0004: Command: 0007 Status ID: 0090 0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xfe38/0x0008 0x0014: BAR io addr: 0xf170/0x0008 0x0018: BAR mem prefetchable 32bit addr: 0xe000/0x1000 0x001c: BAR mem 32bit addr: 0xfe10/0x0010 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1b0a Product ID: 00c7 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0090: Capability 0x05: Message Signaled Interrupts (MSI) 0x00d0: Capability 0x01: Power Management 0:2:1: Intel Pineview Video 0x: Vendor ID: 8086 Product ID: a012 0x0004: Command: 0007 Status ID: 0090 0x0008: Class: 03 Subclass: 80 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xfe30/0x0008 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1b0a Product ID: 00c7 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00d0: Capability 0x01: Power Management 0:26:0: Intel 82801H USB 0x: Vendor ID: 8086 Product ID: 2834 0x0004: Command: 0005 Status ID: 0280 0x0008: Class: 0c Subclass: 03 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR io addr: 0xf0a0/0x0020 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1b0a Product ID: 00c7 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0:26:1: Intel 82801H USB 0x: Vendor ID: 8086 Product ID: 2835 0x0004: Command: 0005 Status ID: 0280 0x0008: Class: 0c Subclass: 03 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR io addr: 0xf080/0x0020 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1b0a Product ID: 00c7 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt
cpu section in dmesg was changed
After upgrade to latest snapshot I see strange lines in dmesg: Constant TSC= yes Invariant TSC [ITSC]= no Architectural Performance Monitoring [PERF] = yes eax_07-00: Version ID = 2 eax_15-08: Num. of general counters = 2 eax_23-16: Bit width of general counters= 40 eax_31-24: EBX enumeration length = 7 ebx_00:Core cycle event = yes ebx_01:Instruction retired event= yes ebx_02:Reference cycles event = yes ebx_03:Last-level cache reference event = yes ebx_04:Last-level cache misses event= yes ebx_05:Branch instruction retired event = yes ebx_06:Branch mispredict retired event = yes edx_04-00: Num. of fixed counters = 3 edx_12-05: Bit width of fixed counters = 40 Is it ok? OpenBSD 5.2-current (GENERIC.MP) #103: Sun Nov 4 20:54:51 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4184567808 (3990MB) avail mem = 4050690048 (3863MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version 7VET80WW (3.10 ) date 10/02/2009 bios0: LENOVO 406257G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) Constant TSC= yes Invariant TSC [ITSC]= no Architectural Performance Monitoring [PERF] = yes eax_07-00: Version ID = 2 eax_15-08: Num. of general counters = 2 eax_23-16: Bit width of general counters= 40 eax_31-24: EBX enumeration length = 7 ebx_00:Core cycle event = yes ebx_01:Instruction retired event= yes ebx_02:Reference cycles event = yes ebx_03:Last-level cache reference event = yes ebx_04:Last-level cache misses event= yes ebx_05:Branch instruction retired event = yes ebx_06:Branch mispredict retired event = yes edx_04-00: Num. of fixed counters = 3 edx_12-05: Bit width of fixed counters = 40 cpu0: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz, 798.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) Constant TSC= yes Invariant TSC [ITSC]= no Architectural Performance Monitoring [PERF] = yes eax_07-00: Version ID = 2 eax_15-08: Num. of general counters = 2 eax_23-16: Bit width of general counters= 40 eax_31-24: EBX enumeration length = 7 ebx_00:Core cycle event = yes ebx_01:Instruction retired event= yes ebx_02:Reference cycles event = yes ebx_03:Last-level cache reference event = yes ebx_04:Last-level cache misses event= yes ebx_05:Branch instruction retired event = yes ebx_06:Branch mispredict retired event = yes edx_04-00: Num. of fixed counters = 3 edx_12-05: Bit width of fixed counters = 40 cpu1: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz, 798.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu1: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4620 serial 929 type LION oem Panasonic acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0:
Re: boot(8) on amd64 asks for passphrase but keydisk...?
On Nov 5, 2012, at 2:50 AM, Jiri B wrote: On Sun, Nov 04, 2012 at 02:46:55PM -0600, Aaron Poffenberger wrote: Theo de Raadt dera...@cvs.openbsd.org writes: Well I moved to position that booting with a passphrase and then concatenate strong passphrase from an Yubikey configured with static passphrase would be better solution than keydisk and passphrase. Although I don't have an Yubikey token now but as an Yubikey token is simulatin usb keyboard it should work. Has anybody tested Yubikey with new boot(8) asking for passphrase? Then you had better start work on the usb stack for the bootcode. The Yubikey presents itself to the system as a standard USB keyboard. It has two slots for passwords. You can program either slot (or both) to hold a static value or as an OTP generator. When you touch the button on the Yubikey it types out slot one's value. If you touch and hold for 2-3 seconds it types out slot two's value. I just tried mine. At the /boot prompt I plugged it in and touched the type button and it typed out my OTP. I also tried the static password. No problem. Obviously the OTP wouldn't be useful since it requires custom code in the receiver but the static password seems like a viable option. I was thinking the same as Jiri except I'd prepend the system-specific value before letting the Yubikey type the password since it types a carriage return at the end. OTP would be nice but probably one would not get anything as it would need access to something like /var/db/yubikey which could not be secured enough for boot(8)... This was exactly was I meant with '...then concatenate strong passphrase from an Yubikey...'. Thanks for info! jirib Mea culpa. You did write …then concatenate. So much for comprehension 101. ;-) You're welcome. --Aaron
5.2 bsd.rd -- panic: cannot open disk, error EINVAL
I seem to be unable to boot from locally-compiled bsd.rd (i386). I have triple-checked everything I'm doing against release(8) instructions and tried both 5.2 -stable and release CVS tags; the result is the same: panic: cannot open disk, 0x1100/0x2f02, error 22 It may be of note that the bsd.rd distributed by the project works fine and I have had no problems at all with bsd.sp. This problem is also reproducible in the VMware VM that I use to compile. Included below is bsd.rd output from my ALIX system and dmesg from bsd.sp. Thanks. --david ### bsd.rd ### PC Engines ALIX.2 v0.99h 640 KB Base Memory 261120 KB Extended Memory 01F0 Master 044A TS16GCF133 Phys C/H/S 16383/15/63 Log C/H/S 1023/240/63 Using drive 0, partition 3. Loading... probing: pc0 com0 com1 pci mem[640K 255M a20=on] disk: hd0+ OpenBSD/i386 BOOT 3.18 switching console to com0 OpenBSD/i386 BOOT 3.18 boot boot bsd.rd booting hd0a:bsd.rd: 6968724+961936 [52+229744+218028]=0x7fd9e8 entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.2 (RAMDISK_CD) #2: Fri Nov 2 15:19:26 EDT 2012 root@vm.localdomain:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 267976704 (255MB) avail mem = 254894080 (243MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 AMD Geode LX Crypto rev 0x00 at pci0 dev 1 function 2 not configured vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:1e:60:7c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:1e:60:7d ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 15, address 00:0d:b9:1e:60:7e ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 pcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03 pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: TS16GCF133 wd0: 1-sector PIO, LBA, 15296MB, 31326208 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 12, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 12 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr 2 at uhub1 port 2 not configured softraid0 at root scsibus0 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b panic: cannot open disk, 0x1100/0x2f02, error 22 syncing disks... done dumping to dev 1101, offset 0 dump area unavailable rebooting... ### bsd ### OpenBSD 5.2 (GENERIC) #2: Fri Nov 2 15:15:16 EDT 2012 root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 267976704 (255MB) avail mem = 252735488 (241MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:1e:60:7c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11,
Re: 5.2 bsd.rd -- panic: cannot open disk, error EINVAL
I seem to be unable to boot from locally-compiled bsd.rd (i386). I have triple-checked everything I'm doing against release(8) instructions and tried both 5.2 -stable and release CVS tags; the result is the same: panic: cannot open disk, 0x1100/0x2f02, error 22 Let me guess. You have compiled RAMDISK, copied that to bsd.rd, and tried to boot it, didn't you? Compiling RAMDISK is not enough for it to work. You need to put a filesystem in it afterwards - this is what the machinery within src/distrib/ does. Miod
Re: 5.2 bsd.rd -- panic: cannot open disk, error EINVAL
You guessed right. Apparently I don't understand the build process as well as I thought. I skipped the userland + release steps, since there hadn't been any -stable patches against those with 5.2. Sorry for the noise. --david On Mon, Nov 5, 2012 at 8:51 AM, Miod Vallat m...@online.fr wrote: I seem to be unable to boot from locally-compiled bsd.rd (i386). I have triple-checked everything I'm doing against release(8) instructions and tried both 5.2 -stable and release CVS tags; the result is the same: panic: cannot open disk, 0x1100/0x2f02, error 22 Let me guess. You have compiled RAMDISK, copied that to bsd.rd, and tried to boot it, didn't you? Compiling RAMDISK is not enough for it to work. You need to put a filesystem in it afterwards - this is what the machinery within src/distrib/ does. Miod
Re: cpu section in dmesg was changed
Yes, that is expected from snaps right now. 2012/11/5 Sergey Bronnikov este...@gmail.com: After upgrade to latest snapshot I see strange lines in dmesg: Constant TSC= yes Invariant TSC [ITSC]= no Architectural Performance Monitoring [PERF] = yes eax_07-00: Version ID = 2 eax_15-08: Num. of general counters = 2 eax_23-16: Bit width of general counters= 40 eax_31-24: EBX enumeration length = 7 ebx_00:Core cycle event = yes ebx_01:Instruction retired event= yes ebx_02:Reference cycles event = yes ebx_03:Last-level cache reference event = yes ebx_04:Last-level cache misses event= yes ebx_05:Branch instruction retired event = yes ebx_06:Branch mispredict retired event = yes edx_04-00: Num. of fixed counters = 3 edx_12-05: Bit width of fixed counters = 40 Is it ok? OpenBSD 5.2-current (GENERIC.MP) #103: Sun Nov 4 20:54:51 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4184567808 (3990MB) avail mem = 4050690048 (3863MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version 7VET80WW (3.10 ) date 10/02/2009 bios0: LENOVO 406257G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) Constant TSC= yes Invariant TSC [ITSC]= no Architectural Performance Monitoring [PERF] = yes eax_07-00: Version ID = 2 eax_15-08: Num. of general counters = 2 eax_23-16: Bit width of general counters= 40 eax_31-24: EBX enumeration length = 7 ebx_00:Core cycle event = yes ebx_01:Instruction retired event= yes ebx_02:Reference cycles event = yes ebx_03:Last-level cache reference event = yes ebx_04:Last-level cache misses event= yes ebx_05:Branch instruction retired event = yes ebx_06:Branch mispredict retired event = yes edx_04-00: Num. of fixed counters = 3 edx_12-05: Bit width of fixed counters = 40 cpu0: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz, 798.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) Constant TSC= yes Invariant TSC [ITSC]= no Architectural Performance Monitoring [PERF] = yes eax_07-00: Version ID = 2 eax_15-08: Num. of general counters = 2 eax_23-16: Bit width of general counters= 40 eax_31-24: EBX enumeration length = 7 ebx_00:Core cycle event = yes ebx_01:Instruction retired event= yes ebx_02:Reference cycles event = yes ebx_03:Last-level cache reference event = yes ebx_04:Last-level cache misses event= yes ebx_05:Branch instruction retired event = yes ebx_06:Branch mispredict retired event = yes edx_04-00: Num. of fixed counters = 3 edx_12-05: Bit width of fixed counters = 40 cpu1: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz, 798.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF cpu1: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is
Re: low signal strength hostap (Solved)
On 11/04/2012 08:33 PM, Mihai Popescu wrote: Hello there, You need to post full dmesg and configuration files for wireless letting out the sensitive data like wpakey or passwords, maybe domain names too. This way you might get some help, because nobody likes to guess what you have there. Just curious, what is that kind of hardware you posted on the web, is it an alix board? Thanks. . It's not OpenBSD issue. Low signal was due weak contact in labelled red area: http://i.piccy.info/i7/37594bb9588bf4f5da19327a4419f1ca/4-48-188/36478797/SAM_5902.jpg After some hand made tweaks and available means problem was solved. This is not ALIX board. # dmesg OpenBSD 5.1 (GENERIC.MP) #188: Sun Feb 12 09:55:11 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Celeron(R) CPU P4500 @ 1.87GHz (GenuineIntel 686-class) 1.87 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,POPCNT,LAHF real mem = 2003460096 (1910MB) avail mem = 1960562688 (1869MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/27/09, SMBIOS rev. 2.6 @ 0xeb140 (26 entries) bios0: vendor American Megatrends Inc. version 4.6.3 date 05/07/2010 bios0: ICP / iEi B158 acpi0 at bios0: rev 3 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG HPET ASF! acpi0: wakeup devices P0P1(S1) PEGP(S4) P0P2(S1) P0P3(S1) P0P4(S1) P0P5(S1) PS2K(S1) PS2M(S1) BR20(S1) EUSB(S4) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USBE(S4) USB4(S1) USB5(S1) USB6(S1) PEX0(S1) PEX1(S1) PEX2(S1) PEX3(S1) PEX4(S1) PEX5(S1) PEX6(S1) LAN2(S1) PEX7(S1) GBE_(S4) SLPB(S0) PWRB(S1) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Celeron(R) CPU P4500 @ 1.87GHz (GenuineIntel 686-class) 1.87 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,POPCNT,LAHF ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (BR20) acpiprt2 at acpi0: bus 1 (PEX0) acpiprt3 at acpi0: bus -1 (PEX1) acpiprt4 at acpi0: bus -1 (PEX2) acpiprt5 at acpi0: bus -1 (PEX3) acpiprt6 at acpi0: bus -1 (PEX4) acpiprt7 at acpi0: bus -1 (PEX5) acpiprt8 at acpi0: bus 2 (PEX6) acpiprt9 at acpi0: bus -1 (PEX7) acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 bios0: ROM list: 0xc/0xfa00! 0xd/0x1000 ipmi at mainbus0 not configured cpu0: Enhanced SpeedStep 1867 MHz: speeds: 1862, 1729, 1596, 1463, 1330, 1197, 1064, 931 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x12 vga1 at pci0 dev 2 function 0 Intel Mobile HD graphics rev 0x12 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1: apic 0 int 16 drm0 at inteldrm0 Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address 00:18:7d:0e:f5:34 ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 0 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x06: apic 0 int 17 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 6 Intel 3400 PCIE rev 0x06: apic 0 int 18 pci2 at ppb1 bus 2 em1 at pci2 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi, address 00:18:7d:0e:f5:33 ehci1 at pci0 dev 29 function 0 Intel 3400 USB rev 0x06: apic 0 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xa6 pci3 at ppb2 bus 3 pcib0 at pci0 dev 31 function 0 Intel QM57 LPC rev 0x06 ahci0 at pci0 dev 31 function 2 Intel 3400 AHCI rev 0x06: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 1 lun 0: ATA, WDC WD800HLFS-75, 04.0 SCSI3 0/direct fixed naa.50014ee0ab8b7ce0 sd0: 76293MB, 512 bytes/sector, 15625 sectors cd0 at scsibus0 targ 5 lun 0: Optiarc, DVD RW AD-7710H, 1.01 ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 Intel 3400 SMBus rev 0x06: apic 0 int 18 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-8500 SO-DIMM isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: probed fifo depth: 15 bytes com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo com1:
Incomplete packages for sh?
I noticed when populating my mirror with the 5.2 release, that the packages for sh just end with the packages starting with 'g'. I just double checked when writing this, and even ftp.openbsd.org has the same incomplete set of packages for sh. Was there some glitch? Or is there some limitation of the sh architecture I am unaware of? :) --Kurt
Re: boot(8) on amd64 asks for passphrase but keydisk...?
Theo de Raadt wrote: Well I moved to position that booting with a passphrase and then concatenate strong passphrase from an Yubikey configured with static passphrase would be better solution than keydisk and passphrase. Although I don't have an Yubikey token now but as an Yubikey token is simulatin usb keyboard it should work. Has anybody tested Yubikey with new boot(8) asking for passphrase? Then you had better start work on the usb stack for the bootcode. This totally got a chuckle out of me. But really, since it pretends to be a USB keyboard, wouldn't it work? I haven't had trouble using USB keyboards when interacting with boot(8). It's probably the BIOS making it happen, but I'd hope the BIOS would do the same for the yubikey in that case. --Kurt
Chaining serial consoles?
Hi, I need to get serial access to my workstation at work but I have limited real serial ports to work with. Right now I have my two main servers connected by null modem cable to my 2 carped firewalls and that's all good. Each of those servers also has a second serial port that is not used. Can I connect my workstation to one of those servers with another null modem cable? I would then shell in via ssh or cu, then use cu to connect to the console on my workstation. I'm working remotely so I can't just try it but I will be in the office in a couple of weeks. If this will work I'll order in another couple of null modem cables. Thanks, Jeff Ross
Re: When to update -stable?
John Long codeb...@inbox.lv writes: I'm trying to remember how I should know when to update -stable. Is the errata web page the definitive source or is there some place else I should keep an eye on? I just have a cvs up in /etc/weekly.local. The next morning, I look at the emailed output and decide whether to do anything about it.
Re: When to update -stable?
On Mon, Nov 05, 2012 at 07:40:26AM -0600, Carson Chittom wrote: John Long codeb...@inbox.lv writes: I'm trying to remember how I should know when to update -stable. Is the errata web page the definitive source or is there some place else I should keep an eye on? I just have a cvs up in /etc/weekly.local. The next morning, I look at the emailed output and decide whether to do anything about it. That sounds pretty good. Thanks. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: Incomplete packages for sh?
I noticed when populating my mirror with the 5.2 release, that the packages for sh just end with the packages starting with 'g'. I just double checked when writing this, and even ftp.openbsd.org has the same incomplete set of packages for sh. Was there some glitch? Or is there some limitation of the sh architecture I am unaware of? :) The remaining packages are moving to the mirrors now.
Re: Relayd issues with check icmp after upgrade to 5.2
On 2012-11-02, Andrew Klettke aklet...@opticfusion.net wrote:
Just upgraded to 5.2 on one of our backup firewalls, and we are having
issues with hosts that are being checked with ICMP:
This should have been fixed post-5.2, please try this diff against
/usr/src/usr.sbin/relayd and let me know how it goes.
(also at http://junkpile.org/relayd.icmp.diff)
Index: check_icmp.c
===
RCS file: /cvs/src/usr.sbin/relayd/check_icmp.c,v
retrieving revision 1.31
diff -u -p -r1.31 check_icmp.c
--- check_icmp.c9 May 2011 12:08:47 - 1.31
+++ check_icmp.c5 Nov 2012 17:18:30 -
@@ -172,6 +172,7 @@ send_icmp(int s, short event, void *arg)
socklen_tslen;
int i = 0, ttl, mib[4];
size_t len;
+ u_int32_tid;
if (event == EV_TIMEOUT) {
icmp_checks_timeout(cie, HCE_ICMP_WRITE_TIMEOUT);
@@ -208,18 +209,18 @@ send_icmp(int s, short event, void *arg)
continue;
i++;
to = (struct sockaddr *)host-conf.ss;
+ id = htonl(host-conf.id);
+
if (cie-af == AF_INET) {
icp-icmp_seq = htons(i);
icp-icmp_cksum = 0;
- memcpy(icp-icmp_data, host-conf.id,
- sizeof(host-conf.id));
+ icp-icmp_mask = id;
icp-icmp_cksum = in_cksum((u_short *)icp,
sizeof(packet));
} else {
icp6-icmp6_seq = htons(i);
icp6-icmp6_cksum = 0;
- memcpy(packet + sizeof(*icp6), host-conf.id,
- sizeof(host-conf.id));
+ memcpy(packet + sizeof(*icp6), id, sizeof(id));
icp6-icmp6_cksum = in_cksum((u_short *)icp6,
sizeof(packet));
}
@@ -270,7 +271,7 @@ recv_icmp(int s, short event, void *arg)
u_int16_ticpid;
struct host *host;
ssize_t r;
- objid_t id;
+ u_int32_tid;
if (event == EV_TIMEOUT) {
icmp_checks_timeout(cie, HCE_ICMP_READ_TIMEOUT);
@@ -279,6 +280,7 @@ recv_icmp(int s, short event, void *arg)
bzero(packet, sizeof(packet));
bzero(ss, sizeof(ss));
+ slen = sizeof(ss);
r = recvfrom(s, packet, sizeof(packet), 0,
(struct sockaddr *)ss, slen);
@@ -291,7 +293,7 @@ recv_icmp(int s, short event, void *arg)
if (cie-af == AF_INET) {
icp = (struct icmp *)(packet + sizeof(struct ip));
icpid = ntohs(icp-icmp_id);
- memcpy(id, icp-icmp_data, sizeof(id));
+ id = icp-icmp_mask;
} else {
icp6 = (struct icmp6_hdr *)packet;
icpid = ntohs(icp6-icmp6_id);
@@ -299,6 +301,7 @@ recv_icmp(int s, short event, void *arg)
}
if (icpid != cie-env-sc_id)
goto retry;
+ id = ntohl(id);
host = host_find(cie-env, id);
if (host == NULL) {
log_warn(%s: ping for unknown host received, __func__);
Re: Relayd issues with check icmp after upgrade to 5.2
Applied the patch, compiled and installed the new version of relayd, and
everything looks good again. Thanks much!
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/05/2012 09:20 AM, Stuart Henderson wrote:
On 2012-11-02, Andrew Klettke aklet...@opticfusion.net wrote:
Just upgraded to 5.2 on one of our backup firewalls, and we are having
issues with hosts that are being checked with ICMP:
This should have been fixed post-5.2, please try this diff against
/usr/src/usr.sbin/relayd and let me know how it goes.
(also at http://junkpile.org/relayd.icmp.diff)
Index: check_icmp.c
===
RCS file: /cvs/src/usr.sbin/relayd/check_icmp.c,v
retrieving revision 1.31
diff -u -p -r1.31 check_icmp.c
--- check_icmp.c9 May 2011 12:08:47 - 1.31
+++ check_icmp.c5 Nov 2012 17:18:30 -
@@ -172,6 +172,7 @@ send_icmp(int s, short event, void *arg)
socklen_tslen;
int i = 0, ttl, mib[4];
size_t len;
+ u_int32_tid;
if (event == EV_TIMEOUT) {
icmp_checks_timeout(cie, HCE_ICMP_WRITE_TIMEOUT);
@@ -208,18 +209,18 @@ send_icmp(int s, short event, void *arg)
continue;
i++;
to = (struct sockaddr *)host-conf.ss;
+ id = htonl(host-conf.id);
+
if (cie-af == AF_INET) {
icp-icmp_seq = htons(i);
icp-icmp_cksum = 0;
- memcpy(icp-icmp_data, host-conf.id,
- sizeof(host-conf.id));
+ icp-icmp_mask = id;
icp-icmp_cksum = in_cksum((u_short *)icp,
sizeof(packet));
} else {
icp6-icmp6_seq = htons(i);
icp6-icmp6_cksum = 0;
- memcpy(packet + sizeof(*icp6), host-conf.id,
- sizeof(host-conf.id));
+ memcpy(packet + sizeof(*icp6), id, sizeof(id));
icp6-icmp6_cksum = in_cksum((u_short *)icp6,
sizeof(packet));
}
@@ -270,7 +271,7 @@ recv_icmp(int s, short event, void *arg)
u_int16_ticpid;
struct host *host;
ssize_t r;
- objid_t id;
+ u_int32_tid;
if (event == EV_TIMEOUT) {
icmp_checks_timeout(cie, HCE_ICMP_READ_TIMEOUT);
@@ -279,6 +280,7 @@ recv_icmp(int s, short event, void *arg)
bzero(packet, sizeof(packet));
bzero(ss, sizeof(ss));
+ slen = sizeof(ss);
r = recvfrom(s, packet, sizeof(packet), 0,
(struct sockaddr *)ss, slen);
@@ -291,7 +293,7 @@ recv_icmp(int s, short event, void *arg)
if (cie-af == AF_INET) {
icp = (struct icmp *)(packet + sizeof(struct ip));
icpid = ntohs(icp-icmp_id);
- memcpy(id, icp-icmp_data, sizeof(id));
+ id = icp-icmp_mask;
} else {
icp6 = (struct icmp6_hdr *)packet;
icpid = ntohs(icp6-icmp6_id);
@@ -299,6 +301,7 @@ recv_icmp(int s, short event, void *arg)
}
if (icpid != cie-env-sc_id)
goto retry;
+ id = ntohl(id);
host = host_find(cie-env, id);
if (host == NULL) {
log_warn(%s: ping for unknown host received, __func__);
Re: spammers getting less stupid?
Rod Whitworth glis...@witworx.com writes: I have had a stack of both sides of the invalid address email stuff for some time. I make all the ficticious addresses into spam traps. That way I punish the fools whose servers return mail whence it came not. They just get tarpitted and I don't care as they should be refusing to accept incoming mail which they cannot deliver. Just like Rod describes here, I get a fair amount of goodness out of some local greytrapping, where joejob-generated bounces serve as the source of the bogus addresses. I *do* see some of the increased spam volume delivered too, but then it's fairly easy to feed the offending IP addresses into the local spamd-greytrap and serve them as training to the bayesian beast. http://undeadly.org/cgi?action=articlesid=20120604050025 and references therein show a 'works for me' example config (although the first ruleset block should really be discarded in favor of the second one, a true brainfart if there ever was one), with some further field notes to be found over at my blag. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: remote out-of-band management / intel vpro
On 2012-11-03, Tomas Bodzar tomas.bod...@gmail.com wrote: On Fri, Nov 2, 2012 at 9:07 PM, Dewey Hylton dewey.hyl...@gmail.com wrote: for some of my remote customers, as well as my own office, i'm looking for an out-of-band management solution that's cheaper than iLO or DRAC. remote power management would be nice, but network KVM is a must. i read about intel vpro / amt recently and just started looking into it; it seems to be baked into most of their q-series chipsets. has anyone here successfully used the intel solution for KVM or anything else? how about unsuccessfully? having something baked into the chipset makes me worry about compatibility with openbsd, as i'm not sure just how transparent/non-invasive it is. reports either way would be appreciated - as would another usable solution. Just saw it in 52.html Added support for using AMT to provide console-over-Ethernet (c.f. the amtterm package) http://openports.se/comms/amtterm So maybe good chance for you amtterm is for serial console over the NIC, it works on X220 but iirc it doesn't share the nic nicely with em(4). On OpenBSD I'd consider it more of a developer/debug tool than anything else really. For the remote customers, you might do better with some external 1-port IP KVM box (I have a little AdderLink IPEPS box which works directly with a standard VNC client, in my case I've got this so I can use my laptop as a portable screen/keyboard to plug into a server, but it would also work as something that could be left onsite and plugged into a machine as needed, there are slightly smaller alternatives like the lantronix spider but I suspect many of these, though based on VNC type protocols, might need some special java client).
Re: spammers getting less stupid?
On 2012-11-01, Jan Stary h...@stare.cz wrote: Anyway, it seems (some) spambots got less demented and actually do resend, getting themselves whitelisted - thus working themselves around the whole premise of greylisting. Not the whole premise... A good part of it is to just delay the mail, this increases the chance that spamtraps etc will have picked up the mail before you accept it, thus increasing the effectiveness of other checks (DNSBL, razor/pyzor, etc).
Panic during halt (5.2)
Got this panic while running halt -p to shut down my VMware system this evening. First time I've seen it and haven't been able to reproduce in several reboot since. I can't see this being related to my mistakes this morning with bsd.rd, but don't feel entirely confident it wasn't somehow my fault. Either way, here's ps+trace+dmesg for posterity. Thanks. --david syncing disks... uvm_fault(0xd54eea00, 0x0, 0, 1) - e kernel: page fault trap, code=0 Stopped at handle_workitem_freeblocks+0x2b:movl0x10(%eax),%eax ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *22985 1 22985 0 7 0halt 12 0 0 0 30x100200 aiodoned aiodoned 11 0 0 0 30x100200 syncerupdate 10 0 0 0 30x100200 cleaner cleaner 9 0 0 0 30x100200 reaperreaper 8 0 0 0 30x100200 pgdaemon pagedaemon 7 0 0 0 30x100200 bored crypto 6 0 0 0 30x100200 pftm pfpurge 5 0 0 0 30x100200 acpi0 acpi0 4 0 0 0 30x100200 bored syswq 3 0 0 0 3 0x40100200idle0 2 0 0 0 30x100200 kmalloc kmthread 1 0 1 0 30x80 wait init 0 -1 0 0 3 0x200 scheduler swapper ddb trace handle_workitem_freeblocks(d546d498,d532e1fc,d5430e88,f3776dbc) at handle_workitem_freeblocks+0x2b process_worklist_item(d11ff000,0,f3776dfc,d041b72e,0) at process_worklist_item+0x171 softdep_process_worklist(d11ff000,0,f3776e2c,d041a8ca,d54bcd7c) at softdep_process_worklist+0x136 softdep_flushworklist(d11ff000,f3776e6c,d5430e88,d041c8fa,50) at softdep_flushworklist+0x7c ffs_sync(d11ff000,1,d54fd5f0,d5430e88,d11ff01c) at ffs_sync+0x119 dounmount(d11ff000,8,d5430e88,0,f3776ee8) at dounmount+0x66 vfs_unmountall(d0a36420,0,0,d5430e88,9) at vfs_unmountall+0x68 vfs_shutdown(d5430e88,d54eea00,3c00e000,1000,d54eea00) at vfs_shutdown+0x7f boot(1008,0,f3776f9c,d057f7aa,d5430e88) at boot+0x18a sys_reboot(d5430e88,f3776f64,f3776f84,d057fbea,d5430e88) at sys_reboot+0x2c syscall() at syscall+0x26a --- syscall (number 0) --- 0x2: ddb boot reboot vmware: sending length failed, eax=, ecx= vmt0: failed to send shutdown ping vmware: close failed, eax=, ecx= rebooting... OpenBSD 5.2 (GENERIC) #1: Mon Nov 5 08:54:29 EST 2012 root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 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,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,SSSE3,CX16,LAHF real mem = 267907072 (255MB) avail mem = 252665856 (240MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/02/11, BIOS32 rev. 0 @ 0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version 6.00 date 06/02/2011 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) Z01C(S3) P2P1(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) Z01C(S3) P2P2(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) Z01C(S3) P2P3(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) Z01C(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) PE60(S3) S1F0(S3) PE70(S3) S1F0(S3) PE80(S3) S1F0(S3) PE90(S3) S1F0(S3) PEA0(S3) S1F0(S3) PEB0(S3) S1F0(S3) PEC0(S3) S1F0(S3) PED0(S3) S1F0(S3) PEE0(S3) S1F0(S3) PE41(S3) S1F0(S3) PE42(S3) S1F0(S3) PE43(S3) S1F0(S3) PE44(S3) S1F0(S3) PE45(S3) S1F0(S3) PE46(S3) S1F0(S3) PE47(S3) S1F0(S3) PE51(S3) S1F0(S3) PE52(S3) S1F0(S3) PE53(S3) S1F0(S3) PE54(S3) S1F0(S3) PE55(S3) S1F0(S3) PE56(S3) S1F0(S3) PE57(S3) S1F0(S3) PE61(S3) S1F0(S3) PE62(S3)
a pf ruleset 5.2
Hi,
I just built a small firewall using OpenBSD 5.2
Advices are welcome... ;-)
Thank you very much.
So, 2 interfaces, with the following rules :
-Traffic only Ipv4
-Allow pings in/out
-Allow our lan to only have ftp/http and https
-Allow an access from anywhere to our RDP server
-Prioritizing Acks
*
lan=rl0
allow={www,ftp,https}
rdphost=10.0.0.10
set skip on lo
set block-policy return
match in all scrub (no-df max-mss 1440)
match out on egress inet from $lan:network to any nat-to egress
block log all
anchor ftp-proxy/*
pass in quick inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
pass out on egress inet proto tcp set prio (1,7)
pass out on egress inet proto udp
pass out on $lan inet
pass in on $lan proto udp from $lan:network to port domain
pass in on $lan proto tcp from $lan:network to port $allow
pass inet proto icmp all icmp-type echoreq
pass in on egress inet proto tcp from any to any port 3389 \
rdr-to $rdphost tag rdp set prio (1,7)
pass out on $lan tagged rdp
*
Cheers,
Wesley
