Thanks for the responses.
I cannot discount a problem in the driver, that is a likely area for the missed/dropped frame. With the high rate of traffic required to cause this failure it will be a bit more difficult pinpointing this failure at that level, but I am adding some instrumentation now for this.
To answer your questions, I am running an OS (Xilkernel), with multiple threads. I am using the socket API with one thread writing to the socket and another thread reading from the socket. I have attempted to protect the calls to lwip for thread safety. Example:
ReadThread
{
select(…,&timeout)
mutex_lock()
recv(…)
mutex_unlock()
}
WriteThread
{
mutex_lock()
send(…)
mutex_unlock()
}
I will take a look at the driver failing to find a free RX slot. Perhaps there is a silent drop in this case.
Thanks!
From: address@hidden [mailto:address@hidden On Behalf Of Enrico Murador - Research & Development - CET
Sent: November-11-15 5:12 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Missed Ethernet Frame
Dear Colin,
If I can add one possible cause to the list, maybe your netif driver ran out of receive buffers. This could happen e.g. if you advertised a too big TCP receive window. To check this, maybe you can place a breakpoint on your low level driver at the code point (if you already have one, or if you can manage to make one) it fails to find a free RX slot.
I'm using lwIP since 1.3.2 and I can confirm I've never seen a missing packet in normal use.
Enrico
On 10/11/2015 18:37, Sergio R. Caprile wrote:
My best bet is that lwIP is not missing an ethernet frame, but you are.
Your frame enters your chip, goes to your driver and is then sent to
lwIP, which runs in your system (your port of it), then the TCP data (I
guess you are using TCP because you talk about ACKs) is sent to your
application, and your application must tell the stack the data is done
so lwIP can ACK. Let's put this last one aside as it is a bit more involved.
Have you checked between your driver and lwIP ?
Have you checked between your driver and your chip ?
Is your port a good one ? Do you know it works OK ?
BTW, are you running with or without an OS (NO_SYS=?)
Are you honoring the thread-safety recommendations ? That includes not
calling lwIP from main loop and interrupt handler at the same time.
This list has seen lots of reports from people running vendor provided
demos with broken drivers that miss (at least) the second frame on a
burst because they don't poll the chip for more data after an interrupt,
and so on.
Try to be more specific, 1.4.1 runs more than OK, and git HEAD has lots
of bugfixes, you should upgrade anyway, but to me this problem is not
lwIP's.