google_iot_mqtt sample does not work with qemu_x86 out of the box

[rlubos]

I've been testing google_iot_mqtt with qemu_x86 and it does not work out of the box. In order to make it work I've needed to add the following lines to the project configuration:

CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_MY_IPV4_GW="192.0.2.2"
CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.0.2.1"

While the first two configs are totally understandable, I have no clue why did I need to set CONFIG_NET_CONFIG_MY_IPV4_ADDR even thoug DHCP leased address was used. I did not dig any further though.

Additionally, compared to Zephyr networking guide, a more generic rule for iptables had to be added in order to allow DHCP leased addresses to reach the internet:

sudo iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.0.2.0/24

Some afterthoughts regarding documentation, from a GCloud newbie point of view:

• Perhaps we should add a section about how to run the sample on qemu, as it needs some extra steps (like setting up DHCP server or this extra iptables rule),
• CLOUD_CLIENT_ID and CLOUD_AUDIENCE description - I got confused with the telemetry field. Google Cloud documentation refers to it as project/project-id:
  projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}
  Especially for CLOUD_AUDIENCE - it's simply a project-id. It'd be good to make it clear, as this is vital for device authentication.
• create_keys.py script - it's super convenient, that's for sure. But I found it confusing, that by default it generates RSA keys, while default sample configuration expects ECDSA key. I think this should be stressed out in the docs, especially that no warning is shown if RSA key is used. Cloud server will reject the device in this case, which does not provide too much information, beside that something is wrong.

[captcha1]

I agree that the google_iot_mqtt doc could be better.

For example, regarding CONFIG_CLOUD_AUDIENCE , this web page : https://cloud.google.com/iot/docs/how-tos/credentials/jwts ... states :

aud ("Audience"): This must be a single string containing the cloud project ID where the device is registered

Also, under "requirements", the docs say "Google IOT Cloud credentials and required information" ... probably good to have a link to "gcloud iot devices create" page : https://cloud.google.com/sdk/gcloud/reference/iot/devices/create

Also, the "device" parameter to "create_keys.py" has to match string in CONFIG_CLOUD_CLIENT_ID ... and probably CONFIG_CLOUD_PUBLISH_TOPIC (I got an error : "could not publish, error -128" ... so something is broken).

[carlescufi]

@jukkar @rlubos does this still apply?

[rlubos]

AFAIK there were no fixes/changes in this area.

[dieselburner]

TLDR; This example seriously lacks documentation.

Yes, there are issues in this example. The most critical part is what @rlubos mentioned in regards to the absence of documentation on configuration options. Obviously, some nerd would say: pfff, read the docs. No. First of all, Google Cloud documentation is MASSIVE, and I feel like looking for a needle. Second, for example, Client ID has a format of projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}, which took me few hours to figure out. And finally, certificate / key handling at this moment is a mess - Google says it needs Google Root CA certificate for TLS connection, while this MQTT example uses GlobalSign Root CA, and the funny thing is that TLS connection works with GlobalSign certificate, but not with Google's. WTF? This clearly should have been addressed somewhere.

I constantly getting connection errors, don't know how to proceed, and would appreciate if someone could have a look at this sample and at least provide a working scenario or short description on how to get this thing working.

[d3zd3z]

Let me see if I can get this working again. I was able to get it working last time I tried, which was at least a few months ago.

[d3zd3z]

First thing I've discovered is that 0fa86cb removes CONFIG_LEGACY_TIMEOUT_API as being selected by the net code. It'd probably be best to make this sample work without the legacy timeout api, but it can be made to at least compile by enabling this in the prj.conf for the sample.

[d3zd3z]

@dieselburner Does #25108 help you get this working? The instructions in the README.rst were somewhat difficult to follow (and even downright wrong).

[dieselburner]

I would love to test on master, but blocked by #25140

[d3zd3z]

I would love to test on master

It is just documentation and prj.conf changes, so it shouldn't be difficult to try on whatever branch you have that works.

[jukkar]

This was merged already so closing.

[dieselburner]

Thanks, I got it working because of your changes.