Nem az a hiba, hanem az, hogy a második write() visszatérési értéke nincs ellenőrizve. Az ethtool -K eth0 tx off azt csinálja, hogy a kiküldött IP-csomagok checksum számítását a CPU csinálja, az ethtool -K eth0 tx on pedig ugyanezt a hálózati kártyára delegálja.
Összességében az a baj, hogy újabb vasakon a hálózati kártyák olyan intelligensek, hogy ha van offload, akkor a \n-t kiíró write() néha nem sikerül, a write() "most épp elfoglalt vagyok, próbáld meg később" hibaüzenettel tér vissza. Mivel az alkalmazás ezt nem vette észre, így simán tovább akart működni, a túloldal meg, ahol a protokoll szerint várták volna a \n-t nem tudta, hogy mi van, ezért furcsa dolgokat művelt.
tcpdump kimenetében finoman szólva nehéz észrevenni, hogy egy \n néha hiányzik a string végéről (bár végül ezt vettem észre), mert ugye a TCP intelligens és ha sikerül, akkor a két write()-ot egy csomagban akarja elküldeni...