Device looses the ability to resolve hostnames (Unsandboxed R14)

Hi, I have an app running on an FX30 using R14. It is unsandboxed and creates a connection to the internet using le_data_Request().

Some modems suddenly stop being able to connect to my server… SSHing to the device shows that it is not managing to resolve the hostname. By changing it to an IP address lets it work again.

It has been suggested this could have to do with the routes set up, but why would it work for a while and then loose the ability to resolve them?

Thanks,

Karl

Hiya,

Just out of interest, is your FX30 being issued with an IPV6 address from your ISP?

There’s a bug in the current (16.10.1.m3) version of FX30 legato if the ISP issues both IPv6 and IPv4 addresses - the IPv6 addresses end up at the top of the resolver list, and then the resolver doesn’t resolve IPv4 hostnames.

This has been fixed in Legato 18.07 (or so), but hasn’t made it back to the FX30 yet.

I deal with it by setting the connection context to IPv4 only.

ciao, Dave

@davidc Thanks for your reply…

ahhh. actually the profile is set to IPV4V6 on one of the modems… and ifconfig gives me an inet6 address on rmnet0. But so does a different IPV4 only modem.

The etc/resolv.conf is empty? I am running as unsanboxed. Then I checked /mnt/flash/ufs/resolv.conf but it is the same.

I checked on another device that is IPV4 only and is managing to resolve hostnames. It’s resolv.conf files are also blank.

I was expecting to see a DNS server somewhere? Am I looking in the correct place?

Thanks,

Karl

Hi @karlkuhn,

I would expect to see the IP addresses of the nameservers in /erc/resolv.conf

resolv.conf appears to be created when the Packed Connection is made (i.e cm data connect) so if you haven’t connected to the network then the file might not be present.

Note that even if there are more than three nameservers in /etc/resolv.conf then if you are using the standard resolver library (in glibc), only the first three name servers are used…

ciao, Dave

Hi @davidc ,

hmmm strange… running nslookup on the device that is not working shows

root@fx30s:/bin# nslookup google.co.uk
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

nslookup: can’t resolve ‘google.co.uk

But the device that is resolving I get

root@fx30s:/bin# nslookup google.co.uk
Server: 8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com

Name: google.co.uk
Address 1: 74.125.133.94 wo-in-f94.1e100.net
Address 2: 2a00:1450:400c:c07::5e wo-in-x5e.1e100.net

Both these devices have a resolv.conf file, but they are both empty. Should I be looking anywhere else for those files?

Edited after post…
I think I must be going nuts… the device that was working, now has two entries in the resolv.conf file…

Either way, from your suggestiong regarding the bug, I am expecting to see at least an IPV6 address in the file (in the device that is not working)… but I am not.

using nslookup www.google.co.uk 8.8.8.8 then manages to resolve the hostname (on the device that is otherwise not managing), proving that the connecting is established.

So the questions stand, how can I find out what the resolver list is if not in those two files?

Thanks,
Karl

Making a little more progress… if I turn the radio off and then on again, I see the following two lines in my trace

`Jan 25 09:12:39 fx30s user.info Legato:  INFO | dcsDaemon[577]/dataConnectionService T=main | dcsServer.c AddNameserversToResolvConf() 1281 | Set DNS '8.8.8.8' '212.9.0.136'
Jan 25 09:12:39 fx30s user.warn Legato: -WRN- | dcsDaemon[577]/dataConnectionService T=main | dcsServer.c AddNameserversToResolvConf() 1351 | fopen on /etc/resolv.conf failed
Jan 25 09:12:39 fx30s user.info Legato:  INFO | dcsDaemon[577]/dataConnectionService T=main | dcsServer.c SetDnsConfiguration() 1542 | IPv4: Could not write in resolv file
Jan 25 09:12:39 fx30s user.err Legato: =ERR= | dcsDaemon[577]/dataConnectionService T=main | dcsServer.c SetModemGateway() 1619 | Failed to get configuration DNS`

So it is not managing to set the DNS for this device. What would have caused this? I can also see this by trying to edit the file directly… I cannot save to it.

So something is not allowing the file to be edited…

I ran fuser -m resolv.conf -k to find and kill any processes that might be accessing the file. Trying to reconnect gives the same error as in the previous port.

running “fuser -m resolv.conf” shows two processes that seem to be accessing the file, but won’t close.

  • 3811 pts/0 00:00:00 sh
  • 3774 ? 00:00:00 run_getty.sh

Which are my terminals… which does not make sense…

Any thoughts?

Thanks

Hi @davidc, I am now seeing this on IPV4 in R14.

It seem seems o connect, set the resolv.conf file. (only two IP addresses) and then a few moments later it clears it? I have two apps running on this device using the data connection. Not sure if that effects anything.

The other curious thing is that the route only has one route set up for the USB not rmnet.

Any thoughts on how can resolv this, or what to check.