Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

stable-digest V5 #831

2 views

Skip to first unread message

owner-freebsd...@freebsd.org

unread,

Mar 25, 2003, 9:50:31 PM3/25/03

stable-digest Tuesday, March 25 2003 Volume 05 : Number 831

In this issue:
Last minute checks before FBSD-4.8 release?
Re: Weird problem!!
Re: Weird problem!!
Re: Weird problem!!
Re: Resolver Issues (non valid hostname characters)
Odd link order behaviour with OpenSSL and DES
Re: Odd link order behaviour with OpenSSL and DES
Re: Resolver Issues (non valid hostname characters)
subscribe
Re: VCD disks
Re: Resolver Issues (non valid hostname characters)
Re: ifconfig alias file exists error
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Ident in a jailed environment (continued)
Re: Resolver Issues (non valid hostname characters)
Re: 4.8-RC, XFree86 4.3.0, and GDM
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)
Re: Resolver Issues (non valid hostname characters)

----------------------------------------------------------------------

Date: Tue, 25 Mar 2003 10:13:00 -0500
From: "Ken Mays" <kmay...@hotmail.com>
Subject: Last minute checks before FBSD-4.8 release?

I saw the note on the holdup of FBSD 4.8. You may want to review the FBSD
03/25/03 snapshot or whatever the FBSD team feels is important to review
before release.

Hate to see the offical release 'buggier' or unloadable in some way if it
can be avoided.
ftp://snapshots.jp.freebsd.org
/pub/FreeBSD/snapshots/i386/4.8-RC-20030325-JPSNAP

Ken

------------------------------

Date: Tue, 25 Mar 2003 07:14:39 -0800
From: "vizion communication" <viz...@ixpres.com>
Subject: Re: Weird problem!!

Thanks for your help

I ave attached the output from dmesg and will send pciconf
with my next posting.

Any help would be much appreciated.

David
- ----- Original Message -----
From: "Mike Hoskins" <mi...@adept.org>
To: <sta...@freebsd.org>
Sent: Monday, March 24, 2003 7:38 PM
Subject: Re: Weird problem!!

> On Mon, 24 Mar 2003, vizion communication wrote:
> > The server is a compaq Proliant 5500 with quad zeons
with a
> > 4 portANA-6944A/TX card. The output from ifconfig is
shown
> > below.
>
> Have you searched the arcives for entries relating to this
card? There
> have been issues reported in the past, and I've even had
issues with the
> same card under Linux. (The cards got tore out and
replaced with
> Intel's.)
>
> Assuming the card is functioning correctly, it may be IRQ
related... Do
> you have an updated BIOS installed on the machine? That's
a common
> reccomendation. Additional output from pciconf, verbose
boot, etc. is
> probably needed to say more.
>
> --
> "Since when is skepticism un-American? Dissent's not
treason but
> they talk like it's the same..." --Sleater-Kinney, "Combat
Rock"
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the
message
>

------------------------------

Date: Tue, 25 Mar 2003 07:16:49 -0800
From: "vizion communication" <viz...@ixpres.com>
Subject: Re: Weird problem!!

Sorry the dmesga was not included--

Here it is:
- -----------------------------

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 4.7-RELEASE #0: Sun Feb 16 17:25:33 PST 2003
ro...@dns3.vizion2000.net:/usr/obj/usr/src/sys/COMPAQ
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (499.84-MHz
686-class CPU)
Origin = "GenuineIntel" Id = 0x672 Stepping = 2

Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,S
EP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory = 2147467264 (2097136K bytes)
config> di sn0
config> di lnc0
config> di ie0
config> di fe0
config> di cs0
config> q
avail memory = 2086445056 (2037544K bytes)
APIC_IO: MP table broken: 8259->APIC entry missing!
Changing APIC ID for IO APIC #0 from 0 to 8 on chip
Programming 35 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee00000
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000
cpu2 (AP): apic id: 1, version: 0x00040011, at 0xfee00000
cpu3 (AP): apic id: 2, version: 0x00040011, at 0xfee00000
io0 (APIC): apic id: 8, version: 0x00220011, at 0xfec00000
Preloaded elf kernel "kernel" at 0xc051f000.
Preloaded userconfig_script "/boot/kernel.conf" at
0xc051f09c.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82454NX PXB#0, Bus#A> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <PCI to PCI bridge (vendor=8086 device=5200)> at
device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci0: <unknown card> (vendor=0x8086, dev=0x5201) at 1.1 irq
9
pci0: <NVidia Riva Ultra Vanta TNT2 graphics accelerator> at
2.0 irq 5
pci0: <unknown card> (vendor=0x0e11, dev=0xa0f0) at 12.0
sym0: <875> port 0x2000-0x20ff mem
0xc4fd0000-0xc4fd0fff,0xc4fe0000-0xc4fe00ff irq 10 at device
13.0 on pci0
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
sym1: <875> port 0x2400-0x24ff mem
0xc4fb0000-0xc4fb0fff,0xc4fc0000-0xc4fc00ff irq 15 at device
13.1 on pci0
sym1: No NVRAM, ID 7, Fast-20, SE, parity checking
pci0: <ATI Mach64-GV graphics accelerator> at 14.0
isab0: <Intel 82371AB PCI to ISA bridge> at device 15.0 on
pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 ATA33 controller> port 0x2c00-0x2c0f
at device 15.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port
0x2c20-0x2c3f at device 15.2 on pci0
pci_cfgintr: can't route an interrupt to 0:15 INTD
uhci0: Could not allocate irq
device_probe_and_attach: uhci0 attach returned 6
Timecounter "PIIX" frequency 3579545 Hz
chip0: <Intel 82371AB Power management controller> port
0x1240-0x124f at device 15.3 on pci0
pcib2: <Intel 82454NX PCI Expander Bridge> at device 18.0 on
pci0
pcib3: <Intel 82454NX PCI Expander Bridge> at device 19.0 on
pci0
pcib4: <Intel 82454NX PXB#0, Bus#B> on motherboard
pci4: <PCI bus> on pcib4
pcib5: <IBM 82351 PCI-PCI bridge> at device 1.0 on pci4
pci5: <PCI bus> on pcib5
ida0: <Compaq Smart Array 3200 controller> port
0x4000-0x40ff mem 0xc6ef0000-0xc6ef00ff irq 15 at device 0.0
on pci5
ida0: drives=4 firm_rev=4.06
idad0: <Compaq Logical Drive> on ida0
idad0: 24997MB (51195840 sectors), blocksize=512
idad1: <Compaq Logical Drive> on ida0
idad1: 14997MB (30714240 sectors), blocksize=512
idad2: <Compaq Logical Drive> on ida0
idad2: 12096MB (24773760 sectors), blocksize=512
idad3: <Compaq Logical Drive> on ida0
idad3: 26029MB (53309280 sectors), blocksize=512
ahc0: <Adaptec 2940 SCSI adapter> port 0x3000-0x30ff mem
0xc6df0000-0xc6df0fff irq 11 at device 2.0 on pci4
aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs
pcib6: <DEC 21152 PCI-PCI bridge> at device 5.0 on pci4
pci6: <PCI bus> on pcib6
de0: <Digital 21140A Fast Ethernet> port 0x5000-0x507f mem
0xc6ff0000-0xc6ff007f irq 9 at device 4.0 on pci6
de0: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2
de0: address 00:00:d1:1c:c4:f9
de1: <Digital 21140A Fast Ethernet> port 0x5080-0x50ff mem
0xc6fe0000-0xc6fe007f irq 9 at device 5.0 on pci6
de1: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2
de1: address 00:00:d1:1c:c4:fa
de2: <Digital 21140A Fast Ethernet> port 0x5400-0x547f mem
0xc6fd0000-0xc6fd007f irq 9 at device 6.0 on pci6
de2: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2
de2: address 00:00:d1:1c:c4:fb
de3: <Digital 21140A Fast Ethernet> port 0x5480-0x54ff mem
0xc6fc0000-0xc6fc007f irq 9 at device 7.0 on pci6
de3: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2
de3: address 00:00:d1:1c:c4:fc
eisa0: <EISA bus> on motherboard
mainboard0: <CPQ0808 (System Board)> on eisa0 slot 0
orm0: <Option ROMs> at iomem 0xe8000-0xedfff,0xee000-0xeffff
on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6
drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on
isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model IntelliMouse Explorer, device ID 4
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem
0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: cannot reserve I/O port range
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
acd0: CDROM <CDU5211> at ata0-master PIO4
Waiting 15 seconds for SCSI devices to settle
SMP: AP CPU #3 Launched!
de1: enabling Full Duplex 100baseTX port
de0: enabling 10baseT port
de2: enabling 10baseT port
de0: link down: cable problem?
de2: link down: cable problem?
de3: autosense failed: cable problem?
(probe32:ahc0:0:2:0): SCB 0x4 - timed out
ahc0: Dumping Card State in Message-out phase, at SEQADDR
0xe0
ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0x8c, ARG_2 = 0x0
HCNT = 0x0 SCBPTR = 0x0
SCSISEQ = 0x12, SBLKCTL = 0x0
DFCNTRL = 0x0, DFSTATUS = 0x29
LASTPHASE = 0xa0, SCSISIGI = 0xb6, SXFRCTL0 = 0x88
SSTAT0 = 0x7, SSTAT1 = 0x3
STACK == 0xe1, 0xfb, 0x156, 0x0
SCB count = 10
Kernel NEXTQSCB = 5
Card NEXTQSCB = 2
QINFIFO entries: 2 9 8 7
Waiting Queue entries:
Disconnected Queue entries: 2:4
QOUTFIFO entries:
Sequencer Free SCB List: 1 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info: 0(c 0x40, s 0x47, l 0, t 0x3) 1(c 0x40,
s 0x17, l 0, t 0xff) 2(c 0x44, s 0x27, l 0, t 0x4) 3(c 0x0,
s 0xff, l 255, t 0xff) 4(c 0x0, s 0xff, l 255, t 0xff) 5(c
0x0, s 0xff, l 255, t 0xff) 6(c 0x0, s 0xff, l 255, t 0xff)
7(c 0x0, s 0xff, l 255, t 0xff) 8(c 0x0, s 0xff, l 255, t
0xff) 9(c 0x0, s 0xff, l 255, t 0xff) 10(c 0x0, s 0xff, l
255, t 0xff) 11(c 0x0, s 0xff, l 255, t 0xff) 12(c 0x0, s
0xff, l 255, t 0xff) 13(c 0x0, s 0xff, l 255, t 0xff) 14(c
0x0, s 0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255, t 0xff)
Pending list: 7(c 0x40, s 0x17, l 1), 8(c 0x40, s 0x7, l 1),
9(c 0x50, s 0x67, l 0), 2(c 0x50, s 0x57, l 0), 3(c 0x40, s
0x47, l 0), 4(c 0x40, s 0x27, l 0)
Kernel Free SCB list: 6 1 0
Untagged Q(0): 8
Untagged Q(1): 7
Untagged Q(2): 4
Untagged Q(4): 3
Untagged Q(5): 2
Untagged Q(6): 9
(probe32:ahc0:0:2:0): Other SCB Timeout
(probe34:ahc0:0:4:0): SCB 0x3 - timed out
ahc0: Dumping Card State in Message-in phase, at SEQADDR
0x15c
ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0x8c, ARG_2 = 0x0
HCNT = 0x0 SCBPTR = 0x1
SCSISEQ = 0x12, SBLKCTL = 0x0
DFCNTRL = 0x0, DFSTATUS = 0x29
LASTPHASE = 0xe0, SCSISIGI = 0xe6, SXFRCTL0 = 0x88
SSTAT0 = 0x7, SSTAT1 = 0x3
STACK == 0xfb, 0x156, 0x0, 0xe1
SCB count = 10
Kernel NEXTQSCB = 4
Card NEXTQSCB = 9
QINFIFO entries: 9 8 7 5
Waiting Queue entries:
Disconnected Queue entries: 0:3
QOUTFIFO entries:
Sequencer Free SCB List: 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info: 0(c 0x44, s 0x47, l 0, t 0x3) 1(c 0x40,
s 0x57, l 0, t 0x2) 2(c 0x40, s 0x27, l 0, t 0xff) 3(c 0x0,
s 0xff, l 255, t 0xff) 4(c 0x0, s 0xff, l 255, t 0xff) 5(c
0x0, s 0xff, l 255, t 0xff) 6(c 0x0, s 0xff, l 255, t 0xff)
7(c 0x0, s 0xff, l 255, t 0xff) 8(c 0x0, s 0xff, l 255, t
0xff) 9(c 0x0, s 0xff, l 255, t 0xff) 10(c 0x0, s 0xff, l
255, t 0xff) 11(c 0x0, s 0xff, l 255, t 0xff) 12(c 0x0, s
0xff, l 255, t 0xff) 13(c 0x0, s 0xff, l 255, t 0xff) 14(c
0x0, s 0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255, t 0xff)
Pending list: 5(c 0x40, s 0x27, l 1), 7(c 0x40, s 0x17, l
1), 8(c 0x40, s 0x7, l 1), 9(c 0x50, s 0x67, l 0), 2(c 0x40,
s 0x57, l 0), 3(c 0x40, s 0x47, l 0)
Kernel Free SCB list: 6 1 0
Untagged Q(0): 8
Untagged Q(1): 7
Untagged Q(2): 5
Untagged Q(4): 3
Untagged Q(5): 2
Untagged Q(6): 9
(probe34:ahc0:0:4:0): Other SCB Timeout
(probe35:ahc0:0:5:0): SCB 0x2 - timed out
ahc0: Dumping Card State in Message-in phase, at SEQADDR
0x15c
ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0x8c, ARG_2 = 0x0
HCNT = 0x0 SCBPTR = 0x1
SCSISEQ = 0x12, SBLKCTL = 0x0
DFCNTRL = 0x0, DFSTATUS = 0x29
LASTPHASE = 0xe0, SCSISIGI = 0xe6, SXFRCTL0 = 0x88
SSTAT0 = 0x7, SSTAT1 = 0x3
STACK == 0xfb, 0x156, 0x0, 0xe1
SCB count = 10
Kernel NEXTQSCB = 4
Card NEXTQSCB = 9
QINFIFO entries: 9 8 7 5
Waiting Queue entries:
Disconnected Queue entries: 0:3
QOUTFIFO entries:
Sequencer Free SCB List: 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info: 0(c 0x44, s 0x47, l 0, t 0x3) 1(c 0x40,
s 0x57, l 0, t 0x2) 2(c 0x40, s 0x27, l 0, t 0xff) 3(c 0x0,
s 0xff, l 255, t 0xff) 4(c 0x0, s 0xff, l 255, t 0xff) 5(c
0x0, s 0xff, l 255, t 0xff) 6(c 0x0, s 0xff, l 255, t 0xff)
7(c 0x0, s 0xff, l 255, t 0xff) 8(c 0x0, s 0xff, l 255, t
0xff) 9(c 0x0, s 0xff, l 255, t 0xff) 10(c 0x0, s 0xff, l
255, t 0xff) 11(c 0x0, s 0xff, l 255, t 0xff) 12(c 0x0, s
0xff, l 255, t 0xff) 13(c 0x0, s 0xff, l 255, t 0xff) 14(c
0x0, s 0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255, t 0xff)
Pending list: 5(c 0x40, s 0x27, l 1), 7(c 0x40, s 0x17, l
1), 8(c 0x40, s 0x7, l 1), 9(c 0x50, s 0x67, l 0), 2(c 0x40,
s 0x57, l 0), 3(c 0x40, s 0x47, l 0)
Kernel Free SCB list: 6 1 0
Untagged Q(0): 8
Untagged Q(1): 7
Untagged Q(2): 5
Untagged Q(4): 3
Untagged Q(5): 2
Untagged Q(6): 9
(probe35:ahc0:0:5:0): BDR message in message buffer
(probe35:ahc0:0:5:0): no longer in timeout, status = 300
Mounting root from ufs:/dev/idad0s1a
da0 at ahc0 bus 0 target 0 lun 0
da0: <SEAGATE ST34371N 0280> Fixed Direct Access SCSI-2
device
da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged
Queueing Enabled
da0: 4148MB (8496960 512 byte sectors: 64H 32S/T 4148C)
da3 at ahc0 bus 0 target 4 lun 0
da3: <SEAGATE ST34371N 0280> Fixed Direct Access SCSI-2
device
da3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged
Queueing Enabled
da3: 4148MB (8496960 512 byte sectors: 64H 32S/T 4148C)
da2 at ahc0 bus 0 target 2 lun 0
da2: <SEAGATE ST34371N 0484> Fixed Direct Access SCSI-2
device
da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged
Queueing Enabled
da2: 4148MB (8496884 512 byte sectors: 64H 32S/T 4148C)
da5 at ahc0 bus 0 target 6 lun 0
da5: <SEAGATE ST15150N 0023> Fixed Direct Access SCSI-2
device
da5: 10.000MB/s transfers (10.000MHz, offset 15), Tagged
Queueing Enabled
da5: 4095MB (8388315 512 byte sectors: 64H 32S/T 4095C)
da4 at ahc0 bus 0 target 5 lun 0
da4: <SEAGATE ST15150N 0023> Fixed Direct Access SCSI-2
device
da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged
Queueing Enabled
da4: 4095MB (8388315 512 byte sectors: 64H 32S/T 4095C)
da1 at ahc0 bus 0 target 1 lun 0
da1: <SEAGATE ST34371N 0484> Fixed Direct Access SCSI-2
device
da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged
Queueing Enabled
da1: 4148MB (8496884 512 byte sectors: 64H 32S/T 4148C)

- ----- Original Message -----
From: "Mike Hoskins" <mi...@adept.org>
To: <sta...@freebsd.org>
Sent: Monday, March 24, 2003 7:38 PM
Subject: Re: Weird problem!!

------------------------------

Date: Tue, 25 Mar 2003 07:17:46 -0800
From: "vizion communication" <viz...@ixpres.com>
Subject: Re: Weird problem!!

THanks again -- here is the pciconf
- -----------------

pcib1@pci0:1:0: class=0x060400 card=0x00018086
chip=0x52008086 rev=0x03 hdr=0x01
none0@pci0:1:1: class=0x020000 card=0x00018086
chip=0x52018086 rev=0x03 hdr=0x00
none1@pci0:2:0: class=0x030000 card=0x00000000
chip=0x002d10de rev=0x15 hdr=0x00
none2@pci0:12:0: class=0x088000 card=0xb0f30e11
chip=0xa0f00e11 rev=0x00 hdr=0x00
sym0@pci0:13:0: class=0x010000 card=0x70040e11
chip=0x000f1000 rev=0x14 hdr=0x00
sym1@pci0:13:1: class=0x010000 card=0x70040e11
chip=0x000f1000 rev=0x14 hdr=0x00
none3@pci0:14:0: class=0x030000 card=0x00000000
chip=0x47561002 rev=0x7a hdr=0x00
isab0@pci0:15:0: class=0x060100 card=0x00000000
chip=0x71108086 rev=0x02 hdr=0x00
atapci0@pci0:15:1: class=0x010180 card=0x00000000
chip=0x71118086 rev=0x01 hdr=0x00
none4@pci0:15:2: class=0x0c0300 card=0x00000000
chip=0x71128086 rev=0x01 hdr=0x00
chip0@pci0:15:3: class=0x068000 card=0x00000000
chip=0x71138086 rev=0x02 hdr=0x00
chip1@pci0:16:0: class=0x060000 card=0x00000000
chip=0x84ca8086 rev=0x03 hdr=0x00
pcib2@pci0:18:0: class=0x060000 card=0x84cb8086
chip=0x84cb8086 rev=0x04 hdr=0x00
pcib3@pci0:19:0: class=0x060000 card=0x84cb8086
chip=0x84cb8086 rev=0x04 hdr=0x00
pcib5@pci4:1:0: class=0x060400 card=0x00000000
chip=0x00221014 rev=0x07 hdr=0x01
ahc0@pci4:2:0: class=0x010000 card=0x00000000
chip=0x71789004 rev=0x03 hdr=0x00
pcib6@pci4:5:0: class=0x060400 card=0x000000dc
chip=0x00241011 rev=0x03 hdr=0x01
ida0@pci5:0:0: class=0x018000 card=0x40320e11
chip=0xae100e11 rev=0x03 hdr=0x00
de0@pci6:4:0: class=0x020000 card=0x24001109 chip=0x00091011
rev=0x22 hdr=0x00
de1@pci6:5:0: class=0x020000 card=0x00000000 chip=0x00091011
rev=0x22 hdr=0x00
de2@pci6:6:0: class=0x020000 card=0x00000000 chip=0x00091011
rev=0x22 hdr=0x00
de3@pci6:7:0: class=0x020000 card=0x00000000 chip=0x00091011
rev=0x22 hdr=0x00

- ----- Original Message -----
From: "Mike Hoskins" <mi...@adept.org>
To: <sta...@freebsd.org>
Sent: Monday, March 24, 2003 7:38 PM
Subject: Re: Weird problem!!

------------------------------

Date: Tue, 25 Mar 2003 09:59:17 -0600
From: Marius Strom <mar...@marius.org>
Subject: Re: Resolver Issues (non valid hostname characters)

FWIW, I've been having trouble with domains that in particular have '_'
in the hostname.

I know it violates RFC952, but lots of people are using them now, for
good or bad. How about a compile-time flag to allow a "looser"
adherence to the RFC? (Yeah, I know this would likely be gross, and thus
I'll defer to people who are more familiar with FreeBSD internals here)

On Mon, 24 Mar 2003, Dave Duchscher wrote:
> It seems that the use of invalid characters in hostnames is cropping
> up more and more. Besides complaining to the offending site which
> often doesn't work, I was wondering if these restrictions on FreeBSD
> should be re-examined. At this time, it seems that many OSes are no
> longer enforcing this requirement or never have. In my case, I am
> running into a hostnames with an underscore character in the name. It
> seems that Linux, MacOS X, Solaris and Windows all allow this hostname
> to resolve but FreeBSD, as well as the other *BSD, reject it. Should
> FreeBSD follow suit?
>
> DaveD
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>

- --
/------------------------------------------------->
Marius Strom | Always carry a short length of fibre-optic cable.
Professional Geek | If you get lost, then you can drop it on the
System/Network Admin | ground, wait 10 minutes, and ask the backhoe
http://www.marius.org/ | operator how to get back to civilization.
\-------------| Alan Frame |---------------------->

------------------------------

Date: Tue, 25 Mar 2003 16:12:19 +0000
From: Pete French <pfr...@firstcallgroup.co.uk>
Subject: Odd link order behaviour with OpenSSL and DES

I have a tiny program:

puts("hello");
SSL_load_error_strings();
SSL_library_init();
return 0;

If I link it as:

-lobjc -lz -ldes -lm -lssl -lcrypto

Then it segmentation faults. If I re-arrange it such that the line line is:

-lobjc -lz -lm -lssl -lcrypto -ldes

Then I get no segemntation fault! This has only started happening
with a CVSUP of todays code for 4.8-RC. Previously I was running
a CVSup from the 18th of March.

Is this a deliberate change to linking behaviour ?

- -pcf.

------------------------------

Date: Tue, 25 Mar 2003 19:23:19 +0300
From: "Sergey A. Osokin" <o...@freebsd.org.ru>
Subject: Re: Odd link order behaviour with OpenSSL and DES

On Tue, Mar 25, 2003 at 04:12:19PM +0000, Pete French wrote:
> I have a tiny program:
#include <stdio.h>
#include <openssl/ssl.h>

int main(void)
{
>
> puts("hello");
> SSL_load_error_strings();
> SSL_library_init();
> return 0;

}
$ cc t.c -o t -lssl -lcrypto
$ ./t
hello
$

> If I link it as:
>
> -lobjc -lz -ldes -lm -lssl -lcrypto
>
> Then it segmentation faults. If I re-arrange it such that the line line is:
>
> -lobjc -lz -lm -lssl -lcrypto -ldes
>
> Then I get no segemntation fault! This has only started happening
> with a CVSUP of todays code for 4.8-RC. Previously I was running
> a CVSup from the 18th of March.
>
> Is this a deliberate change to linking behaviour ?

AFAIK -ldes deprecated.

- --

Rgdz, /"\ ASCII RIBBON CAMPAIGN
Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL
http://ozz.pp.ru/ X AND NEWS
/ \

------------------------------

Date: Tue, 25 Mar 2003 11:39:36 -0500
From: "Ken Menzel" <ke...@icarz.com>
Subject: Re: Resolver Issues (non valid hostname characters)

hi,
I am not sure where you think freebsd needs support for underscores in
the resolver.
freebsd2# hostname -s free_bsd2
freebsd2# hostname
free_bsd2.icarz.com
freebsd2#vi /etc/hosts (edit host file here adding new name)
freebsd2# ping free_bsd2
PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes
64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms
freebsd2# su
free_bsd2#

If you are having trouble with bind try 'check-names ignore;'
zone "_msdcs.icarz.com" {
type master;
file "_msdcs.icarz.com.db";
allow-update { dmcs; 127.0.0.1; };
check-names ignore;
};

If that is not what you mean please be more specific.
Best of luck, hope this helps.
Ken

- ----- Original Message -----
From: "Marius Strom" <mar...@marius.org>
To: "David J Duchscher" <da...@nostrum.com>
Cc: <freebsd...@FreeBSD.ORG>
Sent: Tuesday, March 25, 2003 10:59 AM
Subject: Re: Resolver Issues (non valid hostname characters)

> FWIW, I've been having trouble with domains that in particular have
'_'
> in the hostname.
>
> I know it violates RFC952, but lots of people are using them now,
for
> good or bad. How about a compile-time flag to allow a "looser"
> adherence to the RFC? (Yeah, I know this would likely be gross, and
thus
> I'll defer to people who are more familiar with FreeBSD internals
here)
>
> On Mon, 24 Mar 2003, Dave Duchscher wrote:
> > It seems that the use of invalid characters in hostnames is
cropping
> > up more and more. Besides complaining to the offending site which
> > often doesn't work, I was wondering if these restrictions on
FreeBSD
> > should be re-examined. At this time, it seems that many OSes are
no
> > longer enforcing this requirement or never have. In my case, I am
> > running into a hostnames with an underscore character in the name.
It
> > seems that Linux, MacOS X, Solaris and Windows all allow this
hostname
> > to resolve but FreeBSD, as well as the other *BSD, reject it.
Should
> > FreeBSD follow suit?
> >
> > DaveD
> >
> >
> > To Unsubscribe: send mail to majo...@FreeBSD.org
> > with "unsubscribe freebsd-stable" in the body of the message
> >
>
> --
>
/------------------------------------------------->
> Marius Strom | Always carry a short length of fibre-optic
cable.
> Professional Geek | If you get lost, then you can drop it on
the
> System/Network Admin | ground, wait 10 minutes, and ask the
backhoe
> http://www.marius.org/ | operator how to get back to civilization.
> \-------------| Alan Frame
|---------------------->
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>

------------------------------

Date: Tue, 25 Mar 2003 19:01:32 +0100
From: Johan Bakker <jo...@provonet.org>
Subject: subscribe

------------------------------

Date: Tue, 25 Mar 2003 19:20:39 +0100 (CET)
From: Oliver Fromme <ol...@secnetix.de>
Subject: Re: VCD disks

Tak Pui LOU <l...@man-97-187.reshall.berkeley.edu> wrote:
> Tosha works great except the syntax does not work for me. So, I make a
> fifo and then write to it with tosha. Then, use mplayer to play that fifo.

What syntax (exactly) doesn't work? If there's a bug,
I'd like to fix it.

For me, it works as described in the manpage, i.e.:
tosha -t 1 -o - | whatever...

Regards
Oliver

- --
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"If you do things right, people won't be sure you've done
anything at all." -- God in Futurama season 4 episode 8

------------------------------

Date: Tue, 25 Mar 2003 19:40:09 +0100 (CET)
From: Oliver Fromme <ol...@secnetix.de>
Subject: Re: Resolver Issues (non valid hostname characters)

Ken Menzel <ke...@icarz.com> wrote:
> I am not sure where you think freebsd needs support for underscores in
> the resolver.
> freebsd2# hostname -s free_bsd2
> freebsd2# hostname
> free_bsd2.icarz.com
> freebsd2#vi /etc/hosts (edit host file here adding new name)
> freebsd2# ping free_bsd2
> PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes
> 64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms

Neither the machine's hostname nor /etc/hosts have got anything
to do with DNS or BIND. In fact, you can set the machine's
hostname to anything you like, including not setting it at all,
or setting it to something completely different from the machine's
DNS name. It might confuse a few programs or scripts, though.

In fact, I was working for some time on a Solaris machine before
I noticed that its hostname was "-s" (yes, a dash followed by the
letter s). It turned out that a cow-orker had run a configure
script of some crappy Linux software a few days before. That
configure script used "hostname -s" to find out the hostname, but
that particular version of Solaris did not support that option.
Instead, it just set the hostname to whatever was given as the
first argument.

On another pool of machines, /etc/hosts contains MAC addresses.
Those wouldn't be legal names in DNS (because of the colons),
but they work perfectly fine in /etc/hosts, so you can easily
lookup and ping MAC addresses. That has been very handy in
that environment.

But in DNS, anything except letters, digits and dashes is not
allowed (apart from the separating dots, of course).

Regards
Oliver

"If you do things right, people won't be sure you've done
anything at all." -- God in Futurama season 4 episode 8

------------------------------

Date: Tue, 25 Mar 2003 14:44:06 +0200
From: Willie Viljoen <wi...@unfoldings.net>
Subject: Re: ifconfig alias file exists error

On Tuesday 25 March 2003 14:34, someone, possibly Sten Daniel S=F8rsdal,=20
typed:
> > Hello all,
> > I want to put second IP on my nic cart. I have been using
> > FreeBSD-4.8-RC, when i put the command,
> > ifconfig rl0 alias xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
> > returns me:
> > ifconfig: ioctl (SIOCAIFADDR): File exists
> > What is the problem?

This is a common problem. You're probably adding IPs on the same subnet. Fo=
r=20
the second IP on a subnet, you want a netmask of 255.255.255.255, or=20
routing can go badly wrong. The command you want is:

ifconfig rl0 add xxx.xxx.xxx.xxx netmask 255.255.255.255

By the way, you can set this permanently in /etc/rc.conf:

ifconfig_rl0=3D"inet 10.0.0.1 netmask 255.255.255.0"
ifconfig_rl0_alias0=3D"inet 10.0.0.9 netmask 255.255.255.255"

Will

=2D-=20
Willie Viljoen
=46reelance IT Consultant

214 Paul Kruger Avenue, Universitas
Bloemfontein
9321
South Africa

+27 51 522 15 60
+27 51 522 44 36 (after hours)
+27 82 404 03 27 (mobile)

wi...@unfoldings.net

------------------------------

Date: Tue, 25 Mar 2003 13:55:24 -0600
From: David J Duchscher <da...@nostrum.com>
Subject: Re: Resolver Issues (non valid hostname characters)

Try pinging this 'dont_work.net.tamu.edu'. Then try doing a
nslookup or dig on the name. You will find that in
/usr/src/lib/libc/net/res_comp.c at line 133 in the function
res_hnok() the code that restricts DNS queries to RFC 952.

DaveD

On Tuesday, March 25, 2003, at 10:39 AM, Ken Menzel wrote:

> hi,
> I am not sure where you think freebsd needs support for underscores in
> the resolver.
> freebsd2# hostname -s free_bsd2
> freebsd2# hostname
> free_bsd2.icarz.com
> freebsd2#vi /etc/hosts (edit host file here adding new name)
> freebsd2# ping free_bsd2
> PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes
> 64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms
> freebsd2# su
> free_bsd2#
>
> If you are having trouble with bind try 'check-names ignore;'
> zone "_msdcs.icarz.com" {
> type master;
> file "_msdcs.icarz.com.db";
> allow-update { dmcs; 127.0.0.1; };
> check-names ignore;
> };
>
> If that is not what you mean please be more specific.
> Best of luck, hope this helps.
> Ken
>
> ----- Original Message -----
> From: "Marius Strom" <mar...@marius.org>
> To: "David J Duchscher" <da...@nostrum.com>
> Cc: <freebsd...@FreeBSD.ORG>
> Sent: Tuesday, March 25, 2003 10:59 AM
> Subject: Re: Resolver Issues (non valid hostname characters)
>
>
>> FWIW, I've been having trouble with domains that in particular have
> '_'
>> in the hostname.
>>
>> I know it violates RFC952, but lots of people are using them now,
> for
>> good or bad. How about a compile-time flag to allow a "looser"
>> adherence to the RFC? (Yeah, I know this would likely be gross, and
> thus
>> I'll defer to people who are more familiar with FreeBSD internals
> here)
>>
>> On Mon, 24 Mar 2003, Dave Duchscher wrote:
>>> It seems that the use of invalid characters in hostnames is
> cropping
>>> up more and more. Besides complaining to the offending site which
>>> often doesn't work, I was wondering if these restrictions on
> FreeBSD
>>> should be re-examined. At this time, it seems that many OSes are
> no
>>> longer enforcing this requirement or never have. In my case, I am
>>> running into a hostnames with an underscore character in the name.
> It
>>> seems that Linux, MacOS X, Solaris and Windows all allow this
> hostname
>>> to resolve but FreeBSD, as well as the other *BSD, reject it.
> Should
>>> FreeBSD follow suit?
>>>
>>> DaveD
>>>
>>>
>>> To Unsubscribe: send mail to majo...@FreeBSD.org
>>> with "unsubscribe freebsd-stable" in the body of the message
>>>
>>
>> --
>>
> /------------------------------------------------->
>> Marius Strom | Always carry a short length of fibre-optic
> cable.
>> Professional Geek | If you get lost, then you can drop it on
> the
>> System/Network Admin | ground, wait 10 minutes, and ask the
> backhoe
>> http://www.marius.org/ | operator how to get back to civilization.
>> \-------------| Alan Frame
> |---------------------->
>>
>> To Unsubscribe: send mail to majo...@FreeBSD.org
>> with "unsubscribe freebsd-stable" in the body of the message
>>

------------------------------

Date: Tue, 25 Mar 2003 14:07:24 -0600
From: David J Duchscher <da...@nostrum.com>
Subject: Re: Resolver Issues (non valid hostname characters)

On Tuesday, March 25, 2003, at 05:03 AM, Terry Lambert wrote:

> It's probably not very useful to talk about doing this until
> local caching-only name servers on border servers are capable
> of handling the 8-bit, as well. For the RFC's that FreeBSD
> currently complies with, it's right to be strict about this.

I think this is the wrong approach to take with this problem.
Linux, Windows, and Solaris do not enforce this restriction. If
RFC 952 is being thrown out the window, then why should FreeBSD
continue to enforce this restriction? At the moment, the
problems I am seeing have little to do with 8-bit data but
characters outside of the what RFC 952 allows.

DaveD

------------------------------

Date: Tue, 25 Mar 2003 13:55:24 -0600
From: David J Duchscher <da...@nostrum.com>
Subject: Re: Resolver Issues (non valid hostname characters)

DaveD

On Tuesday, March 25, 2003, at 10:39 AM, Ken Menzel wrote:

------------------------------

Date: Tue, 25 Mar 2003 12:44:23 -0800
From: "Kevin Oberman" <obe...@es.net>
Subject: Re: Resolver Issues (non valid hostname characters)

> Date: Tue, 25 Mar 2003 14:07:24 -0600
> From: David J Duchscher <da...@nostrum.com>
> Sender: owner-free...@FreeBSD.ORG
>
> On Tuesday, March 25, 2003, at 05:03 AM, Terry Lambert wrote:
>
> > It's probably not very useful to talk about doing this until
> > local caching-only name servers on border servers are capable
> > of handling the 8-bit, as well. For the RFC's that FreeBSD
> > currently complies with, it's right to be strict about this.
>
> I think this is the wrong approach to take with this problem.
> Linux, Windows, and Solaris do not enforce this restriction. If
> RFC 952 is being thrown out the window, then why should FreeBSD
> continue to enforce this restriction? At the moment, the
> problems I am seeing have little to do with 8-bit data but
> characters outside of the what RFC 952 allows.

It should be noted that this limitation was in RFC952 which is not a DNS
specification. See RFC2181. I think our implementation is simply
broken.

The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name.
[...]
Those restrictions
aside, any binary string whatever can be used as the label of any
resource record. Similarly, any binary string can serve as the value
of any record that includes a domain name as some or all of its value
(SOA, NS, MX, PTR, CNAME, and any others that may be added).
Implementations of the DNS protocols must not place any restrictions
on the labels that can be used. In particular, DNS servers must not
refuse to serve a zone because it contains labels that might not be
acceptable to some DNS client programs. A DNS server may be
configurable to issue warnings when loading, or even to refuse to
load, a primary zone containing labels that might be considered
questionable, however this should not happen by default.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634

------------------------------

Date: Tue, 25 Mar 2003 12:55:52 -0800 (PST)
From: ". ." <neonin...@yahoo.com>
Subject: Ident in a jailed environment (continued)

Sorry for the cross-post. I have seen this issue in
both lists and just want to make sure it gets through
to the proper people. I have sent this request to
- -stable list before, just reopening the issue:

Hey. Ident under -stable doesn't work correctly. This
has been discussed before and is fixed in 5.0 but I'm
not sure if I want to use 5.0 on a production server.
I applied a patch that was made by Robert Watson that
was submitted in 2001 for 4.3 (I believe). It applies
but still doesn't work. I have pasted the patch below.
Does anyone have any other suggestions a hack to get
ident to work inside a 4.7 jail?

I have also patched tcp6_subr.c and udp_subr.c. I am
just wanting to get ident working which is ipv4 tcp
port 113.

I've applied all the patches I could find (this one)
and still nothing. The u_cansee code is no longer in
4.x so I can't put that in.

I have tried built in auth, ident2, oidentd. None of
them return correctly.

Any ideas?

Thanks,

Kevin Bockman

Index: tcp_subr.c
===================================================================

RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.73.2.22
diff -u -r1.73.2.22 tcp_subr.c
- --- tcp_subr.c 22 Aug 2001 00:59:12 -0000 1.73.2.22
+++ tcp_subr.c 7 Dec 2001 16:56:23 -0000
@@ -910,7 +910,7 @@
struct inpcb *inp;
int error, s;

- - error = suser(req->p);
+ error = suser_xxx(NULL, req->p, PRISON_ROOT);
if (error)
return (error);
error = SYSCTL_IN(req, addrs, sizeof(addrs));

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

------------------------------

Date: Tue, 25 Mar 2003 16:39:23 -0500
From: "Ken Menzel" <ke...@icarz.com>
Subject: Re: Resolver Issues (non valid hostname characters)

I understand, even though the DNS server, windows linux, nslookup
and dig see the name, you can't get to it with any tool using the
resolver. BTW if you put the name in /etc/hosts you can still use it
with ping etc (this fooled me!), but it won't allow it from DNS. Why
wouldn't we use the same rules on the hosts file? Should etc/hosts be
'looser'?

Ken
- ----- Original Message -----
From: "David J Duchscher" <da...@nostrum.com>
To: "Ken Menzel" <ke...@icarz.com>
Cc: "Marius Strom" <mar...@marius.org>; <freebsd...@FreeBSD.ORG>
Sent: Tuesday, March 25, 2003 2:55 PM
Subject: Re: Resolver Issues (non valid hostname characters)

> Try pinging this 'dont_work.net.tamu.edu'. Then try doing a
> nslookup or dig on the name. You will find that in
> /usr/src/lib/libc/net/res_comp.c at line 133 in the function
> res_hnok() the code that restricts DNS queries to RFC 952.
>
> DaveD
>
> On Tuesday, March 25, 2003, at 10:39 AM, Ken Menzel wrote:
>
> > hi,
> > I am not sure where you think freebsd needs support for
underscores in
> > the resolver.
> > freebsd2# hostname -s free_bsd2
> > freebsd2# hostname
> > free_bsd2.icarz.com
> > freebsd2#vi /etc/hosts (edit host file here adding new name)
> > freebsd2# ping free_bsd2
> > PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes
> > 64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms
> > freebsd2# su
> > free_bsd2#
> >
> > If you are having trouble with bind try 'check-names ignore;'
> > zone "_msdcs.icarz.com" {
> > type master;
> > file "_msdcs.icarz.com.db";
> > allow-update { dmcs; 127.0.0.1; };
> > check-names ignore;
> > };
> >
> > If that is not what you mean please be more specific.
> > Best of luck, hope this helps.
> > Ken
> >
> > ----- Original Message -----
> > From: "Marius Strom" <mar...@marius.org>
> > To: "David J Duchscher" <da...@nostrum.com>
> > Cc: <freebsd...@FreeBSD.ORG>
> > Sent: Tuesday, March 25, 2003 10:59 AM
> > Subject: Re: Resolver Issues (non valid hostname characters)
> >
> >
> >> FWIW, I've been having trouble with domains that in particular
have
> > '_'
> >> in the hostname.
> >>
> >> I know it violates RFC952, but lots of people are using them now,
> > for
> >> good or bad. How about a compile-time flag to allow a "looser"
> >> adherence to the RFC? (Yeah, I know this would likely be gross,
and
> > thus
> >> I'll defer to people who are more familiar with FreeBSD internals
> > here)
> >>
> >> On Mon, 24 Mar 2003, Dave Duchscher wrote:
> >>> It seems that the use of invalid characters in hostnames is
> > cropping
> >>> up more and more. Besides complaining to the offending site
which
> >>> often doesn't work, I was wondering if these restrictions on
> > FreeBSD
> >>> should be re-examined. At this time, it seems that many OSes
are
> > no
> >>> longer enforcing this requirement or never have. In my case, I
am
> >>> running into a hostnames with an underscore character in the
name.
> > It
> >>> seems that Linux, MacOS X, Solaris and Windows all allow this
> > hostname
> >>> to resolve but FreeBSD, as well as the other *BSD, reject it.
> > Should
> >>> FreeBSD follow suit?
> >>>
> >>> DaveD
> >>>
> >>>
> >>> To Unsubscribe: send mail to majo...@FreeBSD.org
> >>> with "unsubscribe freebsd-stable" in the body of the message
> >>>
> >>
> >> --
> >>
> > /------------------------------------------------->
> >> Marius Strom | Always carry a short length of
fibre-optic
> > cable.
> >> Professional Geek | If you get lost, then you can drop it on
> > the
> >> System/Network Admin | ground, wait 10 minutes, and ask the
> > backhoe
> >> http://www.marius.org/ | operator how to get back to
civilization.
> >> \-------------| Alan Frame
> > |---------------------->
> >>
> >> To Unsubscribe: send mail to majo...@FreeBSD.org
> >> with "unsubscribe freebsd-stable" in the body of the message
> >>
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>

------------------------------

Date: Tue, 25 Mar 2003 22:59:07 +0100 (CET)
From: =?iso-8859-1?q?=20?= <oldg...@yahoo.com>
Subject: Re: 4.8-RC, XFree86 4.3.0, and GDM

I have this same problem. It seemed to only allow me
in under root for
gnome-sessions originally. It turns out, though that
it is a security
breach of some sort. If I add a new user and try to
log them into gnome
2.2, they log in under the root desktop. If I log into
an old user, the
same thing with the .xsession-errors thing happens,
but if I open a
failsafe xterm, it lets me in under root privileges.
Like the original person who reported this, I also
cvsup stable
and have 4.8 rc. This also only started happening
after upgrading to
XFree86 4.3.0.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

------------------------------

Date: Tue, 25 Mar 2003 17:27:04 -0500 (EST)
From: Geoffrey <geof...@reptiles.org>
Subject: Re: Resolver Issues (non valid hostname characters)

On Tue, 25 Mar 2003, Kevin Oberman wrote:

> It should be noted that this limitation was in RFC952 which is not a DNS
> specification. See RFC2181. I think our implementation is simply
> broken.
>
> The DNS itself places only one restriction on the particular labels
> that can be used to identify resource records. That one restriction
> relates to the length of the label and the full name.
> [...]
> Those restrictions
> aside, any binary string whatever can be used as the label of any
> resource record. Similarly, any binary string can serve as the value
> of any record that includes a domain name as some or all of its value
> (SOA, NS, MX, PTR, CNAME, and any others that may be added).
> Implementations of the DNS protocols must not place any restrictions
> on the labels that can be used. In particular, DNS servers must not
> refuse to serve a zone because it contains labels that might not be
> acceptable to some DNS client programs. A DNS server may be
> configurable to issue warnings when loading, or even to refuse to
> load, a primary zone containing labels that might be considered
> questionable, however this should not happen by default.
>
Before anyone considers removing restrictions, I hope
consideration is given to the very real probability of vulnerabilities in
bind which may have much more interesting implications as a result of the
same.
Test, test, fix, probe, fix and test some more before considering
this please. At least then when the vulns happen (and they will), there
will at least be a starting point to implement a fix.

"You cannot deftly manipulate the control stick if you are suffering
from diarrhoea"-
[from a manual for Japanese Kamikaze pilots]

------------------------------

Date: Tue, 25 Mar 2003 16:46:27 -0600
From: Marius Strom <mar...@marius.org>
Subject: Re: Resolver Issues (non valid hostname characters)

I've submitted a PR for this: misc/50299 documenting the RFC
mis-following (is that a word?) as well as a patch for res_comp.c.

On Tue, 25 Mar 2003, Kevin Oberman wrote:
> > Date: Tue, 25 Mar 2003 14:07:24 -0600
> > From: David J Duchscher <da...@nostrum.com>
> > Sender: owner-free...@FreeBSD.ORG
> >
> > On Tuesday, March 25, 2003, at 05:03 AM, Terry Lambert wrote:
> >
> > > It's probably not very useful to talk about doing this until
> > > local caching-only name servers on border servers are capable
> > > of handling the 8-bit, as well. For the RFC's that FreeBSD
> > > currently complies with, it's right to be strict about this.
> >
> > I think this is the wrong approach to take with this problem.
> > Linux, Windows, and Solaris do not enforce this restriction. If
> > RFC 952 is being thrown out the window, then why should FreeBSD
> > continue to enforce this restriction? At the moment, the
> > problems I am seeing have little to do with 8-bit data but
> > characters outside of the what RFC 952 allows.
>
> It should be noted that this limitation was in RFC952 which is not a DNS
> specification. See RFC2181. I think our implementation is simply
> broken.
>
> The DNS itself places only one restriction on the particular labels
> that can be used to identify resource records. That one restriction
> relates to the length of the label and the full name.
> [...]
> Those restrictions
> aside, any binary string whatever can be used as the label of any
> resource record. Similarly, any binary string can serve as the value
> of any record that includes a domain name as some or all of its value
> (SOA, NS, MX, PTR, CNAME, and any others that may be added).
> Implementations of the DNS protocols must not place any restrictions
> on the labels that can be used. In particular, DNS servers must not
> refuse to serve a zone because it contains labels that might not be
> acceptable to some DNS client programs. A DNS server may be
> configurable to issue warnings when loading, or even to refuse to
> load, a primary zone containing labels that might be considered
> questionable, however this should not happen by default.
>
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: obe...@es.net Phone: +1 510 486-8634
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>

------------------------------

Date: Tue, 25 Mar 2003 15:11:03 -0800
From: "Kevin Oberman" <obe...@es.net>
Subject: Re: Resolver Issues (non valid hostname characters)

> Date: Tue, 25 Mar 2003 16:46:27 -0600
> From: Marius Strom <mar...@marius.org>
>
> I've submitted a PR for this: misc/50299 documenting the RFC
> mis-following (is that a word?) as well as a patch for res_comp.c.

As Mark Andrews pointed out in a private message, this is not a BIND
issue. It's a resolver issue. The resolver does enforce the RFC limiting
the characters used for host names in accordance with the RFC. BIND will
handle anything.

A big issue is that ICANN appears to have authorized internationalized
names and those appear certain to break LOTS of things.

But this PR is probably not correct as BIND does adhere to the
RFC. RFC952 still holds sway as confirmed in RFC1123.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634

------------------------------

Date: Wed, 26 Mar 2003 08:02:39 +1100
From: Mark.A...@isc.org
Subject: Re: Resolver Issues (non valid hostname characters)

> David J Duchscher wrote:
> > It seems that the use of invalid characters in hostnames is cropping
> > up more and more. Besides complaining to the offending site which
> > often doesn't work, I was wondering if these restrictions on FreeBSD
> > should be re-examined. At this time, it seems that many OSes are no
> > longer enforcing this requirement or never have. In my case, I am
> > running into a hostnames with an underscore character in the name. It
> > seems that Linux, MacOS X, Solaris and Windows all allow this hostname
> > to resolve but FreeBSD, as well as the other *BSD, reject it. Should
> > FreeBSD follow suit?
>
> Welcome to DNSINT.
>
> Specifically, restrictions were relaxed on the root level servers;
> this was generally announced about a month ago. All data is 8-bit
> now, but not all DNS servers can handle it (e.g. try putting a tab
> or space or whatever in a zone name, which is now legal).

8 bit characters have ALWAYS been legal in the DNS.

Hostnames when stored in the DNS are still restricted to
the characterset specified in RFC 952. Letters, digits and
hyphen (LDH) for the labels.

> The root servers were mostly switched over to totally different
> software from bind. 8-(.

Really. The route operators would be very interested to
know this.

$ for s in a b c d e f g h i j k l m
> do
> echo $s `dig9 +short version.bind txt chaos +norec @$s.root-servers.net`
> done
a "VGRS2"
b "8.2.5-REL"
c "8.3.3-REL"
d "8.3.1-REL"
e "8.3.3-REL"
f "9.2.2"
g
h "8.3.4-REL"
i "8.2.3-REL"
j "VGRS2"
k
l "BIND-8.3.1-MA-PATCH-JMB-01"
m "8.3.4-REL"
$

> The specific reasons were for support of Big5 due to increased
> political pressure coming from China. See the ICANN web site
> for details.
>
> Personally, I think it's to make it harder to cut-and-paste
> domain names from SPAM to find the responsible party (chars
> in Big5 don't go over very well in ISO 8859-1, and end up
> being shell escapes, etc.).
>
> The answer is that it will have to be supported when DNSINT is
> supported (but nit until then; significant resolver library
> changes, which are not easy, are required, etc.).

IDN (internationalised domain name) requires a translation
layer ABOVE the DNS to translate the extended hostname range
(which is not every UNICODE character) into LDH and back.

> It's probably not very useful to talk about doing this until
> local caching-only name servers on border servers are capable
> of handling the 8-bit, as well. For the RFC's that FreeBSD
> currently complies with, it's right to be strict about this.

Nameservers and resolvers DO NOT need to be changed to
support IDN. Applications need to know how and when to
perform the translations.

New / extended API's to lookup and return IDN's are
needed. The application needs to know in advance
that it is going to get IHN (internationalised hostname
name) returned. IHN are a subset of IDN which when
stored in the DNS is a subset of the legal hostnames
which intern are a subset of all domainnames.

> Mostly it's still about domain name speculation, and, IMO,
> will be for a while. I'd say it's about as widely adopted as
> IPv6 -- which is to say: not very.
>
> PS: I was on the DNSINT IETF working group for a while, FWIW.

Well you obviously do not know what the consensus was or
the correct title (IDN).

For those that want the RFC's and current drafts see
http://www.ietf.org/html.charters/idn-charter.html

Mark

> -- Terry
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
- --
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org

------------------------------

Date: Wed, 26 Mar 2003 08:32:02 +1100
From: Mark.A...@isc.org
Subject: Re: Resolver Issues (non valid hostname characters)

> > Date: Tue, 25 Mar 2003 14:07:24 -0600
> > From: David J Duchscher <da...@nostrum.com>
> > Sender: owner-free...@FreeBSD.ORG
> >
> > On Tuesday, March 25, 2003, at 05:03 AM, Terry Lambert wrote:
> >
> > > It's probably not very useful to talk about doing this until
> > > local caching-only name servers on border servers are capable
> > > of handling the 8-bit, as well. For the RFC's that FreeBSD
> > > currently complies with, it's right to be strict about this.
> >
> > I think this is the wrong approach to take with this problem.
> > Linux, Windows, and Solaris do not enforce this restriction. If
> > RFC 952 is being thrown out the window, then why should FreeBSD
> > continue to enforce this restriction? At the moment, the
> > problems I am seeing have little to do with 8-bit data but
> > characters outside of the what RFC 952 allows.
>
> It should be noted that this limitation was in RFC952 which is not a DNS
> specification. See RFC2181. I think our implementation is simply
> broken.
>
> The DNS itself places only one restriction on the particular labels
> that can be used to identify resource records. That one restriction
> relates to the length of the label and the full name.
> [...]
> Those restrictions
> aside, any binary string whatever can be used as the label of any
> resource record. Similarly, any binary string can serve as the value
> of any record that includes a domain name as some or all of its value
> (SOA, NS, MX, PTR, CNAME, and any others that may be added).
> Implementations of the DNS protocols must not place any restrictions
> on the labels that can be used. In particular, DNS servers must not
> refuse to serve a zone because it contains labels that might not be
> acceptable to some DNS client programs. A DNS server may be
> configurable to issue warnings when loading, or even to refuse to
> load, a primary zone containing labels that might be considered
> questionable, however this should not happen by default.

gethostby*(), get*info() all talk RFC 952. They use the
DNS as a database to store records in as they use /etc/hosts
and NIS. gethostbyaddr() and gethostinfo() should not be
returning names that don't comply to RFC 952.

Like most people you are confusing hostnames and domainnames.
The are NOT the same things. They are in fact overlapping
sets. There are legal hostnames that cannot be stored in
the DNS and the are domainnames that are not hostnames.

Checking the results returned from a public database is
good engineering practice. NIS and /etc/hosts are local
databases and can be assumed to be correct.

Mark

> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: obe...@es.net Phone: +1 510 486-8634
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
- --
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org

------------------------------

Date: Wed, 26 Mar 2003 11:36:20 +1100 (EST)
From: rap...@research.canon.com.au (Andrew Raphael)
Subject: Re: Resolver Issues (non valid hostname characters)

Kevin Oberman <obe...@es.net> writes:

>A big issue is that ICANN appears to have authorized internationalized
>names and those appear certain to break LOTS of things.

Well, now that ICANN's CEO is an Australian, you'll be able to tell
them this in Australian English. We've got 5 meanings of the word
"buggery", for example. ;-)

------------------------------

End of stable-digest V5 #831
****************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-stable-digest in the body of the message

0 new messages