Sudo no longer working with RADIUS logins after upgrade to 5.4
uftdi12 at uhub6 port 1 configuration 1 interface 0 FTDI USB FAST SERIAL ADAPTER rev 2.00/5.00 addr 10 ucom12 at uftdi12 portno 1 uftdi13 at uhub6 port 1 configuration 1 interface 1 FTDI USB FAST SERIAL ADAPTER rev 2.00/5.00 addr 10 ucom13 at uftdi13 portno 2 uftdi14 at uhub6 port 2 configuration 1 interface 0 FTDI USB FAST SERIAL ADAPTER rev 2.00/5.00 addr 11 ucom14 at uftdi14 portno 1 uftdi15 at uhub6 port 2 configuration 1 interface 1 FTDI USB FAST SERIAL ADAPTER rev 2.00/5.00 addr 11 ucom15 at uftdi15 portno 2 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a swap on sd0b dump on sd0b -- Thanks, Andrew Klettke Systems Admin Optic Fusion
Re: Sudo no longer working with RADIUS logins after upgrade to 5.4
Should also add that a /usr/bin/sudo binary copied over from a 5.3 machine works as expected. Thanks, Andrew Klettke Systems Admin Optic Fusion On 11/06/2013 11:17 AM, Andrew Klettke wrote: We're seeing a strange issue where logging into a newly-upgraded 5.4 machine with a RADIUS login works fine, but when trying to use sudo to execute commands, I get incorrect password attempts in /var/log/secure. Transcript of this (server name censored to foo, user censored to user), log messages, and dmesg follow, any help or insight would be very much appreciated. Sudo worked perfectly fine with this same user before the upgrade: $ ssh foo user@foo's password: Last login: Wed Nov 6 11:04:55 2013 from .***.net OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. [foo:~]$ sudo whoami We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. Password: Where did you learn to type? Password: My pet ferret can type better than you! Password: Do you think like you type? sudo: 3 incorrect password attempts [foo:~]$ From /var/log/secure: Nov 6 11:11:11 foo sudo: user : 3 incorrect password attempts ; TTY=ttyp1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/whoami Dmesg: OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 1.61 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,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 = 2138222592 (2039MB) avail mem = 2091827200 (1994MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 07/10/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xfd170 (27 entries) bios0: vendor American Megatrends Inc. version 1.0a date 07/10/2009 bios0: Supermicro X7SLA acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIC OEMB acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) PS2M(S4) EUSB(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) LAN0(S1) P0P9(S4) LAN1(S1) USB0(S4) USB1(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 cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (GenuineIntel 686-class) 1.61 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,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 330 @ 1.60GHz (GenuineIntel 686-class) 1.61 GHz cpu2: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,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 330 @ 1.60GHz (GenuineIntel 686-class) 1.61 GHz cpu3: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,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 1, remapped to apid 4 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 4 (P0P1) acpiprt3 at acpi0: bus 1 (P0P4) acpiprt4 at acpi0: bus -1 (P0P5) acpiprt5 at acpi0: bus -1 (P0P6) acpiprt6 at acpi0: bus -1 (P0P7) acpiprt7 at acpi0: bus 2 (P0P8) acpiprt8 at acpi0: bus 3 (P0P9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB bios0: ROM list: 0xc/0xaa00! 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 0xe000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 Raw EDID: 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Re: Sudo no longer working with RADIUS logins after upgrade to 5.4
Hey man, hope you're doing well.
The new version of sudo definitely breaks radius support somehow.
Old binary on newly-upgraded server, calling login_radius as expected:
32409 sudo CALL lstat(0xcfbda248,0xcfbd9fe0)
32409 sudo NAMI /usr/libexec/auth/login_radius
32409 sudo STRU struct stat { dev=1030, ino=1559049,
mode=-r-xr-sr-x , nlink=1, uid=0, gid=63, rdev=6221688,
atime=1383766914.276995603, mtime=1375206816,
ctime=1383763312.710865788, size=14768, blocks=32, blksize=16384,
flags=0x0, gen=0x79206db9 }
32409 sudo RET lstat 0
32409 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbda1cc)
32409 sudo RET socketpair 0
32409 sudo CALL fork()
32409 sudo RET fork 4137/0x1029
32409 sudo CALL close(0x5)
32409 sudo RET close 0
32409 sudo CALL sigprocmask(SIG_BLOCK,~0)
32409 sudo RET sigprocmask 0
32409 sudo CALL mprotect(0x2cff2000,0x2000,0x3PROT_READ|PROT_WRITE)
32409 sudo RET mprotect 0
32409 sudo CALL mprotect(0x2cff2000,0x2000,0x1PROT_READ)
32409 sudo RET mprotect 0
32409 sudo CALL sigprocmask(SIG_SETMASK,0)
32409 sudo RET sigprocmask ~0x10100SIGKILL|SIGSTOP
32409 sudo CALL write(0x3,0x89efdeac,0x1)
32409 sudo GIO fd 3 wrote 1 bytes
\0
32409 sudo RET write 1
32409 sudo CALL write(0x3,0x819f6a4c,0xa)
32409 sudo GIO fd 3 wrote 10 bytes
\0
32409 sudo RET write 10/0xa
32409 sudo CALL read(0x3,0x7ec6b034,0x2000)
32409 sudo GIO fd 3 read 10 bytes
authorize
New binary on newly-upgraded server, no longer calling login_radius:
31629 sudo CALL lstat(0xcfbfc908,0xcfbfc6a0)
31629 sudo NAMI /usr/libexec/auth/login_passwd
31629 sudo STRU struct stat { dev=1030, ino=1559048,
mode=-r-sr-xr-x , nlink=1, uid=0, gid=11, rdev=6233224,
atime=1383766539.484583023, mtime=1375206816,
ctime=1383763312.710865788, size=10256, blocks=24, blksize=16384,
flags=0x0, gen=0xa0c01eca }
31629 sudo RET lstat 0
31629 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbfc88c)
31629 sudo RET socketpair 0
31629 sudo CALL fork()
31629 sudo RET fork 23258/0x5ada
31629 sudo CALL close(0x5)
31629 sudo RET close 0
31629 sudo CALL sigprocmask(SIG_BLOCK,~0)
31629 sudo RET sigprocmask 0
31629 sudo CALL mprotect(0x2c105000,0x2000,0x3PROT_READ|PROT_WRITE)
31629 sudo RET mprotect 0
31629 sudo CALL mprotect(0x2c105000,0x2000,0x1PROT_READ)
31629 sudo RET mprotect 0
31629 sudo CALL sigprocmask(SIG_SETMASK,0)
31629 sudo RET sigprocmask ~0x10100SIGKILL|SIGSTOP
31629 sudo CALL write(0x3,0x7e83d5bc,0x1)
31629 sudo GIO fd 3 wrote 1 bytes
\0
31629 sudo RET write 1
31629 sudo CALL write(0x3,0x8a96d20c,0xa)
31629 sudo GIO fd 3 wrote 10 bytes
***\0
31629 sudo RET write 10/0xa
31629 sudo CALL read(0x3,0x8a2d6034,0x2000)
31629 sudo GIO fd 3 read 7 bytes
reject
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/06/2013 11:28 AM, Bryan Irvine wrote:
Now, that's interesting. ktrace that sucker.
On Wed, Nov 6, 2013 at 11:22 AM, Andrew Klettke
aklet...@opticfusion.net mailto:aklet...@opticfusion.net wrote:
Should also add that a /usr/bin/sudo binary copied over from a 5.3
machine works as expected.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/06/2013 11:17 AM, Andrew Klettke wrote:
We're seeing a strange issue where logging into a
newly-upgraded 5.4 machine with a RADIUS login works fine, but
when trying to use sudo to execute commands, I get incorrect
password attempts in /var/log/secure. Transcript of this
(server name censored to foo, user censored to user), log
messages, and dmesg follow, any help or insight would be very
much appreciated. Sudo worked perfectly fine with this same
user before the upgrade:
$ ssh foo
user@foo's password:
Last login: Wed Nov 6 11:04:55 2013 from .***.net
OpenBSD 5.4 (GENERIC.MP http://GENERIC.MP) #44: Tue Jul 30
12:13:32 MDT 2013
Welcome to OpenBSD: The proactively secure Unix-like operating
system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
[foo:~]$ sudo whoami
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others
Re: Sudo no longer working with RADIUS logins after upgrade to 5.4
On 11/06/2013 12:26 PM, Alexander Hall wrote:
On 11/06/13 20:47, Andrew Klettke wrote:
Hey man, hope you're doing well.
The new version of sudo definitely breaks radius support somehow.
Old binary on newly-upgraded server, calling login_radius as expected:
32409 sudo CALL lstat(0xcfbda248,0xcfbd9fe0)
32409 sudo NAMI /usr/libexec/auth/login_radius
32409 sudo STRU struct stat { dev=1030, ino=1559049,
mode=-r-xr-sr-x , nlink=1, uid=0, gid=63, rdev=6221688,
atime=1383766914.276995603, mtime=1375206816,
ctime=1383763312.710865788, size=14768, blocks=32, blksize=16384,
flags=0x0, gen=0x79206db9 }
32409 sudo RET lstat 0
32409 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbda1cc)
32409 sudo RET socketpair 0
32409 sudo CALL fork()
32409 sudo RET fork 4137/0x1029
32409 sudo CALL close(0x5)
32409 sudo RET close 0
32409 sudo CALL sigprocmask(SIG_BLOCK,~0)
32409 sudo RET sigprocmask 0
32409 sudo CALL
mprotect(0x2cff2000,0x2000,0x3PROT_READ|PROT_WRITE)
32409 sudo RET mprotect 0
32409 sudo CALL mprotect(0x2cff2000,0x2000,0x1PROT_READ)
32409 sudo RET mprotect 0
32409 sudo CALL sigprocmask(SIG_SETMASK,0)
32409 sudo RET sigprocmask ~0x10100SIGKILL|SIGSTOP
32409 sudo CALL write(0x3,0x89efdeac,0x1)
32409 sudo GIO fd 3 wrote 1 bytes
\0
32409 sudo RET write 1
32409 sudo CALL write(0x3,0x819f6a4c,0xa)
32409 sudo GIO fd 3 wrote 10 bytes
\0
32409 sudo RET write 10/0xa
32409 sudo CALL read(0x3,0x7ec6b034,0x2000)
32409 sudo GIO fd 3 read 10 bytes
authorize
New binary on newly-upgraded server, no longer calling login_radius:
31629 sudo CALL lstat(0xcfbfc908,0xcfbfc6a0)
31629 sudo NAMI /usr/libexec/auth/login_passwd
31629 sudo STRU struct stat { dev=1030, ino=1559048,
mode=-r-sr-xr-x , nlink=1, uid=0, gid=11, rdev=6233224,
atime=1383766539.484583023, mtime=1375206816,
ctime=1383763312.710865788, size=10256, blocks=24, blksize=16384,
flags=0x0, gen=0xa0c01eca }
31629 sudo RET lstat 0
31629 sudo CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xcfbfc88c)
31629 sudo RET socketpair 0
31629 sudo CALL fork()
31629 sudo RET fork 23258/0x5ada
31629 sudo CALL close(0x5)
31629 sudo RET close 0
31629 sudo CALL sigprocmask(SIG_BLOCK,~0)
31629 sudo RET sigprocmask 0
31629 sudo CALL
mprotect(0x2c105000,0x2000,0x3PROT_READ|PROT_WRITE)
31629 sudo RET mprotect 0
31629 sudo CALL mprotect(0x2c105000,0x2000,0x1PROT_READ)
31629 sudo RET mprotect 0
31629 sudo CALL sigprocmask(SIG_SETMASK,0)
31629 sudo RET sigprocmask ~0x10100SIGKILL|SIGSTOP
31629 sudo CALL write(0x3,0x7e83d5bc,0x1)
31629 sudo GIO fd 3 wrote 1 bytes
\0
31629 sudo RET write 1
31629 sudo CALL write(0x3,0x8a96d20c,0xa)
31629 sudo GIO fd 3 wrote 10 bytes
***\0
31629 sudo RET write 10/0xa
31629 sudo CALL read(0x3,0x8a2d6034,0x2000)
31629 sudo GIO fd 3 read 7 bytes
reject
What happens if you specifically request radius authentication, e.g.
$ sudo -a radius whoami
?
/Alexander
Hi Alexander,
I get the following:
[foo:~]$ sudo -a radius whoami
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Password:
sudo: radius-server not configured
stty: unknown mode: doofus
Password:
sudo: 1 incorrect password attempt
[foo:~]$
Which is odd, and definitely incorrect, as it works with the old binary,
and radius is set up correctly in login.conf (IP censored):
radius:\
:auth=radius:\
:radius-server=***.***.***.***:\
:ignorenologin:\
:requirehome@:\
:radius-challenge-styles=login:
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/06/2013 11:28 AM, Bryan Irvine wrote:
Now, that's interesting. ktrace that sucker.
On Wed, Nov 6, 2013 at 11:22 AM, Andrew Klettke
aklet...@opticfusion.net mailto:aklet...@opticfusion.net wrote:
Should also add that a /usr/bin/sudo binary copied over from a 5.3
machine works as expected.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/06/2013 11:17 AM, Andrew Klettke wrote:
We're seeing a strange issue where logging into a
newly-upgraded 5.4 machine with a RADIUS login works fine, but
when trying to use sudo to execute commands, I get incorrect
password attempts in /var/log/secure. Transcript of this
(server name censored to foo, user censored to user), log
messages, and dmesg follow, any help
Re: USB ethernet for OpenBSD
Just wanted to throw my 2 cents in and state that Apple's USB ethernet adapter also works fine: http://www.ebay.co.uk/itm/Apple-USB-Ethernet-Adapter-NEW-MC704ZM-A-/290983700399?pt=UK_Computing_USB_Cableshash=item43bffae7af Thanks, Andrew Klettke Systems Admin Optic Fusion On 10/02/2013 12:50 PM, obsd, cgi wrote: Hi! Can someone please mention a working USB to Ethernet adapter for OpenBSD 5.3? (anybody has a working one and can share the name of it?) It doesn't need to be Gbit big... just a 10/100 would be more then enough.. +1 if it could be buyed from: http://www.ebay.co.uk/ Many Thanks, have a nice day!
Two Intel PRO/1000 QP (82571EB) NICs, only one recognized.
not configured vendor Intel, unknown product 0x3cb3 (class system subclass miscellaneous, rev 0x07) at pci13 dev 16 function 3 not configured vendor Intel, unknown product 0x3cb4 (class system subclass miscellaneous, rev 0x07) at pci13 dev 16 function 4 not configured vendor Intel, unknown product 0x3cb5 (class system subclass miscellaneous, rev 0x07) at pci13 dev 16 function 5 not configured vendor Intel, unknown product 0x3cb6 (class system subclass miscellaneous, rev 0x07) at pci13 dev 16 function 6 not configured vendor Intel, unknown product 0x3cb7 (class system subclass miscellaneous, rev 0x07) at pci13 dev 16 function 7 not configured vendor Intel, unknown product 0x3cb8 (class system subclass miscellaneous, rev 0x07) at pci13 dev 17 function 0 not configured vendor Intel, unknown product 0x3ce4 (class system subclass miscellaneous, rev 0x07) at pci13 dev 19 function 0 not configured vendor Intel, unknown product 0x3c43 (class DASP subclass Time and Frequency, rev 0x07) at pci13 dev 19 function 1 not configured vendor Intel, unknown product 0x3ce6 (class DASP subclass Time and Frequency, rev 0x07) at pci13 dev 19 function 4 not configured vendor Intel, unknown product 0x3c44 (class DASP subclass Time and Frequency, rev 0x07) at pci13 dev 19 function 5 not configured vendor Intel, unknown product 0x3c45 (class system subclass miscellaneous, rev 0x07) at pci13 dev 19 function 6 not configured mtrr: Pentium Pro MTRR support uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2 uhidev0 at uhub2 port 3 configuration 1 interface 0 Winbond Electronics Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhidev1 at uhub2 port 3 configuration 1 interface 1 Winbond Electronics Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes wskbd0 at ukbd0 mux 1 wskbd0: connecting to wsdisplay0 uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2 uhidev2 at uhub3 port 3 configuration 1 interface 0 Peppercon AG Multidevice rev 2.00/0.01 addr 3 uhidev2: iclass 3/1 ukbd1 at uhidev2: 8 variable keys, 6 key codes wskbd1 at ukbd1 mux 1 wskbd1: connecting to wsdisplay0 uhidev3 at uhub3 port 3 configuration 1 interface 1 Peppercon AG Multidevice rev 2.00/0.01 addr 3 uhidev3: iclass 3/0 ums1 at uhidev3: 3 buttons, Z dir wsmouse1 at ums1 mux 0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (f78a68bca6af9ef4.a) swap on sd0b dump on sd0b -- Thanks, Andrew Klettke Systems Admin Optic Fusion
5.3 relayd instability -- crashes with hce exiting
revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: apic 2 int 16 pci4 at ppb3 bus 5 ppb4 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: apic 2 int 16 pci5 at ppb4 bus 13 em2 at pci5 dev 0 function 0 Intel PRO/1000MT (82573E) rev 0x03: msi, address 00:30:48:fa:ec:c8 ppb5 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02: apic 2 int 17 pci6 at ppb5 bus 15 em3 at pci6 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: msi, address 00:30:48:fa:ec:c9 uhci3 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 2 int 23 uhci4 at pci0 dev 29 function 1 Intel 82801I USB rev 0x02: apic 2 int 22 uhci5 at pci0 dev 29 function 2 Intel 82801I USB rev 0x02: apic 2 int 18 ehci1 at pci0 dev 29 function 7 Intel 82801I USB rev 0x02: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb6 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x92 pci7 at ppb6 bus 17 vga1 at pci7 dev 3 function 0 ATI ES1000 rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 2 int 22 drm0 at radeondrm0 pciide0 at pci7 dev 4 function 0 ITExpress IT8213F rev 0x00: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 2 int 23 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) ichpcib0 at pci0 dev 31 function 0 Intel 82801IR LPC rev 0x02: PM disabled pciide1 at pci0 dev 31 function 2 Intel 82801I SATA rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using apic 2 int 17 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: ST3160316CS 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 82801I SMBus rev 0x02: apic 2 int 17 iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627HF wbng0 at iic0 addr 0x2f: w83793g spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x52: 1GB DDR2 SDRAM ECC PC2-6400CL5 pciide2 at pci0 dev 31 function 5 Intel 82801I SATA rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide2: using apic 2 int 18 for native-PCI interrupt Intel 82801I Thermal rev 0x02 at pci0 dev 31 function 6 not configured usb2 at uhci0: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 Intel UHCI root hub rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 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 com1 at isa0 port 0x2f8/8 irq 3: 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41 lm2 at wbsio0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 mtrr: Pentium Pro MTRR support lm1: disabling sensors due to alias with lm2 uhidev0 at uhub1 port 2 configuration 1 interface 0 Peppercon AG Multidevice rev 2.00/0.01 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub1 port 2 configuration 1 interface 1 Peppercon AG Multidevice rev 2.00/0.01 addr 2 uhidev1: iclass 3/0 ums0 at uhidev1: 3 buttons, Z dir wsmouse0 at ums0 mux 0 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a swap on wd0b dump on wd0b -- Thanks, Andrew Klettke Systems Admin Optic Fusion
Re: 5.3 relayd instability -- crashes with hce exiting
Thanks very much Sebastian,
I'll try this and let you know how it goes once I'm cleared to do so.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 06/03/2013 03:05 PM, Sebastian Benoit wrote:
Hi,
unfortunatly you do not show your configfile, so i have to guess (you can
send it to me in private if you do not want to send it to a mailing-list).
You have a relay or redirect with ssl in your config?
Please try the attached patch, it's against -current, but should apply
on 5.3.
Apply by doing:
cd /usr/src/usr.sbin/relayd/
patch thisemail
make obj
make depend
make
make install
/Benno
Index: ssl.c
===
RCS file: /cvs/src/usr.sbin/relayd/ssl.c,v
retrieving revision 1.18
diff -u -p -r1.18 ssl.c
--- ssl.c 30 May 2013 20:17:12 - 1.18
+++ ssl.c 31 May 2013 20:16:35 -
@@ -220,8 +220,10 @@ ssl_cleanup(struct ctl_tcp_event *cte)
SSL_shutdown(cte-ssl);
SSL_clear(cte-ssl);
}
- if (cte-buf != NULL)
+ if (cte-buf != NULL) {
ibuf_free(cte-buf);
+ cte-buf = NULL;
+ }
}
void
Andrew Klettke(aklet...@opticfusion.net) on 2013.06.03 14:50:33 -0700:
Hey all,
Ever since upgrading to 5.3 a pair of firewalls whose main job is
running relayd, we're seeing significant instability compared to the 5.2
version. Right now we're seeing relayd crash around 8 times a day, with
the following not-so-informative error message 'hce exiting' (names of
relays and IPs edited out):
relay ***, session 39269 (43 active), 0, ***.***.19.132 -
***.***.15.81:80, done
relay ***, session 38573 (43 active), 0, ***.***.93.209 - :0, closed
relay_close: sessions inflight decremented, now 0
relay ***, session 38318 (40 active), 0, ***.***.93.209 -
***.***.15.104:443, done
relay ***, session 39165 (44 active), 0, ***.***.19.132 -
***.***.15.81:80, done
hce exiting, pid 19342
relay ***, session 38371 (43 active), 0, ***.***.93.209 -
***.***.15.104:443, done
kill_tables: deleted 2 tables
flush_rulesets: flushed rules
relay_close: sessions inflight decremented, now 1
relay_close: sessions inflight decremented, now 0
relay_close: sessions inflight decremented, now 0
relay exiting, pid 2067
pfe exiting, pid 12850
relay exiting, pid 20156
relay exiting, pid 7514
relay_close: sessions inflight decremented, now 0
relay exiting, pid 576
relay exiting, pid 3186
parent terminating, pid 11155
relay exiting, pid 26777
relay exiting, pid 19108
relay exiting, pid 4265
When these firewalls were running 5.2, we saw relayd crash maybe 3-4
times a month with these same settings and load levels, now its
occurring around 10 times a day. I was hoping for any ideas or hints on
where to look next. These are production firewalls so I'm waiting on
word from the customer about if/when I can drop in compiled relayd and
relayctl binaries from the -CURRENT source tree.
dmesg:
OpenBSD 5.3 (GENERIC.MP) #58: Tue Mar 12 18:43:53 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (GenuineIntel
686-class) 2.94 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,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF
real mem = 2145374208 (2045MB)
avail mem = 2099318784 (2002MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/03/09, BIOS32 rev. 0 @ 0xfdb70,
SMBIOS rev. 2.5 @ 0x7fedf000 (39 entries)
bios0: vendor Phoenix Technologies LTD version 1.3a date 11/03/2009
bios0: Supermicro X7SBi
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP _MAR MCFG APIC BOOT SPCR ERST HEST BERT EINJ
SLIC SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices PXHA(S5) PEX_(S5) LAN_(S5) USB4(S5) USB5(S5)
USB7(S5) ESB2(S5) EXP1(S5) EXP5(S5) EXP6(S5) USB1(S5) USB2(S5) USB3(S5)
USB6(S5) ESB1(S5) PCIB(S5) KBC0(S1) MSE0(S1) COM1(S5) COM2(S5) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-16
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 290MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (GenuineIntel
686-class) 3.20 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,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 3 pa 0xfecc, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PXHA)
acpiprt2 at acpi0: bus 3 (PEX_)
acpiprt3 at acpi0: bus 5 (EXP1)
acpiprt4 at acpi0: bus 13 (EXP5)
acpiprt5 at acpi0: bus 15 (EXP6
Re: relayd and header directives
I'm seeing this exact same issue after upgrading a firewall this
afternoon; any use of the header(); function in PHP with SSL is causing
a big 500 Internal Server Error page to be displayed by relayd, while
the other firewall (which I'm now holding out on upgrading) is having no
issues at all when it's the CARP master:
Nov 20 13:06:23 fw02 relayd[4423]: relay wwwssl, session 134 (2 active), 0,
***.***.127.152 - 192.168.21.218:443, invalid (500 Internal Server Error)
Nov 20 13:06:26 fw02 relayd[32703]: relay wwwssl, session 166 (1 active), 0,
***.***.114.27 - 192.168.21.207:443, invalid (500 Internal Server Error)
Nov 20 13:06:27 fw02 relayd[5856]: relay wwwssl, session 207 (2 active), 0,
***.***.192.47 - 192.168.21.218:443, invalid (500 Internal Server Error)
Nov 20 13:06:30 fw02 relayd[32703]: relay wwwssl, session 167 (1 active), 0,
***.***.130.66 - 192.168.21.213:443, invalid (500 Internal Server Error)
Nov 20 13:06:34 fw02 relayd[20956]: relay wwwssl, session 191 (1 active), 0,
***.***.127.152 - 192.168.21.218:443, invalid (500 Internal Server Error)
Any suggestions?
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/15/2012 04:04 AM, Bogdan Andu wrote:
Hello,
I looked briefly in relay.c file and it seems that in the function
void relay_read_http/2 - which is called only in ssl context - the following
piece of code produces the error:
} else if ((cre-method ==
HTTP_METHOD_DELETE ||
cre-method == HTTP_METHOD_GET ||
cre-method == HTTP_METHOD_HEAD ||
cre-method == HTTP_METHOD_OPTIONS ||
cre-method ==
HTTP_METHOD_POST ||
cre-method == HTTP_METHOD_PUT ||
cre-method == HTTP_METHOD_RESPONSE)
strcasecmp(Content-Length, pk.key) == 0) {
/*
* Need to read data from
the client after the
* HTTP header.
* XXX What about non-standard clients not using
* the carriage return? And some browsers seem to
* include the line length in the content-length.
*/
cre-toread =
strtonum(pk.value, 0, ULLONG_MAX, errstr);
if
(errstr) {
relay_close_http(con, 500, errstr,
0);
goto abort;
}
pk.value contains a value that cannot be converted to a number, hence the
function strtonum sets the error invalid in errstr, which appears in this
log message:
relayd www_ssl, session 1 (1 active), 0, 10.10.11.66 -
127.0.0.1:8080, invalid
I think the problem is that the variable pk.value
contains whatever follows after the header Content-Length.
For example, curl
sends this header to the server:
$ curl -XPOST -k
-vhttps://server/cgi-bin/query -d'param1=val1param2=val2'
** SSL
handshake***
POST /cgi-bin/query HTTP/1.1
User-Agent: curl/7.27.0
Host:
server
Accept: */*
Content-Length: 23
Content-Type:
application/x-www-form-urlencoded
The code stops reading further key:value
header entries when encounters Content-Length, and any entry, like
Content-Type: application/x-www-form-urlencoded, that follows is accumulated
in pk.value, and cannot be converted to number becasue contains alfanumeric
characters
yielding the error invalid, in conversion, while pk.key remains
with value Content-Length.
What is curious enough is that a plain http
request does not even calls this function, and that is why is working.
Bogdan
From: Bogdan Andu bo...@yahoo.com
To:
Sebastian Benoit be...@openbsd.org; misc@openbsd.org misc@openbsd.org
Cc: r...@openbsd.org r...@openbsd.org
Sent: Thursday, November 15, 2012
9:36 AM
Subject: Re: relayd and header directives
Hello,
In the meanwhile I
have discovered the following issues:
[WITH SSL]:
1) No headers directives
are allowed - the session is reported as invalid
2)
If the POST arguments are
sent as usual, like this:
$ curl -XPOST -k -v
https://server/cgi-bin/query
-d'param1=val1param2=val2'
relayd reports the
session invalid:
relayd
www_ssl, session 1 (1 active), 0, 10.10.11.66 -
127.0.0.1:8080, invalid
and
the local web server is not accessed
3) If the
POST argumenst are converted
into GET like this:
$ curl -XPOST -k -v
https://server/cgi-bin/query?param1=val1¶m2=val2'
everything work ok.
Although there are sessions reported as invalid, the dialog with local web
server
works, and the respons returns to the client
[WITHOUT SSL]
Everything
work as expected with and without header directives
So, if the
relayd does
not makes ssl offloading seems that everything work ok. I suspect
there must
be something with ssl processing.
The machine is in trunk0 setup
with link
failover in dual stack. So the relayd listens on both IPv4 and IPv6.
With or
without SSL offloading I cannot change
Re: relayd and header directives
A little more info; turns out this is happening on any POST when you
have the option ``header change Connection to close`` in your http
protocol stanza, and not necessarily when the header(); function is
called, as I previously thought. Here's the simple script I was using to
test:
?php
echo form method=POST action=\index.php\;
echo input type=\hidden\ name=\hidden\ value=\1\;
echo input type=\submit\ name=\submit\ value=\submit\;
echo /form;
?
Clicking the submit button instantly gets me a 500 error from relayd
in 5.2 when my http protocol is defined like so:
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Keep-Alive to $TIMEOUT
header change Connection to close
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
return error
ssl { sslv3, tlsv1, no sslv2, ciphers
HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM }
}
Commenting out the ``header change Connection to close`` option makes
everything work just fine, as far as I can tell.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
253-830-2943
On 11/20/2012 02:31 PM, Andrew Klettke wrote:
I'm seeing this exact same issue after upgrading a firewall this
afternoon; any use of the header(); function in PHP with SSL is
causing a big 500 Internal Server Error page to be displayed by
relayd, while the other firewall (which I'm now holding out on
upgrading) is having no issues at all when it's the CARP master:
Nov 20 13:06:23 fw02 relayd[4423]: relay wwwssl, session 134 (2
active), 0, ***.***.127.152 - 192.168.21.218:443, invalid (500
Internal Server Error)
Nov 20 13:06:26 fw02 relayd[32703]: relay wwwssl, session 166 (1
active), 0, ***.***.114.27 - 192.168.21.207:443, invalid (500
Internal Server Error)
Nov 20 13:06:27 fw02 relayd[5856]: relay wwwssl, session 207 (2
active), 0, ***.***.192.47 - 192.168.21.218:443, invalid (500
Internal Server Error)
Nov 20 13:06:30 fw02 relayd[32703]: relay wwwssl, session 167 (1
active), 0, ***.***.130.66 - 192.168.21.213:443, invalid (500
Internal Server Error)
Nov 20 13:06:34 fw02 relayd[20956]: relay wwwssl, session 191 (1
active), 0, ***.***.127.152 - 192.168.21.218:443, invalid (500
Internal Server Error)
Any suggestions?
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/15/2012 04:04 AM, Bogdan Andu wrote:
Hello,
I looked briefly in relay.c file and it seems that in the function
void relay_read_http/2 - which is called only in ssl context - the
following
piece of code produces the error:
} else if ((cre-method ==
HTTP_METHOD_DELETE ||
cre-method == HTTP_METHOD_GET ||
cre-method == HTTP_METHOD_HEAD ||
cre-method == HTTP_METHOD_OPTIONS ||
cre-method ==
HTTP_METHOD_POST ||
cre-method == HTTP_METHOD_PUT ||
cre-method == HTTP_METHOD_RESPONSE)
strcasecmp(Content-Length, pk.key) == 0) {
/*
* Need to read data from
the client after the
* HTTP header.
* XXX What about non-standard clients not
using
* the carriage return? And some browsers
seem to
* include the line length in the
content-length.
*/
cre-toread =
strtonum(pk.value, 0, ULLONG_MAX, errstr);
if
(errstr) {
relay_close_http(con, 500, errstr,
0);
goto abort;
}
pk.value contains a value that cannot be converted to a number, hence
the
function strtonum sets the error invalid in errstr, which appears
in this
log message:
relayd www_ssl, session 1 (1 active), 0, 10.10.11.66 -
127.0.0.1:8080, invalid
I think the problem is that the variable pk.value
contains whatever follows after the header Content-Length.
For example, curl
sends this header to the server:
$ curl -XPOST -k
-vhttps://server/cgi-bin/query -d'param1=val1param2=val2'
** SSL
handshake***
POST /cgi-bin/query HTTP/1.1
User-Agent: curl/7.27.0
Host:
server
Accept: */*
Content-Length: 23
Content-Type:
application/x-www-form-urlencoded
The code stops reading further key:value
header entries when encounters Content-Length, and any entry, like
Content-Type: application/x-www-form-urlencoded, that follows is
accumulated
in pk.value, and cannot be converted to number becasue contains
alfanumeric
characters
yielding the error invalid, in conversion, while pk.key remains
with value Content-Length.
What is curious enough is that a plain http
request does not even calls this function, and that is why is working.
Bogdan
From: Bogdan Andu bo...@yahoo.com
To:
Sebastian Benoit be...@openbsd.org; misc@openbsd.org
Re: Relayd issues with check icmp after upgrade to 5.2
Applied the patch, compiled and installed the new version of relayd, and
everything looks good again. Thanks much!
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
On 11/05/2012 09:20 AM, Stuart Henderson wrote:
On 2012-11-02, Andrew Klettke aklet...@opticfusion.net wrote:
Just upgraded to 5.2 on one of our backup firewalls, and we are having
issues with hosts that are being checked with ICMP:
This should have been fixed post-5.2, please try this diff against
/usr/src/usr.sbin/relayd and let me know how it goes.
(also at http://junkpile.org/relayd.icmp.diff)
Index: check_icmp.c
===
RCS file: /cvs/src/usr.sbin/relayd/check_icmp.c,v
retrieving revision 1.31
diff -u -p -r1.31 check_icmp.c
--- check_icmp.c9 May 2011 12:08:47 - 1.31
+++ check_icmp.c5 Nov 2012 17:18:30 -
@@ -172,6 +172,7 @@ send_icmp(int s, short event, void *arg)
socklen_tslen;
int i = 0, ttl, mib[4];
size_t len;
+ u_int32_tid;
if (event == EV_TIMEOUT) {
icmp_checks_timeout(cie, HCE_ICMP_WRITE_TIMEOUT);
@@ -208,18 +209,18 @@ send_icmp(int s, short event, void *arg)
continue;
i++;
to = (struct sockaddr *)host-conf.ss;
+ id = htonl(host-conf.id);
+
if (cie-af == AF_INET) {
icp-icmp_seq = htons(i);
icp-icmp_cksum = 0;
- memcpy(icp-icmp_data, host-conf.id,
- sizeof(host-conf.id));
+ icp-icmp_mask = id;
icp-icmp_cksum = in_cksum((u_short *)icp,
sizeof(packet));
} else {
icp6-icmp6_seq = htons(i);
icp6-icmp6_cksum = 0;
- memcpy(packet + sizeof(*icp6), host-conf.id,
- sizeof(host-conf.id));
+ memcpy(packet + sizeof(*icp6), id, sizeof(id));
icp6-icmp6_cksum = in_cksum((u_short *)icp6,
sizeof(packet));
}
@@ -270,7 +271,7 @@ recv_icmp(int s, short event, void *arg)
u_int16_ticpid;
struct host *host;
ssize_t r;
- objid_t id;
+ u_int32_tid;
if (event == EV_TIMEOUT) {
icmp_checks_timeout(cie, HCE_ICMP_READ_TIMEOUT);
@@ -279,6 +280,7 @@ recv_icmp(int s, short event, void *arg)
bzero(packet, sizeof(packet));
bzero(ss, sizeof(ss));
+ slen = sizeof(ss);
r = recvfrom(s, packet, sizeof(packet), 0,
(struct sockaddr *)ss, slen);
@@ -291,7 +293,7 @@ recv_icmp(int s, short event, void *arg)
if (cie-af == AF_INET) {
icp = (struct icmp *)(packet + sizeof(struct ip));
icpid = ntohs(icp-icmp_id);
- memcpy(id, icp-icmp_data, sizeof(id));
+ id = icp-icmp_mask;
} else {
icp6 = (struct icmp6_hdr *)packet;
icpid = ntohs(icp6-icmp6_id);
@@ -299,6 +301,7 @@ recv_icmp(int s, short event, void *arg)
}
if (icpid != cie-env-sc_id)
goto retry;
+ id = ntohl(id);
host = host_find(cie-env, id);
if (host == NULL) {
log_warn(%s: ping for unknown host received, __func__);
Relayd issues with check icmp after upgrade to 5.2
at pci3 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 4 int 16, address 00:15:17:a6:2e:70 em1 at pci3 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 4 int 17, address 00:15:17:a6:2e:71 ppb3 at pci2 dev 1 function 0 IDT 89HPES12N3A rev 0x04 pci4 at ppb3 bus 4 em2 at pci4 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 4 int 17, address 00:15:17:a6:2e:72 em3 at pci4 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 4 int 18, address 00:15:17:a6:2e:73 vga1 at pci0 dev 2 function 0 Intel 82945G Video rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 4 int 16 drm0 at inteldrm0 ppb4 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 4 int 16 pci5 at ppb4 bus 5 ppb5 at pci0 dev 28 function 4 Intel 82801G PCIE rev 0x01: apic 4 int 16 pci6 at ppb5 bus 6 re0 at pci6 dev 0 function 0 Realtek 8168 rev 0x02: RTL8168C/8111C (0x3c00), apic 4 int 16, address 00:30:48:9f:33:52 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ppb6 at pci0 dev 28 function 5 Intel 82801G PCIE rev 0x01: apic 4 int 17 pci7 at ppb6 bus 7 re1 at pci7 dev 0 function 0 Realtek 8168 rev 0x02: RTL8168C/8111C (0x3c00), apic 4 int 17, address 00:30:48:9f:33:53 rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 2 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 4 int 23 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 4 int 19 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 4 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 4 int 16 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 4 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb7 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci8 at ppb7 bus 8 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 pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) 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 4 int 19 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: ST980210AS wd0: 16-sector PIO, LBA48, 76319MB, 156301488 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 4 int 19 iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627DHG spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-6400CL5 spdmem1 at iic0 addr 0x52: 1GB DDR2 SDRAM non-parity PC2-6400CL5 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 com1 at isa0 port 0x2f8/8 irq 3: 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: W83627DHG-P rev 0x73 lm2 at wbsio0 port 0x290/8: W83627DHG npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 mtrr: Pentium Pro MTRR support lm1: disabling sensors due to alias with lm2 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a swap on wd0b dump on wd0b -- Thanks, Andrew Klettke Systems Admin Optic Fusion
ospf6d.conf -- Man page discrepancy
Running 5.1-RELEASE. According to ospf6d.conf(5): *router-dead-time* /seconds/ Set the router dead time, a.k.a. neighbor inactivity timer. The default value is 40 seconds; valid range is 2-2147483647 seconds. When a neighbor has been inactive for router-dead-time its state is set to DOWN. Neighbors that have been inactive for more than 24 hours are completely removed. However, when I try to set this value to, say, 60 seconds (well within the range specified above), I get the following when starting ospf6d: /etc/ospf6d.conf:13: router-dead-time out of range (2-65535) Just thought I'd bring this up, see if anyone could shed some light on this. -- Thanks, Andrew Klettke Systems Admin Optic Fusion 253-830-2943
Relayd -- Logging Weirdness
dev 3 function 0 ATI ES1000 rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 2 int 22 drm0 at radeondrm0 pciide0 at pci7 dev 4 function 0 ITExpress IT8213F rev 0x00: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 2 int 23 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) ichpcib0 at pci0 dev 31 function 0 Intel 82801IR LPC rev 0x02: PM disabled pciide1 at pci0 dev 31 function 2 Intel 82801I SATA rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using apic 2 int 17 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: ST3160316CS 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 82801I SMBus rev 0x02: apic 2 int 17 iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627HF wbng0 at iic0 addr 0x2f: w83793g spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x52: 1GB DDR2 SDRAM ECC PC2-6400CL5 pciide2 at pci0 dev 31 function 5 Intel 82801I SATA rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide2: using apic 2 int 18 for native-PCI interrupt Intel 82801I Thermal rev 0x02 at pci0 dev 31 function 6 not configured usb2 at uhci0: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 Intel UHCI root hub rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 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 com1 at isa0 port 0x2f8/8 irq 3: 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41 lm2 at wbsio0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 mtrr: Pentium Pro MTRR support lm1: disabling sensors vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a swap on wd0b dump on wd0b -- Thanks, Andrew Klettke Systems Admin Optic Fusion 253-830-2943
Relayd -- No longer logging relays after upgrade to 5.0
Hey all, Relayd seems to have stopped logging relays by default in 5.0; and neither the -v flag when starting relayd nor specifying log all or log updates in relayd.conf is working. For reference, /var/log/daemon used to be filled with relay logs like so: Oct 29 11:05:04 fw01 relayd[20205]: relay httpproxy, session 125663 (2 active), 0, ***.***.66.206 - 192.168.15.102:80, last write (done) These are no longer appearing. Any ideas? -- Thanks, Andrew Klettke Systems Admin Optic Fusion 253-830-2943
Relayd -- Downloading large files fails with Cannot allocate memory
Running 4.9, downloading large files (250MB) from a website behind a
firewall clustered with relayd fails with the following error in our logs:
Dec 6 12:14:15 fw01 relayd[5615]: relay httpproxy, session 768464 (23
active), 0, * - 192.168.15.101:80, Cannot allocate memory
Here are the applicable relayd.conf directives:
relay httpproxy {
listen on $relayd_addr port $relayd_port
protocol httpfilter
forward to web_parents port 80 mode loadbalance check http /
code 200
}
http protocol httpfilter {
tcp { nodelay, sack, socket buffer 65536, backlog 50 }
return error
header append $REMOTE_ADDR to X-Forwarded-For
header change Keep-Alive to $TIMEOUT
}
Any thoughts? Has anyone seen anything like this before? vmstat shows
plenty of free RAM.
--
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
253-830-2943
Re: Relayd.conf -- Default closing of connection
Anybody?
What makes this even more confusing is that in the man page for
relayd.conf, it specifies a protocol called http_ssl that does NOT
have this directive:
http protocol http_ssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to
X-Forwarded-By
header change Keep-Alive to $TIMEOUT
query hash sessid
cookie hash sessid
path filter *command=* from /cgi-bin/index.cgi
ssl { sslv2, ciphers MEDIUM:HIGH }
}
The protocol in the default relayd.conf DOES, however:
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
# Various TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
I'm just after an explanation of what closing the connection is
attempting to accomplish, and why it seems to be arbitrarily inserted
into the default relayd.conf.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion NOC
253-830-2943
On 05/31/2011 10:34 AM, Andrew Klettke wrote:
Hello,
In the default relayd.conf, we have, in the httpssl protocol, the
directive `header change Connection to close`.
What about relayd makes this desirable (why close connections when we
can reuse them or let them time out?), and what are the consequences
of NOT having this directive?
Relayd.conf -- Default closing of connection
Hello, In the default relayd.conf, we have, in the httpssl protocol, the directive `header change Connection to close`. What about relayd makes this desirable (why close connections when we can reuse them or let them time out?), and what are the consequences of NOT having this directive? -- Thanks, Andrew Klettke Systems Admin Optic Fusion NOC 253-830-2943
Force Internet traffic out IPSec VPN
We have a working IPSec VPN between two 4.8 endpoints. One of them is at a remote location, and the other at the main office. The remote location has its own external, routable IP (to establish the VPN), and an internal subnet behind it. The main office has its own external IP, though which it is NATing its own internal subnet. Basically, I want to force all internet traffic from the remote, internal subnet through the main office's internal gateway so it can NAT out from there. I've been attempting to accomplish this with route-to and reply-to rules on the remote box, but have had no luck. I know IPSec keeps its own routing table, is this interfering? Is this possible to do with PF? -- Thanks, Andrew Klettke Systems Admin Optic Fusion NOC 253-830-2943
Re: Relayd -- FQDN length limit?
An update,
I have had a chance to start Relayd with verbose logging to troubleshoot
this, and I get the following on startup with any FQDN longer than 32
characters in relayd.conf (config details are the same as in my previous
email):
SSL library error: ..com:
relay_ssl_ctx_create: error:140DB111:SSL
routines:SSL_CTX_set_session_id_context:ssl session id context too long
fatal: relay_init: failed to create SSL context: Invalid argument
It doesn't look like there's a hard limit for FQDN length in the source
for relayd, anybody have any ideas?
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion NOC
253-830-2943
On 02/04/2011 04:04 PM, Andrew Klettke wrote:
Hello all,
It looks like we've run into a limit for the length of a SSL hostname
in relayd.
If we define a relay with a hostname that is longer than 32
characters, we get the following:
Feb 1 22:14:00 fw02 relayd[22062]: fatal: relay_init: failed to
create SSL context: No buffer space available
However, shorter hostnames do not cause relayd to throw the error.
We've tested this with multiple domain names.
Is this an expected behavior of relayd?
Here is the defined protocol and the relay giving us the issue in
relayd.conf (FQDN censored):
http protocol httpsfilter {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
return error
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Keep-Alive to $TIMEOUT
ssl { sslv3, tlsv1, no sslv2, ciphers
HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM }
}
relay ..com {
listen on ..com port 443 ssl
protocol httpsfilter
forward to web_hosts port 443 mode loadbalance check http /
code 200
}
Relayd -- Random rashes of session failed errors
uhub6 at usb6 Intel UHCI root hub rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 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 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41 lm2 at wbsio0 port 0x290/8: W83627HF lm1 detached npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 mtrr: Pentium Pro MTRR support uhidev0 at uhub5 port 2 configuration 1 interface 0 Alcor Micro product 0x3107 rev 1.10/1.00 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 uhidev1 at uhub5 port 2 configuration 1 interface 1 Alcor Micro product 0x3107 rev 1.10/1.00 addr 2 uhidev1: iclass 3/0, 2 report ids uhid0 at uhidev1 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root root on wd0a swap on wd0b dump on wd0b -- Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943
Re: OBSD 4.7 and Via C7 motherboards problem
Peter, We purchased a couple of VIA C7 machines, specifically the NFR7500 for use as firewalls (http://www.via.com.tw/en/products/embedded/ProductDetail.jsp?id=341), and had an insane number of problems with the network interfaces, to the point of them being unusable (namely, they could not keep a link). We ended up just returning them; a Ubuntu Live CD worked perfectly, but 4.7 would not play nice with them. Just throwing that out there, you aren't the only one who has had issues with the C7 and VIA. Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 On 08/01/2010 01:49 PM, Peter Merritt wrote: I have a firewall that has been running several versions of OpenBSD successfully, the last being 4.6. After installing 4.7, I could not get the firewall to pass any traffic from the lan side. We have been having thunderstorms lately and I thought may be something was wrong with the nics so I changed the MB our for something similar, another c7 motherboard with 2 nics. I had the same problem, I can ping outside the network as well as the lan computers from the firewall. Tcpdump shows the lan traffic hitting the lan side, but no response back to the lan computers, lan traffic never gets to wan side nic. I put in a very minimal pf.conf and it still works the same. I'm at a loss what is wrong. pf.conf and dmess follows. Any ideas would be greatly appreciated. Peter Motherboard #1 Jetway 7f4k1G5D-LF 1.5ghz Motherboard #2 Jetway J7F4 1.2 Ghz # sysctl net.inet.ip.forwarding net.inet.ip.forwarding=1 # cat pf.min ext_if = re0 int_if = re1 match out log on egress from (self) to anytag EGRESS nat-to ($ext_if:0) port 1024:65535 #pass all pass out log on $ext_if all pass out log on $int_if all pass in log on $ext_if all pass in log on $int_if all # dmesg OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA Eden Processor 1200MHz (CentaurHauls 686-class) 1.21 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MM X,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR real mem = 1005023232 (958MB) avail mem = 965070848 (920MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/25/08, BIOS32 rev. 0 @ 0xfa340, SMBIOS rev. 2.3 @ 0xf (33 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 11/25/2008 apm0 at bios0: Power Management spec V1.2 (slowidle) apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0xc7f4 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc720/208 (11 entries) pcibios0: bad IRQ table checksum pcibios0: PCI BIOS has 11 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 5 10 11 15 pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT8237 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x1 cpu0 at mainbus0: (uniprocessor) cpu0: RNG AES AES-CTR SHA1 SHA256 RSA cpu0: unknown Enhanced SpeedStep CPU, msr 0x04090c0a04000c0a cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 1201 MHz: speeds: 1600, 533 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 VIA CN700 Host rev 0x00 viaagp0 at pchb0: v3 agp0 at viaagp0: aperture at 0xf800, size 0xe80 pchb1 at pci0 dev 0 function 1 VIA CN700 Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA CN700 Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA PT890 Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA CN700 Host rev 0x00 pchb5 at pci0 dev 0 function 7 VIA CN700 Host rev 0x00 ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 VIA S3 Unichrome PRO IGP rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) re0 at pci0 dev 9 function 0 Realtek 8169SC rev 0x10: RTL8169/8110SCd (0x1800), irq 10, address 00:30:18:ad:ed:96 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 re1 at pci0 dev 11 function 0 Realtek 8169SC rev 0x10: RTL8169/8110SCd (0x1800), irq 11, address 00:30:18:ad:ed:97 rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 2 pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA pciide0: using irq 15 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0:ST380815AS wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81: irq 5 uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 5 uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 15 uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 15 ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 VIA EHCI root hub rev 2.00/1.00 addr 1 viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2
Ospfd -- Default config produces syntax error
All, A fresh install of OpenBSD 4.7 includes the default ospfd.conf (here are just the first 11 lines): # $OpenBSD: ospfd.conf,v 1.4 2007/06/19 16:49:56 reyk Exp $ # macros password=secret # global configuration # router-id 10.0.0.1 # fib-update no # stub router no # spf-delay 1 # spf-holdtime 5 If you uncomment out the fib-update no line, and have Ospfd perform a syntax check of the file... $ sudo ospfd -nf /etc/ospfd.conf WARNING: IP forwarding NOT enabled, running as stub router /etc/ospfd.conf:8: syntax error Why does uncommenting a line in the default configuration throw a syntax error? Under 4.7, Ospfd will ALWAYS update the FIB, as you cannot tell it not to. Surely, this is a bug. -- Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943
Ospfd.conf, fib-update, and Syntax Errors
All,
I'm having a really strange issue with a 4.7 box running -stable and the
option fib-update no in ospfd.conf:
Here's my ospfd.conf:
# cat /etc/ospfd.conf
# $OpenBSD: ospfd.conf,v 1.4 2007/06/19 16:49:56 reyk Exp $
# Global Config
router-id ***.***.***.***
fib-update no
area 0.0.0.31 {
interface fxp0 {
auth-type crypt
auth-md-keyid **
auth-md 1
}
interface lo1 {
passive
}
}
Now, when I try to bring up ospfd...
# ospfd -n
/etc/ospfd.conf:5: syntax error
Line 5, of course, is the fib-update no line. I know this is the
correct synatx ( or at least the man page for ospfd.conf says so), so
what gives?
--
Thanks,
Andrew Klettke
Optic Fusion NOC
253-830-2943
Radius Auth and Insecurity Outputs
Hello all, I'm having a (cosmetic) problem with a couple of OpenBSD boxes that are using RADIUS authentication. When I install the OS, I create a local user with local authentication. After the box's network config is all done, I then change the login class of the user to so I can use RADIUS, by modifying /etc/master.passwd with `vipw', so it looks like this: (removed):*:1000:10:radius:0:0::/home/(removed):/bin/ksh The problem then occurs when /etc/security runs, as it gives the following output: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. This login is being used successfully with RADIUS, all is working as expected, I just want to get rid of this error. Any input? -- Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 Subscribe to Optic Fusion's Twitter service for up to the minute network issues and maintenance notifications. http://www.twitter.com/opticfusion
Re: Radius Auth and Insecurity Outputs
Ted, You mean the * field? I've replaced that with radius, as you suggested, so it looks like so: (removed):radius:1000:10:radius:0:0:nocstaff:/home/(removed):/bin/ksh It works, the user can log in fine still; however, OpenBSD still isn't happy about it: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. Any thoughts? Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 Subscribe to Optic Fusion's Twitter service for up to the minute network issues and maintenance notifications. http://www.twitter.com/opticfusion On 04/19/2010 02:34 PM, Ted Unangst wrote: On Mon, Apr 19, 2010 at 3:14 PM, Andrew Klettke aklet...@opticfusion.net wrote: When I install the OS, I create a local user with local authentication. After the box's network config is all done, I then change the login class of the user to so I can use RADIUS, by modifying /etc/master.passwd with `vipw', so it looks like this: (removed):*:1000:10:radius:0:0::/home/(removed):/bin/ksh The problem then occurs when /etc/security runs, as it gives the following output: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. This login is being used successfully with RADIUS, all is working as expected, I just want to get rid of this error. Any input? Looks like changing the password field to radius will work.
Re: Radius Auth and Insecurity Outputs
Thanks again Ted, This is an ugly hack (and one that I'll have to keep performing with these types of installs), but if it's the only way to get /etc/security to stop complaining, then I guess that's what I'll have to do. Thanks, Andrew Klettke Optic Fusion NOC 253-830-2943 Subscribe to Optic Fusion's Twitter service for up to the minute network issues and maintenance notifications. http://www.twitter.com/opticfusion On 04/19/2010 03:04 PM, Ted Unangst wrote: On Mon, Apr 19, 2010 at 5:42 PM, Andrew Klettke aklet...@opticfusion.net wrote: You mean the * field? I've replaced that with radius, as you suggested, so it looks like so: (removed):radius:1000:10:radius:0:0:nocstaff:/home/(removed):/bin/ksh It works, the user can log in fine still; however, OpenBSD still isn't happy about it: Checking the /etc/master.passwd file: Login (removed) is off but still has a valid shell and alternate access files in home directory are still readable. Guess my awk isn't as awesome as it used to be. I'd just edit /etc/security. There's a check in there to make sure the password isn't skey. Add another check that's it's not radius.
