[MUD-Dev] randomly dropped connections
darius at connect.com.au
Sat Mar 4 13:55:56 New Zealand Daylight Time 2000
(I originally sent this straight to Matthew, but it occurred to me it might
be useful info for others, so I'm copying it back to the list ;) Hope it
--- Cut'n'paste follows ---
Potentially. Best way to trap this is to find someone who's having this
problem, and setup a tcpdump to catch all their traffic. It'll be verbose,
but the last few packets of the connection should give some idea of what's
happening - why the tcp session is being reset.
tcpdump -n host <ip of client> -o debug.file will catch it - you could
automate to catch and hold only a given amount, or something. You'll have to
have a passing understanding of tcp sequence to spot what's causing it to
break - attention paid to the seq numbers and flags on the last few packets
should pay off, tho, as it'll show which side is dropping, and whether
it's because of getting out of sequence or dropping too much or whatever.
Paranoid option: People could be attempting to hijack connections - not
likely, tho. Other option: timeouts on sessions (NAT getting in the way
at the remote end, or cisco/*nix firewall rules). Hrm - vaguely possible
there's routing issues that are disrupting things too - view of various
looking-glasses at various times _may_ help there, but it's dubious -
depends a bit on what sort of timeframes you're looking at for
disconnection (can people login again immediately? Have you had any
multi-players have the problem across all their connections?)
Very vaguely, it could also be resource shortage on routers between src and
dest - although I'd not expect/haven't seen that sort of failure mode, and
tcp will do it's best to recover from dropped packets that way anyhow.
Other potential I forgot: path MTU. If you see them dropping connections
specifically when a large hunk of data is sent to them, this is a good
possibility. NAT and IP tunnels will cause these sorts of problems - if
the MTU isn't high enough, but the other end can't effectively signal that,
then you'll see problems.
Oh, you're not firewalling ICMP are you? _Must_ let certain icmp through -
destination-unreachable flags (type, um, 3, sub-type 4) in particular,
otherwise this will bite you.
Hope that helps some - I'd be happy to lend a hand debugging/analysing, if
(currently job-hunting, too - has to be mentioned ;)
>>> Matthew Mihaly wrote
> Something JC said in his post about network setups made me wonder if maybe
> our ISP (mudservices) has a bad piece of hardware. Could a faulty router
> or something be causing this sort of problem?
> Matthew A. Mihaly
> President, Achaea LLC
> Scito te ipsum.
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev