Hi all,

I've been using lwIP 2.0.2 branch as a base my networking stack. I implemented a device driver and am using a tcpip thread, these are my options:


#define LWIP_SKIP_CONST_CHECK       1
#define LWIP_PROVIDE_ERRNO          1
#define LWIP_TCPIP_CORE_LOCKING     1
#define TCPIP_THREAD_PRIO           LWIP_TASK_PRIO
#define TCPIP_THREAD_STACKSIZE      LWIP_TASK_STK_SZ
#define LWIP_TCPIP_CORE_LOCKING_INPUT   0

#define TCPIP_MBOX_SIZE             16
#define SYS_SEM_MAX                 0xffff
#define SYS_LIGHTWEIGHT_PROT        1

#define LWIP_NETCONN                1
#define DEFAULT_RAW_RECVMBOX_SIZE   8
#define DEFAULT_UDP_RECVMBOX_SIZE   8
#define DEFAULT_TCP_RECVMBOX_SIZE   8
#define DEFAULT_ACCEPTMBOX_SIZE     8

#define LWIP_NETIF_HOSTNAME         0
#define LWIP_DHCP                   1
#define LWIP_IPV6                   1
#define MEM_LIBC_MALLOC             1
#define MEMP_MEM_MALLOC             1

#define CHECKSUM_GEN_IP             0
#define CHECKSUM_GEN_TCP            0
// IPv4 UDP checksum is optional. Hardware does not support checksumming UDP packets, so we will choose to just not checksum the UDP.
#define CHECKSUM_GEN_UDP            0
#define CHECKSUM_GEN_ICMP           0
#define CHECKSUM_GEN_ICMP6          0
#define CHECKSUM_CHECK_IP           0
#define CHECKSUM_CHECK_UDP          0
#define CHECKSUM_CHECK_TCP          0
#define CHECKSUM_CHECK_ICMP         0
#define CHECKSUM_CHECK_ICMP6        0

So far, all of ICMP, UDP, ARP, DHCP work nicely. TCP however, does not.
This is the debugging code I have (in a separate task):

  nc = netconn_new(NETCONN_TCP);
  err_t bind = netconn_bind(nc, NULL, 5005);
  err_t list = netconn_listen(nc);
  while (1) {
      txrx = NULL;
      err = netconn_accept(nc, &txrx);
      DelaySeconds(5);
      netconn_close(txrx);
      netconn_delete(txrx);
  }

I would expect this to be able to handle a connection properly and close it gracefully. Indeed this is exactly what happens on the first connection (< is lwIP, > is client):

> SYN [SEQ=2292262937]
< SYN ACK [SEQ=6510 ACK=2292262938]
> ACK [SEQ=2232262938 ACK=6511]
(some time passes)
< FIN ACK [SEQ=6511 ACK=2292262938]
> ACK [SEQ=2292262938 ACK=6512]
> FIN ACK [SEQ=2292262938 ACK=6512]
< TCP Keep Alive [SEQ=6511]
> TCP Keep Alive ACK [ACK=6512]
< TCP Keep Alive [SEQ=6511]
> TCP Keep Alive Ack [ACK=6512]
< TCP Keep Alive [SEQ=6511]
< TCP Keep Alive [SEQ=6511]
< TCP Keep Alive [SEQ=6511]

This is, however, what happens during the subsequent connections (after the first has closed):

> SYN [SEQ=401742920]
< SYN ACK [SEQ=6710 ACK=401742921]
> ACK [SEQ=401742921 ACK=6711]
< RST ACK [SEQ=6711 ACK=401742921]

Which is not the graceful close I would have expected.

This RST comes from tcp_process function in SYN_RCVD case.
The check which leads to the reset being sent looks like this:

TCP_SEQ_BETWEEN(6711, 6710+1, 6710)

while during the first connection, it looks like this:

TCP_SEQ_BETWEEN(6511, 6510+1, 6511)

So it seems like for some reason the pcb->snd_nxt is one-off.

I would really appreciate any help figuring this out. Is it a bug in my code (even though everything else works fine)? Am I using netconn incorrectly? Is there some option I forgot to flip (or set one of the above wrongly?)

Thanks,
Simonas

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

Reply via email to