Моя цель - попытаться установить соединение с нашим AWS MQTT через Wi-Fi интернет-провайдера через порт 8883 с ESP8266. Для этого я использую Mongoose OS.
Мы используем брокера AWS MQTT на порту 8883. Мы можем подключиться к сети Wi-Fi (VLAN) поставщика и совершать HTTPS-вызовы. Мы также подтвердили, что в других сетях Wi-Fi мы можем установить соединение с брокером (точка доступа на телефоне и офисный Wi-Fi) с такой же конфигурацией устройства. При попытке подключения создается впечатление, что соединение не было установлено (на стороне брокера), и CONNACK никогда не получен.
Мы также попытались использовать незашифрованный MQTT через порт 1883, и мы безуспешно пытались использовать порт 80 на устройствах.
Мы подключились к той же сети с нашими Macbook Pro и смогли успешно подключиться к внешним серверам через порт MQTT 1883.
Мы попытались установить локальный сервер MQTT на порт 1883 и получили неоднозначные результаты.
Тесты:
Мы проверили журналы AWS, чтобы узнать, было ли установлено соединение, но не похоже, что какое-либо соединение было. Это то, что нам показывают журналы устройства.
[Jan 22 19:21:35.196] mgos_mqtt.c:427 MQTT connecting to a3po4n40bckdri-ats.iot.us-east-1.amazonaws.com:8883
[Jan 22 19:21:35.208] mg_net.c:916 0x3fff44f4 a3po4n40bckdri-ats.iot.us-east-1.amazonaws.com:8883 aws-10191211-0002.crt.pem,ATCA:0,ca.pem
[Jan 22 19:21:35.218] mgos_vfs.c:255 aws-10191211-0002.crt.pem -> /aws-10191211-0002.crt.pem pl 1 -> 1 0x3fff01a4
[Jan 22 19:21:35.237] mgos_vfs.c:349 aws-10191211-0002.crt.pem 0x0 0x1b6 => 0x3fff01a4 aws-10191211-0002.crt.pem 1 => 257 (refs -10)
[Jan 22 19:21:35.243] mgos_vfs.c:508 257 => 0x3fff01a4:1 => 0 (size 1140)
[Jan 22 19:21:35.248] mgos_vfs.c:508 257 => 0x3fff01a4:1 => 0 (size 1140)
[Jan 22 19:21:35.253] mgos_vfs.c:536 257 0 1 => 0x3fff01a4:1 => 0
[Jan 22 19:21:35.258] mgos_vfs.c:536 257 1024 0 => 0x3fff01a4:1 => 1024
[Jan 22 19:21:35.263] mgos_vfs.c:536 257 0 0 => 0x3fff01a4:1 => 0
[Jan 22 19:21:35.269] mgos_vfs.c:382 257 => 0x3fff01a4:1 => 0 (refs -11)
[Jan 22 19:21:35.282] mgos_vfs.c:255 ca.pem -> /ca.pem pl 1 -> 1 0x3fff01a4
[Jan 22 19:21:35.298] mgos_vfs.c:349 ca.pem 0x0 0x1b6 => 0x3fff01a4 ca.pem 1 => 257 (refs -10)
[Jan 22 19:21:35.303] mgos_vfs.c:382 257 => 0x3fff01a4:1 => 0 (refs -11)
[Jan 22 19:21:35.311] mg_net.c:916 0x3fff21ac udp://172.20.40.1:53 -,-,-
[Jan 22 19:21:35.316] mg_net.c:796 0x3fff21ac udp://172.20.40.1:53
[Jan 22 19:21:35.321] mgos_event.c:135 ev NET3 triggered 3 handlers
[Jan 22 19:21:35.328] mg_net.c:811 0x3fff21ac udp://172.20.40.1:53 -> 0
[Jan 22 19:21:35.335] mg_rpc.c:470 0x3fff1504 CHAN OPEN (loopback)
[Jan 22 19:21:35.339] mgos_event.c:135 ev RPC0 triggered 0 handlers
[Jan 22 19:21:35.378] mg_net.c:796 0x3fff44f4 tcp://52.202.201.44:8883
[Jan 22 19:21:35.405] mg_net.c:811 0x3fff44f4 tcp://52.202.201.44:8883 -> 0
[Jan 22 19:21:35.405] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => handshake
[Jan 22 19:21:35.410] mg_ssl_if_mbedtls.c:35 0x3fff44f4 client state: 0
[Jan 22 19:21:35.415] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => flush output
[Jan 22 19:21:35.419] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= flush output
[Jan 22 19:21:35.424] mg_ssl_if_mbedtls.c:35 0x3fff44f4 client state: 1
[Jan 22 19:21:35.429] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => flush output
[Jan 22 19:21:35.434] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= flush output
[Jan 22 19:21:35.439] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => write client hello
[Jan 22 19:21:35.445] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => write handshake message
[Jan 22 19:21:35.451] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => write record
[Jan 22 19:21:35.456] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => flush output
[Jan 22 19:21:35.462] mg_ssl_if_mbedtls.c:35 0x3fff44f4 message length: 151, out_left: 151
[Jan 22 19:21:35.469] mg_ssl_if_mbedtls.c:35 0x3fff44f4 ssl->f_send() returned 151 (-0xffffff69)
[Jan 22 19:21:35.474] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= flush output
[Jan 22 19:21:35.479] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= write record
[Jan 22 19:21:35.484] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= write handshake message
[Jan 22 19:21:35.489] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= write client hello
[Jan 22 19:21:35.494] mg_ssl_if_mbedtls.c:35 0x3fff44f4 client state: 2
[Jan 22 19:21:35.499] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => flush output
[Jan 22 19:21:35.503] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= flush output
[Jan 22 19:21:35.509] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => parse server hello
[Jan 22 19:21:35.513] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => read record
[Jan 22 19:21:35.518] mg_ssl_if_mbedtls.c:35 0x3fff44f4 => fetch input
[Jan 22 19:21:35.524] mg_ssl_if_mbedtls.c:35 0x3fff44f4 in_left: 0, nb_want: 5, in_buf_size: 13
[Jan 22 19:21:35.531] mg_ssl_if_mbedtls.c:35 0x3fff44f4 in_left: 0, nb_want: 5, in_buf_size: 13
[Jan 22 19:21:35.536] mg_ssl_if_mbedtls.c:35 0x3fff44f4 <= handshake
При попытке через порт 1883 мы получаем следующие журналы. Мы не получаем CONNACK, но устройство отправляет PINGREQ и TCP в порядке:
[Jan 23 10:45:04.149] mgos_net.c:101 WiFi STA: ready, IP 172.20.40.105, GW 172.20.40.1, DNS > 172.20.40.1
[Jan 23 10:45:04.154] mgos_sntp.c:127 SNTP next query in 1063 ms
[Jan 23 10:45:04.160] mgos_mqtt.c:427 MQTT connecting to iot.eclipse.org:1883
[Jan 23 10:45:04.166] mg_net.c:916 0x3fff4124 iot.eclipse.org:1883 -,-,-
[Jan 23 10:45:04.177] mg_net.c:916 0x3fff48ec udp://172.20.40.1:53 -,-,-
[Jan 23 10:45:04.177] mg_net.c:796 0x3fff48ec udp://172.20.40.1:53
[Jan 23 10:45:04.182] mgos_event.c:135 ev NET3 triggered 3 handlers
[Jan 23 10:45:04.188] mg_net.c:811 0x3fff48ec udp://172.20.40.1:53 -> 0
[Jan 23 10:45:04.195] mg_rpc.c:470 0x3fff13a4 CHAN OPEN (loopback)
[Jan 23 10:45:04.199] mgos_event.c:135 ev RPC0 triggered 0 handlers
[Jan 23 10:45:04.252] mg_net.c:796 0x3fff4124 tcp://198.41.30.254:1883
[Jan 23 10:45:04.279] mg_net.c:811 0x3fff4124 tcp://198.41.30.254:1883 -> 0
[Jan 23 10:45:04.279] mgos_mqtt.c:141 MQTT TCP connect ok (0)
[Jan 23 10:45:05.232] mg_net.c:916 0x3fff4064 udp://time.google.com:123 -,-,-
[Jan 23 10:45:05.243] mg_net.c:916 0x3fff48ec udp://172.20.40.1:53 -,-,-
[Jan 23 10:45:05.243] mg_net.c:796 0x3fff48ec udp://172.20.40.1:53
[Jan 23 10:45:05.248] mgos_sntp.c:95 SNTP query to time.google.com
[Jan 23 10:45:05.252] mgos_sntp.c:127 SNTP next query in 2061 ms
[Jan 23 10:45:05.260] mg_net.c:811 0x3fff48ec udp://172.20.40.1:53 -> 0
[Jan 23 10:45:05.289] mg_net.c:796 0x3fff4064 udp://216.239.35.8:123
[Jan 23 10:45:05.299] mg_net.c:811 0x3fff4064 udp://216.239.35.8:123 -> 0
[Jan 23 10:45:05.299] mgos_sntp.c:48 SNTP sent query to 216.239.35.8
[Jan 23 10:45:05.346] mgos_sntp.c:59 SNTP reply from 216.239.35.8: time 1579794306.188667, local 8.356276, delta 1579794297.832391
[Jan 23 10:45:05.351] mgos_event.c:135 ev MOS3 triggered 2 handlers
[Jan 23 10:45:05.355] mgos_sntp.c:78 SNTP close
[Jan 23 10:45:05.360] mgos_sntp.c:127 SNTP next query in 7905143 ms
[Jan 23 10:45:05.367] mg_mqtt.c:188 Send PINGREQ
[Jan 23 10:45:12.939] pm open,type:0 0
Мы попробовали локальный сервер MQTT на портах 80 и 1883, используя один из наших Macbook Pro. Это дало смешанные результаты. Нам пришлось вручную пропинговать устройство, когда оно пыталось подключиться к MQTT, в противном случае казалось, что оно не подключится.
Мы также заметили, что наш провайдер также предоставил нам сеть 5 ГГц с тем же SSID, что и сеть 2,4 ГГц. Я не знаю, может ли это вызвать проблемы с сетевым трафиком.
Я ищу понимание того, в чем может быть проблема, поэтому я могу представить решение ИТ-специалистам, с которыми я работаю. У меня пока нет доступа к их сетевым конфигурациям, мне нужно убедить ИТ-специалиста, отвечающего за здание (действующего в качестве посредника), что проблема может быть связана с неправильной конфигурацией поставщика или необычной проблемой сетевого трафика. Я также хотел бы знать, что вызывает эту проблему и как я могу ее протестировать и предотвратить, чтобы не столкнуться с ней снова в будущем.
Особое спасибо всем, кто это читает!