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