On 2008-Dec-30 05:48:26 -0500, Terry Kennedy <te...@tmk.com> wrote: >> Unfortunately, you need the last packets that were exchanged in order >> to identify which end has the problem (and hopefully provide some >> pointers as to why). If possible, can you repeat the dump whilst you >> run a tcpdump on the rdump flow and then post the last dozen or so >> packets in each direction. > > That could be pretty unpleasant - this happens at a random point while >dumping 4GB or so. If I have to, I'll do it but I was hoping there was >a better way.
Sorry, I can't think of any - by the time you see it hung, whatever went wrong has already happened. You might glean some insight from the TCP socket state (on the FreeBSD side, use 'netstat -A' to print the PCB address and gdb to dump the contents but I'm not sure how to get this data out of OpenVMS). The '-C' and '-W' options to tcpdump will help. > Shouldn't this get torn down by a keepalive at some point? It has been >sitting for 9 hours or so at this point... On FreeBSD, keepalives are off by default. You change change the default with sysctl net.inet.tcp.always_keepalive but I think that only affects new connections. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpEhfcVex9gC.pgp
Description: PGP signature
