Subject: Server disconnects - any ideas ?

From: Matthew Geier <[email-masked]>
Date: Wed, 22 Nov 2000 13:07:47 +1100

Im having problems with clients dropping their server connections, this
appears to only happen when they go 'idle' for a few minutes, the client
machines don't drop out while running Helio LanTest for example.

 The only clue in the logs is -

Nov 22 12:50:23 aristotle afpd[28825]: dsi_stream_read(0): Connection
refused
Nov 22 12:50:23 aristotle afpd[28825]: dsi_tcp_open: invalid header
Nov 22 12:50:23 aristotle afpd[812]: server_child[1] 28825 exited 1
Nov 22 13:01:13 aristotle afpd[28881]: dsi_stream_read(0): Connection
refused
Nov 22 13:01:13 aristotle afpd[28881]: dsi_tcp_open: invalid header
Nov 22 13:01:13 aristotle afpd[812]: server_child[1] 28881 exited 1

-- 
Matthew Geier			[email-masked]
Arts IT Unit			+61 2 9351 4713
Sydney University

---

From: Matthew Geier <[email-masked]>
Date: Wed, 22 Nov 2000 18:16:49 +1100

> Nov 22 13:01:13 aristotle afpd[812]: server_child[1] 28881 exited 1

 I guess I should have added - Redhat 6.2, Kernel 2.4.0test7
NetAtalk asun 39b

 Im about to conduct a test with the latest source-forge version.

---

From: "Marc J. Miller" <[email-masked]>
Date: Wed, 22 Nov 2000 20:40:21 -0800

That log segment seems to indicate an invalid login or a failed attempt to 
send forged TCP packets.  You're certain that these are processes that got 
past the login process?

---

From: Matthew Geier <[email-masked]>
Date: Fri, 24 Nov 2000 09:38:10 +1100

> send forged TCP packets.  You're certain that these are processes that got

 After this comment it dawned on me that these processes are due to a
network script I have 'pinging' the afpovertcp port to see if it
responds.

 After installeding the lastest source forge version, the client
connections don't seem to drop out as often. Its kinda difficult to test
when students come up to an otherwise idle machine and reset it on
you.... :-)

---

From: Chris Johns <[email-masked]>
Date: Fri, 24 Nov 2000 13:04:57 +1100

> send forged TCP packets.  You're certain that these are processes that got

I saw these sorts of traces when the Mac client was releasing the DHCP
assigned address instead of renewing it (unload TCP stack when not
active setting on). I put it down to the TCP socket being closed by the
client.

-- 
 Chris Johns, mailto:[email-masked] mailto:[email-masked]