On Fri, 13 Jun 2003, shrek-m@xxxxxx wrote: sorry to take so long to respond -- server down... re addressing linux to unix ssh, telnet stalling over same connection that win to (same) unix server ssh/telnet running cleanly: > Melissa Golter schrieb: > >>How about the tail of /var/log/messages, any > >>interesting info? > >> > >> > > > >tail var/log/messages: > >Jun 8 04:02:31 localhost syslogd 1.4.1: restart. > >Jun 9 04:02:37 localhost kernel: (scsi0:A:1:0): Locking max tag count at > >40 > >Jun 9 16:15:03 localhost kernel: eth0: link up, 100Mbps, full-duplex, lpa > >0x45E1 > >Jun 9 17:25:23 localhost kernel: eth0: Bus master arbitration failure, > >status ffff. > > > > google for it > i never had such a message > is your connection always ok? > hardware, driver, nic, wire, switch, ... google for what???? ack all connections are ok, yes: When running a number of machines the only time anything stalls is when a. there are *network* difficulties b. I load Linux (RH9.0 in this case) both ssh and telnet stall somedays are better than others... while the machine is in *stall* mode, the connections are good even tho keystroke response doesn't happen (Example: when I use pine, new message alerts show up, etc. even tho a keystroke response such as hitting *backspace* or *enter* results in no action until after the *stall* is over. > > # cat /etc/modules.conf > # lsmod > # modinfo your_nic_module > > > ping your-server-ip (eg. with temporary unplugged wire) > 64 bytes from www2.vip.lng.yahoo.com (217.12.3.11): icmp_seq=44 ttl=246 > time=96.2 ms > 64 bytes from www2.vip.lng.yahoo.com (217.12.3.11): icmp_seq=45 ttl=246 > time=97.7 ms > From 192.168.101.10 icmp_seq=117 Destination Host Unreachable > 64 bytes from www2.vip.lng.yahoo.com (217.12.3.11): icmp_seq=129 ttl=246 > time=2097 ms temporarily unplug what wire? > or check from time to time with > # mii-tool eth0 > eth0: negotiated 100baseTx-FD, link ok # mii-tool eth0 does usually yield eth0: negotiated 100baseTx-FD, link ok even when telnet or ssh is *stalled* same for below as said before: some days are better than others -- yesterday this stalling happened only a few times. Today it is happening every 5 minutes. At one point the connection was severed, but I am willing to chalk that up to other difficulties (such as Ameritech connection being re-set, etc) > # ethtool eth0 > Settings for eth0: > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > Supports auto-negotiation: Yes > Advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > Advertised auto-negotiation: Yes > Speed: 100Mb/s > Duplex: Full > Port: MII > PHYAD: 8 > Transceiver: internal > Auto-negotiation: on > Current message level: 0x00000001 (1) > Link detected: yes > > >Jun 9 17:25:23 localhost last message repeated 2 times > >Jun 12 11:45:01 localhost kernel: ip_tables: (C) 2000-2002 Netfilter core > >team > >Jun 12 11:45:01 localhost iptables: succeeded > > > > > telnet your_server_ip 22 > > $ telnet localhost 22 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > SSH-1.99-OpenSSH_3.4p1 > ^] > [ctl][altgr][9] > telnet> quit > Connection closed. same as above with replacement: SSH-1.99-OpenSSH_3.5p1 > > > ssh-verbose-mode > > $ ssh -vvv your_server_ip (eg. wrong password) > ... > Permission denied, please try again. > debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug1: authentications that can continue: > publickey,password,keyboard-interactive > Permission denied, please try again. > debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug1: authentications that can continue: > publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug1: no more auth methods to try > Permission denied (publickey,password,keyboard-interactive). > debug1: Calling cleanup 0x80674b0(0x0) > > > $ ssh -vvv your_server_ip (eg. correct login) > ... > debug3: tty_make_modes: 71 0 > debug3: tty_make_modes: 72 1 > debug3: tty_make_modes: 73 0 > debug3: tty_make_modes: 74 0 > debug3: tty_make_modes: 75 0 > debug3: tty_make_modes: 90 1 > debug3: tty_make_modes: 91 1 > debug3: tty_make_modes: 92 0 > debug3: tty_make_modes: 93 0 > debug2: x11_get_proto /usr/X11R6/bin/xauth list :0 2>/dev/null > debug1: Requesting X11 forwarding with authentication spoofing. > debug1: channel request 0: x11-req > debug1: channel request 0: shell > debug1: fd 3 setting TCP_NODELAY > debug2: callback done > debug1: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 131072 I'll take it you mean login, a password diff is not what am checking... with incorrect login, response is *user unknown* > > # iptables -A INPUT -p tcp -m multiport --sport 22 -j DROP > > $ ssh -vvv localhost (eg. closed input-sourceport 22) > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to localhost [127.0.0.1] port 22. > you can wait here - and wait - and wait - and wait - and wait - ... well, wait wait wait is the order of the day...however, with this command there is no wait wait, just nothing, nada; the cursor just reappears with no comment... What is supposed to happen??? > good luck hmm, thanks...today has been a hair puller with the stalling -- hope you can make something of the above responses. ;P > > -- > shrek-m > > > > -- > Shrike-list mailing list > Shrike-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/shrike-list >
