Modify

Opened 7 years ago

Closed 7 years ago

#8344 closed defect (fixed)

Reverse/Resolving Problems back in Trunk

Reported by: Ernesto Owned by: acoul
Priority: high Milestone:
Component: base system Version: Trunk
Keywords: RESOLVER UCLIBC Cc:

Description

i compiled yesterday a actual trunk with kernel 2.6.36 and orion
and get the old Resolverproblems back:

"web2.website.80.in-addr.arpa"

so the reverse-Resolving/lookup in the uClibC is still broken

Attachments (0)

Change History (5)

comment:1 Changed 7 years ago by Ernesto

By using external Resolvers in /etc/resolv.conf
the resolution is OK.
Using local dnsmasq for resolving the "addr.arpa" errors
are back.

comment:2 Changed 7 years ago by acoul

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

this looks like a dnsmasq issue, not related to uClibc. The uClibc issue has been resolved in r24029.

comment:3 Changed 7 years ago by Ernesto

I recompiled entire trunk with uclibc 0.9.32 and the problem is solved with existing dnsmasq! - but here are old iptables compatibility issues back imq0/layer7 related.

Conclusion: in uclibC 0.9.31 is not finaly fixed at all in resolver part.

comment:4 Changed 7 years ago by Ernesto

@acoul: i compiled latest "18test" for dnsmasq with uclibc 0.9.31 and the reverse Problems this time are NOT solved! still the old IN.ADDR.ARPA problems.

Switching to uclibc 0.9.32 solved ALL resolverproblems without the need for the
dnsmasq-testversion.

So by using uclibc 0.9.31 we really need a working fixx for the local resolver.

comment:5 Changed 7 years ago by nbd

  • Resolution set to fixed
  • Status changed from assigned to closed

0.9.31 is gone, 0.9.32 is default

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.