Goal:
- The goal is to try and establish a connection with our AWS MQTT via an Internet Provider’s WiFi on port 8883 with the ESP8266.
Actions:
-
We are using AWS MQTT broker on port 8883. We are able to connect to the vendor’s WiFi (VLAN) and we are able to do HTTPS calls. We have also confirmed that on other WiFi networks, we are able to establish a connection to the broker (hotspot on phone and office WiFi) with the same device configuration. When attempting to connect, it seems as though the connection was not established (on the broker side), and no CONNACK is ever received.
-
We also attempted to use unencrypted MQTT over port 1883, and we tried port 80 without any success on the devices.
-
We connected to the same network with our Macbook Pros, and we were able to make a successful connection to external servers via MQTT port 1883.
-
We attempted to setup a local MQTT server on port 1883 and got mixed results.
Results:
We checked the AWS logs to see if a connection had been established, but it does not look like any connection has been. This is what the device logs are showing us.
[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
When attempting over port 1883, we get the following logs. We get no CONNACK, but the device is sending a PINGREQ and TCP is OK:
[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
We tried a local MQTT server on both port 80 and port 1883 using one of our Macbook Pros. This had mixed results. We had to manually ping the device when it was attempting to connect to MQTT, otherwise, it did not seem like it would connect.
We also noticed that our provider also gave us a 5GHZ network with the same SSID as the 2.4GHZ network. I do not know if that could be causing some problem with network trafficking.
Expectation:
I am looking for insight into what might be the problem, so I can present a solution to the IT people I am working with. I do not have any access to their network configurations yet, I need to convince the IT person in charge of the building (acting as a middleman) that the problem may be related to a vendor misconfiguration or unusual network trafficking issue. I would also like to know what is causing this issue and how I can test and prevent this so that I do not run into it again in the future.
A special thanks to everyone reading this!