You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this is ugly hack:
You aren't always connected to the network (i.e. cable unplugged).
Google DNS BGP segment could be unreachable.
You may have no route for their network at all, i.e. private network segment not connected to the internet.
There could be no UP interfaces at the moment (except lo).
Have you tested the exception types you'll get from s.connect for all above?
The text was updated successfully, but these errors were encountered:
Hey @grey-olli ,
Thanks for noticing that. I'm open to suggestions on how to better deal with it and feel free to open new PR with improvements of the existing implementation.
However, this would return every IP Address that is valid on the machine to request the hostname.
In [13]: socket.gethostbyname_ex(hostname)[2]
Out[13]:
['169.254.180.126',
'172.17.1.17',
'192.168.149.1',
'192.168.96.1',
'192.168.254.129']
The reason the Google DNS hack works so well is that the socket will only bind to the address for which there is a route going out to 8.8.8.8.
This leaves us with only the "correct" active IP.
I'm not sure if implementing the above somehow would be an actual improvement. It would also require a lot of extra validation to essentially reach the same.
Maybe there's some wisdom in finding interfaces with a gateway first, and then connecting to that gateway.
What exactly would you expect to happen in some cases like below:
If there is only an lo, do we show 127.0.0.1 ?
What if there's no interfaces up at all ? What do you expect to see?
What if we have multiple interfaces up, but none with LAN, what do you want to see for "active IP" then ?
Here for example:
In [14]: socket.gethostbyname_ex(hostname)[2]
Out[14]: ['169.254.180.126', '172.17.1.17', '192.168.149.1', '192.168.96.1'] # All these IP's are virtual / local
I might be able to glue something together, but it largely depends on the requirements / expected behavior.
this is ugly hack:
You aren't always connected to the network (i.e. cable unplugged).
Google DNS BGP segment could be unreachable.
You may have no route for their network at all, i.e. private network segment not connected to the internet.
There could be no UP interfaces at the moment (except lo).
Have you tested the exception types you'll get from s.connect for all above?
The text was updated successfully, but these errors were encountered: