ФЗ 54 и ККМ ПИРИТ : Кристалл УКМ

Puzatik · █ 14.06.2017 03:19

Упростили схему: касса - роутер - инет.
С 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".

Есть предположение что касса пытается отправить сразу несколько чеков, а не по одному, и Такском их не принимает в таком виде. Суппорт Такскома по этому поводу ничего сказать не может: "нам чеки не пришли, ничем не можем помочь". Просил перевести на специалистов более высокого уровня, сказали "не можем".

EugeneT · █ 14.06.2017 06:23

попингуйте ОФД пакетами на 1500 байт, гляньте результат для проверки

Puzatik · █ 14.06.2017 10:25

Такском фильтрует пинг.

Адрес их сервера - f1.taxcom.ru

EugeneT · █ 14.06.2017 12:12

traceroute f1.taxcom.ru 1500
прямо от кассы. во всяком случае что происходит вплоть до gw-taxcom.ru.rt-comm.ru увидеть можно. А вот фильтровать icmp это очень плохо и чревато глюками с TCP, пруф

Цитата:

При блокировке ICMP сообщений типа 3.4 (fragmentation needed and DF set)
возможно нарушение нормальной фрагментации пакетов, что вполне может
проявляться как внезапная остановка передачи данных большого объема и разрыв
сесcии по таймауту, например, если на пути трафика встречается туннель.

grafstroganov · █ 14.06.2017 16:29

для информации
Примечание: Для всех ФД, кроме кассового чека и БСО, длина данных документа не должна превышать 4096 байт. Для кассового чека и БСО длина данных документа не должна превышать 32768 байт. Для подтверждения оператора длина данных не должна превышать 512 байт
поэтому 1500 байт это ни о чем, должно бегать

Puzatik · █ 15.06.2017 10:06

Похоже нужно дампить траффик и смотреть что внутри пакета.

grafstroganov · █ 15.06.2017 15:03

вопрос такой. Чеки не уходят выборочно? или перестали вообще? Если вообще - обращайтесь к ЦТО, - сдавайте ФН на экспертизу. По признаку похоже на выход из строя ФНа, он не правильно криптует и поэтому и "Unable to receive title". У нас таких бракованных ФНов свыше 120 шт. :( уже.

~Guest~ · █ 15.06.2017 18:10

Написал в другой теме порядок. Со слов ОФД-ников, ФН валится на каком то из чеков и все остальные собираются за ним в очередь в памяти устройства.

Причины и следствия пока неизвестны, что вызывает такой коллапс.

Puzatik · █ 16.06.2017 04:18

Перестают вообще. Просто копятся в ФН.

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

Какую магию делает ComProxyWindows?

EugeneT · █ 16.06.2017 06:44

Цитата:

Puzatik ➤ Какую магию делает ComProxyWindows?

Фрагментирует пакеты?