iodined doesn't accept clients if not directly connected

[guest]

ktrace of iodined shows incoming packets:

 53722 iodined  CALL  gettimeofday(0xbfbfeac8,0)
 53722 iodined  RET   gettimeofday 0
 53722 iodined  CALL  select(0x6,0xbfbfeb30,0,0,0xbfbfebb8)
 53722 iodined  RET   select 1
 53722 iodined  CALL  recvfrom(0x5,0xbfbae910,0x10000,0,0xbfbbe910,0xbfbae908)
 53722 iodined  GIO   fd 5 read 50 bytes
       0x0000 01ce 0000 0001 0000 0000 0000 1256 4141  |.............VAA|
       0x0010 4141 4941 4141 3141 4141 4141 4141 4103  |AAIAAA1AAAAAAAA.|
       0x0020 7475 6e06 7261 6d73 7973 0268 7500 0001  |tun.ramsys.hu...|
       0x0030 0001                                     |..|

 53722 iodined  RET   recvfrom 50/0x32

but no reply is sent:

 53722 iodined  CALL  gettimeofday(0xbfbfeac8,0)
 53722 iodined  RET   gettimeofday 0
 53722 iodined  CALL  select(0x6,0xbfbfeb30,0,0,0xbfbfebb8)
 53722 iodined  RET   select 1
 53722 iodined  CALL  recvfrom(0x5,0xbfbae910,0x10000,0,0xbfbbe910,0xbfbae908)
 53722 iodined  GIO   fd 5 read 50 bytes
       0x0000 ae87 0000 0001 0000 0000 0000 1256 4141  |.............VAA|
       0x0010 4141 4941 4141 3141 4141 4141 4141 4103  |AAIAAA1AAAAAAAA.|
       0x0020 7475 6e06 7261 6d73 7973 0268 7500 0001  |tun.ramsys.hu...|
       0x0030 0001                                     |..|

 53722 iodined  RET   recvfrom 50/0x32
 53722 iodined  CALL  gettimeofday(0xbfbfeac8,0)
 53722 iodined  RET   gettimeofday 0
 53722 iodined  CALL  select(0x6,0xbfbfeb30,0,0,0xbfbfebb8)

(next packet came in meanwhile)

The connection works if no in-between DNS servers are used, but that's of course not very effective.

tcpdump of port 53 traffic on server:

16:29:47.619870 IP 213.46.246.51.32768 > 85.90.162.26.53:  44679 A? VAAAAIAAA1AA
AAAAAA.tun.ramsys.hu. (50)
16:29:48.118367 IP 213.46.246.51.32768 > 85.90.162.26.53:  31780 A? VAAAAIAAA1AA
AAAAAA.tun.ramsys.hu. (50)
16:29:48.504343 IP 213.46.246.51.32768 > 85.90.162.26.53:  15571 A? VAAAAIAAA1AA
AAAAAB.tun.ramsys.hu. (50)

Server is FreeBSD, client is OSX.

[guest]

It first fails here, at iodined.c:147

if(in[0] == 'V' || in[0] == 'v')

Why? Both sides are 0.4.0.

[yarrick]

Your tcpdump shows type A requested (the A? part). A working request looks like this:

16:29:48.504343 IP 213.46.246.51.32768 > 85.90.162.26.53: 15571 NULL? VAAAAIAAA1AA AAAAAB.tun.ramsys.hu. (50)

Is that what you get when you run without a relaying dns?

It seems the relay is very restrictive. Have you tried any other servers?

[guest]

Yes, with direct connection:

01:23:03.479870 IP 80.98.239.124.56431 > 85.90.162.26.53:  1+ [1au] NULL? VAAAAIAAA1AAAAAAAA.tun.ramsys.hu. (61)
01:23:03.479993 IP 85.90.162.26.53 > 80.98.239.124.56431:  1*- 1/0/0 (71)

I'll continue tomorrow.

[guest]

Well so far I have found only 2 DNS servers which work. Anyways these two are on public net, so no use for me so far. The ones not working are:

• openwrt's dnsmasq

• ruckus wireless ap's unknown dns daemon

• a nearby ap's dns daemon could be used to build up the connection, but only 4 icmp echo reply packets could be sent before the connection becomes mute (despite that the DNS still sends the keepalive packets every seconds):

  PING 10.0.100.254 (10.0.100.254): 56 data bytes
  64 bytes from 10.0.100.254: icmp_seq=0 ttl=64 time=1144.541 ms
  64 bytes from 10.0.100.254: icmp_seq=1 ttl=64 time=182.955 ms
  64 bytes from 10.0.100.254: icmp_seq=2 ttl=64 time=1132.816 ms
  64 bytes from 10.0.100.254: icmp_seq=3 ttl=64 time=171.070 ms
  ^C
  --- 10.0.100.254 ping statistics ---
  13 packets transmitted, 4 packets received, 69% packet loss
  round-trip min/avg/max/stddev = 171.070/657.846/1144.541/480.869 ms
  

I didn't know iodine is soo picky :( It also doesn't work with the local Vodafone WAP-only APN's DNS. What's the criteria?

[yarrick]

This is the first report I have seen on this. Do all the servers convert NULL to A? What MTU do you use?

[yarrick]

The only thing iodine does is sending requests for the NULL types of various subdomains. The requests include an EDNS0 part to increase possibility for handling a large (>512 byte) reply. All subdomains end with a counter value to reduce cache hits.

[guest]

A server that doesn't work:

Opened UDP socket
iodine: no query or answer in answer
read: Unknown error: 0

19:04:50.195305 IP 192.168.10.134.52181 > 192.190.173.38.53:  1+ [1au] NULL? VAAAAIAAA1AAAAAAAA.tun.ramsys.hu. (61)
E..Y....@.....
....&...5.E...............VAAAAIAAA1AAAAAAAA.tun.ramsys.hu..

        ....).
19:04:50.217746 IP 192.190.173.38.53 > 192.168.10.134.52181:  1 FormErr [0q] 0/0/0 (12)
E..(=..........&..
.
        .5....y%............

named 8.2.4-REL Tue Aug 21 09:28:13 DFT 2001 running on AIX

[yarrick]

That is one very old nameserver. Who operates it? Your ISP? I wonder if the FormatError? reported is for EDNS0 or the NULL type.

[guest]

Well it's very hard to find a DNS that works with iodine, the above is just one exceptionally old server. This is what the ticket is about.

[yarrick]

I understand. But the problems seems to be in your environment/dns relays, not in iodined.

The thing iodine could is to fallback to CNAME queries if NULL isnt accepted, but that hasnt been prioritized yet since noone (before now) has had this problem.

[yarrick]

Closing.

[guest]

Well I'd like to reopen this ticket as an enhancement, since I (not the initial reporter) also found this problem with two public WLAN-hotspots in Berlin.

I think with the increasing use of linux (and dnsmasq therefore) on wlan access points this might happen more often in the future.

[yarrick]

What is the enhancement here? Falling back to other DNS types is mentioned in #30. Is there something else you want?

[yarrick]

Inactive.. closing