question for TCP gurus (in ipfw)

Julian Elischer julian at elischer.org
Thu Dec 14 11:44:14 PST 2006


Andre Oppermann wrote:
> Julian Elischer wrote:
>> in the ipfw function send_reject6() we go to great length to calculate 
>> the sequence number to put into the ack field of the reject packet..
>>
>> but it's a RESET we are generating..
>>
>> do we need to go to all the work of setting the ACK value etc?
> 
> Yes, at least some of it.
> 
>> could we do either of:
>> 1/ not set the ACK bit  and just not do the extra work. Just send a 
>> reset?
> 
> Doesn't work.
> 
>> or
>> 2/ instead of ACKing all the data in the packet we are resetting,
>> how about just ACKing the sequence number it starts with
>> and saving ourselves from doing the work of ACKing all the  data
>> up to the current packet end. (which is the packet we are rejecting 
>> anyhow) (It takes some calculation to work out the new ack value
>> which seems pointless as we are rejecting it..)
> 
> Section 3 of this document describes the situation and requirements
> quite accurately:
> 
>  http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt

it sounds to me from this document that the SEQUENCE NUMBER of the RST
needs to be the expected value but the calculations seem to be 
calculating the ACK value.. ie it is taking the sequence number,
adding the amount of data to find the new sequence number, and sending 
that back in the ACK field..This seems un-needed. (?)

i.e shouldn't the RST have a sequence number that is the value of the 
received ACK (minus 1?) and an ACK value of the received data is only 
checked (if at all) to be in the window. (It doesn't talk about the ACK
value at all in the section you referenced.

in fact it says:
    A legitimate peer, after restart, would not have a TCB
    in the synchronized state.  Thus when the ACK arrives the peer should
    send a RST segment back with the sequence number derived from the ACK
    field that caused the RST.

however in the code I an pointing to in send_reject6() in ip_fw2.c
it seems that it is the ACK that is being calculated, and not the 
SEQUENCE number.





More information about the freebsd-net mailing list