LTE NB-IoT DNS

[Redferne]

Hi,

I just managed to get the FIPY connected to our internal test network using the recently released NB-IoT firmware from Sequans. However I'm having some issues with getting the DNS information from the network propagated to the FIPY modem. I discovered this when socket.getaddrinfo('www.google.com', 80) was returning nonsense IPs. So I digged a bit further and found this:

lte.send_at_cmd('AT+CGCONTRDP')
'\r\n+CGCONTRDP: 1,5,"internet.xxxx.xx.mncXXX.mccXXX.gprs","10.41.136.10.255.255.255.255","","","","",""\r\n\r\nOK\r\n'

Refering to the Sequans AT manual, the empty parameters should contain gateway, primary and secondary dns IP addresses. So basically there is no DNS specified and all hostname lookups fails. Socket communication using IP addresses works fine.

[Lonefish]

@combaindeft I finally found the time to test this and it works indeed! Just a heads up, Google DNS is 8.8.8.8 and 8.8.4.4, not 4.4.4.4 :)

[combaindeft]

@Lonefish @Redferne

Take a look at the new 1.18.2 release ... they implemented so we can add our own dnsserver ...

Tested it now, and it works 👍🏻 ... we got DNS over NB-IOT 👍🏻

Please update to the latest 1.18.2 (stable):
https://forum.pycom.io/topic/4361/new-stable-firmware-release-v1-18-2

or to the latest 1.20.0.rc7 (development):
https://forum.pycom.io/topic/4359/new-v1-20-0-release-candidate-v1-20-0-rc7

Use the following to set your DNS Server to Google's DNS Servers ...

usocket.dnsserver(0,'8.8.8.8')
usocket.dnsserver(1,'4.4.4.4')
usocket.dnsserver()
('8.8.8.8', '4.4.4.4')

Then bring up your LTE Connection, and do:

>>> print(usocket.getaddrinfo("www.google.com", 80)[0][-1])
('216.58.211.4', 80)

[combaindeft]

@lonefish

I've been doing some google searching (https://www.google.se/search?num=100&q=%2Bmicropython+dns+client) and looking up some Python-based DNS Clients:

• https://github.com/lettier/dnsclient
• https://github.com/ValeryTyumen/DNS-Client
• https://github.com/shubhammatta/DNS-Client-Socket/blob/master/DNS-Proxy-Server.py
• http://www.dnspython.org/

and see which one is the easiest to port to MicroPython

@Lonefish ... may we should start a GitHUB project for "our" MicroPython DNS-Client port for PyCom devices?

[Lonefish]

@combaindeft That was my plan too, to be honest, do the dns-request myself. When I checked the modems DNS with AT-commands it did show an empty DNS-address. But, remembering cisco and OSI-layer, DNS is an application protocol, so it's not necessarily an implementation problem in the standard as you said.

[combaindeft]

@Paul-Thornton @Lonefish

Hi again,

Got a reply from our contact @Telia ... and the the devices they use, do support DNS-lookups ... natively ... from the Device manufacturer.

They can enter any http://www.address.com and it works.

So I guess then, it's more up to PyCam @Paul-Thornton to implement a native DNS-Client into the MicroPython Firmware.

I'm guessing adding a list of "prefered" DNS-Server is the way to go ... like adding Google's own DNS-servers (8.8.8.8) to the list ... etc etc ... and then having a built-in-DNS-Client that does the DNS-Lookups via UDP ... as the LTE-CATNB1 network(s) are most likely UDP based ... at least it's for us here in Sweden with Telia ...

Further more, DNS is TCP / UDP agnostic ... and protocol independent ...

So, yeah, guess it's 100% in the hands of PyCom to implement their own native DNS-client into the Firmware :-) @Paul-Thornton @Lonefish

[combaindeft]

@paul-thornton @Lonefish

I'm in talks with our operator, Telia here in Sweden ... regarding why they didn't implemented the network for NB-IOT (LTE CATNB1) ... with DNS support.

But I got it confirmed today from our contact person:

"There is no restriction in 3GPP as regards to the support of DNS in LTE-CATNB1"

[so I updated my previous post to reflect that...]

But, for some reason, it seems that operators around the world are ALL implementing their LTE-CATNB1 networks without DNS supports.

Talking with our backends guys ... they said to think of LTE-CATNB1 as a "LoRa Network" as it's competing against it. Meaning a device should only wake-up, quickly burst the data over, and enter deep_sleep ... Hence removing DNS, and implementing an only IP network. Make it more efficient, as there is no dependency on a Download-link to get DNS working

Furthermore, signs of this is that our operator only supports UDP-packets! ... meaning we are only sending data ... and hoping it'll reach the server (like in a LoRa-network ...)

[Paul Thornton]

@lonefish @combaindeft took a quick google myself and couldnt manage to find anything on this either. If you have any documentation or links to share Id love to read them.

[Lonefish]

@combaindeft I can't seem to find anything that supports this claim (or denies it).. Where have you heard/read/seen this?

Not stating you're wrong, it doesn't work with my fipy either, but looking for an answer why not and what would be a solution/recommended way of communicating then.

[combaindeft]

Hi all,

From what I've read, heard and seen ... NB-IOT isn't ment to have DNS ...

LTE-M (or LTE-CATM1) networks ... contrary to NB-IOT ( or LTE-NB1) networks .... do support DNS ...

As someone so elegantly put it ... Think of LTE-NB1 as the lowest power consumption .vs LTE-M vs LTE ... they had to the "optimise" LTE-NB1 network as much as they could for longterm lifecycle in the field... and removing DNS lookups is a feature they had to remove ... as the devices conceived to LTE-NB1 is "wake-up, AS-FAST-AS-POSSIBLE-get-the-data-out, turn off Modem, and put device to deep sleep" ...

With that in mind, all in all, it makes 100% sense not to have DNS in LTE-NB1 ... and all we have to do is design our solutions around this factor.

[Redferne]

@aris Actually in our case the DNS problem was caused by Sequans using EPCO in their NB-IOT firmware. Once we added support for EPCO in our network we got the DNS server info populated.

[Aris]

I get the same problem with the FiPy and our internal NB-IoT network. The DNS seems to be broken for NB-IoT. Are there any plans to fix the problem, or do we have to keep working with fixed IPs?

Related issue: https://github.com/pycom/pycom-libraries/issues/57

[Redferne]

@jcaron
It worked fine using the Cat M1 firmware. It's part of the PDN Connectivity Request (PCO) sent from UE to network. Not sure whether PCO or ePCO is used when requesting the IP configuration. The UE must request a DNS when establishing a connection on the default bearer, and the network will respond with a Activate Default EPS Bearer Request which includes UE IP, DNS etc.

[jcaron]

@redferne Are you sure your test network is indeed sending that information to the node?