Unable to Connect LTE

[robert-hh]

@pycom_user123 connect follows attach

[pycom_user123]

@robert-hh Correct. See my code in the previous reply. I issue the function connect(), which attempts to attach first and then connect.

[robert-hh]

@robert-hh I see lte.attach(), but no lte.connect(). Does your code wait in the function connect() after sending lte.attach(), until attach succeeded, before issuing lte.connect()?

[pycom_user123]

@robert-hh Alright now I've successfully connected but I'm getting the following error when I try to run the google() function.

>>> lte.attach()
>>> lte.isattached()
True
>>> lte.connect(cid=3)
>>> lte.isconnected()
True
>>> google()
Connecting to socket...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "boot.py", line 40, in google
OSError: [Errno 113] EHOSTUNREACH

[testuser]

@pycom_user123 transmissions like this can be very finicky. The functions do quite a bit of work to parse everything into exactly the right format with authorizations, acknowledgements, payloads, etc... Add in all of the formatting changes as everything is translated into hex, binary, etc....

Something as small as

    s = socket.socket()
    ss = ssl.wrap_socket(s)
    i = socket.getaddrinfo('www.google.com', 443)[0][-1]
    print('Connecting to socket...')
    ss.connect(i)
    print('Send...')
    ss.send(b"GET / HTTP/1.0\r\n\r\n")
    print(ss.recv(4096))
    print('Close...')
    ss.close()

versus

 s = socket.socket()
 s = ssl.wrap_socket(s)
 s.connect(socket.getaddrinfo('www.google.com', 443)[0][-1])
 s.send(b"GET / HTTP/1.0\r\n\r\n")
 print(s.recv(4096))
 s.close()

can somehow result in a slightly different message being sent because

s.connect(socket.getaddrinfo('www.google.com', 443)[0][-1]) 

is treated slightly differently than

i = socket.getaddrinfo('www.google.com', 443)[0][-1]
s.connect(i)

because of some small difference between floats, doubles, integers, strings, booleans, etc... I'd recommend starting with the Pycom documentation examples, or examples on the forums that are verified to be working.

[robert-hh]

@testuser That is an interesting observation you talk of. Can you give an example of that which is reproducible? The two statement you highlight should make exactly the same call, and if not, I would consider it as a bug, which should be fixed. For that, examples are essential.

[pycom_user123]

@testuser The google() function works when I'm connected using wifi, so I don't think the function is the issue. I did retry using the code exactly as its written in the example as you suggest, but got the same error unfortunately.

[robert-hh]

@pycom_user123 Using my FiPy and an 1nce SIM, the google() function fails at getaddrinfo(), but replacing the symbolic address 'www.google.com' with the numeric '172.217.22.110' value succeeds, and I get data back from the server.
This error at resolving names was discussed before.
And yes: I disabled WiFi before the test. With WiFi, getaddrinfo() works.

[pycom_user123]

@robert-hh Still getting the same error when I change 'google.com' to its numeric value. I tried just getaddrinfo and it seems to work, so perhaps the issue as is with the s.connect() component.

>>> print(socket.getaddrinfo('172.217.22.110', 443)[0][-1])
('172.217.22.110', 443)

[robert-hh]

@pycom_user123 Forgot to mention: My firmware is 1.20.0.rc11.1.
What I wanted to tell is, that your function google() generally works, but each provider may have different omissions.

[robert-hh]

@pycom_user123 After setting DNS servers manually with:

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

also getaddrinfo() works.

[pycom_user123]

@robert-hh It still doesn't seem to work for me even after setting the DNS servers. Aside from this method is there another way I can verify my connection?