Я очень сомневаюсь, что проблема только в вашей программе.Быстрая проверка с netcat в качестве сервера, к которому подключается ваша немодифицированная программа, показывает:
$ nc -l 7046 | hd
00000000 33 39 30 38 30 30 38 30 33 38 30 30 30 30 30 30 |3908008038000000|
00000010 30 30 30 30 30 30 30 34 30 30 30 30 30 30 30 30 |0000000400000000|
00000020 30 30 30 30 30 30 30 30 30 30 30 37 30 39 32 32 |0000000000070922|
Другими словами - было получено только то, что вы ожидали отправить.
Дамп с сервера интересен:
30 38 30 30 38 30 33 38 30 30 30 30 30 30 30 30 0800803800000000
В нем отсутствует 39, отправленный в начале.Это заставляет меня поверить, что сервер интерпретирует это как длину данных, которые вы отправляете, и согласно информации, которую я нашел в Wireshark: ISO 8583-1 , это на самом деле имеет место при использовании TCP в качестве передачипротокол.
Только похоже, что сервер не использует ASCII 39 в качестве длины, как вы предполагали, а вместо этого - двоичное представление 0x3339, то есть 13113 десятичное, которое хорошо соответствует вашему утверждению "... носервер - приемник более 13 Кбайт ".И сервер мог бы тогда слепо принять эту длину сообщения без проверки фактической длины - что довольно опасно, как видно из атаки Heartbleed .И, как в Heartbleed, у вас фактически есть унифицированный буфер, который, как видно из вашего вопроса, в настоящее время содержит части двоичного файла ELF, но может также содержать некоторые конфиденциальные данные.
В любом случае, ваш код, вероятно, должен отправить длину сообщения вдвоичный файл, как и ожидалось сервером.Это может выглядеть так:
import struct
...
msg = b'080080380000000000000400000000000000000007092250121018001'
s.send(struct.pack('>H',len(msg)) + msg)