I finally figured it out. As *stevestrong* suggested problem was in my low-level driver. The problem actually looked like this: - any amount of ping is fine, ping -f is fine for any given time - low-frequency and small tcp packets are fine - however, if I tried to send the same small (about 50-60 bytes) packets frequently (more than a 10 times per second) - everything broke.
How did it broke? Well, in wireshark I saw a packet with a bunch of zeros at the end. And that packet was not ACKed by the server. It baffled me because server was just a netcat, it should ACK anything. It turned out that wireshark doesn't show (or check) ethernet frame checksum by default! It needs to be enabled. So this last packet had incorrect ethernet CRC and that's why it wasn't ACKed. The actual problem was in my low-level driver. I pulled it together myself using an example; in example there was one special array for eth sending buffer. That array should be aligned by 4 and it is only accessed by 4 bytes. But for some reason it was declared as uint8_t (with __attribute_align__). Naturally I made it uint32_t. And forgot to modify one function that copied pbuf's into it :( So when no pbuf chaining occured, packet was copied correctly and everything worked. But if two pbuf were chained, counter variable went mad and copied memory from beyond pbuf (which just happened to always have zeros in it). -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
