Валится SQL при возвратах, аннулировании и сторно : УКМ-4

Mtirt · █ 23.09.2015 10:26

Это порт кассы, а не сервера...

DJRampAge · █ 23.09.2015 11:02

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

внимательнее посмотрел логи и сравнил ещё раз запрос-ответ.
как я понял, сам сервер при соединении через сокет отдаёт неверный порт подключения и по этим данным касса, естественно, не может установить соединение.

есть у кого мысли по поводу того, где можно отредактировать эти данные?

лог кассы:

логи сервера:

DJRampAge · █ 23.09.2015 11:06

извиняюсь за то, что плодю пложу развожу много постов.
в момент отказа запуска возврата на экране кассы появляется окно ошибки, где имя пользователя ukm000000002059pc, которое отдаёт сервер. соответственно, проблема именно в сервере, т.к. совпадают все данные подключения, но отдаётся неверный порт, в который пытается стучаться касса.

OlegON · █ 23.09.2015 11:16

А если netstat -an или tcpdump посмотреть в момент отрыва, он правда на 0 пытается лезть? не уверен, что ему удастся создать такой пакет, но вдруг... Просто иногда 0 обозначает бродкаст или "по умолчанию", а по умолчанию там честный 3306.

DJRampAge · █ 23.09.2015 11:23

ок, попробую тогда анализатором пакетов зацепиться за момент попытки соединения

akonev · █ 23.09.2015 11:44

время синхронизировано на кассе и сервере?
я к тому, что мы точно можем рассчитывать на временные отметки в логах для определения очередности?

а так-то да, пока похоже на глюк сервера.

кстати! сервер в принципе принимает у вас подключения извне к MySQL?
я бы начал с создания пользователя и проверки возможности подключения.

DJRampAge · █ 23.09.2015 11:54

да, сервер через sql manager принимает соединение по 3306 порту по стандартным имени и паролю. по данным временного подключения не пускает, ибо пароля не знаю.
время на сервере и кассе примерно одинаково, но не синхронно, т.к. кассы берут время с другого сервера.

DJRampAge · █ 23.09.2015 12:27

от техподдержки с+ получил, наконец, ответ. будем его прорабатывать.

Цитата:

10:35:18: 0x000016f8: INFO: NtlpTrnManager: Answer for 192.168.1.20
host: remotehost, db = ukmserver, port = 0, user = ukm00000002059pc

в данном случае port = 0 - значит использовать порт по умолчанию, а порт по умолчанию 3306

в логе
10:37:53: 0x00004000: WARNING:
debug#/usr/local/storage/home/ukm/build-br-65-2015_07_13_18_26_15/ukm/libukm/ccontext_default.cpp(706)
HandleReturnbyreceiptBasic: Ошибка при подключении БД. Параметры
подключения: host=192.168.1.20, user=ukm00000002059pc, db=ukmserver,
port=0: Error(2003) Can't connect to MySQL server on '192.168.1.20'

при возврате при попытке подключения в mysql 192.168.1.20, получаем Can't connect to MySQL server on '192.168.1.20'

проблема скорей всего в сети

попробуйте сделать возврат получите ошибку вида (см. выше)

на сервере в бд mysql в таблице user будет запись для пользователя ukm00000002059pc (взять из последних логов)
поставьте ему пароль такой же как у root

и попробуйте подключиться с кассы к mysql на 192.168.1.20 с логином ukm00000002059pc и паролем CtHDbCGK.C
скорей всего получите ошибку Can't connect to MySQL server on '192.168.1.20'
причем если локально подключаться с 192.168.1.20 в mysql с такими данными все ок

=> кто-то между кассой и сервером блокирует порт 3306

DJRampAge · █ 23.09.2015 16:28

вчера прописал всевозможные правила разрешений в брандмауэре - не помогло. сейчас отключил доменное наблюдение - не помогло. отключил слежение ещё и частных и гостевых сетей.
постучался телнетом в различных направлениях на порт 3306. телнет цепляется.
попробовал возврат - работает.

на данный момент проблема решена. если это оказалось не то решение, уважаемые коллеги, напишу здесь.