eth0 going down (connection reset by peer, then connection refused)
I have a fresh install of slack 12.0 on a box on my lan, however from time to time, just like a woman, it ignores everything except ping packets if ping packets are the ipv4 equivalent of poking.
If I am ssh'd into the box I will recieve a connection reset by peer error (or browsing a mounted directory via samba), and after that about 5-10 minutes of "connection refused". At first I thought it was because ipv6 and ipv4 were conflicting in attempting to control listen ports bound to 0.0.0.0, so I made ssh and samba use specific ipv4 IP addresses - that didn't seem to help. There is only one network card in this box. I am not experiencing the same problem on a fresh install of slack 10.2 on a different box (192.168.0.10 for those that are curious) Anyway, here's the ifconfig info of the box in question root@isfrael:/media1# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0D:88:58:80:5F inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:32851 errors:0 dropped:0 overruns:0 frame:0 TX packets:45623 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3216037 (3.0 MiB) TX bytes:53239167 (50.7 MiB) Interrupt:20 and if I ssh from the slack 10.2 box and i'm disconnected, here's the error message pertaining to what I'm talking about root@isfrael:/media1# Read from remote host 192.168.0.11: Connection reset by peer Connection to 192.168.0.11 closed. omega@azhure:~$ ssh 192.168.0.11 ssh: connect to host 192.168.0.11 port 22: Connection refused omega@azhure:~$ If there's any kind of logs I should be looking at (dmesg, /var/log/syslog and /var/log/messages don't tell me anything useful as far as I can tell) then I am more than happy to provide them. Also note that during this time the box cheerfully responds to pings, unlike a woman (they tend to poke you back or hit you in my experience, quite uncheerfully) oh, and i tried the ServerKeepAlive option in ssh_config, doesn't do much except keep ghost connections alive. For instance:- root 3049 0.0 0.1 6400 1928 ? Ss 07:25 0:00 sshd: omega [priv] omega 3051 0.0 0.1 6400 1216 ? S 07:25 0:00 sshd: omega@pts/0 omega 3052 0.0 0.1 3524 1984 pts/0 Ss 07:25 0:00 -bash root 3065 0.0 0.1 3020 1704 pts/0 S+ 07:27 0:00 bash root 3128 0.7 0.0 0 0 ? S 07:41 0:33 [pdflush] root 3130 0.6 0.0 0 0 ? S 07:45 0:31 [pdflush] root 3157 0.0 0.1 6400 1932 ? Ss 08:07 0:00 sshd: omega [priv] omega 3159 0.0 0.1 6400 1220 ? S 08:07 0:00 sshd: omega@pts/1 omega 3160 0.0 0.1 3520 1976 pts/1 Ss 08:07 0:00 -bash root 3179 0.0 0.1 3024 1708 pts/1 S+ 08:10 0:00 bash root 3185 0.0 0.1 3820 1080 ? Ss 08:11 0:00 /usr/sbin/sshd root 3211 0.0 0.1 6404 1928 ? Ss 08:56 0:00 sshd: omega [priv] omega 3213 0.0 0.1 6404 1220 ? S 08:56 0:00 sshd: omega@pts/2 omega 3214 0.0 0.1 3516 1940 pts/2 Ss 08:56 0:00 -bash root@isfrael:/media1# who omega pts/0 2003-05-16 07:25 (192.168.0.10) omega pts/1 2003-05-16 08:07 (192.168.0.10) omega pts/2 2003-05-16 08:56 (192.168.0.10) |
Turns out someone had changed their IP and hadn't told me. Thanks, dude. Thanks for the ip conflict.
The way I found out was this command: arp -a on a different box during the downtime and during the uptime. The MAC address for the conflicted IP changed. |
All times are GMT -5. The time now is 11:15 AM. |