[OpenSER-Devel] bug in the dns failover??

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Feb 19 16:18:46 CET 2008


Hi Guang,

The order is ok as the function that tries to get the next destination 
will take care of this. See:
    get_next_su()

Regards,
Bogdan

Guang Hu wrote:
> Hi Bogdan,
>
> Yes, you are correct.  I failed to look in srv2dns_noode() to
> see what it was doing with the **dn argument.  But shouldn't the
> order be A record then SRV record?
> otherwise you are gonna be doing another do_srv_lookup() when
> get_next_he() gets called to grab the next ip for failover.
>
> thanks,
> Guang
>
>
> ---- On Mon, 18 Feb 2008, Bogdan-Andrei Iancu
> (bogdan at voice-system.ro) wrote:
>
> Hi Guang,
>
> Not exactly correct. Let me explain:
>     - a2dns_node() is called to store the additional results
> returned by 
> SRV lookup. This results will be placed in *dn
>     -srv2dns_node() is later called to store the additional res
> returned 
> by NAPTR lookup. The function takes as param *dn, but if you
> look in the 
> function code, you will see that a new dns_node is created and
> the 
> original dn is attached to this new node. The function returns
> the new node:
>          n->kids = *dn;
>         *dn = n;
>
> Regards,
> Bogdan
>
> Guang Hu wrote:
>   
>> Hi, I encountered this problem while trying to test the dns
>> based failover supported in openSER 1.2.0.  I had a hard time
>> trying to make it work and then I started looking at the code
>> and below is what I found in resolve.c
>>
>> in sip_resolvehost(), the dn argument is non null if it is
>>     
> doing
>   
>> dns failover. after grabbing the naptr record it calls
>> do_srv_lookup(). do_srv_lookup then calls a2dns_node() if
>>     
> there
>   
>> is a second record in the srv lookup. so now *dn is not null
>>     
> but
>   
>> then it calls srv2dns_node with the same dn and this smashes
>> what was originally pointed to by *dn (malloc'ed in
>>     
> a2dns_node).
>   
>> what it needs to do is call the srv2dns_node with the address
>>     
> of
>   
>> (*dn)->kids if *dn is already pointing to something.
>>
>> here is the snippet of code from sip_resolvehost that I am
>> talking about. 
>>
>>         head = get_record( tmp, T_NAPTR);
>>         if (head) {
>>                 /* filter and sort the records */
>>                 filter_and_sort_naptr( &head, &rd, is_sips);
>>                 /* free what is useless */
>>                 free_rdata_list( rd );
>>                 /* process the NAPTR records */
>>                 for( rd=head ; rd ; rd=rd->next ) {
>>                         *proto = get_naptr_proto(
>>     
> get_naptr(rd)
>   
>> );
>>                         he = do_srv_lookup(
>>     
> get_naptr(rd)->repl,
>   
>> port, dn);
>>                         if ( he ) {
>>                                 DBG("DEBUG:sip_resolvehost2:
>> found!\n");
>>                                 if (dn) {
>>                                         /* save the state of
>>     
> the
>   
>> resolver for failure cases */
>>                                         if (*dn==NULL)
>>                                                 rd = rd->next;
>>                                         if (rd &&
>>     
> srv2dns_node(
>   
>> rd, dn)!=0) {
>>                                                 shm_free(*dn);
>>                                                 *dn = 0;
>>                                         }
>>                                 }
>>                                 free_rdata_list(head);
>>                                 return he;
>>                         }
>>                 }
>>                 if (head)
>>                         free_rdata_list(head);
>>         }
>>
>>
>>
>>
>>
>>
>> I checked 1.2.0, 1.2.2, and 1.3.0 and they all look the same.
>>     
> so
>   
>> now my question is how did this ever work before?
>>
>>
>> thanks,
>> Guang
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>>
>>   
>>     
>
>
>
>
>
>   




More information about the Devel mailing list