Re: [lwip-users] TCP 2.0.2 pcb->snd_nxt is not updated somewhere?

[Darius]

Hi Simonai,
What OS you using? 
If without OS
 What is DelaySeconds(5);  function? Looks like  this fuction  blocking
mcu?
BR.
Darius







--
View this message in context: 
http://lwip.100.n7.nabble.com/TCP-2-0-2-pcb-snd-nxt-is-not-updated-somewhere-tp30387p30531.html
Sent from the lwip-users mailing list archive at Nabble.com.

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

Re: [lwip-users] TCP 2.0.2 pcb->snd_nxt is not updated somewhere?

[basi]

Hi Simonas,

Did you find the cause of this issue?

I'm also getting the same failure with lwIP 2.0.2 + FreeRTOS + netconn APIs
for implementing a webserver.

The first connection is successful and subsequent connections are failing at
following at check TCP_SEQ_BETWEEN in tcp_process.

case SYN_RCVD:
if (flags & TCP_ACK) {
  /* expected ACK number? */
  if (TCP_SEQ_BETWEEN(ackno, pcb->lastack+1, pcb->snd_nxt)) {

The wireshark trace shows that, even for the first connection, the ACK for
'GET HTTP/1.1' is coming out of order; i mean after FIN/ACK from client.
Trace file attached..
01_g55.pcapng   




--
View this message in context: 
http://lwip.100.n7.nabble.com/TCP-2-0-2-pcb-snd-nxt-is-not-updated-somewhere-tp30387p30514.html
Sent from the lwip-users mailing list archive at Nabble.com.

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

Re: [lwip-users] TCP 2.0.2 pcb->snd_nxt is not updated somewhere?

[Joel Cunningham]

> 
> On Aug 7, 2017, at 4:43 AM, Simonas Kazlauskas  
> wrote:
> 
> So it seems like for some reason the pcb->snd_nxt is one-off.

This seems really strange.  For an active open, sending of the SYN packet 
advances pcb->snd_nxt by 1.  See the following code in tcp_output():

snd_nxt = lwip_ntohl(seg->tcphdr->seqno) + TCP_TCPLEN(seg);
if (TCP_SEQ_LT(pcb->snd_nxt, snd_nxt)) {
  pcb->snd_nxt = snd_nxt;
}

In tcp_priv.h:

#define TCP_TCPLEN(seg) ((seg)->len + (((TCPH_FLAGS((seg)->tcphdr) & (TCP_FIN | 
TCP_SYN)) != 0) ? 1U : 0U))

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

[lwip-users] TCP 2.0.2 pcb->snd_nxt is not updated somewhere?

[Simonas Kazlauskas]

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 0x
#define SYS_LIGHTWEIGHT_PROT1

#define LWIP_NETCONN1
#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_TCP0
// 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_UDP0
#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_ICMP60

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, );
  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