hello, I've tried the patch Darren has proposed as a solution of Jeremy's problem. Unfortunately the patch did not work for me in case of ssh client, which immediately disconnects from server once connected and within second reconnects to the same server from the same source port.
there are packet dumps attached to email:
on10Patch.pkt - it shows packet dump for client after Darren's patch
was installed. the packet dump is identical with dump
obtained after installation of official 125014-02
patch from sun.
on10NoPatch.pkt - shows pakcet dump prior installation of 125014-02.
note the two minute delay between successfull reconnects
noIPF.pkt - shows packet dump when IPF was disabled.
ipf.conf - shows IPF rules, which were used on ssh server.
the script reconnected and disconnected 10 times to ssh server.
here is an exceprt from Darren's patch.
+ if ((tcp->th_flags & TH_OPENING) == TH_SYN) {
+ if ((is->is_state[0] > IPF_TCPS_ESTABLISHED) &&
+ (is->is_state[1] > IPF_TCPS_ESTABLISHED)) {
+ is->is_state[!source] = IPF_TCPS_CLOSED;
+ fr_movequeue(&is->is_sti, is->is_sti.tqe_ifq,
+ &ips_deletetq);
+ MUTEX_ENTER(&is->is_lock);
+ return 0;
+ }
+ }
I think the problem can be solved by modification of the second if condition,
it should be extended as follows:
if (((is->is_state[0] > IPF_TCPS_ESTABLISHED) || (is->is_state[0]
<= IPF_TCPS_LISTEN)) &&
((is->is_state[1] > IPF_TCPS_ESTABLISHED) ||
(is->is_state[1] <= IPF_TCPS_LISTEN))) {
well I'm not sure with '<=', but I somehow feel, that connections in listen
state, should be handled in the same way...
hope it helps
regards
sasha
on10Patch.pkt
Description: Binary data
ipf.conf
Description: Binary data
on10noPatch.pkt
Description: Binary data
noIPF.pkt
Description: Binary data
