Проблемът се получава само при получаване.
Всъщност аз съм HTTP клиент и за да получа първо пращам заявка, но тя е малка (GET + url...).

По-точно става следното:
1. отварям сокет
2. пращам заявка, тя стига до сървъра и сървърът накуп изпраща целия файл щото обикновено файлът е по-малък от TCP прозореца, т.е. не му трябва потвърждение..
3. Поне един пакет пристига навреме и модула ми го дава
4. Понякога на един следващите TCP пакети модула се замисля и нищо не ми дава. Това че е на границата на TCP пакет го знам сравнявайки лога на Wireshark-а на сървъра и лога на получените данни в процесора.
5. След известно време (15-30 секунди) комуникацията се възстановява - аз от процесора получавам оставащите данни, сървърът от друга страна получава потвърждение че данните са получени.

В цялата тая работа няма грешни или липсващи данни. И от към сървъра лога изглежда чист без препредаване на пакети и от към терминала аз си получавам правилно данните. Единствено тия паузи са проблем, щото клиента се дразни. То нормално да се дразни де... става въпрос за браузър - кликаш на някакъв линк и чакаш по 30 секунди да ти зареди една тъпа малка страничка... Гадно е

Миро, не ти знам модема - но поведението, което описваш, съм го срещал
при калпав handshake между хоста и модема. Нещо като липсваща RTS/CTS връзка,
или прекалено бавна реакция на изпращача спрямо CTS, или забавяне на RTS
откъм получаващия - гледал ли си ги как се държат тия жици? Един пропуснат байт
и пакета се discard-ва и няма кой да го log-не (не знам дали това е възможно в
случая ти). Или, ако караш на XON/XOFF, прекалено късен XOFF от получатреля
би имал същия ефект.
Само спекулации на базата на опит в *подобни* ситуации.

Разбира се това ми е минавало през ума... Хендшейкът е единственият начин да блокирам модула и той да не ми дава данните.
Бих могъл да изключа хендшейка (щото той е хардуерен на UART-a ми) за да съм на 100% сигурен, но аз и така съм достатъчно сигурен защото на UART му зареждам DMA и няма причина то да накъсва трансфера. Още по-малко пък за времена от порядъка 15-30 секунди - това са зверски големи паузи, ако беше в милисекунди да се съмнявам...
Другото което отхвърля тая теория е, че паузата става точно на границата на TCP пакет - аз от към процесорчето няма откъде да знам къде е края на пакета че точно тогава да свалям хендшейка...

Ако питаш мен отвсякъде си мирише на бъг в модула.

Най-вероятно в една нишка си приказват с TCP-стека и правят сокета, а данните после отиват в друга щото аз ползвам чист UART, но може да е през CMUX или пък да отиват към Питонски интерпретатор. Щеше ми се да знам какъв ОС ползват и да видя какви инструменти имат - дали сигнали, евънти или опашки някакви, но най-вероятно е нещо базирано на сигнали.
Като получат пакет сигурно проверяват дали дестинацията е заета и ако е заета, викат блокиращо чакане за сигнал за освобождаване.
Това е стандартна практика, но има проблем ако сигналът се получи точно след проверката за заето и преди влизането за чакане. Тогава нишката остава излъгана - мисли си че ресурсът е зает и като се освободи ще получи сигнал, но дефакто пропуска сигнала и само таймоут може да я изкара от чакането.
В случай че скоростта с която идват пакетите и скоростта с която се изхвърлят към мен се различават много - няма проблем. Но при 38400 за UART-а времената стават съизмерими, демек нишката по едно и също време получава следващия пакет от сокета и сигнала за изпращане на предишния пакет по UART-a. И когато се случи точно между проверката и влизането в чакане става инфекцията...

Аз затова винаги като правя сигнализация избягвам подобни проверки. По-точно те пак си ги има, но са вкарани в ОС-а така че никой не може да ме прекъсне между проверката дали да се съспендне нишката и фактическото съспендване.

Заради хандшейка се губи пакет (ppp?), примерно твой "ack" сегмент. След
това чакаш 30 секунди за повторение - малко вероятен сценарий (30 секунди
за първи retransmission ми се виждат невероятни дори за мобилен оператор).
По-вероятен подобен сценарий - заради калпав хандшейк се изгубват два пакета,
бързо следващите един след друг оригинален и преповторения (сиреч кои да е два
пакета от тая транзакция, колкото да не хване нито първия, нито повтореният сегмент).
След това чакаш 30 секунди за 3-то повторение.

Аз първо бих погледнал какво правят двете RTS/CTS жици в момента, когато
чакането започне, после всичко останало.

RTS/CTS на UARTa са задължителни при ъплоуд на питонските скриптове (115200 бода). Ако там има нещо гнило - щях да бълвам змии и гущери .
От друга страна, тествал съм безпроблемно FTP трансфер до към 200кВ и няма такива закъснения.
Това ми намирисва на настройки.

Както казах без да си залагам топките мисля че проблемът не е в хендшейка... Бих могъл да го докажа, но за да го подслушам трябва да разфасовам устройството а и модулите са BGA на сравнително малка платка. Та сега не ми се занимава, ако някога ми остане време ще го погледна пак. Но се съмнявам да е хендшек проблем. И за настройките също - пробвах всичко... По-скоро ако е при мен може да се дължи на факта че за настройките ползвам мултисокет команди (CGDCONT, SCFG, SGACT, ..) a пък сокета го отварям със старата SKTD.

Както и да е, за сега 19200 мен ме устройства, споменах проблема щото и други казаха че са забелязвали подобни паузи и може да им е от ползва...