Hi,
I gave only a quick look at the log... I stopped at packet 167, that is
a malformed part of a TCP ECHO response sent by Xilinx board. This
message has some fields not OK: Ethernet frame type, IP version field,
and an IP service field. All of these are located in a 32bit word
starting at 0x
...and if it could help (and if I'm not wrong) that packet was correctly
retransmitted (packet 188), so maybe packet 167 has effectively been
altered after creation.
On 09/11/2015 10:29, Enrico Murador - Research & Development - CET wrote:
Hi,
I gave only a quick look at the log... I stopped a
Yes, same impression here, as Enrico said, your dup ACKs are yuour .65
machine asking for the lost frame to be retransmitted.
Your layer-2 driver seems to be broken.
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailma
/**
* MEM_USE_POOLS==1: Use an alternative to malloc() by allocating from a set
* of memory pools of various sizes. When mem_malloc is called, an
element of
* the smallest pool that can provide the length needed is returned.
* To use this, MEMP_USE_CUSTOM_POOLS also has to be enabled.
*/
Di
Would changing any of these have any bearing on the problem I am seeing
#define PBUF_POOL_SIZE 32
#define PBUF_POOL_BUFSIZE (4 * 1024)
#define MEMP_NUM_TCPIP_MSG_INPKT1024
Increasing the PBUF_POOL_SIZE seems to make it better.
Thanks,
Alhad
On Mon, Nov 2
n how to fix/improve it?
> Thanks,
> Tim
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
-- next part --
An HTML attachment was scrubbed...
UR
