Re: Error messages with VMM on 6.6 and 6.7
On Tue, Jun 02, 2020 at 10:18:32AM +0800, jrmu wrote: > OpenBSD VMM suffers from error messages and possibly spontaneous crashing > > System : OpenBSD 6.7 > Details : OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT > 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > > >Description: > I ran VMM on OpenBSD 6.6 with ~30 VMs, a mixture of OpenBSD 6.6, 6.7, > and Debian, and kept seeing the following error messages in logs: > > May 28 00:54:37 srv1 vmd[97924]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 00:59:05 srv1 vmd[24983]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 01:12:35 srv1 vmd[31276]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 01:14:40 srv1 vmd[31276]: vioblk queue notify - nothing to do? > May 28 01:15:12 srv1 last message repeated 806 times > May 28 01:17:03 srv1 last message repeated 78 times > May 28 01:30:03 srv1 vmd[31276]: vioblk queue notify - nothing to do? > May 28 01:40:19 srv1 last message repeated 67 times > May 28 01:44:17 srv1 last message repeated 47 times Those messages are a bit odd, basically it means the in-guest driver notified vioblk (the VM's disk device) that there were descriptors in the ring but when the device-side implementation (in vmd(8)) went to process them, the ring was empty. There shouldn't be any side effect, although it does indicate something unexpected is happening. > May 28 01:44:19 srv1 vmd[9684]: rtc_update_rega: set non-32KHz timebase not > supported > Those messages aren't serious, Linux kernels program the RTC this way. TBH, that message has probably outlived its usefulness. Someone can remove it at this point. > Every 2-3 weeks, the system appeared to crash, but I could not find any other > error message that would narrow down the cause. I am not sure if the crash is > related to either of those two above error messages. Likely unrelated; those messages are from vmd(8), a user-mode process. I think it's difficult for vmd(8) to crash the system. > > Today I upgraded to OpenBSD 6.7 stable with hopes that the problem may have > been fixed. However, I still notice the same two error messages: > > May 31 19:06:32 srv1 vmd[72705]: vcpu_process_com_data: guest reading com1 > when not ready > May 31 19:06:33 srv1 last message repeated 2 times > May 31 19:06:40 srv1 reorder_kernel: kernel relinking done > May 31 19:09:03 srv1 vmd[72705]: rtc_update_rega: set non-32KHz timebase not > supported > > Any workaround or suggestions? What is the question here? If you are tiring of the log messages, you can remove those particular ones. As I said higher up, these messages have likely exceeded their usefulness (these were put in during early development to detect weird corner cases like this). -ml > > dmesg: > OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34306437120 (32717MB) > avail mem = 33254100992 (31713MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec830 (156 entries) > bios0: vendor American Megatrends Inc. version "3.3" date 05/23/2018 > bios0: Supermicro X9DRi-LN4+/X9DR3-LN4+ > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP APIC FPDT SRAT SLIT HPET PRAD SPMI SSDT EINJ ERST > HEST BERT DMAR MCFG > acpi0: wakeup devices P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PWVE(S4) NPE1(S4) > NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) NPEA(S4) NPE2(S4) NPE3(S4) NPE7(S4) > NPE9(S4) NPE2(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.27 MHz, 06-2d-07 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.02 MHz, 06-2d-07 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
Error messages with VMM on 6.6 and 6.7
OpenBSD VMM suffers from error messages and possibly spontaneous crashing System : OpenBSD 6.7 Details : OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I ran VMM on OpenBSD 6.6 with ~30 VMs, a mixture of OpenBSD 6.6, 6.7, and Debian, and kept seeing the following error messages in logs: May 28 00:54:37 srv1 vmd[97924]: rtc_update_rega: set non-32KHz timebase not supported May 28 00:59:05 srv1 vmd[24983]: rtc_update_rega: set non-32KHz timebase not supported May 28 01:12:35 srv1 vmd[31276]: rtc_update_rega: set non-32KHz timebase not supported May 28 01:14:40 srv1 vmd[31276]: vioblk queue notify - nothing to do? May 28 01:15:12 srv1 last message repeated 806 times May 28 01:17:03 srv1 last message repeated 78 times May 28 01:30:03 srv1 vmd[31276]: vioblk queue notify - nothing to do? May 28 01:40:19 srv1 last message repeated 67 times May 28 01:44:17 srv1 last message repeated 47 times May 28 01:44:19 srv1 vmd[9684]: rtc_update_rega: set non-32KHz timebase not supported Every 2-3 weeks, the system appeared to crash, but I could not find any other error message that would narrow down the cause. I am not sure if the crash is related to either of those two above error messages. Today I upgraded to OpenBSD 6.7 stable with hopes that the problem may have been fixed. However, I still notice the same two error messages: May 31 19:06:32 srv1 vmd[72705]: vcpu_process_com_data: guest reading com1 when not ready May 31 19:06:33 srv1 last message repeated 2 times May 31 19:06:40 srv1 reorder_kernel: kernel relinking done May 31 19:09:03 srv1 vmd[72705]: rtc_update_rega: set non-32KHz timebase not supported Any workaround or suggestions? dmesg: OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34306437120 (32717MB) avail mem = 33254100992 (31713MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec830 (156 entries) bios0: vendor American Megatrends Inc. version "3.3" date 05/23/2018 bios0: Supermicro X9DRi-LN4+/X9DR3-LN4+ acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT SRAT SLIT HPET PRAD SPMI SSDT EINJ ERST HEST BERT DMAR MCFG acpi0: wakeup devices P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PWVE(S4) NPE1(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) NPEA(S4) NPE2(S4) NPE3(S4) NPE7(S4) NPE9(S4) NPE2(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.27 MHz, 06-2d-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.02 MHz, 06-2d-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.02 MHz, 06-2d-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.01 MHz, 06-2d-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,
Re: ttyC0 floods with error messages
I'm the original poster of this thread, don't mean to whip a dead horse, but this post is to confirm the state of this issue. The most recent -current release before this post has fixed this issue for me. OpenBSD 6.6-current (GENERIC.MP) #573: Sat Dec 28 19:13:57 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I'm longer greeted with the given train of messages from kernel. >wsmouse0 at ums0 mux 0 >wsmouse0 detached >ums0 detached >uhidev2 detached >uhidev2 at uhub5 port 2 configuration 1 interface 0 "Logitech USB Optical >Mouse" rev 2.00/72.00 addr 3 >uhidev2: iclass 3/1 >ums0 at uhidev2: 3 buttons, Z dir Major props to the OpenBSD Devs for dealing with this successfully and in such a short time.
Re: ttyC0 floods with error messages
"Raymond, David" wrote: > I get similar stuff on console 1 but not on the others on all my > OpenBSD machines. As I use X windows and have clean consoles 2-4 > available if necessary, I just ignore it. > > Dave Raymond > > > On 12/16/19, putridsou...@gmail.com wrote: > > The error does not seem to be a faulty mouse and I > > don't use a KVM switch anyway so it is not the source. > > Following on pervious reply, I tried on a new mouse. > > But was greeted with the same error: > > > > wsmouse0 detached > > ums0 detached > > uhidev0 detached > > uhidev0 at uhub0 port 4 configuration 1 interface 0 "PixArt USB Optical > > Mouse" rev 2.00/1.00 addr 2 > > uhidev0: iclass 3/1 > > ums0 at uhidev0: 3 buttons, Z dir > > wsmouse0 at ums0 mux 0 > > > > Unless I'm the unfortunate person destined to own all faulty > > mice in the world, I look forward to a solution. Is there > > anyone here who uses a desktop setup with a mouse, not greeted > > with these pesky errors. Are experts on here sure this is not > > a bug, or lack of proper driver. More info on the latter, this > > test consisted of Logitech M90 and Dell MS111-P mouse. > > > > > > > -- > David J. Raymond > david.raym...@nmt.edu > http://physics.nmt.edu/~raymond I get this also on my Intel NUC with the mouse connected via an Anker 7 port HUB extender. I was tidying up my cables yesterday and moved my mouse cable to one of the NUC's ports and I haven't been spammed since. The dmesg that was sent in looked like it had a USB HUB and then someone mentioned a KVM switch. So not sure if the mice or host don't like how they are connected.
Re: ttyC0 floods with error messages
On 12-16 10:48, Raymond, David wrote: > I get similar stuff on console 1 but not on the others on all my > OpenBSD machines. As I use X windows and have clean consoles 2-4 > available if necessary, I just ignore it. I get similar messages in dmesg (used to be on the first console), and every couple of days or so (not a consistent period), the mouse just stops working, sometimes working again a few days after I unplug it, so I switch that way between a wireless and wired mouse until they both stop and when I get tired enough of being mouseless then I reboot. Ending message with dmesg output: OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16033533952 (15290MB) avail mem = 15537967104 (14818MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf90 (49 entries) bios0: vendor American Megatrends Inc. version "204" date 11/20/2014 bios0: ASUSTeK COMPUTER INC. X550ZA acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ECDT MCFG MSDM HPET UEFI SSDT SSDT CRAT SSDT SSDT SSDT SSDT acpi0: wakeup devices LOM_(S4) SBAZ(S4) ECIR(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) ODD8(S3) GLAN(S4) LID_(S5) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2496.48 MHz, 15-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu0: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.34 MHz, 15-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu1: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.34 MHz, 15-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu2: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.34 MHz, 15-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu3: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 1 pa 0xfec01000, version 21, 32 pins acpiec0 at acpi0 acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB21) acpiprt2 at acpi0: bus -1 (PB22) acpiprt3 at acpi0: bus -1
Re: ttyC0 floods with error messages
USB subsystem bugs. Whoever said it was your mouse or cable is being an inaccurate jerk. Raymond, David wrote: > I get similar stuff on console 1 but not on the others on all my > OpenBSD machines. As I use X windows and have clean consoles 2-4 > available if necessary, I just ignore it. > > Dave Raymond > > > On 12/16/19, putridsou...@gmail.com wrote: > > The error does not seem to be a faulty mouse and I > > don't use a KVM switch anyway so it is not the source. > > Following on pervious reply, I tried on a new mouse. > > But was greeted with the same error: > > > > wsmouse0 detached > > ums0 detached > > uhidev0 detached > > uhidev0 at uhub0 port 4 configuration 1 interface 0 "PixArt USB Optical > > Mouse" rev 2.00/1.00 addr 2 > > uhidev0: iclass 3/1 > > ums0 at uhidev0: 3 buttons, Z dir > > wsmouse0 at ums0 mux 0 > > > > Unless I'm the unfortunate person destined to own all faulty > > mice in the world, I look forward to a solution. Is there > > anyone here who uses a desktop setup with a mouse, not greeted > > with these pesky errors. Are experts on here sure this is not > > a bug, or lack of proper driver. More info on the latter, this > > test consisted of Logitech M90 and Dell MS111-P mouse. > > > > > > > -- > David J. Raymond > david.raym...@nmt.edu > http://physics.nmt.edu/~raymond >
Re: ttyC0 floods with error messages
I get similar stuff on console 1 but not on the others on all my OpenBSD machines. As I use X windows and have clean consoles 2-4 available if necessary, I just ignore it. Dave Raymond On 12/16/19, putridsou...@gmail.com wrote: > The error does not seem to be a faulty mouse and I > don't use a KVM switch anyway so it is not the source. > Following on pervious reply, I tried on a new mouse. > But was greeted with the same error: > > wsmouse0 detached > ums0 detached > uhidev0 detached > uhidev0 at uhub0 port 4 configuration 1 interface 0 "PixArt USB Optical > Mouse" rev 2.00/1.00 addr 2 > uhidev0: iclass 3/1 > ums0 at uhidev0: 3 buttons, Z dir > wsmouse0 at ums0 mux 0 > > Unless I'm the unfortunate person destined to own all faulty > mice in the world, I look forward to a solution. Is there > anyone here who uses a desktop setup with a mouse, not greeted > with these pesky errors. Are experts on here sure this is not > a bug, or lack of proper driver. More info on the latter, this > test consisted of Logitech M90 and Dell MS111-P mouse. > > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: ttyC0 floods with error messages
The error does not seem to be a faulty mouse and I don't use a KVM switch anyway so it is not the source. Following on pervious reply, I tried on a new mouse. But was greeted with the same error: wsmouse0 detached ums0 detached uhidev0 detached uhidev0 at uhub0 port 4 configuration 1 interface 0 "PixArt USB Optical Mouse" rev 2.00/1.00 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 Unless I'm the unfortunate person destined to own all faulty mice in the world, I look forward to a solution. Is there anyone here who uses a desktop setup with a mouse, not greeted with these pesky errors. Are experts on here sure this is not a bug, or lack of proper driver. More info on the latter, this test consisted of Logitech M90 and Dell MS111-P mouse.
Re: ttyC0 floods with error messages
On Fri, Dec 13, 2019 at 8:42 AM wrote: > After boot, the following error message floods the virtual console on > ttyC0 repeatedly, rest of virtuals console stay clear somehow. Is there a > way to > treat this permanently, other than Ctrl-l everytime, or disconnecting the > mouse. > There must be some config to disable this direct dumping of errors onto > console. > > wsmouse0 at ums0 mux 0 > wsmouse0 detached > ums0 detached > uhidev2 detached > uhidev2 at uhub5 port 2 configuration 1 interface 0 "Logitech USB Optical > Mouse" rev 2.00/72.00 addr 3 > uhidev2: iclass 3/1 > ums0 at uhidev2: 3 buttons, Z dir > In my experience when the console is spammed by mouse detach and attach events, it's because the mouse is defective, usually because the cable is wearing out and developing an intermittent fault. Switch to a different mouse, even if the mouse appears to work ok, because it will probably get worse. Another reason for these messages is because you're using a KVM switch that performs the switch operation by disconnecting/reconnecting your USB devices, but I assume that isn't the cause here. Suppressing the errors is probably a bad idea, in that case how would you know your mouse is developing a fault until more serious problems arise? Better to be notified early so you have time to deal with it. -ken
Re: ttyC0 floods with error messages
On Fri, 13 Dec 2019, putridsou...@gmail.com wrote: Date: Fri, 13 Dec 2019 19:12:41 +0530 (IST) From: putridsou...@gmail.com To: misc@openbsd.org Subject: ttyC0 floods with error messages After boot, the following error message floods the virtual console on ttyC0 repeatedly, rest of virtuals console stay clear somehow. Is there a way to treat this permanently, other than Ctrl-l everytime, or disconnecting the mouse. There must be some config to disable this direct dumping of errors onto console. wsmouse0 at ums0 mux 0 wsmouse0 detached ums0 detached uhidev2 detached uhidev2 at uhub5 port 2 configuration 1 interface 0 "Logitech USB Optical Mouse" rev 2.00/72.00 addr 3 uhidev2: iclass 3/1 ums0 at uhidev2: 3 buttons, Z dir For some reason the same happens to me with both OpenBSD & NetBSD, but not with FreeBSD which is rock solid. I tend to just jump up to tty2 or whatever. Of course you can't do that on the installation. Good Luck, Clay clays.sh...@sdf.org SDF Public Access UNIX System - http://sdf.org
ttyC0 floods with error messages
After boot, the following error message floods the virtual console on ttyC0 repeatedly, rest of virtuals console stay clear somehow. Is there a way to treat this permanently, other than Ctrl-l everytime, or disconnecting the mouse. There must be some config to disable this direct dumping of errors onto console. wsmouse0 at ums0 mux 0 wsmouse0 detached ums0 detached uhidev2 detached uhidev2 at uhub5 port 2 configuration 1 interface 0 "Logitech USB Optical Mouse" rev 2.00/72.00 addr 3 uhidev2: iclass 3/1 ums0 at uhidev2: 3 buttons, Z dir
Re: help understanding ikectl error messages
Thanks Stuart for replies! I can confirm that I could proceed without issues on 6.2-current. :-) BR, Andreas mån 15 jan. 2018 kl. 10:31 skrev Stuart Henderson : > On 2018/01/15 06:35, Andreas Thulin wrote: > > Sorry, my bad! > > > > 6.2-stable. And after sending my e-mail, I found a post about this > issue, that ended up in > > ikeca.c (?) having been patched on 8 November last year to resolve the > same issue, I believe. I > > have installed 6.2-current on another machine to figure out if that > solves the problem. > > > > BR, Andreas > > Thanks - -current should fix this. (I did think that it had been fixed > before 6.2 which is why I asked about the version, but yes it looks like > this one wasn't fixed until 8 Nov). > >
Re: help understanding ikectl error messages
On 2018/01/15 06:35, Andreas Thulin wrote: > Sorry, my bad! > > 6.2-stable. And after sending my e-mail, I found a post about this issue, > that ended up in > ikeca.c (?) having been patched on 8 November last year to resolve the same > issue, I believe. I > have installed 6.2-current on another machine to figure out if that solves > the problem. > > BR, Andreas Thanks - -current should fix this. (I did think that it had been fixed before 6.2 which is why I asked about the version, but yes it looks like this one wasn't fixed until 8 Nov).
Re: help understanding ikectl error messages
Sorry, my bad! 6.2-stable. And after sending my e-mail, I found a post about this issue, that ended up in ikeca.c (?) having been patched on 8 November last year to resolve the same issue, I believe. I have installed 6.2-current on another machine to figure out if that solves the problem. BR, Andreas sön 14 jan. 2018 kl. 23:03 skrev Stuart Henderson : > On 2018-01-09, Andreas Thulin wrote: > > Hi! > > > > Following the example on https://man.openbsd.org/ikectl, I > > > > # ikectl ca test create > > ...and then > > # ikectl ca test certificate sub.domain.com create > > ...filled out "the form", but after that... > > Using configuration from /etc/ssl/test/sub.domain.com-ssl.cnf > > Check that the request matches the signature > > Signature ok > > The Subject's Distinguished Name is as follows > > countryName :PRINTABLE:'SE' > > organizationName :ASN.1 12:'cppm' > > commonName:ASN.1 12:'sub.domain.com' > > emailAddress :IA5STRING:'webmas...@domain.com' > > ERROR: adding extensions in section x509v3_FQDN > > 2198743120:error:22FFF06D:X509 V3 routines:func(4095):invalid null > > value:/usr/src/lib/libcrypto/x509v3/v3_utl.c:355: > > 2198743120:error:22FFF069:X509 V3 routines:func(4095):invalid extension > > > string:/usr/src/lib/libcrypto/x509v3/v3_conf.c:143:name=subjectAltName,section=DNS: > > 2198743120:error:22FFF080:X509 V3 routines:func(4095):error in > > extension:/usr/src/lib/libcrypto/x509v3/v3_conf.c:96:name=subjectAltName, > > value=DNS: > > > > I'm probably doing something stupid, so if anyone can point me in the > right > > direction, that would be highly appreciated. > > > > BR > > Andreas > > > > Which version are you running? (See "Include important information" > on http://www.openbsd.org/mail.html). > > >
Re: help understanding ikectl error messages
On 2018-01-09, Andreas Thulin wrote: > Hi! > > Following the example on https://man.openbsd.org/ikectl, I > > # ikectl ca test create > ...and then > # ikectl ca test certificate sub.domain.com create > ...filled out "the form", but after that... > Using configuration from /etc/ssl/test/sub.domain.com-ssl.cnf > Check that the request matches the signature > Signature ok > The Subject's Distinguished Name is as follows > countryName :PRINTABLE:'SE' > organizationName :ASN.1 12:'cppm' > commonName:ASN.1 12:'sub.domain.com' > emailAddress :IA5STRING:'webmas...@domain.com' > ERROR: adding extensions in section x509v3_FQDN > 2198743120:error:22FFF06D:X509 V3 routines:func(4095):invalid null > value:/usr/src/lib/libcrypto/x509v3/v3_utl.c:355: > 2198743120:error:22FFF069:X509 V3 routines:func(4095):invalid extension > string:/usr/src/lib/libcrypto/x509v3/v3_conf.c:143:name=subjectAltName,section=DNS: > 2198743120:error:22FFF080:X509 V3 routines:func(4095):error in > extension:/usr/src/lib/libcrypto/x509v3/v3_conf.c:96:name=subjectAltName, > value=DNS: > > I'm probably doing something stupid, so if anyone can point me in the right > direction, that would be highly appreciated. > > BR > Andreas > Which version are you running? (See "Include important information" on http://www.openbsd.org/mail.html).
help understanding ikectl error messages
Hi! Following the example on https://man.openbsd.org/ikectl, I # ikectl ca test create ...and then # ikectl ca test certificate sub.domain.com create ...filled out "the form", but after that... Using configuration from /etc/ssl/test/sub.domain.com-ssl.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'SE' organizationName :ASN.1 12:'cppm' commonName:ASN.1 12:'sub.domain.com' emailAddress :IA5STRING:'webmas...@domain.com' ERROR: adding extensions in section x509v3_FQDN 2198743120:error:22FFF06D:X509 V3 routines:func(4095):invalid null value:/usr/src/lib/libcrypto/x509v3/v3_utl.c:355: 2198743120:error:22FFF069:X509 V3 routines:func(4095):invalid extension string:/usr/src/lib/libcrypto/x509v3/v3_conf.c:143:name=subjectAltName,section=DNS: 2198743120:error:22FFF080:X509 V3 routines:func(4095):error in extension:/usr/src/lib/libcrypto/x509v3/v3_conf.c:96:name=subjectAltName, value=DNS: I'm probably doing something stupid, so if anyone can point me in the right direction, that would be highly appreciated. BR Andreas
Re: understanding ldapd log error messages
> Use the options "-dv" at first. If you need to see th BER messages > use "-dvv" (see also "man ldapd"). Do you see anything in this snipped b,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:19:09.481 [18682] found dn uid=rrabbany,ou=users,dc=autonlab,dc=org Apr 23 23:19:09.481 [18682] requesting 01 access to uid=rrabbany,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:19:09.481 [18682] found dn uid=zhez,ou=users,dc=autonlab,dc=org Apr 23 23:19:09.481 [18682] requesting 01 access to uid=zhez,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:19:09.482 [18682] found dn uid=awertz,ou=users,dc=autonlab,dc=org Apr 23 23:19:09.482 [18682] requesting 01 access to uid=awertz,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:19:09.482 [18682] 259 scanned, 135 matched, 0 dups Apr 23 23:19:09.482 [18682] sending response 5 with result 0 Apr 23 23:19:09.482 [18682] finished search on msgid 3 Apr 23 23:19:09.645 [18682] end-of-file on connection 16 Apr 23 23:19:09.645 [18682] closing connection 16 Apr 23 23:19:10.960 [18682] accepted connection from 10.8.0.6 on fd 16 Apr 23 23:19:10.961 [18682] consumed 31 bytes Apr 23 23:19:10.961 [18682] got request type 23, id 1 Apr 23 23:19:10.961 [18682] got extended operation 1.3.6.1.4.1.1466.20037 Apr 23 23:19:10.961 [18682] sending response 24 with result 0 Apr 23 23:19:10.961 [18682] conn_tls_init: switching to TLS Apr 23 23:19:10.978 [18682] error 0x24 on connection 16 Apr 23 23:19:10.978 [18682] closing connection 16 Apr 23 23:19:30.086 [18682] consumed 31 bytes Apr 23 23:19:30.086 [18682] got request type 23, id 1 Apr 23 23:19:30.086 [18682] got extended operation 1.3.6.1.4.1.1466.20037 Apr 23 23:19:30.086 [18682] sending response 24 with result 0 Apr 23 23:19:30.086 [18682] conn_tls_init: switching to TLS Apr 23 23:19:30.105 [18682] error 0x24 on connection 16 Apr 23 23:19:30.105 [18682] closing connection 16 Apr 23 23:19:41.811 [18682] accepted connection from 10.8.0.6 on fd 16 Apr 23 23:19:41.811 [18682] consumed 31 bytes Apr 23 23:19:41.811 [18682] got request type 23, id 1 Apr 23 23:19:41.811 [18682] got extended operation 1.3.6.1.4.1.1466.20037 Apr 23 23:19:41.811 [18682] sending response 24 with result 0 Apr 23 23:19:41.811 [18682] conn_tls_init: switching to TLS Apr 23 23:19:41.828 [18682] error 0x24 on connection 16 Apr 23 23:19:41.828 [18682] closing connection 16 Apr 23 23:19:51.312 [18682] accepted connection from 10.8.0.6 on fd 16 Apr 23 23:19:51.312 [18682] consumed 31 bytes Apr 23 23:19:51.312 [18682] got request type 23, id 1 Apr 23 23:19:51.312 [18682] got extended operation 1.3.6.1.4.1.1466.20037 Apr 23 23:19:51.312 [18682] sending response 24 with result 0 Apr 23 23:19:51.312 [18682] conn_tls_init: switching to TLS Apr 23 23:19:51.331 [18682] error 0x24 on connection 16 Apr 23 23:19:51.331 [18682] closing connection 16 Apr 23 23:20:26.243 [18682] requesting 01 access to uid=yichongx,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.243 [18682] found dn uid=sray,ou=users,dc=autonlab,dc=org Apr 23 23:20:26.243 [18682] requesting 01 access to uid=sray,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] found dn uid=ekennedy,ou=users,dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] requesting 01 access to uid=ekennedy,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] found dn uid=aharley,ou=users,dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] requesting 01 access to uid=aharley,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] found dn uid=rrabbany,ou=users,dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] requesting 01 access to uid=rrabbany,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] found dn uid=zhez,ou=users,dc=autonlab,dc=org Apr 23 23:20:26.244 [18682] requesting 01 access to uid=zhez,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.245 [18682] found dn uid=awertz,ou=users,dc=autonlab,dc=org Apr 23 23:20:26.245 [18682] requesting 01 access to uid=awertz,ou=users,dc=autonlab,dc=org by any, in namespace dc=autonlab,dc=org Apr 23 23:20:26.245 [18682] 259 scanned, 0 matched, 0 dups Apr 23 23:20:26.245 [18682] sending response 5 with result 0 Apr 23 23:20:26.245 [18682] finished search on msgid 7
Re: understanding ldapd log error messages
Robert Klein wrote:
> Hi,
>
> On Sat, 22 Apr 2017 21:55:58 -0400
> Predrag Punosevac wrote:
>
> > Predrag Punosevac write:
> > > Hi misc,
> > >
> > > ldapd on one of my two ldap servers stop working overnight
> > >
> >
> > ldapd died again overnight. I noticed that this started happening not
> > right after the upgrade to 6.1 but less than 24h after I added a
> > person to my LDAP database. How do I go about debugging a daemon? I am
> > reading
> >
> > http://man.openbsd.org/rc.d
> >
> > and I have used option -d when a daemon fails to start but I really
> > need to catch what happens when ldapd dies and redirect to the log
> > file.
>
>
> Use the options "-dv" at first. If you need to see th BER messages use
> "-dvv" (see also "man ldapd").
>
> Could you post an example setup, i.e. ldapd.conf and a LDIF file?
# more /etc/ldapd.conf
# $OpenBSD: ldapd.conf,v 1.2 2010/06/29 02:50:22 martinh Exp $
schema "/etc/ldap/core.schema"
schema "/etc/ldap/inetorgperson.schema"
schema "/etc/ldap/nis.schema"
listen on lo0 tls certificate atlas
listen on em1 tls certificate atlas
listen on "/var/run/ldapi"
namespace "dc=autonlab,dc=org" {
rootdn "cn=admin,dc=autonlab,dc=org"
rootpw "{SSHA}iV3eDxcQ9LM9EJN6ltigbmHFUwuS/tE/"
index sn
index givenName
index cn
index mail
}
This is an example of newuser.ldif file used to add new users to the
database. Note the following file is sanitized for trailing white
spaces. The white spaces you see in my e-mail are not in the database.
# more new_user.ldif
dn: cn=jsmith,ou=group,dc=autonlab,dc=org
cn: jsmith
objectClass: top
objectClass: posixGroup
gidNumber: 1120
memberUid: jsmith
description: User Private Group
dn: uid=jsmith,ou=users,dc=autonlab,dc=org
uid: jsmith
cn: John Smith
sn: Smith
givenName: John
displayName: John Smith
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 1492716996
userPassword: {SSHA}E7VQcALE0zXe4lehOulF/fXIdi2kUQ6b
shadowMin: 1
shadowMax: 180
shadowWarning: 7
shadowInactive: 30
shadowExpire: -1
shadowFlag: 0
loginShell: /bin/bash
uidNumber: 1120
gidNumber: 1120
homeDirectory: /zfsauton/home/jsmith
mail: jsm...@web.de
gecos: John Smith
title: MSc student
postalAddress: NSH 3128
postalAddress: CMU
businessCategory: Graduate Student
telephoneNumber: (412) ???-
o: Auton Lab
>
> Best regards
> Robert
Re: understanding ldapd log error messages
Hi, On Sat, 22 Apr 2017 21:55:58 -0400 Predrag Punosevac wrote: > Predrag Punosevac write: > > Hi misc, > > > > ldapd on one of my two ldap servers stop working overnight > > > > ldapd died again overnight. I noticed that this started happening not > right after the upgrade to 6.1 but less than 24h after I added a > person to my LDAP database. How do I go about debugging a daemon? I am > reading > > http://man.openbsd.org/rc.d > > and I have used option -d when a daemon fails to start but I really > need to catch what happens when ldapd dies and redirect to the log > file. Use the options "-dv" at first. If you need to see th BER messages use "-dvv" (see also "man ldapd"). Could you post an example setup, i.e. ldapd.conf and a LDIF file? Best regards Robert
Re: understanding ldapd log error messages
Predrag Punosevac write: > Hi misc, > > ldapd on one of my two ldap servers stop working overnight > ldapd died again overnight. I noticed that this started happening not right after the upgrade to 6.1 but less than 24h after I added a person to my LDAP database. How do I go about debugging a daemon? I am reading http://man.openbsd.org/rc.d and I have used option -d when a daemon fails to start but I really need to catch what happens when ldapd dies and redirect to the log file. Best, Predrag > # uname -a > OpenBSD atlas.int.autonlab.org 6.1 GENERIC.MP#20 amd64 > > I manually restarted it and it appears to work OK. I started digging > little bit through the log files and I see the following in my > /var/log/message file before and after the upgrade. Can somebody help me > understand what I see and point me to some kind reading? Is my database > corrupted for some reason? The LDAP server overall has being working > really well for the past 3.5 years with Red Hat, FreeBSD, and OpenBSD > clients. I have being upgrading this server since the last database > format change (I think OpenBSD 5.3 or 5.4). > > Best, > Predrag
understanding ldapd log error messages
Hi misc, ldapd on one of my two ldap servers stop working overnight # uname -a OpenBSD atlas.int.autonlab.org 6.1 GENERIC.MP#20 amd64 I manually restarted it and it appears to work OK. I started digging little bit through the log files and I see the following in my /var/log/message file before and after the upgrade. Can somebody help me understand what I see and point me to some kind reading? Is my database corrupted for some reason? The LDAP server overall has being working really well for the past 3.5 years with Red Hat, FreeBSD, and OpenBSD clients. I have being upgrading this server since the last database format change (I think OpenBSD 5.3 or 5.4). Best, Predrag Apr 17 04:03:39 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 17 04:03:39 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 17 04:03:44 atlas ldapd[83666]: error 0x24 on connection 17 Apr 17 04:04:20 atlas last message repeated 3 times Apr 17 04:04:31 atlas ldapd[83666]: error 0x24 on connection 13 Apr 17 04:05:02 atlas last message repeated 3 times Apr 17 04:05:12 atlas ldapd[83666]: error 0x24 on connection 13 Apr 17 04:05:24 atlas ldapd[83666]: error 0x24 on connection 18 Apr 17 04:05:57 atlas last message repeated 3 times Apr 17 04:08:08 atlas last message repeated 12 times Apr 17 04:08:41 atlas last message repeated 3 times Apr 17 04:08:53 atlas ldapd[83666]: error 0x24 on connection 20 Apr 17 04:09:05 atlas ldapd[83666]: error 0x24 on connection 22 Apr 17 04:09:36 atlas last message repeated 3 times Apr 17 04:09:57 atlas last message repeated 2 times Apr 17 04:10:07 atlas ldapd[83666]: error 0x24 on connection 38 Apr 17 04:10:18 atlas ldapd[83666]: error 0x24 on connection 25 Apr 17 04:10:28 atlas ldapd[83666]: error 0x24 on connection 25 Apr 17 04:10:40 atlas ldapd[83666]: error 0x24 on connection 38 Apr 17 04:10:52 atlas ldapd[83666]: error 0x24 on connection 40 Apr 17 04:11:23 atlas last message repeated 3 times Apr 17 04:11:34 atlas ldapd[83666]: error 0x24 on connection 26 Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 17 04:11:44 atlas ldapd[83666]: error 0x24 on connection 40 Apr 17 04:11:56 atlas ldapd[83666]: error 0x24 on connection 41 Apr 17 04:12:29 atlas last message repeated 3 times Apr 17 04:12:50 atlas last message repeated 2 times Apr 17 04:13:00 atlas ldapd[83666]: error 0x24 on connection 28 Apr 17 04:13:36 atlas last message repeated 3 times Apr 17 04:14:09 atlas last message repeated 3 times Apr 17 04:14:21 atlas ldapd[83666]: error 0x24 on connection 14 Apr 17 04:14:44 atlas last message repeated 2 times Apr 17 04:14:54 atlas ldapd[83666]: error 0x24 on connection 15 Apr 17 04:15:25 atlas last message repeated 3 times Apr 17 04:16:10 atlas last message repeated 4 times Apr 17 04:16:20 atlas ldapd[83666]: error 0x24 on connection 29 Apr 17 04:16:53 atlas last message repeated 3 times Apr 17 04:17:05 atlas ldapd[83666]: error 0x24 on connection 29 Apr 17 04:17:17 atlas ldapd[83666]: error 0x24 on connection 32 Apr 17 04:17:50 atlas last message repeated 3 times Apr 17 04:18:23 atlas last message repeated 3 times Apr 17 04:18:33 atlas ldapd[83666]: error 0x24 on connection 16 Apr 17 04:19:06 atlas last message repeated 3 times Apr 17 04:19:18 atlas ldapd[83666]: error 0x24 on connection 33 Apr 17 04:19:51 atlas last message repeated 3 times Apr 17 04:20:01 atlas ldapd[83666]: error 0x24 on connection 33 Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 17 04:20:12 atlas ldapd[83666]: error 0x24 on connection 34 Apr 17 04:20:22 atlas ldapd[83666]: error 0x24 on connection 13 Apr 17 04:20:33 atlas ldapd[83666]: error 0x24 on connection 34 and this is from today Apr 21 12:04:41 atlas ldapd[78718]: error 0x24 on connection 19 Apr 21 12:04:52 atlas ldapd[78718]: error 0x24 on connection 19 Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 21 12:05:01 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 21 12:05:01 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Ap
Error messages in dmesg output about intel_dp_set_link_train and i915_write32
Hi guys, I just upgraded my laptop from 5.7 to 5.8 and I notice error messages in my dmesg output. Any ideas? OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4178116608 (3984MB) avail mem = 4047597568 (3860MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec720 (45 entries) bios0: vendor Dell Inc. version "A03" date 05/27/2014 bios0: Dell Inc. Inspiron 5748 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! LPIT SSDT SLIC SSDT SSDT MCFG HPET SSDT SSDT MSDM DMAR CSRT acpi0: wakeup devices PXSX(S4) RP01(S3) PXSX(S4) RP02(S3) PXSX(S4) RP03(S3) PXSX(S4) RP04(S3) PXSX(S4) RP05(S3) PXSX(S4) RP06(S3) PXSX(S4) RP07(S3) PXSX(S4) RP08(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.86 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE, BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.61 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE, BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.61 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE, BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.61 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE, BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (RP01) acpiprt2 at acpi0: bus 6 (RP03) acpiprt3 at acpi0: bus 7 (RP04) acpiprt4 at acpi0: bus -1 (PEG0) acpiprt5 at acpi0: bus -1 (PEG1) acpiprt6 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 99 degC acpibat0 at acpi0: BAT0 model "DELL FW1MN31" serial 12909 type LION oem "SMP-SDI2.8" acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SBTN acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 1895 MHz: speeds: 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 779 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x0b vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x0b intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 *error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10* *error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns* *error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040* inteldrm0: 1600x900 wsdis
Re: help with bgpd error messages
On Thu, 7 May 2015 13:01:49 +0200 Marko Cupać wrote: > On Wed, 6 May 2015 10:53:38 + (UTC) > Stuart Henderson wrote: > > > Can you get a packet capture of TCP port 179 during a failure? > > > > tcpdump -i -w bgp.`date +%Y%m%d-%H%M`.pcap -s1500 tcp > > and port 179 > > > > It might be best to run it from a script run from cron which pkills > > tcpdump and rotates the file to avoid having huge files. > > I am capturing packets on interface facing problematic ISP, and I will > send pcap files if/when bgpd crashes again. > > > Any idea what software (version number may be relevant too) your > > neighbours are using? Or at least what hardware vendor shows up in > > their MAC address? > > Their MAC is 54:75:d0:45:8f:00 which appears to be Cisco. > > In the meantime I contacted this ISP's support and told them they are > crashing my bgpd, probably because they are sending me non-standard > bgp packets which do not start with all-ones, as the standard > requires. The guy didn't have much idea what I was speaking about, > but he said he will forward request to network engineers. An hour > later he contacted me back, saying that "they indeed found some > irregularities which are now fixed". He couldn't give me the details. > > If my bgpd crashes again I will have pcap files ready. Also, if there > is anything else I can do to help troubleshoot this I'd be glad to > participate. > > Regards, I dropped by just to say that I haven't given this up, but I haven't replied anything because I had no bgpd crashes since my last email. Probably ISP indeed fixed their part of not sending me garbage. I also have been capturing bgp packets, and will continue to do so until the end of the month in case I get another crash. -- Marko Cupać https://www.mimar.rs
Re: help with bgpd error messages
On Wed, 6 May 2015 10:53:38 + (UTC) Stuart Henderson wrote: > Can you get a packet capture of TCP port 179 during a failure? > > tcpdump -i -w bgp.`date +%Y%m%d-%H%M`.pcap -s1500 tcp and > port 179 > > It might be best to run it from a script run from cron which pkills > tcpdump and rotates the file to avoid having huge files. I am capturing packets on interface facing problematic ISP, and I will send pcap files if/when bgpd crashes again. > Any idea what software (version number may be relevant too) your > neighbours are using? Or at least what hardware vendor shows up in > their MAC address? Their MAC is 54:75:d0:45:8f:00 which appears to be Cisco. In the meantime I contacted this ISP's support and told them they are crashing my bgpd, probably because they are sending me non-standard bgp packets which do not start with all-ones, as the standard requires. The guy didn't have much idea what I was speaking about, but he said he will forward request to network engineers. An hour later he contacted me back, saying that "they indeed found some irregularities which are now fixed". He couldn't give me the details. If my bgpd crashes again I will have pcap files ready. Also, if there is anything else I can do to help troubleshoot this I'd be glad to participate. Regards, -- Marko Cupać https://www.mimar.rs
Re: help with bgpd error messages
On Wed, May 06, 2015 at 03:10:44PM +0200, Henning Brauer wrote: > * Marko Cupa?? [2015-05-06 12:01]: > > I am on 5.7 release + errata patches now, and bgpd crashed again: > > > > May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sync error > > > I guess bug is not solved in 5.7 release then. Maybe 5.7 stable? > > Sigh. THERE IS NO BUG. > > As I told you before, sync error means the first 16 bytes of the BGP > message aren't all-ones as required by the Standards. Either the > equipment on the other side is severly broken or something is very > screwed up with the network in between. > > > bgp packets. Regardless of that, I think bgpd shouldn't just shutdown > > itself no matter what payload it gets? > > the later shutdown indeed shouldn't happen. > Yes, that is the bug. I think we fixed some time ago but now I need to double check what happened there. It seems there is still an issue with graceful restart and some peer state transitions. Time to rethink all of this... -- :wq Claudio
Re: help with bgpd error messages
* Marko Cupać [2015-05-06 12:01]: > I am on 5.7 release + errata patches now, and bgpd crashed again: > > May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sync error > I guess bug is not solved in 5.7 release then. Maybe 5.7 stable? Sigh. THERE IS NO BUG. As I told you before, sync error means the first 16 bytes of the BGP message aren't all-ones as required by the Standards. Either the equipment on the other side is severly broken or something is very screwed up with the network in between. > bgp packets. Regardless of that, I think bgpd shouldn't just shutdown > itself no matter what payload it gets? the later shutdown indeed shouldn't happen. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: help with bgpd error messages
On 2015-05-06, Marko Cupać wrote: > On Wed, 29 Apr 2015 11:02:09 +0200 > Marko Cupać wrote: > >> On Tue, 28 Apr 2015 15:11:21 +0200 >> Claudio Jeker wrote: >> >> > The "fatal in RDE: peer_up: bad state" bug is fixed in 5.7 IIRC. Not >> > sure if it was backported to 5.6. As a workaround you can disable >> > the graceful restart capability to not trigger that code path. >> >> I was intending to upgrade on Friday anyway so no problem. In the >> meantime I updated to -stable, it's too early to say if it fixed it. > > I am on 5.7 release + errata patches now, and bgpd crashed again: > > May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sync error > May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sending > notification: Header error, synchronization error > May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): graceful > restart of IPv4 unicast, keeping routes Can you get a packet capture of TCP port 179 during a failure? tcpdump -i -w bgp.`date +%Y%m%d-%H%M`.pcap -s1500 tcp and port 179 It might be best to run it from a script run from cron which pkills tcpdump and rotates the file to avoid having huge files. You can review the files with 'tcpdump -nvvr [filename]', but the raw pcap files (and time of the failure as shown in logs) are more useful for anyone else looking into this. > I guess bug is not solved in 5.7 release then. Maybe 5.7 stable? No changes to bgpd in 5.7-stable. (There were some changes in -current but they won't affect this). > This issue is having really bad impact on my network. Both ISP links > are up and running, but - as bgpd dies - my firewall has no routes > which effectively stops the traffic flow with the Internet. > > I have contacted ISPs and ask them to check if they are sending us bad > bgp packets. Regardless of that, I think bgpd shouldn't just shutdown > itself no matter what payload it gets? There are two parts to this. One is it seems there is a bad BGP message hitting the parser in bgpd. Most likely it comes from the peer (though I haven't looked at the code deeply enough to rule out other possibilities). Every BGP message is supposed to start with 16 0xff bytes, this "sync error" log message is only triggered when a message is seen which does not have this. When this happens it is correct that the *peer* is taken down as there is some major problem. A packet trace with the right parts in it should confirm whether the problem is with a message from the peer or internal to bgpd. The other part is that it's triggering bgpd exiting. That's not good. > Any help with this would be highly appreciated. Any idea what software (version number may be relevant too) your neighbours are using? Or at least what hardware vendor shows up in their MAC address? pkg_add maclookup arp -an | grep | maclookup
Re: help with bgpd error messages
On Wed, 29 Apr 2015 11:02:09 +0200 Marko Cupać wrote: > On Tue, 28 Apr 2015 15:11:21 +0200 > Claudio Jeker wrote: > > > The "fatal in RDE: peer_up: bad state" bug is fixed in 5.7 IIRC. Not > > sure if it was backported to 5.6. As a workaround you can disable > > the graceful restart capability to not trigger that code path. > > I was intending to upgrade on Friday anyway so no problem. In the > meantime I updated to -stable, it's too early to say if it fixed it. I am on 5.7 release + errata patches now, and bgpd crashed again: May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sync error May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Established -> Idle, reason: Fatal error May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Idle -> Connect, reason: Start May 6 10:06:07 bgp1 bgpd[3820]: incremented the demote state of group 'carp' May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened May 6 10:06:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change OpenSent -> Active, reason: Connection closed May 6 10:06:08 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, attribute length wrong May 6 10:06:08 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Active -> Idle, reason: Fatal error May 6 10:06:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Idle -> Connect, reason: Start May 6 10:06:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened May 6 10:06:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change OpenSent -> Active, reason: Connection closed May 6 10:08:07 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, time-out, flushing May 6 10:08:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Active -> Connect, reason: ConnectRetryTimer expired May 6 10:08:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened May 6 10:08:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change OpenSent -> OpenConfirm, reason: OPEN message received May 6 10:08:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change OpenConfirm -> Established, reason: KEEPALIVE message received May 6 10:08:38 bgp1 bgpd[31241]: fatal in RDE: peer_up: bad state May 6 10:08:38 bgp1 bgpd[3820]: dispatch_imsg in main: pipe closed May 6 10:08:38 bgp1 bgpd[3820]: decremented the demote state of group 'carp' May 6 10:08:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down May 6 10:08:38 bgp1 bgpd[11681]: neighbor 82.117.192.121 (sbb): state change Established -> Idle, reason: Stop May 6 10:08:38 bgp1 bgpd[11681]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down May 6 10:08:38 bgp1 bgpd[11681]: neighbor 178.253.194.253 (orion): state change Established -> Idle, reason: Stop May 6 10:08:38 bgp1 bgpd[11681]: session engine exiting May 6 10:08:40 bgp1 bgpd[3820]: kernel routing table 0 (Loc-RIB) decoupled May 6 10:08:40 bgp1 bgpd[3820]: Terminating I guess bug is not solved in 5.7 release then. Maybe 5.7 stable? This issue is having really bad impact on my network. Both ISP links are up and running, but - as bgpd dies - my firewall has no routes which effectively stops the traffic flow with the Internet. I have contacted ISPs and ask them to check if they are sending us bad bgp packets. Regardless of that, I think bgpd shouldn't just shutdown itself no matter what payload it gets? Any help with this would be highly appreciated. -- Marko Cupać https://www.mimar.rs
Re: help with bgpd error messages
On Tue, 28 Apr 2015 15:11:21 +0200 Claudio Jeker wrote: > The "fatal in RDE: peer_up: bad state" bug is fixed in 5.7 IIRC. Not > sure if it was backported to 5.6. As a workaround you can disable the > graceful restart capability to not trigger that code path. I was intending to upgrade on Friday anyway so no problem. In the meantime I updated to -stable, it's too early to say if it fixed it. Thank you, -- Marko Cupać https://www.mimar.rs
Re: help with bgp error messages
* Marko Cupać [2015-04-28 19:06]: > Few days ago I had Internet outage (first in years), which appear to > happen as a result of bgpd crash. I could ping ISP's interface, but > then i noticed i have no routes at all (except connected ones) in > routing table. Next, I discovered there is no bgpd running process. > Restarting bgpd gave me routes and Internet connectivity back. > > Here's excerpt from messages log: > > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error you have some severe errors somewhere between the network and bgpd, or the remote bgpd is severely broken. By definition, the first 16 bytes of a bgp packet have all bits set. this is not the case here. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
help with bgp error messages
Hi, I have a pair of OpenBSD 5.6 firewalls running releases happily for years (I think since 5.1). They are in CARP failover mode, running bgp sessions with upstrem providers and filtering traffic. Few days ago I had Internet outage (first in years), which appear to happen as a result of bgpd crash. I could ping ISP's interface, but then i noticed i have no routes at all (except connected ones) in routing table. Next, I discovered there is no bgpd running process. Restarting bgpd gave me routes and Internet connectivity back. Here's excerpt from messages log: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Also from daemon log at the same time: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established -> Idle, reason: Fatal error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle -> Connect, reason: Start Apr 17 18:29:18 bgp2 bgpd[32268]: incremented the demote state of group 'carp' Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent -> Active, reason: Connection closed Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Active -> Idle, reason: Fatal error Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle -> Connect, reason: Start Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent -> OpenConfirm, reason: OPEN message received Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenConfirm -> Established, reason: KEEPALIVE message received Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[32268]: decremented the demote state of group 'carp' Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established -> Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): state change Established -> Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: session engine exiting Apr 17 18:29:54 bgp2 bgpd[32268]: kernel routing table 0 (Loc-RIB) decoupled Apr 17 18:29:55 bgp2 bgpd[32268]: Terminating I would be grateful if someone explained me me what happened here, and also what to do in order to avoid it in the future. Thank you in advance, -- Marko Cupać https://www.mimar.rs
Re: help with bgpd error messages
On Tue, Apr 28, 2015 at 11:28:31AM +0200, Marko Cupa?? wrote: > Hi, > > I have a pair of OpenBSD 5.6 firewalls running releases happily for > years (I think since 5.1). They are in CARP failover mode, running bgp > sessions with upstrem providers and filtering traffic. > > Few days ago I had Internet outage (first in years), which appear to > happen as a result of bgpd crash. I could ping ISP's interface, but > then i noticed i have no routes at all (except connected ones) in > routing table. Next, I discovered there is no bgpd running process. > Restarting bgpd gave me routes and Internet connectivity back. > > Here's excerpt from messages log: > > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending > notification: Header error, synchronization error > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful > restart of IPv4 unicast, keeping routes > Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri > prefix > Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending > notification: error in UPDATE message, network unacceptable > Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful > restart of IPv4 unicast, not restarted, flushing > Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state > Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed > Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending > notification: Cease, administratively down > Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending > notification: Cease, administratively down > > > Also from daemon log at the same time: > > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending > notification: Header error, synchronization error > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful > restart of IPv4 unicast, keeping routes > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Established -> Idle, reason: Fatal error > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Idle -> Connect, reason: Start > Apr 17 18:29:18 bgp2 bgpd[32268]: incremented the demote state of group 'carp' > Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri > prefix > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Connect -> OpenSent, reason: Connection opened > Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > OpenSent -> Active, reason: Connection closed > Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending > notification: error in UPDATE message, network unacceptable > Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Active -> Idle, reason: Fatal error > Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Idle -> Connect, reason: Start > Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Connect -> OpenSent, reason: Connection opened > Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful > restart of IPv4 unicast, not restarted, flushing > Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > OpenSent -> OpenConfirm, reason: OPEN message received > Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > OpenConfirm -> Established, reason: KEEPALIVE message received > Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state > Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed > Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending > notification: Cease, administratively down > Apr 17 18:29:52 bgp2 bgpd[32268]: decremented the demote state of group 'carp' > Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change > Established -> Idle, reason: Stop > Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending > notification: Cease, administratively down > Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): state > change Established -> Idle, reason: Stop > Apr 17 18:29:52 bgp2 bgpd[9759]: session engine exiting > Apr 17 18:29:54 bgp2 bgpd[32268]: kernel routing table 0 (Loc-RIB) decoupled > Apr 17 18:29:55 bgp2 bgpd[32268]: Terminating > > > I would be grateful if someone explained me me what happened here, and > also what to do in order to avoid it in the future. > The "fatal in RDE: peer_up: bad state" bug is fixed in 5.7 IIRC. Not sure if it was backported to 5.6. As a workaround you can disable the graceful restart capability to not trigger that code path. Hope that helps. -- :wq Claudio
help with bgpd error messages
Hi, I have a pair of OpenBSD 5.6 firewalls running releases happily for years (I think since 5.1). They are in CARP failover mode, running bgp sessions with upstrem providers and filtering traffic. Few days ago I had Internet outage (first in years), which appear to happen as a result of bgpd crash. I could ping ISP's interface, but then i noticed i have no routes at all (except connected ones) in routing table. Next, I discovered there is no bgpd running process. Restarting bgpd gave me routes and Internet connectivity back. Here's excerpt from messages log: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Also from daemon log at the same time: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established -> Idle, reason: Fatal error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle -> Connect, reason: Start Apr 17 18:29:18 bgp2 bgpd[32268]: incremented the demote state of group 'carp' Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent -> Active, reason: Connection closed Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Active -> Idle, reason: Fatal error Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle -> Connect, reason: Start Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect -> OpenSent, reason: Connection opened Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent -> OpenConfirm, reason: OPEN message received Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenConfirm -> Established, reason: KEEPALIVE message received Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[32268]: decremented the demote state of group 'carp' Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established -> Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): state change Established -> Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: session engine exiting Apr 17 18:29:54 bgp2 bgpd[32268]: kernel routing table 0 (Loc-RIB) decoupled Apr 17 18:29:55 bgp2 bgpd[32268]: Terminating I would be grateful if someone explained me me what happened here, and also what to do in order to avoid it in the future. Thank you in advance, -- Marko Cupać https://www.mimar.rs
relayd, how to customize error messages?
Hello, Is there any way to customize the blank screen if the relayd address is down? Also, if I do some layer 7 filtering and use label "something" .. isnt there a way to customize that page also? For example remove the operatin system name. I tried it with response header change "relayd" to "xxx" but that only modified the relayd address webserver and not the relayd error messages. Thank you. David
Re: Error messages from bridge machines
On Wed, Oct 28, 2009 at 06:40:41AM -0500, stan wrote: > I have 2 OpenBSD machines providing a bridge between 2 physical locations > for a specific subnet. Last night, I got the following error messages on > them: > > Oct 28 07:23:13 pb48 isakmpd[11605]: message_recv: invalid cookie(s) > +0e113721bf798717 6b4e0004066c308e > Oct 28 07:23:13 pb48 isakmpd[11605]: dropped message from 10.209.120.15 > port 500 > +due to notification type INVALID_COOKIE > > and on the other: > > Oct 28 07:23:13 pblab isakmpd[2851]: message_recv: invalid cookie(s) > +0e113721bf798717 6b4e0004066c308e > Oct 28 07:23:13 pblab isakmpd[2851]: dropped message from 10.209.142.156 > port > +500 due to notification type INVALID_COOKIE > > Would I be correct in assuming thta these indicate packet coruption on the > network connecting these 2 machines? > > BTW, we have been having a lot of trouble with UDP based protocols here, I > have even switched NFS over to TCP to try to work around this. Is this > error UDP? Or TCP? Without NAT-traversal, which does use UDP, IPv4 IPsec uses a special IP protocol (that is, a "sibling" of TCP, not a "child"). See `grep IPSEC /etc/protocols`. I'm not sure what caused that message, although corrupted packets might be a possibility. You should look into that, really - networks shouldn't randomly corrupt packets. (Are you aware that ping(8) takes -p and -s options?) Joachim
Error messages from bridge machines
I have 2 OpenBSD machines providing a bridge between 2 physical locations for a specific subnet. Last night, I got the following error messages on them: Oct 28 07:23:13 pb48 isakmpd[11605]: message_recv: invalid cookie(s) +0e113721bf798717 6b4e0004066c308e Oct 28 07:23:13 pb48 isakmpd[11605]: dropped message from 10.209.120.15 port 500 +due to notification type INVALID_COOKIE and on the other: Oct 28 07:23:13 pblab isakmpd[2851]: message_recv: invalid cookie(s) +0e113721bf798717 6b4e0004066c308e Oct 28 07:23:13 pblab isakmpd[2851]: dropped message from 10.209.142.156 port +500 due to notification type INVALID_COOKIE Would I be correct in assuming thta these indicate packet coruption on the network connecting these 2 machines? BTW, we have been having a lot of trouble with UDP based protocols here, I have even switched NFS over to TCP to try to work around this. Is this error UDP? Or TCP? -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Realtek 8169 chip PCMCIA network card error messages
Hi!
When I plug in a Linksys PCM1000 Gigabit Network card to my PCMCIA slot, I can
see these messages in dmesg:
re0 at cardbus0 dev 0 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB
(0x1000), irq 268505099, address 00:12:17:f0:c8:21
re0: PHY write failed
re0: PHY write failed
re0: PHY read failed
re0: no PHY found!
I don't know if related to this, but it works only at 100Mbit. Is this card
unsupported at Gbit, or do I have to configure something to make it work?
Also, what does the above error message mean, and what is that weird irq
number?
Any information would be appreciated, thanks!
I'm using -current, and here is my dmesg:
OpenBSD 4.5-current (GENERIC.MP) #13: Wed May 20 15:10:35 MDT 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A
CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR
real mem = 1072066560 (1022MB)
avail mem = 1028255744 (980MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/02/06, BIOS32 rev. 0 @ 0xfd6b0,
SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "79ET66WW (1.10 )" date 08/02/2006
bios0: LENOVO 2007FRG
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4)
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(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 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A
CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2
acpicpu1 at acpi0: C3, C2
acpitz0 at acpi0: critical temperature 127 degC
acpitz1 at acpi0: critical temperature 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4511" serial 21826 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
acpidock at acpi0 not configured
acpivideo at acpi0 not configured
acpivideo at acpi0 not configured
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000!
0xe/0x1
cpu0: unknown Enhanced SpeedStep CPU, msr 0x06130b2c06000613
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1000 MHz (1004 mV): speeds: 1833, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
(irq 11)
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1400" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 1 int 16 (irq 11)
drm0 at radeondrm0
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: apic 1
int 17 (irq 11)
azalia0: RIRB time out
azalia0: codecs: Analog Devices AD1981HD, 0x/0x, using Analog Devices
AD1981HD
azalia0: RIRB time out
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
(irq 11)
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 1 int
16 (irq 11), address 00:16:41:aa:d2:70
ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
(irq 11)
pci3 at ppb2 bus 3
wpi0 at pci3 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: apic 1
int 17 (irq 11), MoW2, address 00:18:de:65:2d:37
ppb3 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
(irq 11)
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
(irq 11)
pci5 at ppb4 bus 12
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
(irq 11)
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
(irq 11)
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
(irq 11)
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
(irq 11)
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
(irq 11)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb5 at pci0 dev 30 functio
Re: error messages
On Mon, 2005-05-16 at 22:34 +0200, Stefan Kell wrote: > Hi, > > I would change the sshd-port from 22 to something different. This way the > attack would run into nirvana. ListenAddress your.ip.address:new_port > And of course disallow root access in sshd_conf. PermitRootLogin no ryanc
Re: error messages
Hi, I would change the sshd-port from 22 to something different. This way the attack would run into nirvana. And of course disallow root access in sshd_conf. Regards Stefan Kell On Mon, 16 May 2005, Kaj Mdkinen wrote: > I connect to my firewall with putty. How can I get rid of messages like > these from > appearing in my ssh terminal session? These appeared twice a second so > it is wery hard to > work with the console. > (It was obviously someone trying to get access to something?) > > May 16 18:30:05 localhost sshd[21201]: Failed password for root from > 64.42.53.150 port 48385 ssh2 > May 16 18:30:06 localhost sshd[21201]: Received disconnect from > 64.42.53.150: 11: Bye Bye > May 16 18:30:08 localhost sshd[12553]: Failed password for root from > 64.42.53.150 port 48446 ssh2 > May 16 18:30:08 localhost sshd[12553]: Received disconnect from > 64.42.53.150: 11: Bye Bye > May 16 18:30:11 localhost sshd[23351]: Failed password for root from > 64.42.53.150 port 48543 ssh2 > May 16 18:30:11 localhost sshd[23351]: Received disconnect from > 64.42.53.150: 11: Bye Bye > May 16 18:30:14 localhost sshd[13243]: Failed password for root from > 64.42.53.150 port 48628 ssh2
Re: error messages
At 11:45 AM 5/16/05, Kaj Mdkinen wrote: I connect to my firewall with putty. How can I get rid of messages like these from appearing in my ssh terminal session? These appeared twice a second so it is wery hard to work with the console. (It was obviously someone trying to get access to something?) May 16 18:30:05 localhost sshd[21201]: Failed password for root from 64.42.53.150 port 48385 ssh2 Don't login as root.
Re: error messages
On Mon, 16 May 2005 18:45:29 +0300, Kaj Mdkinen <[EMAIL PROTECTED]> wrote: >I connect to my firewall with putty. How can I get rid of messages like >these from >appearing in my ssh terminal session? These appeared twice a second so >it is wery hard to >work with the console. >(It was obviously someone trying to get access to something?) > >May 16 18:30:05 localhost sshd[21201]: Failed password for root from >64.42.53.150 port 48385 ssh2 >May 16 18:30:06 localhost sshd[21201]: Received disconnect from >64.42.53.150: 11: Bye Bye >May 16 18:30:08 localhost sshd[12553]: Failed password for root from >64.42.53.150 port 48446 ssh2 >May 16 18:30:08 localhost sshd[12553]: Received disconnect from >64.42.53.150: 11: Bye Bye >May 16 18:30:11 localhost sshd[23351]: Failed password for root from >64.42.53.150 port 48543 ssh2 >May 16 18:30:11 localhost sshd[23351]: Received disconnect from >64.42.53.150: 11: Bye Bye >May 16 18:30:14 localhost sshd[13243]: Failed password for root from >64.42.53.150 port 48628 ssh2 First of all, do not log in as root. Use sudo. And if you're smart, disable root ssh access. Second, the messages are the result of a brute force attack on your system. They are most likely going after your root password since you have ssh for it enabled. Add the offenders IP address to your pf block list. JCR
Re: error messages
On 2005-05-16 at 17:45:29 Kaj Mdkinen wrote: > I connect to my firewall with putty. How can I get rid of messages > like these from appearing in my ssh terminal session? These appeared > twice a second so it is wery hard to work with the console. (It was > obviously someone trying to get access to something?) - Fix your syslog.conf - Don't login as root, use sudo - Add those script kiddies and worms to your blacklist(s) [demime 1.01d removed an attachment of type application/pgp-signature]
Re: error messages
On 5/16/05, Ryan Corder <[EMAIL PROTECTED]> wrote: > On Mon, 2005-05-16 at 18:45 +0300, Kaj Mdkinen wrote: > > I connect to my firewall with putty. How can I get rid of messages like > > these from > > appearing in my ssh terminal session? > > check your /etc/syslog.conf to see if errors, etc are being sent to > specific users. by default, *.errors, *.notice, auth.debug, and > *.alert are sent to root and *.emerg syslog entries are sent to > everyone. > > ryanc > > Or you could try working from another terminal, if you are not logged in as root. -- Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped
Re: error messages
On Mon, 2005-05-16 at 18:45 +0300, Kaj Mdkinen wrote: > I connect to my firewall with putty. How can I get rid of messages like > these from > appearing in my ssh terminal session? check your /etc/syslog.conf to see if errors, etc are being sent to specific users. by default, *.errors, *.notice, auth.debug, and *.alert are sent to root and *.emerg syslog entries are sent to everyone. ryanc
error messages
I connect to my firewall with putty. How can I get rid of messages like these from appearing in my ssh terminal session? These appeared twice a second so it is wery hard to work with the console. (It was obviously someone trying to get access to something?) May 16 18:30:05 localhost sshd[21201]: Failed password for root from 64.42.53.150 port 48385 ssh2 May 16 18:30:06 localhost sshd[21201]: Received disconnect from 64.42.53.150: 11: Bye Bye May 16 18:30:08 localhost sshd[12553]: Failed password for root from 64.42.53.150 port 48446 ssh2 May 16 18:30:08 localhost sshd[12553]: Received disconnect from 64.42.53.150: 11: Bye Bye May 16 18:30:11 localhost sshd[23351]: Failed password for root from 64.42.53.150 port 48543 ssh2 May 16 18:30:11 localhost sshd[23351]: Received disconnect from 64.42.53.150: 11: Bye Bye May 16 18:30:14 localhost sshd[13243]: Failed password for root from 64.42.53.150 port 48628 ssh2
