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:
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=4
59 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=4
60 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=4
61 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:
address@hidden
> To: address@hidden
> 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
> address@hidden
>
https://lists.nongnu.org/mailman/listinfo/lwip-users