With an Affix-enabled version of seash running behind a NAT, it is close to impossible to reach Affix-enabled vessels running behind other NATs. A typical sequence of events looks like this:
Lookup BadSeash key in advertise server 128.238.63.15 --> value 95cb.....zenodotus.poly.edu:1224, c00c....
Lookup in advertise server 128.238.63.51 --> value 95cb.....zenodotus.poly.edu:1224, c000c....
Lookup in UDP advertise server 128.238.63.50 --> value 95cb... only!
DNS query for 95cb... --> answer 192.168.1.130
DNS query for c00c... --> answer 172.31.12.204
Now we contact two NAT forwarders almost at the same time:
Contact 120.216.1.23, get connection to 95cb..., GetVessels, response, everything good!
Contact 128.59.20.226, ......, everything good!
Contact c00c...'s private IP address --> fails of course
Contact 95cb...'s private IP address --> fails of course
The last two steps are the problem -- these would only make sense if seash and the NATted vessels were on the same LAN (which is improbable in general).
I don't claim to know whether contacting the same node over two interfaces is desired behavior by Affix; we might also look at a different bug (e.g. look at the libraries seash_helper.py includes/dy_links: time, advertise, nmclient all use socket_timeout, but only the last has network calls overridden by Affix).
With an Affix-enabled version of
seashrunning behind a NAT, it is close to impossible to reach Affix-enabled vessels running behind other NATs. A typical sequence of events looks like this:The last two steps are the problem -- these would only make sense if
seashand the NATted vessels were on the same LAN (which is improbable in general).I don't claim to know whether contacting the same node over two interfaces is desired behavior by Affix; we might also look at a different bug (e.g. look at the libraries
seash_helper.pyincludes/dy_links: time, advertise, nmclient all use socket_timeout, but only the last has network calls overridden by Affix).