Modify

Opened 6 years ago

Last modified 4 years ago

#10974 accepted defect

asterisk18 broken in trunk on AR71xx/WNDR3800

Reported by: Igor Novgorodov <igor@…> Owned by: zandbelt
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

It seems that uClibc 0.9.33 in OpenWRT has dropped res_n* functions and Asterisk fails to build. Maybe we should fix the toolchain?

#if 0
u_int           res_randomid (void) __THROW;
int             res_nameinquery (const char *, int, int,
                                 const u_char *, const u_char *) __THROW;
int             res_queriesmatch (const u_char *, const u_char *,
                                  const u_char *, const u_char *) __THROW;
const char *    p_section (int section, int opcode) __THROW;
/* Things involving a resolver context. */
int             res_nisourserver (const res_state,
                                  const struct sockaddr_in *) __THROW;
void            fp_resstat (const res_state, FILE *) __THROW;
void            res_npquery (const res_state, const u_char *, int, FILE *)
     __THROW;
const char *    res_hostalias (const res_state, const char *, char *, size_t)
     __THROW;
int             res_nquery (res_state, const char *, int, int, u_char *, int)
     __THROW;
int             res_nsearch (res_state, const char *, int, int, u_char *, int)
     __THROW;
int             res_nquerydomain (res_state, const char *, const char *, int,
                                  int, u_char *, int) __THROW;
int             res_nmkquery (res_state, int, const char *, int, int,
                              const u_char *, int, const u_char *, u_char *,
                              int) __THROW;
int             res_nsend (res_state, const u_char *, int, u_char *, int)
     __THROW;
#endif

But fow no, this patch against Asterisk 1.8.9.2 (latest 1.8) undefs HAVE_RES_NINIT from 'configure' to make it use res_* resolver functions instead of res_n*.

Attachments (1)

300-undef-have-res-ninit.patch (431 bytes) - added by Igor Novgorodov <igor@…> 6 years ago.

Download all attachments as: .zip

Change History (14)

Changed 6 years ago by Igor Novgorodov <igor@…>

comment:1 Changed 6 years ago by anonymous

Hi,

It's still an issue in the trunk and can't build the whole project.
Can someone fix it?

Thanks,

comment:2 follow-up: Changed 6 years ago by Bruno Silva <avlis.onurb@…>

Same problem with a TL-WR1043ND.

with this patch I managed to compile and run release r30624, but one of the asterisk threads is consuming near 100% cpu.

stracing it, it looks like its stuck on some loop reading resolv.conf?

(...)
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0

(...)

this goes on and on and on...

comment:3 in reply to: ↑ 2 ; follow-up: Changed 6 years ago by Bruno Silva <avlis.onurb@…>

Replying to Bruno Silva <avlis.onurb@…>:
with "out of the box (trunk)" asterisk version 1.8.8.0

Same problem with a TL-WR1043ND.

with this patch I managed to compile and run release r30624, but one of the asterisk threads is consuming near 100% cpu.

stracing it, it looks like its stuck on some loop reading resolv.conf?

(...)
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0

(...)

this goes on and on and on...

comment:4 in reply to: ↑ 3 Changed 6 years ago by Bruno Silva <avlis.onurb@…>

Replying to Bruno Silva <avlis.onurb@…>:
just compiled asterisk 1.8.9.2, same output on strace of the asterisk process that is using all the cpu it can get.

uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x76ab4c58)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x76ab4c58)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x76ab4c58)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                      

Replying to Bruno Silva <avlis.onurb@…>:
with "out of the box (trunk)" asterisk version 1.8.8.0

Same problem with a TL-WR1043ND.

with this patch I managed to compile and run release r30624, but one of the asterisk threads is consuming near 100% cpu.

stracing it, it looks like its stuck on some loop reading resolv.conf?

(...)
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0
uname({sys="Linux", node="router", ...}) = 0
open("/etc/resolv.conf", O_RDONLY)      = 7
ioctl(7, TIOCNXCL, 0x77522c60)          = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "nameserver 127.0.0.1\n", 4096) = 21
read(7, "", 4096)                       = 0
close(7)                                = 0

(...)

this goes on and on and on...

comment:5 Changed 6 years ago by Will Scales <will.scales@…>

I am having the same problems on a Buffalo WZR-HP-AG300H after installing the undef-res-ninit patch - one of the threads is looping, and cannot SIP register with provider.

In my setup the looping occurs when res_search() in main/dns.c is called the second time to find a SRV record (for some reason the first SRV lookup doesn't cause a loop).

I found a possible workaround: set "srvlookup=no" in sip.conf.

Not sure if this will work for anyone else..

comment:7 Changed 6 years ago by swalker

  • Owner changed from developers to zandbelt
  • Status changed from new to assigned

comment:8 Changed 6 years ago by anonymous

select uclibc 0.9.32-git in buildroot solve the problem, though its not an ideal solution

comment:9 Changed 6 years ago by zandbelt

  • Status changed from assigned to accepted

Igor's patch is applied in r30878; unsure how to fix the looping problem yet; any input is welcome

comment:10 Changed 6 years ago by Andre Maree <andrem@…>

@zandbelt

I am using the latest trunk #31412 on a Ubiquiti RouterStation Pro and have exactly the same problem. Through experimentation I have found that it is directly linked to the "register" statement.

I have 2 different VoIP provider, 1 in Germsany and 1 in South Africa, that I use and the problem occurs consistently with either or both. When I comment it out in sip.conf and restart the problem disappear.

Hope this helps to find the cause. If you need any specific files to be uploaded, please let me know.

Andre

comment:11 Changed 6 years ago by nathan@…

Actually, it looks like 0.9.33 didn't *remove* res_n*, but actually *added* those functions. They were not present in uClibc prior to 0.9.33. So I think there are two separate issues: 1) the Asterisk build process breaking despite res_ninit being present, and 2) Asterisk spiking to 100% CPU even if you use the "undef-has-res-ninit" patch which causes it to be built the same way it was prior to uClibc 0.9.33.

Since Asterisk only goes in the resolver loop when paired with uClibc 0.9.33, this would seem to be a uClibc bug on the surface. The author who made the commit made the comment that "some reordering of existing functions was necessary in order to provide this functionality." Just a guess, but I think something broke/regressed in the process.

comment:12 Changed 5 years ago by marko

See #11929 , this is probably a uClibc issue with the _res redefintion between res_init() and res_search() in resolv.c

comment:13 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as accepted .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.