Opened 6 years ago
Closed 6 years ago
#33 closed баг (fixed)
Данные, полученные из соединения, не передаются в порт RS-232
Reported by: | san | Owned by: | alx |
---|---|---|---|
Priority: | critical | Milestone: | 1 очередь |
Keywords: | Cc: |
Description
r136
Наблюдал, что после соединения Jun 4 05:33
, данные принятые из соединения не передаются в порт.
Прикрепляю скриншот с настройками порта и лог.
Attachments (3)
Change History (15)
by , 6 years ago
by , 6 years ago
comment:1 by , 6 years ago
comment:2 by , 6 years ago
В таком случае, предлагаю добавить какой-то отладочный вывод и попробовать поймать это снова.
comment:3 by , 6 years ago
В r138 добавлена разная дополнительная информация при выводе в лог. Вероятно, это поможет понять, что происходит. Предлагаю обновить пакет и снова воспроизвести проблему.
follow-up: 5 comment:4 by , 6 years ago
А не может быть эта проблема вызвана некорректной конфигурацией обнаруженой в comment:11:ticket:32
comment:5 by , 6 years ago
Replying to san:
А не может быть эта проблема вызвана некорректной конфигурацией обнаруженой в comment:11:ticket:32
Думаю, может, но все равно поведение мне не кажется нормальным.
comment:6 by , 6 years ago
Причина выяснена: запись в порт не производится по причине ненулевого значения TlsTty::want_read
- см. #32.
comment:7 by , 6 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
In 139/smartCrypto:
comment:8 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Баг воспроизвёлся на r139
Вчера я начал эксперимент.
Jun 6 13:08:57 3gd[400]: tls_tty.cpp:169: TLS connection established: TLSv1.2 GOST2012-GOST8912-GOST8912
Сегодня, примерно в Jun 7 4:30
я обнаружил, что данные из соединения в порт не передаются, наверняка баг проявился ранее, но проверять начал только в 4-30.
by , 6 years ago
Attachment: | server_messages_new added |
---|
comment:9 by , 6 years ago
Алексей сделал прошивку с отладочным выводом и записал в устройства, ждём пока воспроизведётся
comment:10 by , 6 years ago
Утром в 4:04 UTC обнаружил что за ночь проблема воспроизвелась.
Логи сервера положил xchange\alx\Test_and_bugs\3G_ticket33
comment:11 by , 6 years ago
Обнаружена ошибка: при старте 3gd не применялась настройка управления потоком, всегда устанавливался режим RTS/CTS.
После исправления ошибки проблема не воспроизвелась в течение 2.5 суток.
Анализ кода показал следующее.
Увеличение счетчика прочитанных из соединения байт говорит о том, что вызов tty->read() возвращает положительное значение.
Затем прочитанные данные помещаются в буфер rx_buffer1 и вызывается canWrite(serialTty), в которой вызывается serialTty->write().
В SerialTty::write() я вижу только одно условие, при котором данные "молча" поглощаются - это если последовательный порт не открыт (файловый дескриптор меньше нуля). Единственный способ сделать дескриптор меньше нуля - вызвать serialTty->close().
Предварительный вывод - последовательный порт был закрыт в процессе работы по неизвестной причине...
Не считая завершения программы, serialTty->close() вызывается при возникновении ошибки последовательного порта, когда вызывается Link::error(serialTty). При этом в лог выводится сообщение
Но такого сообщения в приложенном логе нет...
Таким образом, мой анализ зашел в тупик...