14.06.2017 03:19
Puzatik
 
Упростили схему: касса - роутер - инет.
С MTU на роутере, который выпускает в инет, всё хорошо.
Цитата:
sh int Vlan200 | i MTU
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
sh int Vlan300 | i MTU
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec
Всё равно не уходят.

Посмотрели на двух кассах первые неотправленные чеки.
Обычные продажи, 15 и 17 позиций. Среди отправленных бывало и больше.

Всё настроено как в документе "Запуск пилота ОФД.pdf".

Есть предположение что касса пытается отправить сразу несколько чеков, а не по одному, и Такском их не принимает в таком виде. Суппорт Такскома по этому поводу ничего сказать не может: "нам чеки не пришли, ничем не можем помочь". Просил перевести на специалистов более высокого уровня, сказали "не можем".
14.06.2017 06:23
EugeneT
 
попингуйте ОФД пакетами на 1500 байт, гляньте результат для проверки
14.06.2017 10:25
Puzatik
 
Такском фильтрует пинг.

Адрес их сервера - f1.taxcom.ru
14.06.2017 12:12
EugeneT
 
traceroute f1.taxcom.ru 1500
прямо от кассы. во всяком случае что происходит вплоть до gw-taxcom.ru.rt-comm.ru увидеть можно. А вот фильтровать icmp это очень плохо и чревато глюками с TCP, пруф
Цитата:
При блокировке ICMP сообщений типа 3.4 (fragmentation needed and DF set)
возможно нарушение нормальной фрагментации пакетов, что вполне может
проявляться как внезапная остановка передачи данных большого объема и разрыв
сесcии по таймауту, например, если на пути трафика встречается туннель.
14.06.2017 16:29
grafstroganov
 
для информации
Примечание: Для всех ФД, кроме кассового чека и БСО, длина данных документа не должна превышать 4096 байт. Для кассового чека и БСО длина данных документа не должна превышать 32768 байт. Для подтверждения оператора длина данных не должна превышать 512 байт
поэтому 1500 байт это ни о чем, должно бегать
15.06.2017 10:06
Puzatik
 
Похоже нужно дампить траффик и смотреть что внутри пакета.
15.06.2017 15:03
grafstroganov
 
вопрос такой. Чеки не уходят выборочно? или перестали вообще? Если вообще - обращайтесь к ЦТО, - сдавайте ФН на экспертизу. По признаку похоже на выход из строя ФНа, он не правильно криптует и поэтому и "Unable to receive title". У нас таких бракованных ФНов свыше 120 шт. :( уже.
15.06.2017 18:10
~Guest~
 
Написал в другой теме порядок. Со слов ОФД-ников, ФН валится на каком то из чеков и все остальные собираются за ним в очередь в памяти устройства.

Причины и следствия пока неизвестны, что вызывает такой коллапс.
16.06.2017 04:18
Puzatik
 
Перестают вообще. Просто копятся в ФН.

В то же время, если подключить этот же Пирит к компу с ComProxyWindows, то все накопившиеся чеки благополучно улетают в ОФД.

Какую магию делает ComProxyWindows?
16.06.2017 06:44
EugeneT
 
Цитата:
Puzatik Какую магию делает ComProxyWindows?
Фрагментирует пакеты?

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.