mqtt_simple sample gets error -2 in getaddrinfo

[tomtomtom2401]

Hello,

We have developed our own module based on the nrf9160 DK and want to use it to send data to a MQTT broker. A few days ago on the dev-kit everything worked fine, now the new PCBs have arrived and we get this error in the mqtt_simple sample (as well as in our own code, but in a little different format):

 *** Booting Zephyr OS build v3.2.99-ncs1 ***                                      
[00:00:00.504,638] <inf> mqtt_simple: The MQTT simple sample started               
[00:00:00.504,699] <inf> mqtt_simple: Disabling PSM and eDRX                              
[00:00:00.505,401] <inf> mqtt_simple: LTE Link Connecting...                              
[00:00:09.277,618] <inf> mqtt_simple: LTE Link Connected!                                 
[00:00:09.277,862] <err> mqtt_simple: getaddrinfo failed: -2                              
[00:00:09.277,893] <err> mqtt_simple: Failed to initialize broker connection              
[00:00:09.277,893] <err> mqtt_simple: client_init: -10   

We just added the following config lines to use NB-IoT in the sample:

CONFIG_LTE_NETWORK_MODE_NBIOT=y
CONFIG_LTE_MODE_PREFERENCE_NBIOT=y

When using the IP address of the moquitto test server, it works perfectly fine.

*** Booting Zephyr OS build v3.2.99-ncs1 ***                                      
[00:00:00.568,603] <inf> mqtt_simple: The MQTT simple sample started                      
[00:00:00.568,664] <inf> mqtt_simple: Disabling PSM and eDRX                              
[00:00:00.569,366] <inf> mqtt_simple: LTE Link Connecting...                              
[00:00:11.186,523] <inf> mqtt_simple: LTE Link Connected!                                 
[00:00:11.186,950] <inf> mqtt_simple: IPv4 Address found 91.121.93.94                     
[00:00:11.187,438] <dbg> mqtt_simple: client_id_get: client_id = nrf-2EB11F7FD373E99C     
[00:00:11.598,114] <inf> mqtt_simple: MQTT client connected                               
[00:00:11.598,144] <inf> mqtt_simple: Subscribing to: my/subscribe/topic len 22       
[00:00:11.746,185] <inf> mqtt_simple: SUBACK packet id: 1234                              
[00:06:48.615,112] <inf> mqtt_simple: MQTT PUBLISH result=0 len=15                        
[00:06:48.615,203] <inf> mqtt_simple: Received: test with ip address                           
[00:06:48.615,783] <inf> mqtt_simple: Publishing: test with ip address                         
[00:06:48.615,814] <inf> mqtt_simple: to topic: my/publish/topic len: 20              
[00:06:48.761,352] <inf> mqtt_simple: PUBACK packet id: 39802 

Has anybody an idea? 

We are using the NCS v2.2.0 with the toolchain 2.2.0 (but tried the 2.1.0 as well, as we used with the dev-kit), modem firmware is 1.2.3

Edit: I forgot to add: when using the same code on the dev-kit, it works also fine with the IP Address and the URL. Modem firmware is here also 1.2.3 - thats the reason we choose 1.2.3 instead of 1.3.3. We also use the same SIM card to prevent any errors from the provider side (bad DNS, APN, whatever...)

Thank you!

BR Thomas

[Hakon]

Hello,

which SIM card are you using?

[tomtomtom2401]

Hello,

We are using a m2m SIM from company "drei" from Austria. I've used the very same SIM card in the dev kit and in our module to exclude any errors from this side.
In the meantime, I tried to set the DNS manually (like in thread), but it only works randomly and only once after flashing the modem firmware. Then it looks like its running into a timeout and a watchdog restarts the module.

BR Thomas

[tomtomtom2401]

with the DNS setting or without?

[Hakon]

Preferably both.

[tomtomtom2401]

Ok, thank you!

I will set it up and get the traces.

[tomtomtom2401]

Hello Hakon,

Here are the two trace files, once without dns with the getaddrinfo result as -2, once with the dns setting resulting in the watchdog (?) restarts of the device

trace_without_dns.bin

trace_with_dns.bin

BR Thomas

[tomtomtom2401]

Anybody an idea? We are completely stucked on this...
In the meantime we tested the CoAP example, but with the same result...

[Achim Kraus]

Beside some "Internet Protocol, bogus version (0)" I didn't see something in trace_with_dns.bin.

What do you use as hostname to look up?

(I see "test.mosquitto.org", is that the one?)

Maybe, that contains unexpected bytes.

In the other comments I see, that you have already tested a lot. Did you try to use an other SIM card from an other provider?

[tomtomtom2401]

I used "test.mosquitto.org" and our mqtt server, also the CoAP server from the example (californium.eclipseprojects.io).

I have no other NB-IoT SIM available at the moment, I try hard to get another one...
But as mentioned before, the dev kit works fine with this SIM card and the same sourcecode. I tested also an other SIM card, but from the same provider and SIM pool, which we use for all our devices in our company.

At the moment I test with the AT client and the LTE Link Monitor: we have similar signal strength and quality parameters as the devkit, often a few dBm better with our hardware (small ext. antenna, ~ -90dBm to ~ -100dBm).

BR Thomas

[Achim Kraus]

Strange. You've tested the "samples/nrf9160/coap_client ?

Some time ago, I get sometimes a "-EAGAIN" and so I added a loop:

 err = getaddrinfo(CONFIG_COAP_SERVER_HOSTNAME, NULL, &hints, &result);
 while (-err == EAGAIN) {
   k_sleep(K_MSEC(1000));
   err = getaddrinfo(CONFIG_COAP_SERVER_HOSTNAME, NULL, &hints, &result);
 }

Maybe you try a similar approach and limit that to say, "3 retries".

[Achim Kraus]

Uuups, I used the wrong modem firmware version.

With 1.2.3 I see the DNS requests in the trace. But it seems, that the DNS responses are missing.

[Achim Kraus]

OK, I compared it with some traces from my devices.

"trace_with_dns.bin"

Contains in the pcapng (converted for version 1.2.3) 3 DNS requests:

10.165.197.63 8.8.8.8 DNS 76 Standard query 0x375d A test.mosquitto.org

10.130.12.1    8.8.8.8    DNS    76    Standard query 0x6b9e A test.mosquitto.org

10.50.56.104 8.8.8.8 DNS 76 Standard query 0x0d59 A test.mosquitto.org

I don't know, why it uses different source addresses (also the port is changing), but in my traces, that's not the case.