Re: hardware problem?! strangely ssh error
Hi Hagen, snip Hope that helps ... Regards Hagen Volpers Is your sshd-config different/modified? If your ssh client can't talk to your own ssh daemon, might indicate they don't understand each other and using different crypto. Maxim
Re: hardware problem?! strangely ssh error - SOLVED
-Urspr|ngliche Nachricht- Von: Stuart Henderson [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 20. Juli 2007 01:22 An: openbsd misc Betreff: Re: hardware problem?! strangely ssh error On 2007/07/20 00:02, Stuart Henderson wrote: If there might be crypto hardware onboard, try sysctl kern.usercrypto=0 The chip is detected as supporting AES, which gets used for ssh with default ciphers. Definitely try this sysctl (takes effect straight away) and if it helps please report back on misc@, if AES is detected incorrectly it would be useful to work out a way to identify and disable it.. Thanks a lot, that solved the problem. Regards Hagen Volpers
Re: hardware problem?! strangely ssh error
On Thu, 19 Jul 2007, openbsd misc wrote: misc(at)openbsd.org wrote: Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect to the system, too. The error I got: 2: Bad packet length integer I googled a bit, but I wasn't able to find out what exactly is wrong. Here are the informations from dmesg about the nics: sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd Btw, I'm talking about a fresh 4.1 installation, completly untouched. Has anyone an idea for me? Driver problem? Unsupported hardware? The hardware was checked twice by producer (and I don't have the problems using linux), I don't think that is a hardware defect. Thanks. Regards Hagen Volpers Have you tried: ssh -vvv host.to.connect.to That might give some clues. HTH Fred -- http://www.crowsons.com/puters/x41.htm Hello, here are the last lines: debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent followed by the error mentioned in my first mail. Does that help? Do you need more informations? Regards Hagen Volpers Try to determine where the error occurs. For example: is this a network driver issue? To find out put another type network card into the machine and try to use ssh over it. Another test would be to connect to another machine (running a different version of sshd?), to test if this is a ssh protcol problem on the local or remote side. Can you ssh INTO the machine? Make notes of what works and what not, etc. Try to be smart and rule out possible causes, this enable you to zoom in into the real problem. -Otto
Re: hardware problem?! strangely ssh error
On Thu, 19 Jul 2007, openbsd misc wrote: misc(at)openbsd.org wrote: Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect to the system, too. The error I got: 2: Bad packet length integer I googled a bit, but I wasn't able to find out what exactly is wrong. Here are the informations from dmesg about the nics: sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd Btw, I'm talking about a fresh 4.1 installation, completly untouched. Has anyone an idea for me? Driver problem? Unsupported hardware? The hardware was checked twice by producer (and I don't have the problems using linux), I don't think that is a hardware defect. Thanks. Regards Hagen Volpers Have you tried: ssh -vvv host.to.connect.to That might give some clues. HTH Fred -- http://www.crowsons.com/puters/x41.htm Hello, here are the last lines: debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent followed by the error mentioned in my first mail. Does that help? Do you need more informations? Regards Hagen Volpers Try to determine where the error occurs. For example: is this a network driver issue? To find out put another type network card into the machine and try to use ssh over it. Another test would be to connect to another machine (running a different version of sshd?), to test if this is a ssh protcol problem on the local or remote side. Can you ssh INTO the machine? Make notes of what works and what not, etc. Try to be smart and rule out possible causes, this enable you to zoom in into the real problem. -Otto Hello, unfortunately I'm not able to test another nic, the system doesn't have a pci slot (we are talking about a all-in-one board - e.g. http://www.visionsystems.de/1_2_5_4.html). I already did all the other tests you mentioned, except changing the ssh protocol - lynx / ping works, ssh from to machine to different machines doesn't work (I can connect from other systems without any problem), ssh to the machine doesn't work, too. Any other ideas? Regards Hagen Volpers
Re: hardware problem?! strangely ssh error
Hello, putting that one back to list, it's not silly ;-) I tried ssh [EMAIL PROTECTED] - same result. So the nic isn't the problem ... I looked into dmesg again, the bios is mentioned as AT/286+ there?! Is that normal? Btw, the IP-Address is unique ;-) Are there known bugs on VIA-CPUs? Which informations do I need to provide? (dmesg is hard, I have to write it up, but if that helps, let me know and I'll do it). Regards Hagen Volpers -Urspr|ngliche Nachricht- Von: Maxim Belooussov [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 19. Juli 2007 21:38 An: openbsd misc Betreff: Re: hardware problem?! strangely ssh error Hi Hagen, Doing this off-the list in case I sound too silly. For starters, have you tried to ssh [EMAIL PROTECTED] This would give a clue where the problem could be. Further make sure that there is no machine with the same ip on your net - I've seen before that some connections were 'dying' all over sudden when another (linux) box with same IP was closing 'illegal' connection. Hope it helps, Maxim On Thu, 19 Jul 2007, openbsd misc wrote: misc(at)openbsd.org wrote: Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect to the system, too. The error I got: 2: Bad packet length integer I googled a bit, but I wasn't able to find out what exactly is wrong. Here are the informations from dmesg about the nics: sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd Btw, I'm talking about a fresh 4.1 installation, completly untouched. Has anyone an idea for me? Driver problem? Unsupported hardware? The hardware was checked twice by producer (and I don't have the problems using linux), I don't think that is a hardware defect. Thanks. Regards Hagen Volpers Have you tried: ssh -vvv host.to.connect.to That might give some clues. HTH Fred -- http://www.crowsons.com/puters/x41.htm Hello, here are the last lines: debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent followed by the error mentioned in my first mail. Does that help? Do you need more informations? Regards Hagen Volpers Try to determine where the error occurs. For example: is this a network driver issue? To find out put another type network card into the machine and try to use ssh over it. Another test would be to connect to another machine (running a different version of sshd?), to test if this is a ssh protcol problem on the local or remote side. Can you ssh INTO the machine? Make notes of what works and what not, etc. Try to be smart and rule out possible causes, this enable you to zoom in into the real problem. -Otto Hello, unfortunately I'm not able to test another nic, the system doesn't have a pci slot (we are talking about a all-in-one board - e.g. http://www.visionsystems.de/1_2_5_4.html). I already did all the other tests you mentioned, except changing the ssh protocol - lynx / ping works, ssh from to machine to different machines doesn't work (I can connect from other systems without any problem), ssh to the machine doesn't work, too. Any other ideas? Regards Hagen Volpers
Re: hardware problem?! strangely ssh error
HID v1.00 Mouse [USBPS2] on usb-:00:07.2-2 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver sl811: driver sl811-hcd, 19 May 2005 ieee1394: Initialized config rom entry `ip1394' ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) ieee1394: sbp2: Try serialize_io=0 for better performance libata version 2.00 loaded. device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised: [EMAIL PROTECTED] md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 JFS: nTxBlock = 3966, nTxLock = 31734 Intel(R) PRO/1000 Network Driver - version 7.2.9-k4 Copyright (c) 1999-2006 Intel Corporation. scsi 0:0:0:0: CD-ROMIOMEGA CDRW86522EXT3-B QOP3 PQ: 0 ANSI: 0 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 usb-storage: device scan complete ISO 9660 Extensions: Microsoft Joliet Level 3 Unable to load NLS charset iso8859-1 Unable to load NLS charset iso8859-1 ISO 9660 Extensions: RRIP_1991A Real Time Clock Driver v1.12ac natsemi dp8381x driver, version 2.1, Sept 11, 2006 originally by Donald Becker [EMAIL PROTECTED] http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder PCI: setting IRQ 11 as level-triggered PCI: Found IRQ 11 for device :00:08.0 natsemi eth0: NatSemi DP8381[56] at 0xd000 (:00:08.0), 00:02:b6:33:50:dd, IRQ 11, port TP. PCI: setting IRQ 12 as level-triggered PCI: Found IRQ 12 for device :00:09.0 natsemi eth1: NatSemi DP8381[56] at 0xdfffe000 (:00:09.0), 00:02:b6:33:50:de, IRQ 12, port TP. PCI: setting IRQ 9 as level-triggered PCI: Found IRQ 9 for device :00:0a.0 natsemi eth2: NatSemi DP8381[56] at 0xdfffd000 (:00:0a.0), 00:02:b6:33:50:df, IRQ 9, port TP. PCI: Found IRQ 10 for device :00:0b.0 PCI: Sharing IRQ 10 with :00:07.2 natsemi eth3: NatSemi DP8381[56] at 0xdfffc000 (:00:0b.0), 00:02:b6:33:50:e0, IRQ 10, port TP. natsemi dp8381x driver, version 2.1, Sept 11, 2006 originally by Donald Becker [EMAIL PROTECTED] http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder natsemi eth0: NatSemi DP8381[56] at 0xd000 (:00:08.0), 00:02:b6:33:50:dd, IRQ 11, port TP. natsemi eth1: NatSemi DP8381[56] at 0xdfffe000 (:00:09.0), 00:02:b6:33:50:de, IRQ 12, port TP. natsemi eth2: NatSemi DP8381[56] at 0xdfffd000 (:00:0a.0), 00:02:b6:33:50:df, IRQ 9, port TP. natsemi eth3: NatSemi DP8381[56] at 0xdfffc000 (:00:0b.0), 00:02:b6:33:50:e0, IRQ 10, port TP. sr 0:0:0:0: Attached scsi generic sg0 type 5 eth1: DSPCFG accepted after 0 usec. eth3: DSPCFG accepted after 0 usec. eth2: DSPCFG accepted after 0 usec. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. eth3: remaining active for wake-on-lan eth1: remaining active for wake-on-lan eth0: remaining active for wake-on-lan fbsplash: console 0 using theme 'livecd-2006.1' eth2: remaining active for wake-on-lan fbsplash: switched splash state to 'on' on console 0 eth2: DSPCFG accepted after 0 usec. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. eth3: DSPCFG accepted after 0 usec. eth1: DSPCFG accepted after 0 usec. Regards Hagen Volpers -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von openbsd misc Gesendet: Donnerstag, 19. Juli 2007 22:19 An: misc@openbsd.org Cc: Maxim Belooussov Betreff: Re: hardware problem?! strangely ssh error Hello, putting that one back to list, it's not silly ;-) I tried ssh [EMAIL PROTECTED] - same result. So the nic isn't the problem ... I looked into dmesg again, the bios is mentioned as AT/286+ there?! Is that normal? Btw, the IP-Address is unique ;-) Are there known bugs on VIA-CPUs? Which informations do I need to provide? (dmesg is hard, I have to write it up, but if that helps, let me know and I'll do it). Regards Hagen Volpers -Urspr|ngliche Nachricht- Von: Maxim Belooussov [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 19. Juli 2007 21:38 An: openbsd misc Betreff: Re: hardware problem?! strangely ssh error Hi Hagen, Doing this off-the list in case I sound too silly. For starters, have you tried to ssh [EMAIL PROTECTED] This would give a clue where the problem could be. Further make sure that there is no machine with the same ip on your net - I've seen before that some connections were 'dying' all over sudden when another (linux) box with same IP was closing 'illegal' connection. Hope it helps, Maxim On Thu, 19 Jul 2007, openbsd misc wrote: misc(at)openbsd.org wrote: Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect
Re: hardware problem?! strangely ssh error
/input/input1 input: USB HID v1.00 Mouse [USBPS2] on usb-:00:07.2-2 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver sl811: driver sl811-hcd, 19 May 2005 ieee1394: Initialized config rom entry `ip1394' ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) ieee1394: sbp2: Try serialize_io=0 for better performance libata version 2.00 loaded. device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised: [EMAIL PROTECTED] md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 JFS: nTxBlock = 3966, nTxLock = 31734 Intel(R) PRO/1000 Network Driver - version 7.2.9-k4 Copyright (c) 1999-2006 Intel Corporation. scsi 0:0:0:0: CD-ROMIOMEGA CDRW86522EXT3-B QOP3 PQ: 0 ANSI: 0 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 usb-storage: device scan complete ISO 9660 Extensions: Microsoft Joliet Level 3 Unable to load NLS charset iso8859-1 Unable to load NLS charset iso8859-1 ISO 9660 Extensions: RRIP_1991A Real Time Clock Driver v1.12ac natsemi dp8381x driver, version 2.1, Sept 11, 2006 originally by Donald Becker [EMAIL PROTECTED] http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder PCI: setting IRQ 11 as level-triggered PCI: Found IRQ 11 for device :00:08.0 natsemi eth0: NatSemi DP8381[56] at 0xd000 (:00:08.0), 00:02:b6:33:50:dd, IRQ 11, port TP. PCI: setting IRQ 12 as level-triggered PCI: Found IRQ 12 for device :00:09.0 natsemi eth1: NatSemi DP8381[56] at 0xdfffe000 (:00:09.0), 00:02:b6:33:50:de, IRQ 12, port TP. PCI: setting IRQ 9 as level-triggered PCI: Found IRQ 9 for device :00:0a.0 natsemi eth2: NatSemi DP8381[56] at 0xdfffd000 (:00:0a.0), 00:02:b6:33:50:df, IRQ 9, port TP. PCI: Found IRQ 10 for device :00:0b.0 PCI: Sharing IRQ 10 with :00:07.2 natsemi eth3: NatSemi DP8381[56] at 0xdfffc000 (:00:0b.0), 00:02:b6:33:50:e0, IRQ 10, port TP. natsemi dp8381x driver, version 2.1, Sept 11, 2006 originally by Donald Becker [EMAIL PROTECTED] http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder natsemi eth0: NatSemi DP8381[56] at 0xd000 (:00:08.0), 00:02:b6:33:50:dd, IRQ 11, port TP. natsemi eth1: NatSemi DP8381[56] at 0xdfffe000 (:00:09.0), 00:02:b6:33:50:de, IRQ 12, port TP. natsemi eth2: NatSemi DP8381[56] at 0xdfffd000 (:00:0a.0), 00:02:b6:33:50:df, IRQ 9, port TP. natsemi eth3: NatSemi DP8381[56] at 0xdfffc000 (:00:0b.0), 00:02:b6:33:50:e0, IRQ 10, port TP. sr 0:0:0:0: Attached scsi generic sg0 type 5 eth1: DSPCFG accepted after 0 usec. eth3: DSPCFG accepted after 0 usec. eth2: DSPCFG accepted after 0 usec. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. eth3: remaining active for wake-on-lan eth1: remaining active for wake-on-lan eth0: remaining active for wake-on-lan fbsplash: console 0 using theme 'livecd-2006.1' eth2: remaining active for wake-on-lan fbsplash: switched splash state to 'on' on console 0 eth2: DSPCFG accepted after 0 usec. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. eth3: DSPCFG accepted after 0 usec. eth1: DSPCFG accepted after 0 usec. Regards Hagen Volpers -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von openbsd misc Gesendet: Donnerstag, 19. Juli 2007 22:19 An: misc@openbsd.org Cc: Maxim Belooussov Betreff: Re: hardware problem?! strangely ssh error Hello, putting that one back to list, it's not silly ;-) I tried ssh [EMAIL PROTECTED] - same result. So the nic isn't the problem ... I looked into dmesg again, the bios is mentioned as AT/286+ there?! Is that normal? Btw, the IP-Address is unique ;-) Are there known bugs on VIA-CPUs? Which informations do I need to provide? (dmesg is hard, I have to write it up, but if that helps, let me know and I'll do it). Regards Hagen Volpers Can you ftp the dmesg out? My answer to all dodgy hardware at the moment is enable acpi via boot -c HTH -- http://www.crowsons.com/puters/x41.htm
Re: hardware problem?! strangely ssh error
openbsd misc wrote: Hello again, I tested the gentoo live cd. I was able to ssh to another machine, so I was able to get a complete (linux) dmesg output. Hope that helps: [...] Regards Hagen Volpers -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von openbsd misc Gesendet: Donnerstag, 19. Juli 2007 22:19 An: misc@openbsd.org Cc: Maxim Belooussov Betreff: Re: hardware problem?! strangely ssh error Hello, putting that one back to list, it's not silly ;-) I tried ssh [EMAIL PROTECTED] - same result. So the nic isn't the problem ... I looked into dmesg again, the bios is mentioned as AT/286+ there?! Is that normal? Btw, the IP-Address is unique ;-) Are there known bugs on VIA-CPUs? Which informations do I need to provide? (dmesg is hard, I have to write it up, but if that helps, let me know and I'll do it). Regards Hagen Volpers Can you ftp the dmesg out? My answer to all dodgy hardware at the moment is enable acpi via boot -c HTH -- http://www.crowsons.com/puters/x41.htm Hello, acpi0 was disabled, but enabling it doesn't make any difference. Here is the openbsd dmesg output (after enableing acpi using config - forgot the good old apache, easier than setting up an ftp server on another machine ;-)): OpenBSD 4.1 (GENERIC) #1435: Sat Mar 10 19:07:45 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA Nehemiah (CentaurHauls 686-class) 1 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,CX8,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE cpu0: RNG AES real mem = 528052224 (515676K) avail mem = 474099712 (462988K) using 4278 buffers containing 26525696 bytes (25904K) of memory User Kernel Config UKC find acpi0 386 acpi0 at mainbus0 bus -1 flags 0x0 UKC quit Continuing... mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 11/27/03, BIOS32 rev. 0 @ 0xfdb30, SMBIOS rev. 2.3 @ 0xf0630 (24 entries) bios0: American Megatrends Inc. Uknown pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf8920/192 (10 entries) pcibios0: PCI Interrupt Router at 000:07:0 (VIA VT82C686 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xc000 0xcc000/0x1000 0xcd000/0x1000 0xce000/0x1000 0xcf000/0x1000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA VT8601 PCI rev 0x05 ppb0 at pci0 dev 1 function 0 VIA VT82C601 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 Trident CyberBlade i1 rev 0x6a wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev 0x40 pciide0 at pci0 dev 7 function 1 VIA VT82C571 IDE rev 0x06: ATA100, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: Maxtor 6E040L0 wd0: 16-sector PIO, LBA, 39205MB, 80293248 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) uhci0 at pci0 dev 7 function 2 VIA VT83C572 USB rev 0x1a: irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered viaenv0 at pci0 dev 7 function 4 VIA VT82C686 SMBus rev 0x40 sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1 sis1 at pci0 dev 9 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 12, address 00:02:b6:33:50:de nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1 sis2 at pci0 dev 10 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 9, address 00:02:b6:33:50:df nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1 sis3 at pci0 dev 11 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 10, address 00:02:b6:33:50:e0 nsphyter3 at sis3 phy 0: DP83815 10/100 PHY, rev. 1 isa0 at pcib0 isadma0 at isa0 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 midi0 at pcppi0: PC speaker spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask e5e5 netmask ffe5 ttymask ffe7 pctr: user-level cycle counter enabled uhidev0 at uhub0 port 2 configuration 1 interface 0 uhidev0: Tangtop USBPS2, rev 1.10/0.01, addr 2, iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub0 port 2 configuration 1 interface 1 uhidev1: Tangtop USBPS2, rev 1.10/0.01, addr 2, iclass 3/1 uhidev1: 3 report ids ums0 at uhidev1 reportid 1: 5 buttons and Z dir. wsmouse0 at ums0 mux 0 uhid0 at uhidev1 reportid 2: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0
Re: hardware problem?! strangely ssh error
On 2007/07/19 23:06, openbsd misc wrote: I tested the gentoo live cd. I was able to ssh to another machine, so I was able to get a complete (linux) dmesg output. Hope that helps: Can you ftp or email out an OpenBSD dmesg from the box? Linux ones make my head hurt, and I suspect other people too. :-) If there might be crypto hardware onboard, try sysctl kern.usercrypto=0
hardware problem?! strangely ssh error
Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect to the system, too. The error I got: 2: Bad packet length integer I googled a bit, but I wasn't able to find out what exactly is wrong. Here are the informations from dmesg about the nics: sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd Btw, I'm talking about a fresh 4.1 installation, completly untouched. Has anyone an idea for me? Driver problem? Unsupported hardware? The hardware was checked twice by producer (and I don't have the problems using linux), I don't think that is a hardware defect. Thanks. Regards Hagen Volpers
Re: hardware problem?! strangely ssh error
misc(at)openbsd.org wrote: Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect to the system, too. The error I got: 2: Bad packet length integer I googled a bit, but I wasn't able to find out what exactly is wrong. Here are the informations from dmesg about the nics: sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd Btw, I'm talking about a fresh 4.1 installation, completly untouched. Has anyone an idea for me? Driver problem? Unsupported hardware? The hardware was checked twice by producer (and I don't have the problems using linux), I don't think that is a hardware defect. Thanks. Regards Hagen Volpers Have you tried: ssh -vvv host.to.connect.to That might give some clues. HTH Fred -- http://www.crowsons.com/puters/x41.htm
Re: hardware problem?! strangely ssh error
misc(at)openbsd.org wrote: Hello, I have a system with openbsd 4.1 installed. Everything works fine (lynx / ping / ...) but I'm not able to connect to another system via ssh. I'm not able to connect to the system, too. The error I got: 2: Bad packet length integer I googled a bit, but I wasn't able to find out what exactly is wrong. Here are the informations from dmesg about the nics: sis0 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 11, address 00:02:b6:33:50:dd Btw, I'm talking about a fresh 4.1 installation, completly untouched. Has anyone an idea for me? Driver problem? Unsupported hardware? The hardware was checked twice by producer (and I don't have the problems using linux), I don't think that is a hardware defect. Thanks. Regards Hagen Volpers Have you tried: ssh -vvv host.to.connect.to That might give some clues. HTH Fred -- http://www.crowsons.com/puters/x41.htm Hello, here are the last lines: debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent followed by the error mentioned in my first mail. Does that help? Do you need more informations? Regards Hagen Volpers
