idg10
commented
5 years ago Closed idg10 closed 4 years ago
idg10
commented
5 years ago idg10
commented
5 years ago idg10
commented
5 years ago idg10
commented
5 years ago 
damonbarry
commented
5 years ago @idg10 Does it work over wifi/4G if you set MQTT as the upstream protocol for edge agent and edge hub? Totally different stack (DotNetty), so wondering if it will behave differently...
damonbarry
commented
5 years ago Also, could you run iotedge check in the hotspot case again, but with the --verbose flag? That will tell us why it was an error vs a warning.
idg10
commented
5 years ago Check with --verbose
Configuration checks
--------------------
√ config.yaml is well-formed - OK
√ config.yaml has well-formed connection string - OK
√ container engine is installed and functional - OK
√ config.yaml has correct hostname - OK
√ config.yaml has correct URIs for daemon mgmt endpoint - OK
√ latest security daemon - OK
× host time is close to real time - Error
Could not query NTP server
caused by: could not send SNTP client request: Address family not supported by protocol (os error 97)
√ container time is close to host time - OK
‼ DNS server - Warning
Container engine is not configured with DNS server setting, which may impact connectivity to IoT Hub.
Please see https://aka.ms/iotedge-prod-checklist-dns for best practices.
You can ignore this warning if you are setting DNS server per module in the Edge deployment.
caused by: Could not open container engine config file /etc/docker/daemon.json
caused by: No such file or directory (os error 2)
‼ production readiness: certificates - Warning
Device is using self-signed, automatically generated certs.
Please see https://aka.ms/iotedge-prod-checklist-certs for best practices.
√ production readiness: certificates expiry - OK
‼ production readiness: container engine - Warning
Device is not using a production-supported container engine (moby-engine).
Please see https://aka.ms/iotedge-prod-checklist-moby for details.
‼ production readiness: logs policy - Warning
Container engine is not configured to rotate module logs which may cause it run out of disk space.
Please see https://aka.ms/iotedge-prod-checklist-logs for best practices.
You can ignore this warning if you are setting log policy per module in the Edge deployment.
caused by: Could not open container engine config file /etc/docker/daemon.json
caused by: No such file or directory (os error 2)
Connectivity checks
-------------------
√ host can connect to and perform TLS handshake with IoT Hub AMQP port - OK
√ host can connect to and perform TLS handshake with IoT Hub HTTPS / WebSockets port - OK
√ host can connect to and perform TLS handshake with IoT Hub MQTT port - OK
√ container on the default network can connect to IoT Hub AMQP port - OK
√ container on the default network can connect to IoT Hub HTTPS / WebSockets port - OK
√ container on the default network can connect to IoT Hub MQTT port - OK
√ container on the IoT Edge module network can connect to IoT Hub AMQP port - OK
√ container on the IoT Edge module network can connect to IoT Hub HTTPS / WebSockets port - OK
√ container on the IoT Edge module network can connect to IoT Hub MQTT port - OK
√ Edge Hub can bind to ports on host - OK
18 check(s) succeeded.
4 check(s) raised warnings.
1 check(s) raised errors.I tried setting MQTT, but I think I messed up and set it only on the hub not the agent. I'll try again, but it'll be a day before I'll be in a position to report back - sorry!
damonbarry
commented
5 years ago I believe if you set it on the agent in config.yaml, then it will automatically get propagated to the hub as well (i.e. you don't have to set it in the deployment JSON).
lt72
commented
4 years ago @idg10 Did you have a chance to try @damonbarry 's suggestion? Please let us know if we can help.
lt72
commented
4 years ago Closing this issue as it seems stale, please feel free to re-open as needed and we will get back to it.
Expected Behavior
When a device is connected to the internet through a cellular data network (e.g., via a mobile hotspot), and when that network seems to be capable of delivering device-to-cloud messages when the application code communicates directly with the IoT Hub (i.e., when not using the edge hub), messages should also get through when the application code goes via the edge hub.
Current Behavior
This table shows the results I'm seeing:
I see failures like this:
Steps to Reproduce
I have a Python client using the V2 client, so I have this:
When communicating directly with the IoT hub, I have an ordinary connection string, and I create the client like this:
When going via the IoT hub, I add an extra clause into the connection string:
and I pass the edge hub's cert during creation:
(I'm not using the
create_from_edge_environmentmethod because I'm not yet deploying as an edge module.)Both of these techniques work just fine when using my normal wired internet connection. And the first of these works when I'm using a local hotspot.
And as far as my client app is concerned the second one also works when using the local hotspot: the edge hub accepts the messages, and I see no errors in the client. The problems occur when the edge hub tries to upload these messages to the Azure IoT hub.
Context (Environment)
I am running on a Raspberry Pi 4,
Output of
iotedge checkHere's the output I get when on the wired network (i.e., when it's all working):
And here's what I see when run the same check when on the mobile hotspot (i.e., when it fails):
Note: I've never seen that NTP message before. Running
timedatectl statusindicates that the date and time are in fact in sync just fine, so I don't understand why it's reporting that.Device Information
On login it reports:
Linux idgpi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7lcat /etc/os-releasereports:Runtime Versions
iotedge 1.0.8 (208b2204fd30e856d00b280112422130c104b9f0)7939e9415e57a480fa622e2adocker version:Logs
To follow, because otherwise I exceed the GitHub limit