@kovid: I had made the gethost... stuff work on my windows machine, but I failed completely to make it work on linux. So I agree with you, it is not useful.
However, netifaces does seem to do the trick. On my windows machine the same "program" returns
Code:
[[{'addr': '169.254.108.184'}],
[{'addr': '192.168.220.38',
'broadcast': '192.168.220.255',
'netmask': '255.255.255.0'}],
[{'addr': '127.0.0.1',
'broadcast': '127.255.255.255',
'netmask': '255.0.0.0'}],
None,
None,
None]
which is indeed useful. If nothing else I can get the list of possible IP addresses. Coupled with having the device show its own IP address (which we can do easily), the user should be able to compare the lists to identify the right one for calibre.
We could also do a variant of what you suggested earlier. Instead of using mdns, which seems to have its own set of problems, we could have a "reverse connect" test. The user would push some button on the device that would cause the device to listen on a port on the wifi, displaying the IP address and port. The user would then push some button in calibre that asks for the device's address and port (supplied in the above dialog) and connects to it. If this connect succeeds, we can easily get calibre's local address from the socket, or even better have the device get the remote address from its socket. In addition to verifying connectivity, this test would supply some diagnostic information we can use to help. It is more complicated to build than using netifaces to display info, but not outrageously so.
So, are you willing to package netifaces into calibre? If you are, then could you produce a "beta" so I can code and test in preparation for next Friday? The beta could be windows only. Thanks.