Не подключается cloud agent

[BrainRoot]

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

[avp]

Да, могу попробовать прокинуть 22й порт
Нужен открытый ключ для ssh

[BrainRoot]

Отправляю в ЛС.

[BrainRoot]

поставил GitHub - wirenboard/atecc-util: Linux command-line tool for ATECC608A and ATECC508A
Получаю:

atecc -b4 -c "info"
Found ATECC608A 

То есть аппаратно чип жив и отвечает.

libateccssl1.1 стоит актуальная 0.2.5

Тем не менее

curl --cert /var/lib/wb-cloud-agent/device_bundle.crt.pem --key ATECCx08:00:02:C0:00 --engine ateccx08 --key-type ENG https://agent.wirenboard.cloud/api-agent/v1/events/ -vvv
*   Trying 5.35.4.252:443...
* Connected to agent.wirenboard.cloud (5.35.4.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* failed to load private key from crypto engine
* Closing connection 0
curl: (58) failed to load private key from crypto engine

И еще:

wb-cloud-agent
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 3452, in _thread_main
    self.loop_forever(retry_first_connection=True)
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 1779, in loop_forever
    rc = self.loop(timeout, max_packets)
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 1181, in loop
    rc = self.loop_read(max_packets)
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 1572, in loop_read
    rc = self._packet_read()
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 2310, in _packet_read
    rc = self._packet_handle()
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 2936, in _packet_handle
    return self._handle_publish()
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 3220, in _handle_publish
    self._handle_on_message(message)
  File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 3444, in _handle_on_message
    self.on_message(self, self._userdata, message)
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 325, in on_message
    raise ValueError("Not a 200 status while making start up request: " + str(http_status))
ValueError: Not a 200 status while making start up request: 400
Traceback (most recent call last):
  File "/usr/bin/wb-cloud-agent", line 9, in <module>
    sys.exit(main.main())
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 411, in main
    make_start_up_request(settings, mqtt)
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 280, in make_start_up_request
    raise ValueError("Not a 200 status while making start up request: " + str(http_status))
ValueError: Not a 200 status while making start up request: 400

Призову коллег посмотреть.

[BrainRoot]

Коллеги удалили регистрацию контроллера в облаке.
Пробую:

apt purge wb-cloud-agent -y
apt autoremove -y

Ну и устанавливаю снова
После установки вызовы

/usr/lib/wb-cloud-agent/check-certs.sh

и

/usr/lib/wb-cloud-agent/activate-providers.sh

Как и проверка (мне указали за ошибку в номере шины, исправил) с помощью

curl --cert /var/lib/wb-cloud-agent/device_bundle.crt.pem --key ATECCx08:00:04:C0:00 --engine ateccx08 --key-type ENG https://agent.wirenboard.cloud/api-agent/v1/events/ -vvv
*   Trying 5.35.4.252:443...
* Connected to agent.wirenboard.cloud (5.35.4.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=agent.wirenboard.cloud
*  start date: Sep 10 21:26:08 2024 GMT
*  expire date: Dec  9 21:26:07 2024 GMT
*  subjectAltName: host "agent.wirenboard.cloud" matched cert's "agent.wirenboard.cloud"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xaa9d70)
> GET /api-agent/v1/events/ HTTP/2
> Host: agent.wirenboard.cloud
> user-agent: curl/7.74.0

Как и до переустановки, ошибок не возвращают.
Но

/usr/bin/wb-cloud-agent
Traceback (most recent call last):
  File "/usr/bin/wb-cloud-agent", line 9, in <module>
    sys.exit(main.main())
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 411, in main
    make_start_up_request(settings, mqtt)
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 280, in make_start_up_request
    raise ValueError("Not a 200 status while making start up request: " + str(http_status))
ValueError: Not a 200 status while making start up request: 400

[avp]

А можно на стороне сервера посмотреть ошибки?

400-я ошибка кажется не похожа на проблему с SSL/сертифом, она скорее прикладная

[BrainRoot]

Добрый день.
Доступ сейчас закрыт к контроллеру?

[avp]

Да, открыть?

[BrainRoot]

Если и сейчас не работает облако - откройте пожалуйста.

[avp]

В общем, у меня нет сейчас доступа к контроллеру(там проблемы с электричеством). Смогу открыть только через две недели, когда физически доеду туда и разберусь

[BrainRoot]

Отлично, напишете? В сервисах, обеспеспечаеющих работу облака разработчитки нашли (и исправили) ошибки, вполне вероятно что заработает. В любом случае - напишите пожалуйста как доберетесь до контроллера.

[avp]

root@wirenboard-ABEMEKY7:~# wb-cloud-agent 
Traceback (most recent call last):
  File "/usr/bin/wb-cloud-agent", line 9, in <module>
    sys.exit(main.main())
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 411, in main
    make_start_up_request(settings, mqtt)
  File "/usr/lib/python3.9/dist-packages/wb/cloud_agent/main.py", line 280, in make_start_up_request
    raise ValueError("Not a 200 status while making start up request: " + str(http_status))
ValueError: Not a 200 status while making start up request: 400

Доступ открыл

[BrainRoot]

Добрый день.
Разработчики все еще работают. Проблема - в том что сертификат именно сгенерированный для контроллера не проходит проверку облачным сервисом. То есть что-то глобальное… Но, думаю, уже близко.

[avp]

А я единственный с такой проблемой?

[BrainRoot]

С такой - два случая. Вот с обоими и возятся.

[BrainRoot]

Добрый день.
Есть результаты: в общем что-то между контроллером и сервисом cloud режет (меняет) заголовки запросов.
Разработчики проанализировали трафик контроллера (исходящие пакеты) и трафик получаемый сервисом - увидели разницу.
Провели эксперимент - отправили трафик к сервису cloud через VPN туннель. В этом случае - соединение поднималось и работало, что подтверждает гипотезу.
Дополнительный эксперимент: трафик к облаку с заведомо работающего контроллера был отправлен через ваш. То есть к вашему - через VPN, а он использовался как шлюз. Тоже не соединяется.
То есть дело в провайдере (оборудовании ТСПУ) или файрволле на шлюзе. Попробуйте для проверки без них.

[avp]

Ого…

пока мысли:
Для выхода в интернет используется keenetic hero c симкой пчелайна. Некоторое время назад там же был другой keenetic с USB модемом. Я не могу уже вспомнить, отвалилось облако “до” смены роутера или после.

я на днях буду на объекте - попробую:

1. Тупо соберу конструкцию с другим оператором и USB-модемом.
2. Если заработает - буду исключать оператора и роутер
3. Если оператор, то по идее, я должен быть не один такой
4. Если роутер, то есть мысли, что потыкать/поотключать

отпишу

НО! Непонятно, почему всё остальное-то работает??

[BrainRoot]

@avp

отпишу

Отлично, мне тоже интересно.

@avp

НО! Непонятно, почему всё остальное-то работает??

Я проверял доступность нескольких https ресурсов - но они не использовали механизм сертификатов для авторизации.

[avp]

О, авторизация по сертифу!

Интересная версия, но

1. Сходу не могу вспомнить где еще используется сейчас
2. Тогда маловероятен пчелайн, если у них вообще “сломан” двухсторонний SSL (разве, что одна локальная железка глючит)

[BrainRoot]

@avp

1. Тогда маловероятен пчелайн, если у них вообще “сломан” двухсторонний SSL (разве, что одна локальная железка глючит)

Нет. В процессе проверки тестировали авторизацию на другом сервере, не боевом.
В подсеть тестового сервера - пакеты доходили без изменений, то есть все работало.
Тол есть тут “что-то” портит их именно по пути до боевого cloud. Соответственно, можно наверно исключить из подозреваемых сам роутер, вряд ли на нем настроена обработка пакетов в зависимости от назначения.
Возможно - сломано где-то на граничном шлюзе.