Your original problem was that bizarre things like a 2-tuple whose first member is a Python string representation of the 4-tuple address are not even close to valid ways to specify an address.
You can fix that by just using dest[4]
itself—that is, the tuple you got back as the sockaddr part of getaddrinfo
—as the address. (As Sander Steffann's answer explains, you're not exactly doing this cleanly. But in your case, at least for '::1'
or 'localhost'
with the other values you've specified, you're going to get back the right values to use.) You should also probably use addrs[0]
rather than addrs[2]
.
Anyway, in your Update 3, you appear to have done exactly that, and you're getting socket.error: [Errno 22] Invalid argument
. But there are two arguments to sendto
, and it's the other one that's invalid: ''
is not a valid ICMP6 packet because it has no ICMP6 header.
You can test this pretty easily by first connect
ing to dest[4]
, which will succeed, and then doing a plain send
, which will fail with the same error.
For some reason, on Fedora 10 (ancient linux), the call seems to succeed anyway. I don't know what goes out over the wire (if anything). But on Ubuntu 13.10 (current linux), it fails with EINVAL
, exactly as it should. On OS X 10.7.5 and 10.9.0, it fails with ENOBUFS
, which is bizarre. In all three cases, if I split the sendto
into a connect
and a send
, it's the send
that fails.
'\x80\0\0\0\0\0\0\0'
is a valid ICMP6 packet (an Echo service request header with no data). If I use that instead of your empty string, it now works on all four machines.
(Of course I still get ENETUNREACH
or EHOSTUNREACH
when I try to hit something on the Internet, because I don't have an IPv6-routable connection.)