Could you arrange for a computer running ethereal or tcpdump, so
one could learn something about the state of the tcp protocol
at the points where it hangs? You know, window sizes, tcp options,
presence of PUSH bit, if the last request is acknowledged, are
there retransmissions, etc.
Also, save a copy of the kernel counters, preferably at points in
time when you know which packets in the capture are included in
the count. Is it possible to signal the programs involved, and have
them report the count of requests sent or received up to that
If an unrelated connection request from another workstation
seems to unlock the situation, is there any chance that any
iptables module is involved? Does udp have similar effects?
icmp or ping? I see you have port 80 in the example telnet
command, may I guess that port 80 is involved in the simulation
too? When the system hangs, what are the processes involved
doing? waiting in "select()" or "poll()"? Have you tried to
attach it with strace? man strace, option "-p".
I really have no idea, but until somebody shows up with one,
it seems natural to do whatever possible to characterize the
situation and find bounds to the problem. Is the hang in
the kernel, in iptables, or in the application? If the process
sleeps on select, are the right file descriptors present in
the fdsets? (strace.)
Twelve connections does not sound overwhelming.