lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] [UIP] Issues with initial window side & w/ FIN packets wit


From: Ryan Gammon
Subject: [lwip-users] [UIP] Issues with initial window side & w/ FIN packets with data
Date: Fri, 14 Feb 2003 00:42:01 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605

Hello,

Sorry for posting this to the LwIP list, but I don't think there's a dedicated uip list.

I'm having two problems with uip:

1. Initial window size:

When uip initiates a connection, the window size in the initial syn packet has a window size of 0. Linux doesn't seem to have a problem with this, but other systems sometimes do.

I added the following in uip.c to fix it:

+       if(uip_conn->mss == 0) {
+           uip_conn->mss = UIP_TCP_MSS;
+       }
#if (UIP_TCP_MSS) > 255
        BUF->wnd[0] = (uip_conn->mss >> 8);
#else
        BUF->wnd[0] = 0;
#endif /* UIP_MSS */
        BUF->wnd[1] = (uip_conn->mss & 0xff);
    }


2. The last (FIN) packet being sent is not being flagged as having uip_newdata()

I fixed it as seen below:

--- /home/ryan/tmp/uip-0.6/uip/uip.c    2002-01-15 13:54:54.000000000 -0400
+++ uip.c       2002-10-11 14:00:59.000000000 -0300
@@ -778,6 +786,19 @@
#endif /* UIP_ACTIVE_OPEN */
case ESTABLISHED:
+        /* RG: Added check for new data above FIN check, as FIN packet
+           also appears to contain data */
+        /* If uip_len > 0 we have TCP data in the packet, and we flag this
+           by setting the UIP_NEWDATA flag and update the sequence number
+           we acknowledge. If the application has stopped the dataflow
+           using uip_stop(), we must not accept any data packets from the
+           remote host. */
+        if(uip_len > 0 && !(uip_conn->tcpstateflags & UIP_STOPPED)) {
+            uip_flags |= UIP_NEWDATA;
+            uip_add_rcv_nxt(uip_len);
+        }
+ +
    /* In the ESTABLISHED state, we call upon the application to feed
    data into the uip_buf. If the UIP_ACKDATA flag is set, the
    application should put new data into the buffer, otherwise we are
@@ -791,8 +812,10 @@

    if(BUF->flags & TCP_FIN) {
      uip_add_rcv_nxt(1 + uip_len);
-      uip_flags = UIP_CLOSE;
-      uip_len = 0;
+            //uip_flags = UIP_CLOSE;
+            //uip_len = 0;
+            uip_flags |= UIP_CLOSE;
+
      UIP_APPCALL();
      uip_add_ack_nxt(1);
      uip_conn->tcpstateflags = LAST_ACK | UIP_OUTSTANDING;
@@ -803,17 +826,6 @@
    }

- /* If uip_len > 0 we have TCP data in the packet, and we flag this
-       by setting the UIP_NEWDATA flag and update the sequence number
-       we acknowledge. If the application has stopped the dataflow
-       using uip_stop(), we must not accept any data packets from the
-       remote host. */
-    if(uip_len > 0 && !(uip_conn->tcpstateflags & UIP_STOPPED)) {
-      uip_flags |= UIP_NEWDATA;
-      uip_add_rcv_nxt(uip_len);
-    }
- -
    /* If this packet constitutes an ACK for outstanding data (flagged
       by the UIP_ACKDATA flag, we should call the application since it
       might want to send more data. If the incoming packet had data








reply via email to

[Prev in Thread] Current Thread [Next in Thread]