Reading 56.html

[Rod Whitworth]

Minor nit:
I have noticed some removals of SSLv3 mentioned on line but the LibreSSL stanza 
of 56.html
only  has SSLv2 noted as No support..

*** NOTE *** Please DO NOT CC me. I  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: lynx: disable old protocols

[Rod Whitworth]

On Thu, 10 Jul 2014 23:17:44 -0400, Daniel Dickman wrote:

>>> For some urls, lynx will invoke an external command. Turn off telnet,
>>> rlogin and tn3270 urls by defining them to false(1) as documented in the
>>> lynx manual.
>>
>> Gopher and NNTP are actually still being used (the former a bit
>> sparsely, but there are a few servers here and there). The rest I don't
>> mind seeing disappear (we don't ship the telnet and rlogin programs
>> anymore AFAIK, I've never heard of bibp, and we have a finger program as
>> an alternative to the functionality in lynx).
>
>this support does not need to be in base.
>
>>
>>> Finally, turn off the file editor which can be accessed with "g."
>>> using the --disable-dired switch.
>>
>> I don't see a good reason to get rid of this. What is the rationale?
>>
>
>I want a text browser not a file manager.
>

And what do you gain by killing the file editor?
Provided it doesn't prevent my use of vi (set up as system editor,
invoked with e) I don't care.

I love that simple e when doing major config changes or pf.conf etc
etc.



*** NOTE *** Please DO NOT CC me. I  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: compare memcmp with 0

[Rod Whitworth]

On Thu, 19 Jun 2014 21:58:01 -0600 (MDT), Theo de Raadt wrote:

>It should use the mandoc blink tag.

Look at what beck@ started with the libressl web page!
8-)

*** NOTE *** Please DO NOT CC me. I  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.

i386 install bug on recent snap

[Rod Whitworth]

I can see why this one goes unnoticed.

When I grab a snapshot and install on a test machine I make a practice
of deleting the k partition because I don't need it and it takes ages
to newfs it. (Slow Atom box)

Today it caught me. Going through the usual accept defaults (as much as
possible) I hit enter to leave the whole disk for OpenBSD and then
chose E when the partition choices came up.
entered "d k " 
then "q 
"Write new label? [y]" appeared and as usual I hit 
To my surprise I was looking at the fdisk choices section again.

What I missed at first was the Segmentation fault message crammed in
between the partition stuff and the fdisk stuff.

So I just left the k partition in  and all went well.

Completely repeatable.

dmesg:


OpenBSD 5.5-beta (GENERIC.MP) #237: Tue Feb 18 16:19:26 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
real mem  = 2137223168 (2038MB)
avail mem = 2090397696 (1993MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/11, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
bios0: vendor American Megatrends Inc. version "080015" date 06/23/2011
bios0: Standard XS35
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3)
P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
EUSB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 GHz
cpu2:
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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 GHz
cpu3:
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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 3, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpiec0 at acpi0
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpitz0 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xda00! 0xce000/0x1800! 0xcf800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:31:2: mem address conflict 0xfc00/0x400
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02:
msi
azalia0: codecs: IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 4
int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 4
int 17
pci2 at ppb1 bus 2
"JMicron SD/MMC" rev 0x80 at pci2 dev 0 function 0 not configured
sdhc0 at pci2 dev 0 function 2 "JMicron SD Host Controller" rev 0x80:
apic 4 int 18
sdmmc0 at sdhc0
"JMicron Memory Stick" rev 0x80 at pci2 dev 0 function 3 not configured
jme0 at pci2 dev 0 function 5 "JMicron JMC250" rev 0x03: msi, address
80:ee:73:28:4b:69
jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1
uhci0 at pci0 dev 29 function 0 "Intel 82801G

Shuttle XS35V2 dmesg & a couple of buglets (video and USB insertion)

[Rod Whitworth]

buglet 1:
When booting and the screen goes to its 34 line 85 column mode the text
mode fits into 30cm wide and 22cm high at the top left corner of a 38cm
wide 30cm high screen.

X runs full screen.

buglet 2:
When capturing the dmesg into a file on a USB mem there was no white on
blue notice telling me that sd0 had been inserted. Or removed 8-)

Neither happens on an Intel 945GTP running the same snapshot.

dmesg:
OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
real mem  = 2137223168 (2038MB)
avail mem = 2090381312 (1993MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/11, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
bios0: vendor American Megatrends Inc. version "080015" date 06/23/2011
bios0: Standard XS35
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3)
P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
EUSB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 GHz
cpu2:
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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 686-class)
1.80 GHz
cpu3:
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,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 3, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpiec0 at acpi0
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpitz0 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xda00! 0xce000/0x1800! 0xcf800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:31:2: mem address conflict 0xfc00/0x400
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02:
msi
azalia0: codecs: IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 4
int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 4
int 17
pci2 at ppb1 bus 2
"JMicron SD/MMC" rev 0x80 at pci2 dev 0 function 0 not configured
sdhc0 at pci2 dev 0 function 2 "JMicron SD Host Controller" rev 0x80:
apic 4 int 18
sdmmc0 at sdhc0
"JMicron Memory Stick" rev 0x80 at pci2 dev 0 function 3 not configured
jme0 at pci2 dev 0 function 5 "JMicron JMC250" rev 0x03: msi, address
80:ee:73:28:4b:69
jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 4
int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 4
int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 4
int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 4
int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 

Re: Buggy i386 install55.iso

[Rod Whitworth]

Latest snap (2014-01-22) has same bug although I don't recall the
original one rebooting after the crash as this one does. OTOH cranial
memory rusty...

On Wed, 22 Jan 2014 12:09:44 +1100, Rod Whitworth wrote:

>Date 2014-01-20 
>Downloaded copies from two mirrors same result.
>Second one from Edmonton.
>
>Doing install (not doing upgrade etc) process gets to the point of
>loading sets and crashes with a 5 line message that disappears before I
>can memorise it and a faster small message that gets away from me.
>
>Tested on two disparate machines - same result.
>
>Repeatability 100%.
>
>I'll try an amd64 and report result.
>
>/R/
>
>*** NOTE *** Please DO NOT CC me. I  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.
>
>

*** NOTE *** Please DO NOT CC me. I  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: Buggy i386 install55.iso

[Rod Whitworth]

On Wed, 22 Jan 2014 12:09:44 +1100, Rod Whitworth wrote:

>Date 2014-01-20 
>Downloaded copies from two mirrors same result.
>Second one from Edmonton.
>
>Doing install (not doing upgrade etc) process gets to the point of
>loading sets and crashes with a 5 line message that disappears before I
>can memorise it and a faster small message that gets away from me.
>
>Tested on two disparate machines - same result.
>
>Repeatability 100%.
>
>I'll try an amd64 and report result.
>
>/R/

The bug is not evident in either test machine running amd64 snap dated
Jan 20 (presently the one on offer in snapshots)

/R/

*** NOTE *** Please DO NOT CC me. I  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.

Buggy i386 install55.iso

[Rod Whitworth]

Date 2014-01-20 
Downloaded copies from two mirrors same result.
Second one from Edmonton.

Doing install (not doing upgrade etc) process gets to the point of
loading sets and crashes with a 5 line message that disappears before I
can memorise it and a faster small message that gets away from me.

Tested on two disparate machines - same result.

Repeatability 100%.

I'll try an amd64 and report result.

/R/

*** NOTE *** Please DO NOT CC me. I  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.

5.5beta wierds

[Rod Whitworth]

I had a short run-up of the first 5.5 i386 snap install and it 
looked pretty much as expected but a more recent one showed up and 
I grabbed it and loaded it onto my little Shuttle.


The dmesg is below but I'll make some observations first.

Unlike the earlier snap the screen does not get entirely covered 
when the boot reaches the point where it changes to the higher 
resolution. It now is 33 lines by 83 columns with a great lump of 
black screen below.


I haven't gone hunting for all the nitty-gritty of the new time 
keeping but I did a bit of playing with date -r to see what 
wonderful years we have ahead of us. 8-)


I'm not sure that giving date -r 65599 is likely to 
ever be used but it works.
Sadly it coredumps somewhere above that number. I'm not sure where 
exactly but if you change the leading 6 to a 7 it crashes..


I feel that date should spit out an error message rather than 
crash even if it only happens when some idiot plays with the numbers.


DMESG:
OpenBSD 5.5-beta (GENERIC.MP) #219: Fri Jan 17 16:08:39 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 
686-class) 1.80 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

real mem  = 2137223168 (2038MB)
avail mem = 2090397696 (1993MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/11, BIOS32 rev. 0 @ 
0xf0010, SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
bios0: vendor American Megatrends Inc. version "080015" date 
06/23/2011

bios0: Standard XS35
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3) 
P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) 
USB3(S3) EUSB(S3)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 
686-class) 1.84 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 
686-class) 1.87 GHz
cpu2: 
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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz ("GenuineIntel" 
686-class) 1.84 GHz
cpu3: 
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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 3, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpiec0 at acpi0
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpitz0 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xda00! 0xce000/0x1800! 0xcf800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:31:2: mem address conflict 0xfc00/0x400
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not 
configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 
0x02: msi

azalia0: codecs: IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 
4 int 16

pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 
4 int 17

pci2 at ppb1 bus 2
"JMicron SD/MMC" rev 0x80 at pci2 dev 0 function 0 not configured
sdhc0 at pci2 dev 0 function 2 "JMicron SD Host Controller" rev 
0x80: apic 4 int 18

sdmmc0 

Re: long long time_t for /bin/date

[Rod Whitworth]

On Sat, 19 Oct 2013 20:07:59 -0700, Philip Guenther wrote:

>On Sat, Oct 19, 2013 at 7:34 PM, J Drivdal  wrote:
>> /bin/date -r stops at 2038 with i386.
>> File: src/bin/date/date.c
>
>Thanks.  Committed
>
>
>Philip Guenther
>

Wow!

I knew about that ages ago but I assumed that Theo had decided that
there was a reason to let it grind to a halt - to wit: getting the
attention of people to the need to start working on the Y2K38 bug.

When I wanted to demonstrate the result of not fixing it, I would do
something like:
# date -u -r -2147483648
to get the Dec 13 20:45:52 GMT 1901 result.

NB for the superstitious flock, that's a Friday.
 8-)

R/



*** NOTE *** Please DO NOT CC me. I  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: Intel D945GPT on recently built -current running with framebuffer and all VCONs

[Rod Whitworth]

I have sent the previous message to dmesg@ and to this list so that the
involved devs can see that not only the Intel 915 stuff works but so
does the D945.

Hope this is useful to jsg@ & co.

Rod/

*** NOTE *** Please DO NOT CC me. I  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.

Intel D945GPT on recently built -current running with framebuffer & all VCONs

[Rod Whitworth]

OpenBSD 5.3-current (GENERIC) #11: Tue Mar 26 13:32:47 EST 2013
r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) D CPU 3.20GHz ("GenuineIntel" 686-class) 3.21 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,PDCM,LAHF
real mem  = 1063272448 (1014MB)
avail mem = 1034477568 (986MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/04/07, SMBIOS rev. 2.3 @ 0xe5410 (31 
entries)
bios0: vendor Intel Corp. version "NT94510J.86A.4078.2007.0504.0047" date 
05/04/2007
bios0: Intel Corporation D945GTP
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC WDDT MCFG ASF! HPET SSDT
acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S4) UAR2(S4) PEX0(S4) PEX1(S4) 
PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) 
EHCI(S3) AC9M(S4) AZAL(S4)
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
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P32_)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus -1 (PEX1)
acpiprt4 at acpi0: bus 2 (PEX2)
acpiprt5 at acpi0: bus 3 (PEX3)
acpiprt6 at acpi0: bus -1 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpicpu0 at acpi0
acpibtn0 at acpi0: SLPB
bios0: ROM list: 0xc/0xae00!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0x4000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: apic 2 int 16
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 2 int 17
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: apic 2 int 18
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 2 int 19
pci3 at ppb2 bus 3
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci4 at ppb3 bus 4
fxp0 at pci4 dev 8 function 0 "Intel 82801GB LAN" rev 0x01, i82562: apic 2 int 
20, address 00:16:76:90:35:68
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 ignored (disabled)
pciide1 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 2 int 19 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 2 int 19
iic0 at ichiic0
adt0 at iic0 addr 0x2e: emc6d100 rev 0x68
spdmem0 at iic0 addr 0x50: 512MB DDR2 SDRAM non-parity PC2-5300CL5
spdmem1 at iic0 addr 0x52: 512MB DDR2 SDRAM non-parity PC2-5300CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 ir

Re: touch(1) doesn't act as expected: One for JMC

[Rod Whitworth]

On Tue, 5 Mar 2013 07:42:32 +, Jason McIntyre wrote:

>i don;t much like describing shell behaviour in other pages, but
>we do do it in other pages, and i agree this one seems particularly
>likely to catch folks out. fix coming...

I agree about the shell behaviour being something the beginners should
learn pretty early in their exploration of unix-like topics.

I too agonised a bit about this case and I think I could be convinced
that an example in the syntax lines would catch the eye of anyone who
has learned that that is an "always read this" item when reading ANY
man page.

R/

*** NOTE *** Please DO NOT CC me. I  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.

touch(1) doesn't act as expected: One for JMC

[Rod Whitworth]

Snip from the manpage describing the format used to apply a date to a
file:
ccyy   Year.
   mm Month: a number from 1 to 12.
   dd Day: a number from 1 to 31.
   T  Either the capital letter `T' or a single
space.
   HH Hour: a number from 0 to 23.
   MM Minute: a number from 0 to 59.
   SS Second: a number from 0 to 60 (permitting a
leap
  second).

Result of using a single space instead of T:
# touch -d 2013-03-01 12:34:56 test
touch: out of range or illegal time specification:
-MM-DDThh:mm:ss[.frac][Z]

Of course it is obvious to experienced hands that the space needs to be
escaped but it's not so obvious to beginners. Particularly when the
documentation shows the same string in the syntax as is shown in the
error message - always with the T.

I told the victim to pretend that the "T" was the only valid char in
that space because it's easier to type one char than two.

jmc, care to comment?

*** NOTE *** Please DO NOT CC me. I  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.

minor patch for bgpd.conf man page

[Rod Whitworth]

Found whilst paging down looking for something else...


--- /usr/share/man/man5/bgpd.conf.5 Mon Feb 13 03:34:48 2012
+++ bgpd.conf.5 Tue Jun 19 16:52:55 2012
@@ -30,7 +30,7 @@ in RFC 4271.
 .Sh SECTIONS
 The
 .Nm
-config file is divided into four main sections.
+config file is divided into five main sections.
 .Bl -tag -width 
 .It Sy Macros
 User-defined variables may be defined and used later, simplifying the

OK?


*** NOTE *** Please DO NOT CC me. I  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: enable/fix vt switching on sandybridge machines

[Rod Whitworth]

On Fri, 2 Mar 2012 21:27:52 -0600, joshua stein wrote:

>hi friends,
>
>this enables vt switching on my laptop (dell xps 13) with
>sandybridge video:
>
>  vga1 at pci0 dev 2 function 0 "Intel GT2 Video" rev 0x09
>
>previously it would do nothing on ctrl+alt+f1 and redraw the screen
>on ctrl+alt+f5.  now i am able to switch between the console and X
>multiple times without any problems or artifacts.
>
>can i get some tests on other sandybridge systems like an x220 and
>on non-sandybridge intel video machines?

I have an E320 with the same dmesg line for vga1 as yours and a cpu
line:
cpu0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz ("GenuineIntel"
686-class) 2.50 GHz

The bug made it impossible to get from X back to any console session
and I couldn't do anything in X once I had tried. An established ssh
session into the E320 would still work - handy to reboot - but I
couldn't make another ssh session.

That sounds a bit worse than yours so I should try your patch.

My tree was last updated about Feb 7 but I eyeballed the relevant file
and your patch matches.

What is the minimum path to just updating xenocara to your patch? I'm
used to doing everything in the "update the tree and make everything"
method and that way I don't have the hassles that some bunnies do. This
is the one time I don't want to do the lot because of some work I'm
involved with.

R/

*** NOTE *** Please DO NOT CC me. I  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: Sandy Bridge problems

[Rod Whitworth]

Heavily chopped to  provide less clutter for busy people


On Fri, 17 Feb 2012 10:29:11 +0100, Matthieu Herrb wrote:


>> I did some reading about UMS vs KMS and noted a Phoronix page showing
>> that for many of their benchmarks ran faster in UMS. Not that it will
>> help us if we can't get UMS drivers for many GPUs. Or maybe some *BSD
>> dev will write a UMS driver, but don't hold your breath 8-)
>
>Looks like you've swapped UMS and KMS at least partially. 

Here is a link to the Phoroni
story.
http://www.phoronix.com/scan.php?page=article&item=ati_ubuntu_kmsums&num
=1
pages 2 and 3 have the graphs. Every picture tells a story.



>> Finally, having "wasted" a bunch of money (by my standards) getting a
>> machine that avoided broadcom wi-fi and nvidia graphics and had a
>> supported 10/100/1000 NIC (alc), I'd love to know what I should look
>> for in graphics in future in laptop land.
>> 

>Currently, even if not perfect intel chipsets are useable under
>OpenBSD (I switched to a Thinkpad X220 as my main hacking laptop 2
>month ago, and except for crappy iwn performance, it rocks).

Well, I'd hardly call my machine usable with X given that it only works
fine if you tread carefully and don't succumb to the muscle memory
temporarily and hit ctl-alt-Fx. If I could get in and out of X and the
wscons I wouldn't care about render speed

>For ATI chips, if you stay away from chips that require KMS (mostly
>the recent integrated ones), there are
>still a bunch of laptops with separate GPUs that should just work with
>the ati 6.14.3 driver once we figure out how to put it back in
>OpenBSD. 

The budget doesn't run to sending you my E320 and replacing it with an
x220, sadly.

If you missed my post on misc@ you can find i
at:
http://old.nabble.com/Lenovo-E320%3A-strange-things-happen-with-X-td3332
0989.html

It is really wierd trying to find where the bug lies in the E320. I
have found that the E320 seems to be frozen but it isn't totally. I can
have an ssh session running from another host and it doesn't freeze.
OTOH I cannot establish an ssh connection when I'm jammed in X. If I do
have a session then top looks normal and nothing hits my eye using ps
auxwww.

I'll keep looking though and if you guys make changes I'll hopefully
spot them and do tests. I am subscribed to cvs@ but if I'm away for
many days I tend to rush through it on my return. So I'll sample
http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-intel/
from time to time.

Merci beaucoup,
Rod/

 

*** NOTE *** Please DO NOT CC me. I  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: Sandy Bridge problems

[Rod Whitworth]

On Thu, 16 Feb 2012 10:43:28 -0800, Mike Larkin wrote:

>Intel drivers later than 2.10 are KMS only, which OpenBSD does not support.
>The version in tree, based from CVS logs, is 2.9.1 with various backports
>added from later versions, and some one-off work done to support the
>later Intel chips in UMS.
>

Thanks for the explanation.

I guess that, for at least some time, I'm going to be able to
experience the sort of environment that users of archs that don't
support virtual consoles live with. One difference being that I will
have to sudo reboot to get to a console or sudo halt -p when I want a
shutdown.

I did some reading about UMS vs KMS and noted a Phoronix page showing
that for many of their benchmarks ran faster in UMS. Not that it will
help us if we can't get UMS drivers for many GPUs. Or maybe some *BSD
dev will write a UMS driver, but don't hold your breath 8-)

One intriguing thing I spotted was a statement that KMS allowed running
X without root privs. There is some tension there I expect.

Finally, having "wasted" a bunch of money (by my standards) getting a
machine that avoided broadcom wi-fi and nvidia graphics and had a
supported 10/100/1000 NIC (alc), I'd love to know what I should look
for in graphics in future in laptop land.

Thanks again,
Rod/

*** NOTE *** Please DO NOT CC me. I  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.

Sandy Bridge problems

[Rod Whitworth]

Hi,
I ran into a problem with X in a new Lenovo E320 so I put out a query
on misc and got a rapid response from David Coppa which pointed out
that my problem was caused by the Intel Sandy Bridge stuff. I didn't
need to bug tech@ with that and misc answered me well enough.

Why I am posting on tech is that I went hunting for info to see what
the state of the Intel driver is at elsewhere and whether that could
help us.

A friend who is a Linux guru from way back told me that Linux had
suffered from the early driver code and that, as far as he knew, it was
now fixed. He mentioned 2.17.0 as the version that fixed heaps of bugs.

So I did two things:

I nailed a copy of the driver source tarball and I grabbed a copy of
Fedora 16 that would run as a live cd.

I ran the Fedora on the E320 and could not get it to misbehave in any
way banging in and out of X and cosole sessions.

I untarred the 2.17.0 sources in an isolated dir on my build machine
and looked at the code and tried to see if any of it appeared in the
current Xenocara code.

My eyes are gritty from looking late into the night but I didn't see
any matching stuff.

Can one who knows tell me this:

Do we have 2.17.0 in our tree? If we do it's obvious that there are yet
more bugs for Intel and co to fix.

If we don't have it can I help? Give me some pointers on using that
code and merging it with existing stuff.

I have the time and the boxes to work. I'm lacking the recipe. Heck I
can even do it on the E320 it has 4GB and 4 cores and plenty of HDD and
it doesn't matter if it crashes.

Obligatory dmesg follows. It is Genuine Generic compiled about a week
ago. It includes the hw.sensors because it is a copy of the one sent to
dmesg@

=
OpenBSD 5.1-beta (GENERIC.MP) #5: Tue Feb  7 08:26:54 EST 2012
r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz ("GenuineIntel"
686-class) 2.50 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,PCLMUL,MWAI
T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE
S,XSAVE,AVX,LAHF
real mem  = 3133054976 (2987MB)
avail mem = 3071692800 (2929MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/30/11, BIOS32 rev. 0 @
0xfc000, SMBIOS rev. 2.6 @ 0xe0830 (71 entries)
bios0: vendor LENOVO version "8NET32WW (1.16 )" date 12/01/2011
bios0: LENOVO 1298CTO
acpi0 at bios0: rev 4
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC SSDT SSDT UEFI UEFI
UEFI
acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) HDEF(S4) PXSX(S4)
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) BLAN(S4) PXSX(S4) RP07(S4) PXSX(S4)
RP08(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) LID_(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz ("GenuineIntel"
686-class) 2.50 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,PCLMUL,MWAI
T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE
S,XSAVE,AVX,LAHF
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz ("GenuineIntel"
686-class) 2.50 GHz
cpu2:
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,PCLMUL,MWAI
T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE
S,XSAVE,AVX,LAHF
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz ("GenuineIntel"
686-class) 2.50 GHz
cpu3:
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,PCLMUL,MWAI
T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE
S,XSAVE,AVX,LAHF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus 8 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpithinkpad0 at acpi0
acpiac0 at acpi0: AC unit onlin

Re: login_yubikey manpage missing stuff

[Rod Whitworth]

On Wed, 1 Feb 2012 15:43:57 +0001, Jason McIntyre wrote:

>dhill has a diff. just be patient ;)
>jmc

Thanks.

*** NOTE *** Please DO NOT CC me. I  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.

login_yubikey manpage missing stuff

[Rod Whitworth]

Curiosity made me look at login_yubikey and so I looked at its manpage.

The synopsis says:
login_yubikey [-d] [-s service] user [class]

Nowhere was an explanation of -d.

Guessing that it was debug I went looking at the source and saw that
there was yet another flag unmentioned, to wit, -v.

This was following a complete cvs up yesterday followed by all the
steps upto and including make release.

Perhaps a maestro manpager would like to explain the missing options?

You wouldn't want a diff from me for  task 8-)


*** NOTE *** Please DO NOT CC me. I  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: Filesystem Hierarchy Standard (FHS) and OpenBSD

[Rod Whitworth]

On Tue, 10 May 2011 01:21:
wrote:

>On 05/10/2011 12:28 AM, Kamo Hiroyasu wrote:
>> I do not understand the benefits of FHS for Unixen other than Linux.
>> Most Unixen, including OpenBSD, are older than FHS and have their own
>> historical constraints.  What do we obtain except for switching costs
>> if we accept FHS?
>>
>> It is not we but FHS people that should explain the benefits.  If the
>> explanation is available and acceptable, we can accept FHS.
>> Otherwise, we neet not consider FHS.
>
>I would see standardization as its own benefit; app developers like 
>having a set of conventions they can rely on.
>
>Perhaps, though, I'm not being as clear as I could be.  I'm not 
>necessarily advocating that OpenBSD adopt FHS; my goal is that, since we 
>are changing FHS, we not exclude anyone who wants to use it.  The 
>standard itself claims to apply to any UNIX-like system, and to not be 
>Linux-specific; I'm wanting to find out if that's true.

See:
http://www.openbsd.org/cgi-bin/man.cgi?query=hier&apropos=0&sektion=0&ma
npath=OpenBSD+Current&arch=i386&format=html

I think the "claim" should never have been made. A blatant error like
that will hardly enhance the reputation of the "standard". The
"standard" only applies to those who choose to use it.

I've worked with many Unix/Unix-like OSes and the variations are
obviously so many and so different that anyone other than a
wet-behind-the-ears noobie or someone stuck with one OS for life would
know it.


>
>If it's not, all well and good; we proceed on our separate ways.  But I 
>don't want to assume that without asking.
>

Lots of luck. The draft LHS was released (IIRC) in 1993 when I was an
IBM instructor. It never cut any ice really during my time there which
ended in 2005. 

Six years later and still trying? Give 'em a tick for persistence.


*** NOTE *** Please DO NOT CC me. I  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: -current kernel freeze

[Rod Whitworth]

On Fri, 8 Apr 2011 02:33:51 +0200, Florian Fuessl wrote:

>upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in
>system freezes after some minutes (up to some hours) without any error
>message, here:
>
>OpenBSD 4.9-current (GENERIC) #1: Fri Apr  8 02:20:49 CEST 2011
>root@[...]:/usr/src/sys/arch/i386/compile/GENERIC
>cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3.01 GHz
>cpu0:
>FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
>SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT
>PR
8> 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: Allegations regarding OpenBSD IPSEC

[Rod Whitworth]

On Fri, 17 Dec 2010 00:30:27 +0100, Marc Espie wrote:

> if you read french, go check
>http://www.macgeneration.com/news/voir/180982/un-systeme-espion-du-fbi-dans-openbsd
>and be amazed at how clueless those writers are.

Gee, even the google page translation makes it clearer than my rusty
frangais (` mon icole secondaire de trop nombreuses annies il ya).

Thanks for the laughs, Marc.
*** NOTE *** Please DO NOT CC me. I  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.

bgpd config to announce one netblock only to one upstream

[Rod Whitworth]

I'm looking after a bgpd setup which announces an IPv6 /32 and an IPv4
/21.

Due to a need for some heavy traffic clients to have their traffic
arrive via just one transit I'd like to turn that /21 into a /22 and
two /23s and only advertise one of the /23s via the "heavy traffic"
transit.

I'm on some medication that makes me dopier than usual but I can't even
see a vague hint in man bgpd.conf. Is it possible?


*** NOTE *** Please DO NOT CC me. I  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: socket buffers

[Rod Whitworth]

On Sat, 3 Jul 2010 17:46:22 +0100, Stuart Henderson wrote:

>there is some pretty serious hardware behind it...
>http://mirror.aarnet.edu.au/indexabout.html

Those guys have some serious uses for that equipment in addition to
being a great source of ftp mirrors.

They are ready (or very close) to handling data from Australia and New
Zealand SKA sites.
(Square Kilometer Array http://www.skatelescope.org/) The data is
measured in Terabytes/day.

BTW their OpenBSD mirror currently has 4.7 pkgs for some archs (I did
not check all but amd64 is there) but not i386. Weird.
*** NOTE *** Please DO NOT CC me. I  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: Patch for bogus pointer arithmetic in adw(4)

[Rod Whitworth]

On Tue, 22 Jun 2010 19:00:59 -0700, Tim Wiess wrote:

>FWIW, the original UNIX had bcopy.

I can't find it in my Bell Labs "Unix programmer's manual" Vol 1 1983


*** NOTE *** Please DO NOT CC me. I  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: PF FAQ example ruleset

[Rod Whitworth]

Bump!

On Sun, 13 Jun 2010 12:34:55 +0100, Stuart Henderson wrote:

>On 2010/06/13 21:01, Rod Whitworth wrote:
>> On Sun, 13 Jun 2010 10:48:49 +0100, Stuart Henderson wrote:
>> 
>> >On 2010/06/13 17:31, Rod Whitworth wrote:
>> >> On Sun, 13 Jun 2010 07:44:26 +0100, Jason McIntyre wrote:
>> >> 
>> >> >On Sun, Jun 13, 2010 at 12:36:52PM +1000, Rod Whitworth wrote:
>> >> >> The rule:
>> >> >> pass in on $int_if inet proto tcp to any port ftp \
>> >> >> rdr-to 127.0.0.1 port 8021
>> >> >> 
>> >> >> in the example ruleset on http://www.openbsd.org/faq/pf/example1.html
>> >> >> does not work for active ftp from NATted hosts.
>> >> >> 
>> >> >> There are three solutions which all work.
>> >> >> 
>> >> >> A> make it "pass in quick ."
>> >> >> B> move the rule as-is to the end of the file. (Last match wins..)
>> >> >> C.> move the rule up to the match rules and change "pass" to "match"
>> >> >> 
>> >> >> Which do you prefer?
>> >> >> 
>> >> >
>> >> >if the point of that rule is the same as the point of the rule in
>> >> >ftp-proxy(8), then the rule should really match the man page (which uses
>> >> >"quick") or vice versa.
>> >> 
>> >> Note that the ftp-proxy manpage does "pass in quick" with no interface
>> >> limitation..
>> >
>> >So what do you think, maybe 'pass in quick on !egress...' ?
>> >
>> 
>> Hmmm, now that I'm getting the hang of match, and it gets a lot of
>> exposure in man pf.conf, I'm half inclined to change both the example
>> ruleset AND ftp-proxy manpage to accept the spirit of the pf.conf
>> descriptions.
>> 
>> Particularly because it is another example of match usage that
>> clarifies the pf.conf docs.
>> 
>> The more examples the better, as long as they all do individual tasks.
>> 
>> Of course you guys decide.
>
>match is a bit tricky when you're giving sample rules, because
>it can be affected by rules either side of it - from that
>perspective 'pass quick' rules are quite attractive.
>
>I'll look at a diff later if noone beats me to it. :)
>

*** NOTE *** Please DO NOT CC me. I  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: PF FAQ example ruleset

[Rod Whitworth]

On Sun, 13 Jun 2010 10:48:49 +0100, Stuart Henderson wrote:

>On 2010/06/13 17:31, Rod Whitworth wrote:
>> On Sun, 13 Jun 2010 07:44:26 +0100, Jason McIntyre wrote:
>> 
>> >On Sun, Jun 13, 2010 at 12:36:52PM +1000, Rod Whitworth wrote:
>> >> The rule:
>> >> pass in on $int_if inet proto tcp to any port ftp \
>> >> rdr-to 127.0.0.1 port 8021
>> >> 
>> >> in the example ruleset on http://www.openbsd.org/faq/pf/example1.html
>> >> does not work for active ftp from NATted hosts.
>> >> 
>> >> There are three solutions which all work.
>> >> 
>> >> A> make it "pass in quick ."
>> >> B> move the rule as-is to the end of the file. (Last match wins..)
>> >> C.> move the rule up to the match rules and change "pass" to "match"
>> >> 
>> >> Which do you prefer?
>> >> 
>> >
>> >if the point of that rule is the same as the point of the rule in
>> >ftp-proxy(8), then the rule should really match the man page (which uses
>> >"quick") or vice versa.
>> 
>> Note that the ftp-proxy manpage does "pass in quick" with no interface
>> limitation..
>
>So what do you think, maybe 'pass in quick on !egress...' ?
>

Hmmm, now that I'm getting the hang of match, and it gets a lot of
exposure in man pf.conf, I'm half inclined to change both the example
ruleset AND ftp-proxy manpage to accept the spirit of the pf.conf
descriptions.

Particularly because it is another example of match usage that
clarifies the pf.conf docs.

The more examples the better, as long as they all do individual tasks.

Of course you guys decide.

/R/

*** NOTE *** Please DO NOT CC me. I  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: PF FAQ example ruleset

[Rod Whitworth]

On Sun, 13 Jun 2010 07:44:26 +0100, Jason McIntyre wrote:

>On Sun, Jun 13, 2010 at 12:36:52PM +1000, Rod Whitworth wrote:
>> The rule:
>> pass in on $int_if inet proto tcp to any port ftp \
>> rdr-to 127.0.0.1 port 8021
>> 
>> in the example ruleset on http://www.openbsd.org/faq/pf/example1.html
>> does not work for active ftp from NATted hosts.
>> 
>> There are three solutions which all work.
>> 
>> A> make it "pass in quick ."
>> B> move the rule as-is to the end of the file. (Last match wins..)
>> C.> move the rule up to the match rules and change "pass" to "match"
>> 
>> Which do you prefer?
>> 
>
>if the point of that rule is the same as the point of the rule in
>ftp-proxy(8), then the rule should really match the man page (which uses
>"quick") or vice versa.

Note that the ftp-proxy manpage does "pass in quick" with no interface
limitation..

>
>anyone?
>
>jmc
>

*** NOTE *** Please DO NOT CC me. I  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.

PF FAQ example ruleset

[Rod Whitworth]

The rule:
pass in on $int_if inet proto tcp to any port ftp \
rdr-to 127.0.0.1 port 8021

in the example ruleset on http://www.openbsd.org/faq/pf/example1.html
does not work for active ftp from NATted hosts.

There are three solutions which all work.

A> make it "pass in quick ."
B> move the rule as-is to the end of the file. (Last match wins..)
C.> move the rule up to the match rules and change "pass" to "match"

Which do you prefer?

*** NOTE *** Please DO NOT CC me. I  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.

Missing option letter in inetd manpage

[Rod Whitworth]

For years I've been using -Helo as the flag string for idetnd in
inetd.conf.

I was explaining the man page to a newbie and pointed to the bunch of
options and noticed that H was missing.

simple diff -u
--- identd.8Sun Jun  6 16:04:39 2010
+++ identd.8.newSun Jun  6 16:06:24 2010
@@ -36,7 +36,7 @@
 .Sh SYNOPSIS
 .Nm identd
 .Bk -words
-.Op Fl 46dehlmNnoUv
+.Op Fl 46deHhlmNnoUv
 .Op Fl b | i | w
 .Op Fl a Ar address
 .Op Fl c Ar charset

OK?

*** NOTE *** Please DO NOT CC me. I  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: 4.7 pf

[Rod Whitworth]

On Mon, 12 Apr 2010 08:56:46 +0059, Jason McIntyre wrote:

>On Mon, Apr 12, 2010 at 05:36:35PM +1000, Rod Whitworth wrote:
>> there is no mention of the "pass out on $ext_if nat-to 1.2.3.4" way of
>> doing NAT in the pf.conf manpage for a "vanilla" firewall. There is one
>> use of the construct but it refers to an unlikely scenario of NATting
>> to a "fake internal" network. That wouldn't jump out of the page to a
>> beginner wanting a simple RFC1928 LAN.
>> 
>
>the EXAMPLES section of pf.conf(5) has a lot of nat stuff in it (we
>formerly had separate example sections for stuff like nat, but we merged
>them all).
>
>the binat-to example in particular should be enough to show a very
>simple example.
I can't agree with that. Quite often we have people wanting (probably
the commonest) a home firewall and these folk are the ones who will
rarely do binat. Besides that all the examples of NAT in the pf.conf
manpage and the upcoming pf FAQ use the match action without ever
explaining why. (I'll get onto Nick in another mail).

>
>> 
>> Further the (only) sample pf.conf, the one in /etc, doesn't really
>> represent a useful ruleset.

I want to pursue that a bit further.
Here is the 4.7 pf.conf:
===
#   $OpenBSD: pf.conf,v 1.49 2009/09/17 06:39:03 jmc Exp $
#
# See pf.conf(5) for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or
net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between
interfaces.

set skip on lo

# filter rules and anchor for ftp-proxy(8)
#anchor "ftp-proxy/*"
#pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021

# anchor for relayd(8)
#anchor "relayd/*"

pass# to establish keep-state

# rules for spamd(8)
#table  persist
#table  persist file "/etc/mail/nospamd"
#pass in on egress proto tcp from any to any port smtp \
#rdr-to 127.0.0.1 port spamd
#pass in on egress proto tcp from  to any port smtp
#pass in log on egress proto tcp from  to any port smtp
#pass out log on egress proto tcp to any port smtp


#block in quick from urpf-failed to any # use with care

# By default, do not permit remote connections to X11
block in on ! lo0 proto tcp to port 6000:6010

Comments:
There isn't much active in there and that's fine but the commented out
lines should be doing something useful when uncommented. So let's look
at a few.
I can't object to the spamd lines. They are a complete complement for a
smtpd on either the firewall or downstream with spamd on the gateway.

Now, there are some lines to support ftp proxying. Fine - we may need
that in a NAT situation but there is no NAT rule to give a clue about
NAT and where the rule would sit in the file. So a naive user R'ing The
Fine Manpage would get a "match out /match in" rule pair that deals
with a pool of public addresses. No NAT at its simplest and no
explanation of why match is used.

I found out early in testing a simple ruleset that I couldn't do simple
NAT without using a "pass out" construct so that state was maintained.

OK, assuming we have worked out how to put in a simple NAT what happens
to the remaining rules that may be needed and we'd just have to
uncomment them, right?

Well what happens to that line that says "#pass in quick proto tcp to
port ftp rdr-to 127.0.0.1 port 8021"  ?

It's right up the top and it does a pass in quick for anybody outside
sending packets to port 21. The manpage warns us about that and the
rule used in the past said "rdr pass on ! egress proto tcp to port ftp
-> 127.0.0.1 port 8021"  because we only want it to happen for ftp
connections TO the outside world.

Assuming that we got rid of the default "pass" with your choice of
block, that rule should probably be nearer the head.
>> 
>> I've got everything  need working but am concerned about the unusual
>> lack of clarity for somebody who has not been using pf for years. At
>> one stage we had a bunch of samples in a /usr/somepath directory and a
>> typical beginners firewall template with commented out spamd stuff in
>> /etc
>> 
>
>i can't claim that no one read those examples, but they were largely
>ignored and forgotten about. the commit message removing them probably
>says as much.
>
>also, with something as complex as pf, it's really nice to have the pf
>faq. if something is not neccessarily for the man page, the faq might be
>a good place. you could look there at making some improvements if you
>think there's some basic, helpful, stuff missing.

I think I'll do a really basic home gateway NAT, leaving in the
commented out ftp and spamd stuff. I'll test in the lab for certainty
and pass it on to Nick because it really is a bit l

Re: Add support to AR5424

[Rod Whitworth]

On Tue, 20 Apr 2010 17:58:17 +0100, Luis Henriques wrote:

>On Tue, Apr 20, 2010 at 12:14:51PM -0400, Adam M. Dutko wrote:
>> Lines identifying the card:
>> 
>> ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
>> 10)
>> ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX
>> 
>> I have the version the other folks had that had issues with your patch.  I
>> can still attempt to use the patch if you'd like...
>
>Well, I guess there's no point trying it since this version has been tested
>already.  I can take a look again at the linux and netbsd code to try to figure
>out what is missing to have your card working.  But it will be trial & error:
>I send you a patch and you test it :-)
>
>I'll try to get some time today or tomorrow to dive into the driver again.
>
>--
>Luis
> 
>> On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques 
>> wrote:
>> 
>> > On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko 
>> > wrote:
>> > > I have a card to test with and am trying to solve the problem on my eeepc
>> > > laptop.  Luis, are you still around and interested in working on this?
>> >
>> > Yep, still around. But not sure how I can help without the actual HW.
>> >
>> > Sometime ago I submited a patch that is working for my card:
>> >
>> > ath0 at pci4 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 19 (irq
>> > 11)
>> > ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX
>> >
>> > I'm using a CVS head kernel with this patch on my laptop, but some
>> > other guys tried
>> > the same patch with different revs of the card without success:
>> >
>> > http://marc.info/?l=openbsd-tech&m=126437914024661&w=2
>> >
>> > Try the patch to see what happens. Ah, and send the dmesg (at least the
>> > lines identifing the card.
>> >
>> > --
>> > Luis



Hi Luis,
I have one too. It shows:
ath0: AR5424 14.2 phy 7.0 rf 0.0, EU1W, address XX:XX:XX:XX:XX:XX
and it is in a Samsung  NC20 like the one Todd Fries has
(http://todd.fries.net/pub/chrome.dmesg) except for the EU1W (Euro?) so
there are at least a few of us using OpenBSD with nogo on the built in
card.

I'd like to try a patch too but it will take me a bit longer to get my
build done as I'm short a build machine ATM.  If I can find a supported
mini-pci that works you might just get the ath if you want it. Let me
know.

If you are mailing the patch please send to yendorloki3 at the
same domain as you use. Don't ever try the glisten address!

Thanks,
Rod

*** NOTE *** Please DO NOT CC me. I  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.

4.7 pf

[Rod Whitworth]

Although henning@ (in
http://marc.info/?l=openbsd-misc&m=125181847818600&w=2) said:
8><--- snip
the new NAT code is very very very flexible. every matching "match"
rule changes the adress on the fly (not really, but that is what it
looks like for subsequent rules), and you can nat or rdr multiple
times.
for pass rules, only the last matching one matters.

so given
  match out on $ext_if nat-to 1.2.3.4
  match out on $ext_if to 1.2.3.4 nat-to 5.6.7.8
both rules will match and 5.6.7.8 will be the new src address.
however, with
  pass out on $ext_if nat-to 1.2.3.4
  pass out on $ext_if nat-to 5.6.7.8
ONLY the second one matters for NAT. same semantic that match rules
have for a lot of other stuff (altq, rtable, log, scrub).
8><---end snip
there is no mention of the "pass out on $ext_if nat-to 1.2.3.4" way of
doing NAT in the pf.conf manpage for a "vanilla" firewall. There is one
use of the construct but it refers to an unlikely scenario of NATting
to a "fake internal" network. That wouldn't jump out of the page to a
beginner wanting a simple RFC1928 LAN.

There is no obvious hint as to why I'd ever want to use the "match out"
"nat-to" form.

I think we have the  in spades. I've
transitioned from ipf through pf up to 4.6 without hassles and I've
found it easy to get newbies started with a quick run over the
manpages.

I've also done a few tricky things because the BNF section gave me
clues and I tried them out. BNF didn't help me this time: Configs that
parse correctly don't always function.

Further the (only) sample pf.conf, the one in /etc, doesn't really
represent a useful ruleset.

I've got everything  need working but am concerned about the unusual
lack of clarity for somebody who has not been using pf for years. At
one stage we had a bunch of samples in a /usr/somepath directory and a
typical beginners firewall template with commented out spamd stuff in
/etc

I have been learning a lot about presenting info to people who don't
already know it, so I'm ready to work with you guys on making pf docs
less of a proficiency test. ;-)

R/


*** NOTE *** Please DO NOT CC me. I  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.

Added commands for bgplg

[Rod Whitworth]

Hi,
I haven't written programs in C for many years and most of the ones at
the end of the era of C did not have Makefiles. Back when I started in
the late '70s/early '80s if we had makefiles they were extremely
simple.

So, with some trepidation I set about adding ping6 and traceroute6
commands to bgplg. Not the simplest re-introduction to C and the
OpenBSD build process for hackers, but easily the simplest from a code
point of view. No C really!

I don't have a clue as to how one can add a directory to a branch of
the tree and add a file to it so I'm just listing the two cases where I
did that. I'll give the paths and the file contents as text herein.

First the diffs for the amended files:
1/

Index: src/usr.bin/bgplg/Makefile
===
RCS file: /cvs/src/usr.bin/bgplg/Makefile,v
retrieving revision 1.1
diff -u -p src/usr.bin/bgplg/Makefile
--- src/usr.bin/bgplg/Makefile  11 Dec 2006 23:10:10 -  1.1
+++ src/usr.bin/bgplg/Makefile  2 Apr 2010 06:28:12 -
@@ -2,7 +2,7 @@

 .include 

-SUBDIR=bgplg bgplgsh bgpctl ping traceroute
+SUBDIR=bgplg bgplgsh bgpctl ping traceroute ping6
traceroute6

 INCFILES=  bgplg.head \
bgplg.foot \

2/

Index: src/usr.bin/bgplg/bgplg.c
===
RCS file: /cvs/src/usr.bin/bgplg/bgplg.c,v
retrieving revision 1.8
diff -u -p src/usr.bin/bgplg/bgplg.c
--- src/usr.bin/bgplg/bgplg.c   9 Jan 2010 02:37:32 -   1.8
+++ src/usr.bin/bgplg/bgplg.c   2 Apr 2010 06:30:51 -
@@ -39,6 +39,8 @@
 #define BGPCTL "/bin/bgpctl", "-s", BGPDSOCK
 #define PING   "/bin/ping"
 #define TRACEROUTE "/bin/traceroute"
+#define PING6  "/bin/ping6"
+#define TRACEROUTE6"/bin/traceroute6"
 #define CONTENT_TYPE   "text/html"

 static struct cmd cmds[] = CMDS;

3/

Index: src/usr.bin/bgplg/bgplg.h
===
RCS file: /cvs/src/usr.bin/bgplg/bgplg.h,v
retrieving revision 1.5
diff -u -p src/usr.bin/bgplg/bgplg.h
--- src/usr.bin/bgplg/bgplg.h   20 May 2009 09:45:59 -  1.5
+++ src/usr.bin/bgplg/bgplg.h   2 Apr 2010 06:31:40 -
@@ -64,6 +64,10 @@ struct cmd {
{ TRACEROUTE, "-Sl", NULL } }, 
\
{ "ping", 1, 1, "
", 
\
{ PING, "-c4", "-w2", NULL } },
\
+   { "traceroute6", 1, 1, "
",  
\
+   { TRACEROUTE6, "-l", NULL } }, 
\
+   { "ping6", 1, 1, "
",
\
+   { PING6, "-c4", "-i2", NULL } },   
\
{ "help", 0, 0, NULL, { NULL }, lg_help }, 
\
{ NULL }   
\
 }

4/

Index: src/usr.bin/bgplg/bgplgsh.c
===
RCS file: /cvs/src/usr.bin/bgplg/bgplgsh.c,v
retrieving revision 1.2
diff -u -p src/usr.bin/bgplg/bgplgsh.c
--- src/usr.bin/bgplg/bgplgsh.c 12 Dec 2006 11:43:50 -  1.2
+++ src/usr.bin/bgplg/bgplgsh.c 2 Apr 2010 06:33:44 -
@@ -38,6 +38,8 @@
 #define BGPCTL "/usr/sbin/bgpctl", "-s", BGPDSOCK
 #define PING   "/sbin/ping"
 #define TRACEROUTE "/usr/sbin/traceroute"
+#define PING6  "/sbin/ping6"
+#define TRACEROUTE6"/usr/sbin/traceroute6"

 static volatile int quit;

Now for the added dirs and contents:

mkdir /usr/src/usr.bin/bgplg/ping6
add Makefile to it containing:

#   $OpenBSD: Makefile,v 0.0 2010/04/02 20:00:09 rodw Exp $

PROGDIR=${.CURDIR}/../../../sbin/ping6

LDSTATIC=   -static
CFLAGS+=-I${PROGDIR}
NOMAN=  yes

.include "${PROGDIR}/Makefile"

BINDIR= /var/www/bin
BINMODE=000

.PATH:  ${PROGDIR}

mkdir /usr/src/usr.bin/bgplg/traceroute6

add Makefile to it containing:

#   $OpenBSD: Makefile,v 0.0 2010/04/02 20:00:09 rodw Exp $

PROGDIR=${.CURDIR}/../../../usr.sbin/traceroute6

LDSTATIC=   -static
CFLAGS+=-I${PROGDIR}
NOMAN=  yes

.include "${PROGDIR}/Makefile"

BINDIR= /var/www/bin
BINMODE=000

.PATH:  ${PROGDIR}

There, I think I have given all the details. Not exactly high tech but
a good learning exercise for me and I'm sure there will be some added
clues as a result of this posting.

I haven't done any of the manpage mods yet and I haven't finished
testing because I need to get it running on a remote box so that I have
real IPv6 access. The static v6 commands do run so that is encouraging.

Comments and constructive criticism welcome.

Thanks,
Rod

I need to get some sleep now. I've been standing on the shoulders of
giants most of the day.



*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server i

Re: spelling kate.4

[Rod Whitworth]

On Sat, 12 Dec 2009 07:28:46 +0001, Jason McIntyre wrote:

>On Fri, Dec 11, 2009 at 09:56:16PM -0500, Brad Tilley wrote:
>> Index: kate.4
>> ===
>> RCS file: /cvs/src/share/man/man4/kate.4,v
>> retrieving revision 1.1
>> diff -N -u -p kate.4
>> --- kate.4  27 Mar 2008 01:54:44 -  1.1
>> +++ kate.4  12 Dec 2009 02:49:24 -
>> @@ -56,7 +56,7 @@ temperature sensors in total.
>>  .Pp
>>  Since many prior revisions of the chips appear to have
>>  valid readings for at least some temperature sensors
>> -in the same address space as the abovementioned revisions,
>> +in the same address space as the above mentioned revisions,
>>  the driver may also attach on such older revisions provided
>>  that it finds some sensor readings that appear valid.
>>  However, in such cases
>
>this was probably meant to be "aforementioned".
>jmc
>
And you could take out all the agony by saying:
"in the same address space as the revisions mentioned above"
 Mind you, abovementioned is found in many dictionaries and some copy
editors insist on above-mentioned.

I prefer rearrangement for simplicity to remove irritation. ;)


*** NOTE *** Please DO NOT CC me. I  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: bgpctl - manpage or code?

[Rod Whitworth]

On Sat, 09 May 2009 13:13:39 +1000, Rod Whitworth wrote:

>Thanks for the attention. I really appreciate the way the OpenBSD ethos
>treats a bug seriously and promptly when it doesn't have any
>deleterious effects.

EDIT 
s/when it doesn't have any/EVEN when it doesn't have any/

Rod/

*** NOTE *** Please DO NOT CC me. I  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/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

Re: bgpctl - manpage or code?

[Rod Whitworth]

On Thu, 7 May 2009 23:26:50 +0100, Stuart Henderson wrote:

>On 2009/05/08 00:01, Claudio Jeker wrote:
>> Doh. Sure it loops because that if will work even after the INET6 dump is
>> over. This should be better.
>
>yep - ok with me.
>
>> 
>> -- 
>> :wq Claudio

Looks good to me too! Will it be committed?
Thanks for the attention. I really appreciate the way the OpenBSD ethos
treats a bug seriously and promptly when it doesn't have any
deleterious effects.

Good work, mates!



*** NOTE *** Please DO NOT CC me. I  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/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device