dual-stack IPv4/IPv6 CARP
4.9-release Greetings. I'm looking to configure IPv6 in addition to IPv4 on a two-box pf setup that uses CARP and pfsync. The systems have multiple VLANs, which are bound to physical interfaces, and the CARP interfaces in turn are bound to the VLAN interfaces. There is no dynamic routing protocol such as OSPF or BGP. This all works OK with IPv4. Here are my questions: 1. What's the syntax for adding v6 to the CARP interfaces? Is it sufficient to add an inet6 alias, something like this: inet 666.1.2.3 255.255.255.0 666.1.2.255 vhid 100 carpdev bge0 advskew 1 pass GoogleMinus inet6 alias 2011:0:1:2::2 64 Or does each address require carp credentials, like this: inet 666.1.2.3 255.255.255.0 666.1.2.255 vhid 100 carpdev vlan1001 advskew 1 pass GoogleMinus inet6 2011:0:1:2::3 64 vhid 100 carpdev bge0 advskew 1 pass GoogleMinus Or does the v6 address require a separate CARP hostname.carpXX interface? 2. Same question regarding aliases for the VLAN interfaces. Is something like this sufficient? inet 666.1.2.4 255.255.255.0 666.1.2.255 vlan 1000 vlandev bge0 inet6 alias 2001:0:f0:0d::82 64 Or do the VLAN interfaces also require something more than an alias? 3. One of the existing CARP interfaces is on a /30 network so there's no IPv4 address configured on the physical interface it uses. (There's no VLAN interface in this case, either; the CARP interface is bound to the physical interface.) Will the same setup work with a dual stack setup, where v4 and v6 CARP addresses are bound to an unnumbered physical interface? Many thanks. dn
Re: bug in the alternate character set output
I get the same results on Linux and OpenBSD so if this is a problem I
suspect it is ncurses rather than OpenBSD.
You can take this to ncurses-dev or I will have a dig around when I have
time, it'd help if you can come up with a simpler example (perhaps where
you only change the x member of acsc).
On Mon, Jul 18, 2011 at 04:28:41PM +0400, alexei.mali...@inetcomm.ru wrote:
> Synopsis: bug in the alternate character set output
> Category: system
> Environment:
> System: OpenBSD 4.2 & 4.9
> Architecture: OpenBSD.i386
> Machine:i386
> Description:
> curses and the like applications display curses ACS_VLINE
> characters incorrectly if the ACS_VLINE character is set
> to "|"
> How-To-Repeat:
> let's prepare test terminfo entry, where curses ACS_VLINE
> character is set to "|" (i. e. acsc must have "x|"
> somewhere in a terminfo description):
>
> # cd
> # vi xterm0.ti
> # cat xterm0.ti
>
> # ACS test
> xterm0|xterm with simple ASCII pseudographics,
> acsc=+>\,<-\^.v0#`+a\:f\\h#j+k+l+m+n+o~p-q-r-s_t+u+v+w+|!}#~ox|,
> use=xterm,
>
> # cat xterm0.ti >> /usr/src/share/termtypes/termtypes.master
> # cd /usr/src/share/termtypes
> # make obj
> # make cleandir
> # make depend
> # make
> # make install
>
> after that let's prepare test curses program:
>
> # cd
> # vi test.c
> # cat test.c
>
> #include
> #include
>
> void ERROR(char *diag) {
> printf("%s\n", diag);
> exit(1);
> }
>
> int main() {
> if (initscr() == NULL)
> ERROR("initscr() error!");
> if (cbreak() != OK)
> ERROR("cbreak() error!");
> if (noecho() != OK)
> ERROR("noecho() error!");
> if (nonl() != OK)
> ERROR("nonl() error!");
> if (intrflush(stdscr, FALSE) != OK)
> ERROR("intrflush(stdscr, FALSE) error!");
> if (keypad(stdscr, TRUE) != OK)
> ERROR("keypad(stdscr, TRUE) error!");
> if (border(0, 0, 0, 0, 0, 0, 0, 0) != OK)
> ERROR("border(0, 0, 0, 0, 0, 0, 0, 0) error!");
> if (refresh() != OK)
> ERROR("refresh() error!");
> if (getch() == ERR)
> ERROR("getch() error!");
> if (endwin() != OK)
> ERROR("endwin() error!");
> return (0);
> }
>
> # rm -f test ; cc -lcurses -o test test.c ; echo $?
> 0
>
> at console with TERM set to "xterm0" or in an xterm
> window (which was started as "xterm -tn xterm0 &")
> let's run our test program:
>
> # ./test
>
> this test shows us that curses ACS_VLINE characters
> are displayed incorrectly (i. e. not as "|")
>
> Fix:
> workaround is dumb - change "|" to "!" and curses
> ACS_VLINE characters will be displayed correctly
> (as "!"); but this does not fix the problem!
>
>
> --
> Alexei Malinin
Re: Bug Tracking system does not work
On Mon, Jul 18, 2011, Sergey Bronnikov wrote: > may be proper link is http://www.openbsd.org/query-pr.html The bug tracker is down and will still that way for some time. > > On 17:28 Mon 18 Jul , ciscoad...@mail.ru wrote: >> Hello. >> >> Today I tried to search in the Bug Tracking system >> but got: >> >> Not Found >> The requested URL /cgi-bin/query-pr-wrapper was not found on this server. >> >> Apache/1.3.29 Server at cvs.openbsd.org Port 80 >> > > -- > sergeyb@ > > [demime 1.01d removed an attachment of type application/pgp-signature]
Re: ping got incorrectly caught by pf
On Wed, Jul 13, 2011 at 01:28:10PM +0900, Ryan McBride wrote:
> Thanks for pointing this out, it was an oversight in the recent changes
> to pf_test_rule().
>
> I recommend specifying explicitly the correct protocols if you're
> wanting to to match by user/group/os fingerprints.
>
> block return out log proto { tcp, udp } all user = 1002
>
> If you'd like, you can apply the patch below which will force you to do
> it this way, but it's not strictly necessary. (hopefully this will be in
> a snapshot near you soon)
Thank you, it's working now (snapshot Jul 15; I checked your commits.).
jirib
Re: time goes too fast on sparc64/current
Le 18 juil. 2011 19:11, "Theo de Raadt" a icrit : > > > >>Time goes too fast on my sparc64/current machine. > > This is a patch being tested in the snapshots; it is affecting some machines > but not others. It will be pulled and revisited later. But this isn't a snapshot, it's a cvs build from three days ago.
Re: time goes too fast on sparc64/current
> >>Time goes too fast on my sparc64/current machine. This is a patch being tested in the snapshots; it is affecting some machines but not others. It will be pulled and revisited later.
Re: time goes too fast on sparc64/current
On Mon, Jul 18, 2011 at 6:09 PM, Dave Anderson wrote: > On Mon, 18 Jul 2011, Mattieu Baptiste wrote: > >>Hi all, >> >>Time goes too fast on my sparc64/current machine. >>I use ntpd to sync the time. In my logs, I have these kind of lines, >>although the machine's time is 4 hours *later* than expected after a >>day of uptime. It seems that ntpd tries to slow down the time but the >>clock is too fast. >> >>Jul 18 18:01:05 cognac ntpd[4470]: adjusting local clock by -6881.070981s >>Jul 18 18:02:38 cognac ntpd[4470]: adjusting local clock by -6880.602320s >>Jul 18 18:06:21 cognac ntpd[4470]: adjusting local clock by -6879.482802s >>Jul 18 18:09:30 cognac ntpd[4470]: adjusting local clock by -6878.537515s >>Jul 18 18:12:09 cognac ntpd[4470]: adjusting local clock by -6877.736360s >>Jul 18 18:14:14 cognac ntpd[4470]: adjusting local clock by -6877.106601s >>Jul 18 18:16:27 cognac ntpd[4470]: adjusting local clock by -6876.438104s >>Jul 18 18:19:30 cognac ntpd[4470]: adjusting local clock by -6875.522796s >>Jul 18 18:20:04 cognac ntpd[4470]: adjusting local clock by -6875.350162s >>Jul 18 18:21:10 cognac ntpd[4470]: adjusting local clock by -6875.013526s >>Jul 18 18:23:53 cognac ntpd[4470]: adjusting local clock by -6874.195840s >>Jul 18 18:26:39 cognac ntpd[4470]: adjusting local clock by -6873.362587s >>Jul 18 18:30:57 cognac ntpd[4470]: adjusting local clock by -6872.067664s >>Jul 18 18:35:07 cognac ntpd[4470]: adjusting local clock by -6870.809967s >>Jul 18 18:36:10 cognac ntpd[4470]: adjusting local clock by -6870.492445s >>Jul 18 18:39:24 cognac ntpd[4470]: adjusting local clock by -6869.519140s >>Jul 18 18:42:07 cognac ntpd[4470]: adjusting local clock by -6868.699951s >>Jul 18 18:45:18 cognac ntpd[4470]: adjusting local clock by -6867.736762s >>Jul 18 18:48:29 cognac ntpd[4470]: adjusting local clock by -6866.780651s > > Note that the magnitude of the correction is decreasing each time, so > your clock is being corrected -- just rather slowly. What I expect > happened is that your clock was way off at boot and you didn't force a > one-time complete correction (one of the options to ntpd). Except when > an initial complete correction is forced, ntpd only makes small > adjustments to the clock rate, so it's expected that a large error will > take a long time to correct completely. No. ntpd slows down the correction but the time continues to drift more and more. I started ntpd with the "-s" flag at my last reboot. When I sent my mail: uptime: 19:27 real time: ~17:30 machine's time: 18:49 =>gap: 01:19 Now: uptime: 20:33 real time: 18:29 machine's time: 20:23 =>gap: 01:54 > >Dave > >>dmesg: >> >>console is /pci@1e,60/isa@7/serial@0,3f8 >>Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >>Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org >> >>OpenBSD 4.9-current (GENERIC.MP) #1: Fri Jul 15 14:34:10 CEST 2011 >>r...@cognac.brimbelle.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP >>real mem = 17179869184 (16384MB) >>avail mem = 16901693440 (16118MB) >>mainbus0 at root: Sun Fire V440 >>cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >>cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >>external (64 b/l) >>cpu1 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >>cpu1: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >>external (64 b/l) >>cpu2 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >>cpu2: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >>external (64 b/l) >>cpu3 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >>cpu3: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >>external (64 b/l) >>"memory-controller" at mainbus0 not configured >>"memory-controller" at mainbus0 not configured >>"memory-controller" at mainbus0 not configured >>"memory-controller" at mainbus0 not configured >>schizo0 at mainbus0: "Tomatillo", version 4, ign 700, bus A 0 to 0 >>schizo0: dvma map c000-dfff >>pci0 at schizo0 >>cas0 at pci0 dev 2 function 0 "Sun Cassini" rev 0x20: ivec 0x718, >>address 00:03:ba:a4:90:53 >>brgphy0 at cas0 phy 1: BCM5421 10/100/1000baseT PHY, rev. 1 >>"ppm" at mainbus0 not configured >>schizo1 at mainbus0: "Tomatillo", version 4, ign 740, bus B 0 to 1 >>schizo1: dvma map c000-dfff >>pci1 at schizo1 >>ppb0 at pci1 dev 2 function 0 "Intel 21154AE/BE PCI-PCI" rev 0x00 >>pci2 at ppb0 bus 1 >>cas1 at pci2 dev 0 function 0 "Sun Cassini" rev 0x20: ivec 0x740, >>address 00:03:ba:93:1c:a1 >>brgphy1 at cas1 phy 1: BCM5401 10/100/1000baseT PHY, rev. 3 >>schizo2 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 0 >>schizo2: dvma map c000-dfff >>pci3 at schizo2 >>ebus0 at pci3 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 >>"flashprom" at ebus0 addr 0-f, 290-290 not configured >>rtc0 at ebus0 addr 70-71: m5819p >>pcfiic0 at ebus0 addr 320-321 ivec 0x1b >>iic0 at pcfiic0 >>"SUNW,i2c-i
Re: time goes too fast on sparc64/current
On Mon, 18 Jul 2011, Mattieu Baptiste wrote: >Hi all, > >Time goes too fast on my sparc64/current machine. >I use ntpd to sync the time. In my logs, I have these kind of lines, >although the machine's time is 4 hours *later* than expected after a >day of uptime. It seems that ntpd tries to slow down the time but the >clock is too fast. > >Jul 18 18:01:05 cognac ntpd[4470]: adjusting local clock by -6881.070981s >Jul 18 18:02:38 cognac ntpd[4470]: adjusting local clock by -6880.602320s >Jul 18 18:06:21 cognac ntpd[4470]: adjusting local clock by -6879.482802s >Jul 18 18:09:30 cognac ntpd[4470]: adjusting local clock by -6878.537515s >Jul 18 18:12:09 cognac ntpd[4470]: adjusting local clock by -6877.736360s >Jul 18 18:14:14 cognac ntpd[4470]: adjusting local clock by -6877.106601s >Jul 18 18:16:27 cognac ntpd[4470]: adjusting local clock by -6876.438104s >Jul 18 18:19:30 cognac ntpd[4470]: adjusting local clock by -6875.522796s >Jul 18 18:20:04 cognac ntpd[4470]: adjusting local clock by -6875.350162s >Jul 18 18:21:10 cognac ntpd[4470]: adjusting local clock by -6875.013526s >Jul 18 18:23:53 cognac ntpd[4470]: adjusting local clock by -6874.195840s >Jul 18 18:26:39 cognac ntpd[4470]: adjusting local clock by -6873.362587s >Jul 18 18:30:57 cognac ntpd[4470]: adjusting local clock by -6872.067664s >Jul 18 18:35:07 cognac ntpd[4470]: adjusting local clock by -6870.809967s >Jul 18 18:36:10 cognac ntpd[4470]: adjusting local clock by -6870.492445s >Jul 18 18:39:24 cognac ntpd[4470]: adjusting local clock by -6869.519140s >Jul 18 18:42:07 cognac ntpd[4470]: adjusting local clock by -6868.699951s >Jul 18 18:45:18 cognac ntpd[4470]: adjusting local clock by -6867.736762s >Jul 18 18:48:29 cognac ntpd[4470]: adjusting local clock by -6866.780651s Note that the magnitude of the correction is decreasing each time, so your clock is being corrected -- just rather slowly. What I expect happened is that your clock was way off at boot and you didn't force a one-time complete correction (one of the options to ntpd). Except when an initial complete correction is forced, ntpd only makes small adjustments to the clock rate, so it's expected that a large error will take a long time to correct completely. Dave >dmesg: > >console is /pci@1e,60/isa@7/serial@0,3f8 >Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. >Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org > >OpenBSD 4.9-current (GENERIC.MP) #1: Fri Jul 15 14:34:10 CEST 2011 >r...@cognac.brimbelle.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP >real mem = 17179869184 (16384MB) >avail mem = 16901693440 (16118MB) >mainbus0 at root: Sun Fire V440 >cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >external (64 b/l) >cpu1 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >cpu1: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >external (64 b/l) >cpu2 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >cpu2: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >external (64 b/l) >cpu3 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz >cpu3: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K >external (64 b/l) >"memory-controller" at mainbus0 not configured >"memory-controller" at mainbus0 not configured >"memory-controller" at mainbus0 not configured >"memory-controller" at mainbus0 not configured >schizo0 at mainbus0: "Tomatillo", version 4, ign 700, bus A 0 to 0 >schizo0: dvma map c000-dfff >pci0 at schizo0 >cas0 at pci0 dev 2 function 0 "Sun Cassini" rev 0x20: ivec 0x718, >address 00:03:ba:a4:90:53 >brgphy0 at cas0 phy 1: BCM5421 10/100/1000baseT PHY, rev. 1 >"ppm" at mainbus0 not configured >schizo1 at mainbus0: "Tomatillo", version 4, ign 740, bus B 0 to 1 >schizo1: dvma map c000-dfff >pci1 at schizo1 >ppb0 at pci1 dev 2 function 0 "Intel 21154AE/BE PCI-PCI" rev 0x00 >pci2 at ppb0 bus 1 >cas1 at pci2 dev 0 function 0 "Sun Cassini" rev 0x20: ivec 0x740, >address 00:03:ba:93:1c:a1 >brgphy1 at cas1 phy 1: BCM5401 10/100/1000baseT PHY, rev. 3 >schizo2 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 0 >schizo2: dvma map c000-dfff >pci3 at schizo2 >ebus0 at pci3 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 >"flashprom" at ebus0 addr 0-f, 290-290 not configured >rtc0 at ebus0 addr 70-71: m5819p >pcfiic0 at ebus0 addr 320-321 ivec 0x1b >iic0 at pcfiic0 >"SUNW,i2c-imax" at iic0 addr 0xb not configured >"SUNW,i2c-imax" at iic0 addr 0xc not configured >admtemp0 at iic0 addr 0x18: max1617 >"pca9555" at iic0 addr 0x21 not configured >"pca9555" at iic0 addr 0x22 not configured >"pca9555" at iic0 addr 0x23 not configured >"pca9555" at iic0 addr 0x24 not configured >"adm1026" at iic0 addr 0x2e not configured >admtemp1 at iic0 addr 0x32: max1617 >admtemp2 at iic0 addr 0x40: max1617 >admtemp3 at iic0 addr 0x48: max1617 >
softraid RAID1 won't come up on boot - disk read errors during rebuild caused only good device to go offline
My HP Proliant D140 G3 running 4.9 CURRENT.MP with one modification
(lowered UDMA mode, see just below) lost its softraid RAID1 volume - it
will not be brought online at boot. Can someone tell me if it's
possible, and how, to bring this volume up from what I think is a
softraid partition that still has good (enough) data in it? I think
the failure that caused the drive to go offline is a disk controller,
not the disk itself.
Thank you, I hope.
This is the sequence of events:
Days ago:
* BIOS detects disk as UDMA mode 5
* kernel autodetects them as UDMA mode 6, i changed kernel to use mode
5, change is reflected in dmesg below
* i set up softraid volume in RAID1 on 2 identical devices on 2
identical disks
* wd0d and wd1d, both 1.0TB, on 1.5TB WDC WD15EARS-00Z5B1
drives, see disklabels below
* i moved drives between machines
* i booted up machine, softraid saw one disk as roaming or something on
boot and brought up the softraid volume degraded - from 1 disk only
* i started softraid rebuild from the one device that was online in the
volume
* i forget which one was being rebuilt from which
* rebuild got to about 75%
Today:
* machine started throwing disk errors (just samples):
wd1(pciide1:1:0): timeout
type: ata
c_bcount: 16384
c_skip: 0
pciide1:1:0: bus-master DMA error: missing interrupt, status=0x21
wd0(pciide1:0:0): timeout
type: ata
c_bcount: 16384
c_skip: 0
pciide1:0:0: bus-master DMA error: missing interrupt, status=0x21
wd0d: device timeout writing fsbn 698343248 of 698343248-698343279 (wd0
bn 708833693; cn 44122 tn 218 sn 29), retrying
wd0: soft error (corrected)
wd0(pciide1:0:0): timeout
type: ata
c_bcount: 16384
c_skip: 0
pciide1:0:0: bus-master DMA error: missing interrupt, status=0x21
wd0d: device timeout reading fsbn 544078240 of 544078240-544078271 (wd0
bn 554568685; cn 34520 tn 77 sn 34), retrying
wd0: soft error (corrected)
wd0(pciide1:0:0): timeout
type: ata
c_bcount: 16384
c_skip: 0
pciide1:0:0: bus-master DMA error: missing interrupt, status=0x21
* rebooted
* more disk errors (just samples):
login: wd0d: uncorrectable data error reading fsbn 195963120 of
195963120-195963151 (wd0 bn 206453565; cn 12851 tn 35 sn 45), retrying
wd0d: uncorrectable data error reading fsbn 195963120 of
195963120-195963151 (wd0 bn 206453565; cn 12851 tn 35 sn 45), retrying
wd0d: uncorrectable data error reading fsbn 195963120 of
195963120-195963151 (wd0 bn 206453565; cn 12851 tn 35 sn 45), retrying
wd0: soft error (corrected)
* disk device being rebuilt from went offline (!!!) <-- i think this
partition device still has good (enough) data
* console filled with I/O errors from postfix and others trying to
write to disk
* i shutdown the machine
* now when i boot:
softraid0 at root
softraid0: trying to bring up sd0 degraded
softraid0: sd0 offline, will not be brought online
root on wd0a swap on wd0b dump on wd0b
* disklabel and sd0 output
# disklabel wd0
# /dev/rwd0c:
type: ESDI
disk: ESDI/IDE disk
label: WDC WD15EARS-00Z
duid: 56a7443e9e93163c
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 182401
total sectors: 2930277168
boundstart: 64
boundend: 2930277168
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 2104448 64 4.2BSD 2048 163841 # /
b: 8385933 2104512swap
c: 29302771680 unused
d: 2097157230 10490445RAID
e: 2104448 2107647680 4.2BSD 2048 163841
# disklabel wd1
# /dev/rwd1c:
type: ESDI
disk: ESDI/IDE disk
label: WDC WD15EARS-00Z
duid: ab1a569ef35a3c17
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 182401
total sectors: 2930277168
boundstart: 64
boundend: 2930277168
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 2104448 64 4.2BSD 2048 163841
b: 8385933 2104512swap
c: 29302771680 unused
d: 2097157230 10490445RAID
e: 2104480 2107647680 4.2BSD 2048 163841
# dmesg
OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz ("GenuineIntel" 686-class)
1.60 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,SSE3,MWAIT,DS-CPL,VMX,TM2
,SSSE3,CX16,xTPR,PDCM,DCA
real mem = 2146054144 (2046MB)
avail mem = 2100785152 (2003MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @
0xfd361, SMBIOS rev. 2.31 @ 0xdc010 (57 entries)
bios0: vendor HP version "O08" date 06/03/2009
bios0: HP ProLiant DL140 G3
acpi0 at bios0: rev 0
acpi0:
time goes too fast on sparc64/current
Hi all, Time goes too fast on my sparc64/current machine. I use ntpd to sync the time. In my logs, I have these kind of lines, although the machine's time is 4 hours *later* than expected after a day of uptime. It seems that ntpd tries to slow down the time but the clock is too fast. Jul 18 18:01:05 cognac ntpd[4470]: adjusting local clock by -6881.070981s Jul 18 18:02:38 cognac ntpd[4470]: adjusting local clock by -6880.602320s Jul 18 18:06:21 cognac ntpd[4470]: adjusting local clock by -6879.482802s Jul 18 18:09:30 cognac ntpd[4470]: adjusting local clock by -6878.537515s Jul 18 18:12:09 cognac ntpd[4470]: adjusting local clock by -6877.736360s Jul 18 18:14:14 cognac ntpd[4470]: adjusting local clock by -6877.106601s Jul 18 18:16:27 cognac ntpd[4470]: adjusting local clock by -6876.438104s Jul 18 18:19:30 cognac ntpd[4470]: adjusting local clock by -6875.522796s Jul 18 18:20:04 cognac ntpd[4470]: adjusting local clock by -6875.350162s Jul 18 18:21:10 cognac ntpd[4470]: adjusting local clock by -6875.013526s Jul 18 18:23:53 cognac ntpd[4470]: adjusting local clock by -6874.195840s Jul 18 18:26:39 cognac ntpd[4470]: adjusting local clock by -6873.362587s Jul 18 18:30:57 cognac ntpd[4470]: adjusting local clock by -6872.067664s Jul 18 18:35:07 cognac ntpd[4470]: adjusting local clock by -6870.809967s Jul 18 18:36:10 cognac ntpd[4470]: adjusting local clock by -6870.492445s Jul 18 18:39:24 cognac ntpd[4470]: adjusting local clock by -6869.519140s Jul 18 18:42:07 cognac ntpd[4470]: adjusting local clock by -6868.699951s Jul 18 18:45:18 cognac ntpd[4470]: adjusting local clock by -6867.736762s Jul 18 18:48:29 cognac ntpd[4470]: adjusting local clock by -6866.780651s dmesg: console is /pci@1e,60/isa@7/serial@0,3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.9-current (GENERIC.MP) #1: Fri Jul 15 14:34:10 CEST 2011 r...@cognac.brimbelle.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 17179869184 (16384MB) avail mem = 16901693440 (16118MB) mainbus0 at root: Sun Fire V440 cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu1 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu1: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu2 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu2: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu3 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu3: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) "memory-controller" at mainbus0 not configured "memory-controller" at mainbus0 not configured "memory-controller" at mainbus0 not configured "memory-controller" at mainbus0 not configured schizo0 at mainbus0: "Tomatillo", version 4, ign 700, bus A 0 to 0 schizo0: dvma map c000-dfff pci0 at schizo0 cas0 at pci0 dev 2 function 0 "Sun Cassini" rev 0x20: ivec 0x718, address 00:03:ba:a4:90:53 brgphy0 at cas0 phy 1: BCM5421 10/100/1000baseT PHY, rev. 1 "ppm" at mainbus0 not configured schizo1 at mainbus0: "Tomatillo", version 4, ign 740, bus B 0 to 1 schizo1: dvma map c000-dfff pci1 at schizo1 ppb0 at pci1 dev 2 function 0 "Intel 21154AE/BE PCI-PCI" rev 0x00 pci2 at ppb0 bus 1 cas1 at pci2 dev 0 function 0 "Sun Cassini" rev 0x20: ivec 0x740, address 00:03:ba:93:1c:a1 brgphy1 at cas1 phy 1: BCM5401 10/100/1000baseT PHY, rev. 3 schizo2 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 0 schizo2: dvma map c000-dfff pci3 at schizo2 ebus0 at pci3 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 "flashprom" at ebus0 addr 0-f, 290-290 not configured rtc0 at ebus0 addr 70-71: m5819p pcfiic0 at ebus0 addr 320-321 ivec 0x1b iic0 at pcfiic0 "SUNW,i2c-imax" at iic0 addr 0xb not configured "SUNW,i2c-imax" at iic0 addr 0xc not configured admtemp0 at iic0 addr 0x18: max1617 "pca9555" at iic0 addr 0x21 not configured "pca9555" at iic0 addr 0x22 not configured "pca9555" at iic0 addr 0x23 not configured "pca9555" at iic0 addr 0x24 not configured "adm1026" at iic0 addr 0x2e not configured admtemp1 at iic0 addr 0x32: max1617 admtemp2 at iic0 addr 0x40: max1617 admtemp3 at iic0 addr 0x48: max1617 lmtemp0 at iic0 addr 0x4e: lm75 spdmem0 at iic0 addr 0x5b: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem1 at iic0 addr 0x5c: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem2 at iic0 addr 0x5d: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem3 at iic0 addr 0x5e: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem4 at iic0 addr 0x63: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem5 at iic0 addr 0x64: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem6 at iic0 addr 0x65: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem7 at iic0 addr 0x66: 1GB DDR SDRAM registered ECC PC2300CL2.5 spdmem8 at iic0 addr 0x6b: 1GB
bug in the alternate character set output
Synopsis: bug in the alternate character set output
Category: system
Environment:
System: OpenBSD 4.2 & 4.9
Architecture: OpenBSD.i386
Machine:i386
Description:
curses and the like applications display curses ACS_VLINE
characters incorrectly if the ACS_VLINE character is set
to "|"
How-To-Repeat:
let's prepare test terminfo entry, where curses ACS_VLINE
character is set to "|" (i. e. acsc must have "x|"
somewhere in a terminfo description):
# cd
# vi xterm0.ti
# cat xterm0.ti
# ACS test
xterm0|xterm with simple ASCII pseudographics,
acsc=+>\,<-\^.v0#`+a\:f\\h#j+k+l+m+n+o~p-q-r-s_t+u+v+w+|!}#~ox|,
use=xterm,
# cat xterm0.ti >> /usr/src/share/termtypes/termtypes.master
# cd /usr/src/share/termtypes
# make obj
# make cleandir
# make depend
# make
# make install
after that let's prepare test curses program:
# cd
# vi test.c
# cat test.c
#include
#include
void ERROR(char *diag) {
printf("%s\n", diag);
exit(1);
}
int main() {
if (initscr() == NULL)
ERROR("initscr() error!");
if (cbreak() != OK)
ERROR("cbreak() error!");
if (noecho() != OK)
ERROR("noecho() error!");
if (nonl() != OK)
ERROR("nonl() error!");
if (intrflush(stdscr, FALSE) != OK)
ERROR("intrflush(stdscr, FALSE) error!");
if (keypad(stdscr, TRUE) != OK)
ERROR("keypad(stdscr, TRUE) error!");
if (border(0, 0, 0, 0, 0, 0, 0, 0) != OK)
ERROR("border(0, 0, 0, 0, 0, 0, 0, 0) error!");
if (refresh() != OK)
ERROR("refresh() error!");
if (getch() == ERR)
ERROR("getch() error!");
if (endwin() != OK)
ERROR("endwin() error!");
return (0);
}
# rm -f test ; cc -lcurses -o test test.c ; echo $?
0
at console with TERM set to "xterm0" or in an xterm
window (which was started as "xterm -tn xterm0 &")
let's run our test program:
# ./test
this test shows us that curses ACS_VLINE characters
are displayed incorrectly (i. e. not as "|")
Fix:
workaround is dumb - change "|" to "!" and curses
ACS_VLINE characters will be displayed correctly
(as "!"); but this does not fix the problem!
--
Alexei Malinin
Re: Simple IPv6 perhaps not that easy
On Fri, 15 Jul 2011 20:21:56 + (UTC), Stuart Henderson wrote: On 2011-07-15, Eric wrote: Hello folks, I'm trying to setup an IPv6 address on my server, it's a simple box with a nic connected to the internet, the housing facility provided me with a /64 matching my IPv4 address and told me to setup rtadv. Quite easy I thought, looking at hostname.if(5), I added a simple "inet6 alias 2001:41d0:2:1d4f::1 64" to my hostname.sis0, turned rtadv Upon reboot, ifconfig shows me inet6 fe80::21c:c0ff:fe82:9213%sis0 prefixlen 64 scopeid 0x1 Another reboot without the "alias" flag in the hostname.sis0, and ifconfig gives me the following result: inet6 fe80::21c:c0ff:fe82:9213%sis0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:1d4f::1 prefixlen 64 I made sure pf allows icmp6 through to get the gateway address, but looking at my routing I suspected something was wrong. Checking with rtsol I end up with the following result: # rtsol -d sis0 checking if sis0 is ready... sis0 is ready send RS on sis0, whose state is 2 received RA from fe80::5:73ff:fea0:0 on sis0, state is 2 stop timer for sis0 there is no timer The documentation of the housing facility tells me their routers are always on ::FF:FF:FF:FF:FF so I tried a ping6: # ping6 2001:41d0:2:1F:FF:FF:FF:FF PING6(56=40+8+8 bytes) 2001:41d0:2:1d4f::1 --> 2001:41d0:2:1f:ff:ff:ff:ff ^C --- 2001:41d0:2:1F:FF:FF:FF:FF ping6 statistics --- 7 packets transmitted, 0 packets received, 100.0% packet loss Most documents I found on the web focus on setting up things through tunnels as most providers still don't offer IPv6 connectivity yet. What am I missing here? The address you're trying to ping is outside of your subnet, should it be 2001:41d0:2:1d4f:ff:ff:ff:ff ? $ sipcalc 2001:41d0:2:1d4f::/64 | grep -A1 range Network range - 2001:41d0:0002:1d4f:::: - 2001:41d0:0002:1d4f:::: netstat -rnfinet6 might give clues. Thank you for pointing that out Stuart, it was of course the wrong subnet, but as I figured a while later, the ipv6 configuration was right, pinging with ping6 -I sis0 returned working replies from both ipv6.google.com and some other addresses. I'm not yet very familiar with all the IPv6 subtle changes but working on it. Regards.
Re: Bug Tracking system does not work
Sergey Bronnikov wrote: > may be proper link is http://www.openbsd.org/query-pr.html I filled fields in the form at the page above, then pressed the button "Query PRs" and got the answer below. > On 17:28 Mon 18 Jul , ciscoad...@mail.ru wrote: > >> Hello. >> >> Today I tried to search in the Bug Tracking system >> but got: >> >> Not Found >> The requested URL /cgi-bin/query-pr-wrapper was not found on this server. >> >> Apache/1.3.29 Server at cvs.openbsd.org Port 8
bug in the alternate character set output
Synopsis: bug in the alternate character set output
Category: system
Environment:
System: OpenBSD 4.2 & 4.9
Architecture: OpenBSD.i386
Machine:i386
Description:
curses and the like applications display curses ACS_VLINE
characters incorrectly if the ACS_VLINE character is set
to "|"
How-To-Repeat:
let's prepare test terminfo entry, where curses ACS_VLINE
character is set to "|" (i. e. acsc must have "x|"
somewhere in a terminfo description):
# cd
# vi xterm0.ti
# cat xterm0.ti
# ACS test
xterm0|xterm with simple ASCII pseudographics,
acsc=+>\,<-\^.v0#`+a\:f\\h#j+k+l+m+n+o~p-q-r-s_t+u+v+w+|!}#~ox|,
use=xterm,
# cat xterm0.ti >> /usr/src/share/termtypes/termtypes.master
# cd /usr/src/share/termtypes
# make obj
# make cleandir
# make depend
# make
# make install
after that let's prepare test curses program:
# cd
# vi test.c
# cat test.c
#include
#include
void ERROR(char *diag) {
printf("%s\n", diag);
exit(1);
}
int main() {
if (initscr() == NULL)
ERROR("initscr() error!");
if (cbreak() != OK)
ERROR("cbreak() error!");
if (noecho() != OK)
ERROR("noecho() error!");
if (nonl() != OK)
ERROR("nonl() error!");
if (intrflush(stdscr, FALSE) != OK)
ERROR("intrflush(stdscr, FALSE) error!");
if (keypad(stdscr, TRUE) != OK)
ERROR("keypad(stdscr, TRUE) error!");
if (border(0, 0, 0, 0, 0, 0, 0, 0) != OK)
ERROR("border(0, 0, 0, 0, 0, 0, 0, 0) error!");
if (refresh() != OK)
ERROR("refresh() error!");
if (getch() == ERR)
ERROR("getch() error!");
if (endwin() != OK)
ERROR("endwin() error!");
return (0);
}
# rm -f test ; cc -lcurses -o test test.c ; echo $?
0
at console with TERM set to "xterm0" or in an xterm
window (which was started as "xterm -tn xterm0 &")
let's run our test program:
# ./test
this test shows us that curses ACS_VLINE characters
are displayed incorrectly (i. e. not as "|")
Fix:
workaround is dumb - change "|" to "!" and curses
ACS_VLINE characters will be displayed correctly
(as "!"); but this does not fix the problem!
Re: 4.9 errata page
On 2011-07-17 at 01:20:43, Theo de Raadt wrote: >So far there hasn't been anything serious enough for an errata. > >That's a good thing, right? That is simply amazing. Thanks to all the developers for such a fine release! __ Daniel A. Ramaley Network Engineer 2 Dial Center 112, Drake University 2407 Carpenter Ave / Des Moines IA 50311 USA Tel: +1 515 271-4540 Fax: +1 515 271-1938 E-mail: daniel.rama...@drake.edu
Re: Bug Tracking system does not work
may be proper link is http://www.openbsd.org/query-pr.html On 17:28 Mon 18 Jul , ciscoad...@mail.ru wrote: > Hello. > > Today I tried to search in the Bug Tracking system > but got: > > Not Found > The requested URL /cgi-bin/query-pr-wrapper was not found on this server. > > Apache/1.3.29 Server at cvs.openbsd.org Port 80 > -- sergeyb@ [demime 1.01d removed an attachment of type application/pgp-signature]
Bug Tracking system does not work
Hello. Today I tried to search in the Bug Tracking system but got: Not Found The requested URL /cgi-bin/query-pr-wrapper was not found on this server. Apache/1.3.29 Server at cvs.openbsd.org Port 80
Per la tua protezione, e necessario verificare questo messaggio
Gentile Cliente, Abbiamo rilevato attivita irregolari sul tuo Verified by Visa / MasterSecure Code Internet banking sul conto 15/07/2011. Per la tua protezione, e necessario verificare questo attivita prima di poter continuare a utilizzare il conto. Si prega di scaricare il documento allegato alla presente email a rivedere le attivita del proprio account. Rivedremo l'attivita sul tuo conto con voi e alla verifica, e ci consentira di eliminare le restrizioni imposte alle il tuo account. Se scegliete di ignorare la nostra richiesta, ci lasciano scelta ma di sospendere temporaly tuo account. Ti chiediamo di consentire almeno 48 ore per il caso di essere indagato e si consiglia di verificare il tuo conto in quel momento. Con i migliori saluti, Responsabile della comunicazione del Cliente ) Copyright Verifid By Visa 2011 - Tutti i diritti riservati [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of Tuo Profilo.20288DEFANGED-htm]
Re: Simple IPv6 perhaps not that easy
On Fri, Jul 15, 2011 at 8:29 PM, Eric wrote: > Most documents I found on the web focus on setting up things through tunnels > as most providers still don't offer IPv6 connectivity yet. > What am I missing here? Someone already pointed out that you are trying to ping outside your net. Try your local IP first, then double check that RA is giving you a proper route for your IPv6 packets. Try tracerouting to the router to see where it fails, etc... Steph
