Re: Keep state connections randomly dropped

Saša Nedvědický wrote:
> 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...

the idea is right...but perhaps a different change can be made
so that this if() doesn't need to be so complex and the natural
comparison holds true...

I'm thinking of either chanigng _CLOSED to be 11 (and renumbering
all of the other states, so that _LIStEN becomes 0) or adding a new
one, IPF_TCPS_DELETE.

The problem with making _CLOSED be 11 (rather than 0) and _LISTEN
be 0, is that _LISTEN isn't technically correct (or maybe it is?), for state
that has been created by the first SYN packet, so one side s
IPF_TCPS_SYN_SENT and the other is IPF_TCPS_LISTEN.
or maybe that does make sense?

Darren