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.