Name resolution working but now not working? What the Heck?

[Jibun-no-Kage]

Name resolution working, but not now? I had the socket connection via name working for weeks, now not working? I checked my DNS configuration and it works! Both forward and reverse lookup for the given name and address. But MP just recently stopped using name? What am I missing here?

import usocket as socket
dir(socket)
['class', 'name', 'AF_INET', 'AF_INET6', 'IPPROTO_IP', 'IP_ADD_MEMBERSHIP', 'SOCK_DGRAM', 'SOCK_RAW', 'SOCK_STREAM', 'SOL_SOCKET', 'SO_REUSEADDR', 'callback', 'getaddrinfo', 'print_pcbs', 'reset', 'socket']
theSocket=socket.socket()
theAddress=socket.getaddrinfo('broker.dd.org', 1883)
Traceback (most recent call last):
File "", line 1, in
OSError: -2
theAddress=socket.getaddrinfo('192.168.1.3', 1883)
theAddress
[(2, 1, 0, '', ('192.168.1.3', 1883))]

nslookup 192.168.1.3
Server: edge.dd.org
Address: 192.168.1.2
Name: infrastructure.dd.org
Address: 192.168.1.3

nslookup broker.dd.org
Server: edge.dd.org
Address: 192.168.1.2
Name: broker.dd.org
Address: 192.168.1.3

Yes broker is CNAME record, or DNS alias. The actual server is 192.168.1.3, its AAA record is infrastructure.dd.org

OSError -2 is bad WiFi credentials? But clearly I am connected, because socket connected via ip address. Really odd, scratching the head on this one.

[robert-hh]

Which board, which firmware version? And which version worked?

[robert-hh]

I cannot get the ip of broker.dd.org from the PC either, and nslookup for it fails as well.

[Jibun-no-Kage]

Right now using ESP8266 but plan to test on ESP32 later today. The broker.dd.org my local LAN broker, so this is not internet visible.
I am using the stable build and latest nightly in testing.

I can connect via IP but not by name. I would have thought it was something in my local LAN DNS environment except direct nslookup works, from Linux, Windows, etc.

I just happen to find a few Google hits on odd things happening with getaddrinfo in python so thought to ask if anyone else had seem the same behavior.

I just found just a minute or so ago via Google search, where someone saw this odd error scenario where the WiFi credentials were part of the problem, this on straight python... which seems really odd, how can any TCP/UDP socket connect unless you have a valid IP from DHCP or static? And I noticed, that the ESP8266 is never dropping the connection completely. I am explicitly calling .active(False), but the ESP8266 reports .isconnected() is always returning true... very odd.

I thank I am going to reflash the ESP module as well, and do some more testing.

[Jibun-no-Kage]

Yes. That is why I am going to re-flash again. But the problem happened on ESP8266 and ESP32, so it is either my environment, or a common issue in MP, that only happens when some odd circumstances exist. I also plan to reboot my WiFi network and check my routers. I am still leaning to some odd reason my the connect state is core the issue. If I had not found a few references to this via normal python, I would have figured this is strictly my environment. While I am trying this, i am decided I would test my DNS setup via one the Raspberry Pi devices I can use. But the initial nslookup from Windows and Linux PCs, worked.

[Jibun-no-Kage]

This is interesting, on a ESP32...

import network
from utime import sleep

print('Interface')
theInterface=network.WLAN(network.STA_IF)

print('Interface? {0}'.format(theInterface.active()))

print('Interface Disable')
theInterface.active(False)
print('Interface? {0}'.format(theInterface.active()))

print('Interface Enable')
theInterface.active(True)
print('Interface? {0}'.format(theInterface.active()))

print('Connect...')
theInterface.connect('DD','DD')

print('Connect? {0}'.format(theInterface.isconnected()))
while (not (theInterface.isconnected())):

    print('Connect? {0}, Status? {1}'.format(theInterface.isconnected(), theInterface.status()))
    #machine.idle()
    sleep(1)

print('Connect? {0}'.format(theInterface.isconnected()))

Output...

Interface
Interface? True
Interface Disable
Interface? False
Interface Enable
Interface? True
Connect...
Connect? False
Connect? False, Status? 1001
Connect? True

I don't recall ever getting status of 1001?

So I added a scan to the program above, and all 3 of my WiFi routers (big house) appear in the scan.

[Jibun-no-Kage]

I believe I can turn off auto connect right? config('reconnects') right? I guess not. But per this link it is supposed to be supported? https://github.com/micropython/micropython/issues/5326

[robert-hh]

There was recently a commit allowing to set the wlan protocol.
interface.config("protocol")

and

interface.config(protocol=MODE_11x)

with x being N,B or G.

[robert-hh]

That was the only recent change for ESP8266.

[Jibun-no-Kage]

Ok, so I got the above code working on ESP32 then tested on ESP8266. For whatever reason I was never seeing the following notification this morning on the ESP8266, which triggered the entire question...

#7 ets_task(4020f560, 28, 3fff9430, 10)

The interface was just not reseting or initializing. Auto reconnecting or something, and that in turn was failing or not fully reconnecting. All I really did was unplug the ESP8266, wrote the above script on ESP32 and tested on it, than connected the ESP8266 and ran the same script about a hour later on the ESP8266.

[Jibun-no-Kage]

Good idea... testing...

For my LAN setup the following is correct...
IfConfig ('192.168.1.54', '255.255.255.0', '192.168.1.2', '192.168.1.2'), my core router is my default gateway, @192.168.1.2. All of my WiFi routers
are AP points that use 192.168.1.2 as the default gateway and 192.168.1.2 is my active DHCP and DNS service provider.

Linux, Windows, resolve google.com to...
C:\Users\Jibun>nslookup www.google.com
Server: edge.dd.org
Address: 192.168.1.2

Non-authoritative answer:
Name: www.google.com
Addresses: 2607:f8b0:4007:809::2004
142.251.40.36

Results from MP ESP8266 with last nights build...
Connect...
Connect? False
Connect? False, Status? 1
Connect? False, Status? 1
Connect? False, Status? 1
Connect? True
IfConfig ('192.168.1.54', '255.255.255.0', '192.168.1.2', '192.168.1.2')
Address {0}
Address {0}
Interface Release
Interface? False
Connect? False

Note Address is no results...

Code...
theSocket=socket.socket()
theAddress=socket.getaddrinfo('www.google.com', 80)
print('Address {0}')

theSocket=socket.socket()
theAddress=socket.getaddrinfo('142.251.40.36', 80)
print('Address {0}')

[Jibun-no-Kage]

Straight Linux (Debian 11) Python3... So something interesting going on... Below is LAN not WLAN so I need to change my Linux test machine to use WLAN only to replicate 100% test scenario. Setting that up now.

# python3 test.py
('142.250.217.132', 80)

import socket

# Query for socket information to connect to example.com
addrInfo = socket.getaddrinfo("www.google.com",80)[0][-1]
# print socket tuples
print(addrInfo)

[robert-hh]

What would you expect that print('Address {0}') would print?

[Jibun-no-Kage]

Oh, the getaddrinfo tuples for the matches

[Jibun-no-Kage]

Nuts, just realized what I did

[Jibun-no-Kage]

Ok... that worked correctly... now...

Address [(2, 1, 0, '', ('142.250.188.228', 80))]
Address [(2, 1, 0, '', ('142.251.40.36', 80))]

So the core issue still seems to be the ESP8266 is getting stuck into some type of incomplete reconnect I guess. When it happens. The last few tests have worked. And I did re-flash to the latest nightly build to test the protocol stuff. The original issue was on the stable firmware image when I tripped over it.

[Jibun-no-Kage]

Have validated it is not a basic DNS or WiFI specific issue, in my local environment. Given the LAN and WLAN testing via other devices, Pi, PC, Windows, Linux. Only seen the behavior on ESP8266, and appears to only be when using the stable build. I can do a bit more testing with different modules, and see this proves out. Really an interesting issue, if slightly annoying. :) Oh, and it may have been specific to the flash on the device, since I did re-flash, might have been a bad flash, but that would be rare in my experience because using the device it becomes unstable or something obviously just screams bad load of firmware.

[Jibun-no-Kage]

Loading latest nightly build on ESP32, will run the same test script.

[Jibun-no-Kage]

Other than ESP32 reports 1001 status versus 1 status ESP8266 reports while connecting... to WiFI. It works.

Connect? True
IfConfig ('192.168.1.56', '255.255.255.0', '192.168.1.2', '192.168.1.2')
Address [(2, 1, 0, 'www.google.com', ('142.250.72.164', 80))]
Address [(2, 1, 0, '142.251.40.36', ('142.251.40.36', 80))]

Given I can't recreate the odd behavior on the latest builds. figure we are done unless I can recreate it again. Thanks for the assistance.