Hello,
I am using the dispatcher module with a database table shared among multiple proxies. Some proxies do both IPv4 and IPv6, others only do IPv4. The problem is when i use an IPv6 address in the dispatcher table. Then the IPv4-only proxies fail to load the table.
ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called ERROR: dispatcher [dispatcher.c:321]: could not initiate a connect to the database ERROR: <core> [sr_module.c:889]: init_mod(): Error while initializing module dispatcher (/usr/lib/kamailio/modules_k/dispatcher.so)
Is there any setting i can use on the IPv4-only proxies to make it skip the IPv6 records? (apart from listening on an IPv6 address)
Hello,
is USE_IPV6 compile flag still on? Do you get any other error/debug message before that can give an hint why is failing?
Cheers, Daniel
On 10/11/12 10:53 AM, Alex Hermann wrote:
Hello,
I am using the dispatcher module with a database table shared among multiple proxies. Some proxies do both IPv4 and IPv6, others only do IPv4. The problem is when i use an IPv6 address in the dispatcher table. Then the IPv4-only proxies fail to load the table.
ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called ERROR: dispatcher [dispatcher.c:321]: could not initiate a connect to the database ERROR: <core> [sr_module.c:889]: init_mod(): Error while initializing module dispatcher (/usr/lib/kamailio/modules_k/dispatcher.so)
Is there any setting i can use on the IPv4-only proxies to make it skip the IPv6 records? (apart from listening on an IPv6 address)
don't they have access to a dns server that could
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
is USE_IPV6 compile flag still on?
Yes, the exact same verion is used on the IPv4 and IPv6 proxy processes. They're even on the same host.
Do you get any other error/debug message before that can give an hint why is failing?
Unfortunately not.
On 10/11/12 10:53 AM, Alex Hermann wrote:
Is there any setting i can use on the IPv4-only proxies to make it skip the IPv6 records? (apart from listening on an IPv6 address)
don't they have access to a dns server that could
I'm not sure i understand this sentence.
A DNS trace show this remarkable lookup:
-> DNS Standard query A [IPv6 address] <- DNS Standard query response, No such name
It seems kamailio isn't recognizing the IPv6 address and tries an A lookup on the address including the square braces. It does this independent from the presence of a listen= statement on an IPv6 address, but the code fails if kamailio isn't listening on an IPv6 address...
On 10/11/12 12:00 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
is USE_IPV6 compile flag still on?
Yes, the exact same verion is used on the IPv4 and IPv6 proxy processes. They're even on the same host.
Do you get any other error/debug message before that can give an hint why is failing?
Unfortunately not.
Not even debug messages that could lead to failure point if running with debug=3?
On 10/11/12 10:53 AM, Alex Hermann wrote:
Is there any setting i can use on the IPv4-only proxies to make it skip the IPv6 records? (apart from listening on an IPv6 address)
don't they have access to a dns server that could
I'm not sure i understand this sentence.
This was mistakenly pasted there, it has no meaning, I finished the message I wanted to say by my signature.
A DNS trace show this remarkable lookup:
-> DNS Standard query A [IPv6 address] <- DNS Standard query response, No such name
It seems kamailio isn't recognizing the IPv6 address and tries an A lookup on the address including the square braces. It does this independent from the presence of a listen= statement on an IPv6 address, but the code fails if kamailio isn't listening on an IPv6 address...
Is dns_try_ipv6 parameter set to yes in configuration file?
Anyhow, the dns resolve is done for doing keepalives, if it is an ipv4 only, you will get some errors at runtime because there is no socket for ipv6. Perhaps the fix would require some coding in dispatcher module. An alternative is to use database views to make available only the groups you want in this ipv4 instance.
Cheers, Daniel
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
On 10/11/12 12:00 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
Do you get any other error/debug message before that can give an hint why is failing?
Unfortunately not.
Not even debug messages that could lead to failure point if running with debug=3?
Sorry, forgot about debug logs. Here they are:
DEBUG: <core> [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: <core> [resolve.c:727]: get_record: lookup([IPv6 Address], 1) failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6 Address], 1, 60, 1) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called
Is dns_try_ipv6 parameter set to yes in configuration file?
I tried with and without it, same result.
Anyhow, the dns resolve is done for doing keepalives, if it is an ipv4 only, you will get some errors at runtime because there is no socket for ipv6. Perhaps the fix would require some coding in dispatcher module. An alternative is to use database views to make available only the groups you want in this ipv4 instance.
I'll see what i can do about it. Thanks
On 10/11/12 2:11 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
On 10/11/12 12:00 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
Do you get any other error/debug message before that can give an hint why is failing?
Unfortunately not.
Not even debug messages that could lead to failure point if running with debug=3?
Sorry, forgot about debug logs. Here they are:
DEBUG: <core> [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: <core> [resolve.c:727]: get_record: lookup([IPv6 Address], 1) failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6 Address], 1, 60,
DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called
looking at the code it seems to be ending in doing an A lookup instead of AAAA, a matter of dns_flags value that should be enabled for IPv6 if you set dns_try_ipv6 global parameter. I couldn't spot where this would be disabled if no IPv6 listen socket is provided.
Maybe you can track it in the sources by adding some debug messages in the functions called from dispatcher module.
If you try the trick of adding one udp worker to listen on ::1, like:
socket_workers=1 listen=[::1]
Does it work?
Cheers, Daniel
Is dns_try_ipv6 parameter set to yes in configuration file?
I tried with and without it, same result.
Anyhow, the dns resolve is done for doing keepalives, if it is an ipv4 only, you will get some errors at runtime because there is no socket for ipv6. Perhaps the fix would require some coding in dispatcher module. An alternative is to use database views to make available only the groups you want in this ipv4 instance.
I'll see what i can do about it. Thanks
On Monday 15 October 2012, Daniel-Constantin Mierla wrote:
On 10/11/12 2:11 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote: DEBUG: <core> [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: <core> [resolve.c:727]: get_record: lookup([IPv6 Address],
- failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6
Address], 1, 60, 1) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called
looking at the code it seems to be ending in doing an A lookup instead of AAAA
Why would it even query for AAAA? The entry is an IP(v6) address, no lookup should be done at all.
Hello,
On 10/16/12 1:37 PM, Alex Hermann wrote:
On Monday 15 October 2012, Daniel-Constantin Mierla wrote:
On 10/11/12 2:11 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote: DEBUG: <core> [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: <core> [resolve.c:727]: get_record: lookup([IPv6 Address],
- failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6
Address], 1, 60, 1) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called
looking at the code it seems to be ending in doing an A lookup instead of AAAA
Why would it even query for AAAA? The entry is an IP(v6) address, no lookup should be done at all.
well, maybe improper formulation, the functions in core doing A/AAAA lookups detect if it is an IP address and don't do the dns query in that case, but convert directly the address to socket structure.
The idea was to add some debug messages to discover why its ending in IPv4-specific function and not in the one for IPv6.
Cheers, Daniel
On Monday 15 October 2012, Daniel-Constantin Mierla wrote:
On 10/11/12 2:11 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
DEBUG: <core> [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: <core> [resolve.c:727]: get_record: lookup([IPv6 Address],
- failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6
Address], 1, 60, 1) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: <core> [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called
looking at the code it seems to be ending in doing an A lookup instead of AAAA, a matter of dns_flags value that should be enabled for IPv6 if you set dns_try_ipv6 global parameter. I couldn't spot where this would be disabled if no IPv6 listen socket is provided.
in main.c: if (default_core_cfg.dns_try_ipv6 && !(socket_types & SOCKET_T_IPV6)){ /* if we are not listening on any ipv6 address => no point * to try to resovle ipv6 addresses */ default_core_cfg.dns_try_ipv6=0; }
If you try the trick of adding one udp worker to listen on ::1, like:
socket_workers=1 listen=[::1]
Does it work?
Yes, that works, but I'd like to prevent the process from listening on IPv6 at all.
I think i'll go with the database view solution or patch dispatcher locally to skip IPv6 records.
Thanks,
On Thursday 11 October 2012, Alex Hermann wrote:
I am using the dispatcher module with a database table shared among multiple proxies. Some proxies do both IPv4 and IPv6, others only do IPv4. The problem is when i use an IPv6 address in the dispatcher table. Then the IPv4-only proxies fail to load the table.
For reference, this little patch solved my issue. Probably not suitable for inclusion without a config option.
diff --git a/modules_k/dispatcher/dispatch.c b/modules_k/dispatcher/dispatch.c index 50df1fc..e0dadda 100644 --- a/modules_k/dispatcher/dispatch.c +++ b/modules_k/dispatcher/dispatch.c @@ -259,7 +259,14 @@ int add_dest2list(int id, str uri, int flags, int priority, str *attrs, LM_ERR("bad uri [%.*s]\n", uri.len, uri.s); goto err; } - + + /* skip IPv6 references if IPv6 lookups are disabled */ + if (default_core_cfg.dns_try_ipv6 == 0 && + puri.host.s[0] == '[' && puri.host.s[puri.host.len-1] == ']') { + LM_DBG("skipping IPv6 record %.*s\n", puri.host.len, puri.host.s); + return 0; + } + /* get dest set */ sp = ds_lists[list_idx]; while(sp)
-
Alex Hermann -
Daniel-Constantin Mierla