..........
binding to the local IP seems to be a windows only thing.No, it is a pretty standard BSD socket layer thing. (Windows got its original TCP stack from there too). I just tested a Linux RHEL6 host binding to a specific address just now using telnet: /usr/bin/telnet -b x.x.x.193 x.x.x.174 22 where the .193 is not the primary address - it is an additional local address. The connection was correctly received by the target as from the alias address, not the base address:
I don't think I'll be able to do all I need with telnet :( ........
Please show me the exact code you're using. This really should work without annoying "device" binding. The counter examples in the articules you cite are for particularly weird circumstances, such as where the routing table cannot correctly deduce the interface (distinct attached networks with the _same_ network numbering - ghastly). They don't say "binding to the local IP seems to be a windows only thing" that I can see. Please post your failing code. I suspect you're missing something.
.......Well originally I was hacking on miproxy to try and get it to use a specific ip address. I must have messed up somewhere there as when I try this more obvious code
from socket import socket, SOL_SOCKET
BIND_DEVICE='eth0.0'
sock = socket()
sock.settimeout(10)
sock.bind(('xx.xx.xx.13', 0))
#sock.setsockopt(SOL_SOCKET, 25, BIND_DEVICE)
sock.connect(("int.hhhhhh.com", 80))
sock.send("GET / HTTP/1.0\r\n\r\n")
print sock.recv(20)
sock.close()
it does work as intended and I can see the .13 address hitting the remote server. I guess my hack of the miproxy code didn't work as intended.
Anyhow my upstream provider has taken over the problem so hopefully I will get the address cleared at some point.
-- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
