Thanks Michael,I had actually missed that and have now applied it, which seems to have fixed the intermittent speed problem, but I am still having some issues. After a number of successful packets, everything seems to stall. Looking at the wireshark capture, and TCP Output/ Input debugging here: https://docs.google.com/uc?authuser=0&id=0B9QDXbfPYFfeQVNyMG81MFdUMW8&export=download It looks as though lwip stops acking, and the python end keeps retransmitting the same packet. 58 2.257102 192.168.1.64 192.168.1.24 TCP 58 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=459 2.556697 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=460 3.156804 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=461 4.356948 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4 In the lwip logs, all is well up until the first line saying: tcpip_thread : tcp_receive: duplicate seqno 664403702, so its receiving the retransmitions, however straight after this, the logging reports tcpip_thread : tcp_output: sending ACK for 664403706 which is in the function tcp_send_empty_ack() Presumably this ack has already been sent, along with the 2 byte reply data before (although this doesn't seem to be printed out as debug info), and due to there currently being more data to send, its just sending an empty ack() - fine. However, none of these acks appear on the wireshark trace. The filter is set to "eth.addr eq 22:a3:11:14:65:22", but even without any filtering and looking by eye, I cannot find these acks. I am suspecting this may well be a driver bug, but I have yet to manage to narrow it down. I've turned on all DMA error interrupts and have a handler with a loops in it that should get hit if there is anything wrong as far as the MAC goes, but so far it has not been hit. So its either the driver, or or a problem with lwip itself. But these packets never seem to get on the wire as far as I can see? Any suggestions would be greatly appreciated. Thanks Rob.
> Date: Mon, 6 Oct 2014 08:36:39 -0700 > From: [email protected] > To: [email protected] > Subject: Re: [lwip-users] lwip stall > > Hi, > > actually, STM made only a partial bugfix. I've ran in the same mistake. The > do/while loop in ethernetif_input() is still missing in the CubeMX software. > > > void ethernetif_input( void const * argument ) > { > struct pbuf *p; > struct netif *netif = (struct netif *) argument; > > for( ;; ) > { > if (osSemaphoreWait( s_xSemaphore, TIME_WAITING_FOR_INPUT)==osOK) > { > do > { > p = low_level_input( netif ); > if (p != NULL) > { > if (netif->input( p, netif) != ERR_OK ) > { > pbuf_free(p); > } > } > }while(p!=NULL); > } > } > } > > > > -- > View this message in context: > http://lwip.100.n7.nabble.com/lwip-stall-tp23366p23370.html > Sent from the lwip-users mailing list archive at Nabble.com. > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
