Re: [lwip-users] lwip_write() eventually blocks

[Alhad Palkar]

update: if we use TCP_NO_DELAY, we are able to reproduce this problem much more deterministically. The signature of the failure is the same as before. 

one more thing, after enabling the checksum checks in wireshark we noticed that the retransmitted packets at the end have checksum errors. 

Our original setting was 

#define TCP_CHECKSUM_ON_COPY_SANITY_CHECK 0

#define LWIP_CHECKSUM_ON_COPY         0

I set both to 1, but that doesn't solve the issue. 

Any help is greatly appreciated.

Thanks,

Alhad

On Tue, Nov 17, 2015 at 4:37 PM, Alhad Palkar <address@hidden> wrote:

What seems to be happening here is something like this

(A is the running LWIP, while B is running mac os x. )

1. A sends segment 75562:75594

2. B sends ack 75594

3. A sends segment 78482:78514 ( this is what i see in wireshark, which probably means the segments in between were not received by B )

4. B sends ack 75594 again ( Dup )

5. A retransmits segment 75594:77054

6. B sends ack 77054

7. A retransmits segment 77054:78482

8. B sends ack 78514 

9. from this point on we see that A keeps retransmitting segment 78482:78514

Once this happens I examined the tcp pcb for this socket, and I see the following

lastack = 78514

unacked = 78482, <one more packet>

For some reason it seems like 78482 is never removed from the unacked queue even though LWIP seems to have received the 78514 ack

Anyone seen this behavior before?

Thanks,

Alhad

On Mon, Nov 16, 2015 at 3:21 PM, alhadpalkar <address@hidden> wrote:

​Hi,

​I can reproduce this fairly easily when transmitting data from an arm
system (192.168.5.15 ) using LWIP to a server running on mac os x (
192.168.5.10 ). I am using LWIP version 1.4.1. I have attached a copy of the
pcapng file that captures the failure.

failure.pcapng <http://lwip.100.n7.nabble.com/file/n25368/failure.pcapng>

My lwipopts.h file looks like below

#define NO_SYS                                      0
#define MEM_LIBC_MALLOC                 1
#define MEM_ALIGNMENT                     4
#define MEM_SIZE                                 1600

#define MEMP_NUM_PBUF                        64
#define MEMP_NUM_TCP_PCB                 16
#define MEMP_NUM_TCP_PCB_LISTEN   16
#define MEMP_NUM_TCP_SEG                 (TCP_SND_QUEUELEN+1)
#define MEMP_NUM_SYS_TIMEOUT         8
#define MEMP_NUM_NETBUF                   16
#define MEMP_NUM_NETCONN                16
#define PBUF_POOL_SIZE                         128
#define PBUF_POOL_BUFSIZE                  (4 * 1024)

#define MEMP_NUM_TCPIP_MSG_INPKT        128

#define IP_FORWARD                         0
#define IP_OPTIONS_ALLOWED        0
#define IP_REASSEMBLY                   0
#define IP_FRAG                                 0
#define IP_REASS_MAXAGE              3
#define IP_REASS_BUFSIZE              2048
#define IP_FRAG_MAX_MTU              1500

#define TCP_SYNMAXRTX                   2
#define TCP_QUEUE_OOSEQ              1
#define TCP_MSS                                  1460
#define TCP_WND                                 (16 * TCP_MSS)
#define TCP_SND_BUF                         TCP_WND
#define TCP_SND_QUEUELEN                32

#define TCPIP_MBOX_SIZE                               128
#define DEFAULT_TCP_RECVMBOX_SIZE       128
#define DEFAULT_ACCEPTMBOX_SIZE       128

Does anything look obviously wrong here?

Looking at the capture it is evident that LWIP is trying to retransmit
packets, but it never seems to come out of this. What might cause this?

Thanks,
Alhad



--
View this message in context: http://lwip.100.n7.nabble.com/lwip-write-eventually-blocks-tp25368.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users