On 28Oct2015 10:41, Robin Becker <ro...@reportlab.com> wrote:
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 :(
Indeed:-( But it is very handy as a test for basic connection stuff in the
field.
Please show me the exact code you're using. This really should work without
annoying "device" binding. [...]
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.
That is reassuring to me. Thanks for checking. Reaching for a particular device
is annoying and weird and possibly even pointless.
Anyhow my upstream provider has taken over the problem so hopefully I will get
the address cleared at some point.
Ok.
Cheers,
Cameron Simpson <c...@zip.com.au>
--
https://mail.python.org/mailman/listinfo/python-list
