Re: [lwip-users] netconn api problem

[Tyrel Newton]

> You could add a UDP broadcast after the big write and use that in WireShark
> to find the smaller packet that follows.

I like the UDP broadcast approach as it will give something unique to trigger 
wireshark (and potentially my python scripts) against.

> Wouldn't you hate to go down this
> path for a long time to find out byte ends up being in the WireShark
> capture?  Sure, I agree, it's 99.9% sure not going to be there.  But the
> Wireshark capture might show other problems in and around that area.  And
> are there errors in the capture or is it clean?
> 
> Can you shrink iteratively the size of the first large send until the 2nd
> send works?  This might point to some size or boundary condition when the
> problem appears.

Sure, but the problem is random enough that I'm not sure I could reproduce 
anything useful in a controlled manner. At this point, I really think the 
problem is a third party on our network that broadcasts something while lwIP is 
sending the large chunk of data. And that something is somehow screwing with 
lwIP's internals. I'm sure that turning on asserts and debugging in lwIP would 
show what's wrong, but that would change the dynamics of the situation by 
bringing throughput to a screeching halt.

I'll add the UDP broadcast thing and capture it my python scripts in parallel, 
hopefully that will shed some light.

Thanks for the tip!
Tyrel