You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the client only has IPv4 available, and the server has both IPv4 and IPv6, raw login can be attempted on IPv6 anyway if the DNS servers in use prefer it.
It works this way since the server does not always know its addresses (if listen addresses are not set). The server should respond with addresses for both protocols (guessing its address if required) to allow the client to try either one.
$ sudo ./bin/iodine -f4 dns.tun
Enter tunnel password:
Opened dns0
Opened IPv4 UDP socket
Sending DNS queries for dns.tun to 127.0.0.53
Autodetecting DNS query type (use -T to override).iodine: ..
Using DNS type TXT queries
Version ok, both using protocol v 0x00000502. You are user #1
Setting IP of dns0 to 10.4.5.3
Setting MTU of dns0 to 1130
Server tunnel IP is 10.4.5.1
Requesting server address to attempt raw UDP mode (skip with -r)
Server is at 2001:db8::1, trying raw login: (skip with -r) ....failed
The text was updated successfully, but these errors were encountered:
As shown in the log, adding -4 to the client does not help, because that only switches the communication to the first DNS server to IPv4. That server then continues with IPv6 to the iodine server.
yarrick
changed the title
Improve raw login from v4 network against v6-capable server
Improve raw login from v4-only network against v6-capable server
Aug 16, 2021
The server could look up its own address (just like how relaying nameservers find it). But due to wildcard support for domain names (since 95fde8b) it needs to be done on the fly instead of once at start-up.
If the client only has IPv4 available, and the server has both IPv4 and IPv6, raw login can be attempted on IPv6 anyway if the DNS servers in use prefer it.
It works this way since the server does not always know its addresses (if listen addresses are not set). The server should respond with addresses for both protocols (guessing its address if required) to allow the client to try either one.
The text was updated successfully, but these errors were encountered: