I'm
still trying to fix this dropped packet issue. When I have debugging
on, it seems the only reason this is happening is bad TCP checksums.
Otherwise, I'm not seeing any problems. The other issue with this is
the delays caused by writing to my debug output device
when enabled seems to somewhat alleviate the dropped packet issue. I
have used the debugger to break when it finds a bad TCP checksum, and
indeed, the pbuf->payload contains data that I have no idea where it
came from. Right now, I'm simply throwing away all data I recieve just
for testing.
So, now for a Wireshark trace that I am baffled
by. First in the trace is a connection to a Shoutcast streaming radio
server. 192.168.0.169 is the lwIP board. It starts to choke by the
11th packet. Then, starting at packet 40 is a connection to a simple
Windows app I wrote that waits for a connection from my lwIP board,
then starts sending packets to lwIP. My computer is 192.168.0.112.
The data simply cycles from 0x0 to 0xFF. This closely simulates the
behavior of the streaming audio I believe, the main difference being
that this is coming across a LAN; the streaming audio is coming over
the Internet. This stream is error-free with *no* dropped packets that
I can see, yet is moving data *much* faster!
Honestly,
I had hoped it would behave the same so I could root-cause the issue
with known data. I don't understand what is occurring here. The first
capture chokes after the server sends very little data, yet I have
PBUF_POOL_BUFSIZE=256 and PBUF_POOL_SIZE=24, so it seems I should have
plenty of buffers. If anyone cares to look at the attached capture,
that would be greatly appreciated. It's a zip file, so rename the extension.
|
capture.piz