This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SYN problem with new TCP/IP stack


On 2006-02-12, Grant Edwards <grante@visi.com> wrote:

> Now we rattle on down through the tcp_input fuction a ways and
> end up jumping to "drop" at line 1739:
>
>   1729                /*
>   1730                 * If the ACK bit is off:  if in SYN-RECEIVED state or SENDSYN
>   1731                 * flag is on (half-synchronized state), then queue data for
>   1732                 * later processing; else drop segment and return.
>   1733                 */
>   1734                if ((thflags & TH_ACK) == 0) {
>   1735                        if (tp->t_state == TCPS_SYN_RECEIVED ||
>   1736                            (tp->t_flags & TF_NEEDSYN))
>   1737                                goto step6;
>   1738                        else
>   1739                                goto drop;
>   1740                }
    1741        
    1742                /*
    1743                 * Ack processing.
    1744                 */
    1745                 switch (tp->t_state) {
    1746  
    1747          /*
    1748           * In SYN_RECEIVED state, the ack ACKs our SYN, so enter
    1749           * ESTABLISHED state and continue processing.
    1750           * The ACK was checked above.
    1751           */
  
OK, so here's that same chunk of code from the old stack:

    1467                /*
    1468                 * If the ACK bit is off we drop the segment and return.
    1469                 */
    1470                if ((tiflags & TH_ACK) == 0) {
    1471                        if (tp->t_flags & TF_ACKNOW)
    1472                                goto dropafterack;
    1473                        else
    1474                                goto drop;
    1475                }
    1476                
    1477                /*
    1478                 * Ack processing.
    1479                 */
    1480                switch (tp->t_state) {
    1481        
    1482                /*
    1483                 * In SYN_RECEIVED state, the ack ACKs our SYN, so enter
    1484                 * ESTABLISHED state and continue processing.
    1485                 * The ACK was checked above.
    1486                 */

Note how instead of jumping to drop, we jump to dropafterack at
line 1472.  

Why was the test of TF_ACKNOW and the jump to dropafterack
deleted?  It has to be there to be RFC compliant (and more
importantly, to make my customer stop complaining).

I think that rather than checking TF_ACKNOW in the "drop" code
as I had previously posted, I should just add the test of
ACKNOW and jump to dropafterack back in where it was like this:

  1729                /*
  1730                 * If the ACK bit is off:  if in SYN-RECEIVED state or SENDSYN
  1731                 * flag is on (half-synchronized state), then queue data for
  1732                 * later processing; else drop segment and return.
  1733                 */
  1734                if ((thflags & TH_ACK) == 0) {
  1735                        if (tp->t_state == TCPS_SYN_RECEIVED ||
  1736                            (tp->t_flags & TF_NEEDSYN))
  1737                                goto step6;
  1738                        else if (tp->t_flags & TF_ACKNOW)
                                      goto dropafterack;
                              else                                      
  1739                                goto drop;
  1740                }

Whaddayathink?
  
-- 
Grant Edwards                   grante             Yow!  Yow! Did something
                                  at               bad happen or am I in a
                               visi.com            drive-in movie??


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]