Opened 5 years ago

Closed 5 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)

web.png (101.7 KB ) - added by san 5 years ago.
messages (198.5 KB ) - added by san 5 years ago.
server_messages_new (121.6 KB ) - added by san 5 years ago.

Download all attachments as: .zip

Change History (15)

by san, 5 years ago

Attachment: web.png added

by san, 5 years ago

Attachment: messages added

comment:1 by alx, 5 years ago

Анализ кода показал следующее.

Увеличение счетчика прочитанных из соединения байт говорит о том, что вызов tty->read() возвращает положительное значение.

Затем прочитанные данные помещаются в буфер rx_buffer1 и вызывается canWrite(serialTty), в которой вызывается serialTty->write().

В SerialTty::write() я вижу только одно условие, при котором данные "молча" поглощаются - это если последовательный порт не открыт (файловый дескриптор меньше нуля). Единственный способ сделать дескриптор меньше нуля - вызвать serialTty->close().

Предварительный вывод - последовательный порт был закрыт в процессе работы по неизвестной причине...

Не считая завершения программы, serialTty->close() вызывается при возникновении ошибки последовательного порта, когда вызывается Link::error(serialTty). При этом в лог выводится сообщение

--> Link::error(): serial link!

Но такого сообщения в приложенном логе нет...

Таким образом, мой анализ зашел в тупик...

comment:2 by san, 5 years ago

В таком случае, предлагаю добавить какой-то отладочный вывод и попробовать поймать это снова.

comment:3 by alx, 5 years ago

В r138 добавлена разная дополнительная информация при выводе в лог. Вероятно, это поможет понять, что происходит. Предлагаю обновить пакет и снова воспроизвести проблему.

comment:4 by san, 5 years ago

А не может быть эта проблема вызвана некорректной конфигурацией обнаруженой в comment:11:ticket:32

in reply to:  4 comment:5 by alx, 5 years ago

Replying to san:

А не может быть эта проблема вызвана некорректной конфигурацией обнаруженой в comment:11:ticket:32

Думаю, может, но все равно поведение мне не кажется нормальным.

comment:6 by alx, 5 years ago

Причина выяснена: запись в порт не производится по причине ненулевого значения TlsTty::want_read - см. #32.

comment:7 by alx, 5 years ago

Owner: set to alx
Resolution: fixed
Status: newclosed

In 139/smartCrypto:

Исправлена ошибка: не инициализировались две переменные в конструкторе,
используемом в режиме "сервер". Closes #32, #33.

comment:8 by san, 5 years ago

Resolution: fixed
Status: closedreopened

Баг воспроизвёлся на 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 san, 5 years ago

Attachment: server_messages_new added

comment:9 by san, 5 years ago

Алексей сделал прошивку с отладочным выводом и записал в устройства, ждём пока воспроизведётся

comment:10 by san, 5 years ago

Утром в 4:04 UTC обнаружил что за ночь проблема воспроизвелась.
Логи сервера положил xchange\alx\Test_and_bugs\3G_ticket33

comment:11 by alx, 5 years ago

Обнаружена ошибка: при старте 3gd не применялась настройка управления потоком, всегда устанавливался режим RTS/CTS.

После исправления ошибки проблема не воспроизвелась в течение 2.5 суток.

comment:12 by alx, 5 years ago

Resolution: fixed
Status: reopenedclosed

In 140/smartCrypto:

Исправлена ошибка: при старте 3gd не применялась настройка режима управления потоком.
Всегда устанавливался режим RTS/CTS. Closes #33.

Note: See TracTickets for help on using tickets.