mcnamara: No, there is unfortunately no way to get around using another chip.
And I should have mentioned that the MSS given from this device/chip is at 536 bytes. And this communication takes place at a local network. And there are no ICMP messages indicating that this MSS is set too high.
From a Windows application, which too communicates with this device, the packet size used is 536 bytes (well, only when needed of course). The chip is terrible slow anyway, but doing all this extra ACK'ing is making it much worse.
I'm passing buffers to send() which, some of them, are quite a lot bigger than 536 bytes and still the biggest TCP packet seen has a data length of 268 bytes. And as said the window size announced is always at 536 bytes from the chip. Still I fail to see how this makes any sense.
DGPickett: I can see that send() is swallowing chunks bigger than 268 bytes. I have tried playing around with TCP options like NODELAY, and changing socket buffer sizes. And have tried to change some of the settings found at /proc/sys/net related to TCP, but still nothing have changed this behavior.
Thank you for helping, and more tips are welcome