Rejecting due to inhibit returning by inhibit denomination error

Вернуться в «Купюроприемники»

Что с купюроприемником? Возврат купюры из-за торможения (код ошибки: 0x68)

Сообщение Zlyd » 31 май 2012, 03:52

продавщица пожаловалась, что терминал не прининял деньги у клиента. посмотрел лог, а там вот такое:

это что означает?

Сообщение SashkaDotCom » 31 май 2012, 06:54

Сообщение Женя » 31 май 2012, 08:27

Сообщение LSD » 31 май 2012, 10:33

Сообщение Equinox » 31 май 2012, 11:30

Сообщение Zlyd » 31 май 2012, 11:51

продавец говорит, что это была пятисотка, она не прошла. затем попытались стольник и полтинник, но и они не прошли.

чувствую, что пора делать ТО

проанализирую логи за несколько дней

Сообщение Zlyd » 31 май 2012, 12:14

c ночи запросил логи за три последних дня. сейчас поиском пробежался, везде эти ошибки.

что менять линзы или резинки? или и то и другое?

Сообщение LSD » 31 май 2012, 13:47

Злыд писал(а): c ночи запросил логи за три последних дня. сейчас поиском пробежался, везде эти ошибки.

что менять линзы или резинки? или и то и другое?

Гуру может скажут что-то другое, но мне приходилось менять линзы только после клея — не было такой затертости. Замена резинок помогает от зажевываний.
Я бы сначала почистил от души *_

Сообщение mikel » 31 май 2012, 20:54

Злыд писал(а): c ночи запросил логи за три последних дня. сейчас поиском пробежался, везде эти ошибки.

что менять линзы или резинки? или и то и другое?

И то, и то. Стоит-то копейки.
Хотя резинки по состоянию.

Шестерни посмотреть. Если профиль зуба треугольный, то менять скоро (у нового выпуклые грани).

Сообщение Шурик » 20 сен 2013, 15:34

Сообщение karlson » 20 сен 2013, 20:41

Сообщение unknown » 20 сен 2013, 21:53

Сообщение ALEXTMN » 05 окт 2013, 13:18

Сообщение VKP-80 » 05 окт 2013, 21:26

Сообщение Гость » 18 окт 2013, 23:25

ТАкая же история.

10:18:39 Возврат купюры из-за торможения (код ошибки: 0x68).

Почистил, Заменил Ролики и даже втулки.
не помогло.

В сервисе сказали что это дата кабель.
Заменил (перепоял).
не помогло.

Менял COM порты.
НИЧЕГО не помогает.

Подскажите что делать?.
зае#$%^&*лся уже.
Купюра полностью заглатывается и выплевывается.
Прошивка 1337 G

Сообщение VKP-80 » 18 окт 2013, 23:39

Сообщение e332va » 18 окт 2013, 23:55

Злыд писал(а): продавщица пожаловалась, что терминал не прининял деньги у клиента. посмотрел лог, а там вот такое:

это что означает?

ТАкая же ерунда была, продавщица позвонила, мол деньги у клиента зажевало, приехал, открыл, 50 рублей банка приколов, в логе было именно также.

Источник

Rejecting due to inhibit returning by inhibit denomination error

Controller Command Code Bill-to-Bill unit Response Data

Indicates state of the Bill-to-Bill unit and its activity. The Bill-to-Bill unit will in most cases send 3 bytes of data (unless stated otherwise), but the package length should be determined according to the length of the frame (refer to the 2.2 for the message format).

The following data can be received from Bill-To-Bill unit in response to the POOL command:

POWER UP – The state of a B2B after a power up.

POWER UP with Bill in Validator — Power up with bill in the Bill Validator head/upper chassis channel. The bill(s) will be returned back to the bezel during initialization phase.

POWER UP with bill in Chassis – Power up with bill in switch area, stacker area or in dispenser. The bill will be either returned to the bezel or stacked/dispensed with the credit message reported if necessary.

INITIALIZE – The state in which Bill-to-Bill unit initializes itself after a RESET command from the Controller.

IDLING – The state in which Bill-to-Bill is ready accept bills.

ACCEPTING – In this state Bill-to-Bill unit continues to validate a bill and determine its denomination.

STACKING – In this state, the Bill-to-Bill unit transports a bill from Escrow position to the recycling cassette or to the drop cassette and remains in this state until the bill is stacked or returned if jammed.

RETURNING – In this state Bill-to-Bill unit transports a bill from Escrow position to front bezel and remains in this state until the bill is removed by customer or returned if jammed.

DISABLED – The Bill-to-Bill unit has been disabled by the Controller and also the state in which Bill-to-Bill unit is after initialization.

HOLDING – The state, in which the bill is held in Escrow position after the HOLD command from the Controller.

BUSY — The state in which the Bill-to-Bill unit is unable to act on any command.

REJECTING — Rejecting due to Insertion. Insertion error

REJECTING — Rejecting due to Magnetic. Magnetic error

REJECTING — Rejecting due to bill

Remaining in the head. Bill remains in the head, and new bill is rejected.

REJECTING — Rejecting due to Multiplying. Compensation error/multiplying factor error.

REJECTING — Rejecting due to Conveying. Conveying error.

REJECTING — Rejecting due to Identification1. Identification error.

REJECTING — Rejecting due to Verification. Verification error.

REJECTING — Rejecting due to Optic. Optic error.

REJECTING — Rejecting due to Inhibit. Returning by inhibit denomination error.

REJECTING — Rejecting due to Capacity. Capacitance error.

REJECTING — Rejecting due to Operation. Operation error.

REJECTING — Rejecting due to Length. Length error.

REJECTING — Rejecting due to UV optic. Banknote UV properties do not meet the predefined criteria.

REJECTING — Rejecting due to unrecognised barcode . Bill taken was treated as a barcode but no reliable data can be read from it.

REJECTING — Rejecting due to incorrect number of characters in barcode. Barcode data was read (at list partially) but is inconsistent.

REJECTING — Rejecting due to unknown barcode start sequence. Barcode was not read as no synchronization was established.

REJECTING — Rejecting due to unknown barcode stop sequence. Barcode was read but trailing data is corrupt.

DISPENSING -B2B moves the bill(s) from recycling cassette to dispenser.

DISPENSING -B2B transitions into this state when dispensed bills become accessible to customer.B2B remains in this state until customer takes the bill(s) from dispenser.

UNLOADING – B2B is moving the bill(s) from recycling cassette to drop cassette.

UNLOADING – B2B is moving the bill(s) from recycling cassette to drop cassette. Number of bills requested is more than the number of bills in the cassette.

SETTING TYPE CASSETTE – The unloading of the recycling cassette is carried out, and if it is necessary, reprogramming EEPROM.

DISPENSED – Dispensing is completed.

Number of Bills

UNLOADED – Unloading is completed.

INVALID BILL NUMBER – Required number of bills is incorrect.

SET CASSETTE TYPE – Setting recycling cassette type is completed.

INVALID COMMAND – Command from the Controller is not valid.

DROP CASSETTE FULL – Drop Cassette full condition.

DROP CASSETTE REMOVED – The B2B unit has detected the drop cassette to be open or removed.

JAM IN ACCEPTOR – A bill has jammed in the bill path.

JAM IN STACKER – A bill has jammed in drop cassette.

CHEATED – The Bill-to-Bill unit detected attempts by to user to cheat.

Generic BB ERROR codes. Followed by failure description bytes.

Источник

18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1

Bug Description

[Impact]
Under the following conditions, https connections using client cert authentication will suffer a long delay (about 15s if modreqtimeout is enabled, more if it is disabled):
* TLSv1.2
* client certificate authentication in use
* a Location, Directory, or other such block defining the client certificate authentication for that block only, differing from the SSL vhost as a whole

This was triggered by the OpenSSL 1.1.1 SRU and was caused by this openssl change in SSL_MODE_AUTO_RETRY from disabled to enabled by default: https:/ /github. com/openssl/ openssl/ blob/a4a90a8a3b dcb9336b5c9c15d a419e99a87bc6ed /CHANGES# L121-L130

It helps if you have lxd up and running. Otherwise, a VM or even bare metal host also works, as long as you stick to the «ubuntu» hostname.

Launch a container for the release you are testing. The command below is for bionic:
$ lxc launch ubuntu-daily:bionic ubuntu

Enter the container as root:
$ lxc exec ubuntu bash

Verify hostname is «ubuntu»:
# hostname
ubuntu

Install apache2:
apt update && apt install apache2

Adjust permissions of the key file:
chmod 0640 /etc/apache2/ ubuntu. key
chgrp www-data /etc/apache2/ ubuntu. key

Create this vhost file (caution, lines may wrap, in particular LogFormat: it should be one long line):
cat > /etc/apache2/ sites-available /cert-auth- test.conf

LogLevel info ssl:warn
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
LogFormat «%h %l %u %t »%r» %>s %O »%i» »%i» protocol= % x commonName= % x» combined-ssl
ErrorLog $ /error. log
CustomLog $ /access. log combined-ssl
SSLEngine on
SSLCertificate File /etc/apache2/ ubuntu. pem
SSLCertificate KeyFile /etc/apache2/ ubuntu. key
SSLCACertifica teFile /etc/apache2/ cacert. pem
shtml|phtml| php)$»>
SSLOptions +StdEnvVars

SSLOptions +StdEnvVars

SSLVerifyClie nt require
Require ssl-verify-client

EOF

Enable the ssl module and this new vhost we just created:
a2enmod ssl && a2ensite cert-auth-test.conf

Restart apache2:
systemctl restart apache2

If at this stage you try the following command, it will fail like this because no client certificate was provided:
# curl —output /dev/null https:/ /ubuntu/ —cacert /etc/apache2/ cacert. pem
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 —:—:— —:—:— —:—:— 0
curl: (56) OpenSSL SSL_read: error:14094410:SSL routines: ssl3_read_ bytes:sslv3 alert handshake failure, errno 0

And the apache error log will confirm the reason:
[Mon Jul 01 14:10:23.312645 2019] [ssl:error] [pid 1685:tid 140326396421888] SSL Library Error: error:1417C0C7:SSL routines: tls_process_ client_ certificate: peer did not return a certificate — No CAs known to server for verification?

Now retry, but providing the client certificate and key files, and forcing TLSv1.2 just to be sure. Due to the bug, the command will stall for about 15 seconds, but the index.html file will be downloaded:
# rm -f index.html
# curl —output index.html https:/ /ubuntu/ —cacert /etc/apache2/ cacert. pem —cert client-auth.pem —key client-auth.key —tlsv1.2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10918 100 10918 0 0 706 0 0:00:15 0:00:15 —:—:— 2579
# ll index.html
-rw-r—r— 1 root root 10918 Jul 1 14:15 index.html

Apache will log this in the error.log file:
[Mon Jul 01 14:15:38.014784 2019] [reqtimeout:info] [pid 1685:tid 140326278772480] [client 10.0.100.215:35108] AH01382: Request body read timeout

That is due to modreqtimeout kicking in.
In the access.log file, we will have the request:
10.0.100.215 — — [01/Jul/ 2019:14: 15:22 +0000] «GET / HTTP/1.1» 200 16544 «-» «curl/7.58.0» protocol=TLSv1.2 commonName= client- auth

The protocol and commonName parts confirm the protocol that was used, and the commonName of the client certificate that was used for authentication.
So it works, but takes a long time for each request. This verifies the bug.

After installing the fixed apache2 packages, the download completes almost instantly:
# curl —output index.html https:/ /ubuntu/ —cacert /etc/apache2/ cacert. pem —cert client-auth.pem —key client-auth.key —tlsv1.2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10918 100 10918 0 0 333k 0 —:—:— —:—:— —:—:— 333k

The apache access log confirms the protocol and that client certificate authentication was used:
10.0.100.215 — — [01/Jul/ 2019:14: 29:56 +0000] «GET / HTTP/1.1» 200 16525 «-» «curl/7.58.0» protocol=TLSv1.2 commonName= client- auth

And the error log gets no new entries. This verifies the bug is fixed.

[Regression Potential]
This is reverting, in mod_ssl, a settings change that was made in openssl 1.1.1. It’s committed upstream in mod_ssl, and I found no other follow-up commits about this.
This being SSL-related, of course it can have surprises and be complicated. The openssl commit even warns that hangs could occur (which happened in this bug here), and it’s expected that applications that are affected adjust accordingly.

[Other Info]
The upstream mod_ssl commit that made this change also changed something else in the code, but we decided to not adopt it because it’s TLSv1.3 specific, and that version of the protocol is not enabled in the apache builds from bionic or cosmic. TLSv1.3 is deemed complete only in apache 2.4.37 and later (http:// www.apache. org/dist/ httpd/CHANGES_ 2.4.37)

[Original Description]
I am using Apache2 with client certificate authentication.
Since recently (last week) and without any configuration changes, the following errors occur frequently:

AH02042: rejecting client initiated renegotiation

Client connections are very slow and sometimes it takes more than a minute until a weg page can be opened in the browser.
Before installation of the latest security fixes last week, this error did not occur.

Description: Ubuntu 18.04.2 LTS
Release: 18.04

apache2:
Installiert: 2.4.29-1ubuntu4.6
Installations kandidat: 2.4.29-1ubuntu4.6
Versionstabelle:
*** 2.4.29-1ubuntu4.6 500
500 http:// de.archive. ubuntu. com/ubuntu bionic-updates/main amd64 Packages
500 http:// security. ubuntu. com/ubuntu bionic- security/ main amd64 Packages
100 /var/lib/ dpkg/status
2. 4.29-1ubuntu4 500
500 http:// de.archive. ubuntu. com/ubuntu bionic/main amd64 Packages

openssl:
Installiert: 1.1.1-1ubuntu2. 1

18.04. 2
Installations kandidat: 1.1.1-1ubuntu2. 1

18.04. 2
Versionstabelle:
*** 1.1.1-1ubuntu2. 1

Источник

Permalink

[Impact]
Under the following conditions, https connections using client cert authentication will suffer a long delay (about 15s if modreqtimeout is enabled, more if it is disabled):
* TLSv1.2
* client certificate authentication in use
* a Location, Directory, or other such block defining the client certificate authentication for that block only, differing from the SSL vhost as a whole

This was triggered by the OpenSSL 1.1.1 SRU and was caused by this openssl change in SSL_MODE_AUTO_RETRY from disabled to enabled by default: https://github.com/openssl/openssl/blob/a4a90a8a3bdcb9336b5c9c15da419e99a87bc6ed/CHANGES#L121-L130

[Test Case]

It helps if you have lxd up and running. Otherwise, a VM or even bare metal host also works, as long as you stick to the «ubuntu» hostname.

Launch a container for the release you are testing. The command below is for bionic:
$ lxc launch ubuntu-daily:bionic ubuntu

Enter the container as root:
$ lxc exec ubuntu bash

Verify hostname is «ubuntu»:
# hostname
ubuntu

Install apache2:
apt update && apt install apache2

Download the following files from this bug report and place them in /etc/apache2:
cd /etc/apache2
wget https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274492/+files/cacert.pem https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274493/+files/ubuntu.pem https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274494/+files/ubuntu.key

Adjust permissions of the key file:
chmod 0640 /etc/apache2/ubuntu.key
chgrp www-data /etc/apache2/ubuntu.key

Download the client certificate and key files and place them in /root:
cd /root
wget https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274495/+files/client-auth.pem https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039/+attachment/5274496/+files/client-auth.key

Create this vhost file (caution, lines may wrap, in particular LogFormat: it should be one long line):
cat > /etc/apache2/sites-available/cert-auth-test.conf <<EOF
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        LogLevel info ssl:warn
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        LogFormat «%h %l %u %t «%r» %>s %O «%{Referer}i» «%{User-Agent}i» protocol=%{SSL_PROTOCOL}x commonName=%{SSL_CLIENT_S_DN_CN}x» combined-ssl
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined-ssl
        SSLEngine on
        SSLCertificateFile /etc/apache2/ubuntu.pem
        SSLCertificateKeyFile /etc/apache2/ubuntu.key
        SSLCACertificateFile /etc/apache2/cacert.pem
        <FilesMatch «.(cgi|shtml|phtml|php)$»>
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>
        <Location />
                SSLVerifyClient require
                Require ssl-verify-client
        </Location>
    </VirtualHost>
</IfModule>
EOF

Enable the ssl module and this new vhost we just created:
a2enmod ssl && a2ensite cert-auth-test.conf

Restart apache2:
systemctl restart apache2

If at this stage you try the following command, it will fail like this because no client certificate was provided:
# curl —output /dev/null https://ubuntu/ —cacert /etc/apache2/cacert.pem
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 —:—:— —:—:— —:—:— 0
curl: (56) OpenSSL SSL_read: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure, errno 0

And the apache error log will confirm the reason:
[Mon Jul 01 14:10:23.312645 2019] [ssl:error] [pid 1685:tid 140326396421888] SSL Library Error: error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate — No CAs known to server for verification?

Now retry, but providing the client certificate and key files, and forcing TLSv1.2 just to be sure. Due to the bug, the command will stall for about 15 seconds, but the index.html file will be downloaded:
# rm -f index.html
# curl —output index.html https://ubuntu/ —cacert /etc/apache2/cacert.pem —cert client-auth.pem —key client-auth.key —tlsv1.2
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 10918 100 10918 0 0 706 0 0:00:15 0:00:15 —:—:— 2579
# ll index.html
-rw-r—r— 1 root root 10918 Jul 1 14:15 index.html

Apache will log this in the error.log file:
[Mon Jul 01 14:15:38.014784 2019] [reqtimeout:info] [pid 1685:tid 140326278772480] [client 10.0.100.215:35108] AH01382: Request body read timeout

That is due to modreqtimeout kicking in.
In the access.log file, we will have the request:
10.0.100.215 — — [01/Jul/2019:14:15:22 +0000] «GET / HTTP/1.1» 200 16544 «-» «curl/7.58.0» protocol=TLSv1.2 commonName=client-auth

The protocol and commonName parts confirm the protocol that was used, and the commonName of the client certificate that was used for authentication.
So it works, but takes a long time for each request. This verifies the bug.

After installing the fixed apache2 packages, the download completes almost instantly:
# curl —output index.html https://ubuntu/ —cacert /etc/apache2/cacert.pem —cert client-auth.pem —key client-auth.key —tlsv1.2
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 10918 100 10918 0 0 333k 0 —:—:— —:—:— —:—:— 333k

The apache access log confirms the protocol and that client certificate authentication was used:
10.0.100.215 — — [01/Jul/2019:14:29:56 +0000] «GET / HTTP/1.1» 200 16525 «-» «curl/7.58.0» protocol=TLSv1.2 commonName=client-auth

And the error log gets no new entries. This verifies the bug is fixed.

[Regression Potential]
This is reverting, in mod_ssl, a settings change that was made in openssl 1.1.1. It’s committed upstream in mod_ssl, and I found no other follow-up commits about this.
This being SSL-related, of course it can have surprises and be complicated. The openssl commit even warns that hangs could occur (which happened in this bug here), and it’s expected that applications that are affected adjust accordingly.

[Other Info]
The upstream mod_ssl commit that made this change also changed something else in the code, but we decided to not adopt it because it’s TLSv1.3 specific, and that version of the protocol is not enabled in the apache builds from bionic or cosmic. TLSv1.3 is deemed complete only in apache 2.4.37 and later (http://www.apache.org/dist/httpd/CHANGES_2.4.37)

[Original Description]
I am using Apache2 with client certificate authentication.
Since recently (last week) and without any configuration changes, the following errors occur frequently:

AH02042: rejecting client initiated renegotiation

Client connections are very slow and sometimes it takes more than a minute until a weg page can be opened in the browser.
Before installation of the latest security fixes last week, this error did not occur.

Could it be related to https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1803689?

System information:

Description: Ubuntu 18.04.2 LTS
Release: 18.04

apache2:
  Installiert: 2.4.29-1ubuntu4.6
  Installationskandidat: 2.4.29-1ubuntu4.6
  Versionstabelle:
 *** 2.4.29-1ubuntu4.6 500
        500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.4.29-1ubuntu4 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

openssl:
  Installiert: 1.1.1-1ubuntu2.1~18.04.2
  Installationskandidat: 1.1.1-1ubuntu2.1~18.04.2
  Versionstabelle:
 *** 1.1.1-1ubuntu2.1~18.04.2 500
        500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.1.0g-2ubuntu4.3 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     1.1.0g-2ubuntu4 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages