Age | Commit message (Collapse) | Author |
|
|
|
Hi Erik,
Thanks for all your great work. I found a set of bugs in
resolv.c . Basically, there is code that looks like:
BIGLOCK;
__nameserversXX=__nameservers;
__nameserverXX=__nameserver;
BIGUNLOCK;
i = __dns_lookup(dname, type, __nameserversXX, __nameserverXX, &packet, &a);
which is a problem because the declarations are
int __nameservers;
char * __nameserver[MAX_SERVERS];
int __searchdomains;
char * __searchdomain[MAX_SEARCH];
so you can see that __nameserver is a pointer. Copying the
pointer to __nameserverXX doesn't protect the global variable
space. I have attached a patch and the new file. I hope you
will incorporate these bug fixes. I spent quite a bit of time
tracking them down.
Many thanks,
Ron
|
|
gethostbyname2_r tries to resolve an ipv6 address from /etc/hosts using
get_hosts_byname_r, but with AF_INET instead of the supplied address family.
This returns ipv4 addresses marked as ipv6 ones. Fix from nbd.
|
|
|
|
things, and avoid potential deadlocks caused when a thread holding a uClibc
internal lock get canceled and terminates without releasing the lock. This
change also provides a single place, bits/uClibc_mutex.h, for thread libraries
to modify to change all instances of internal locking.
|
|
otherwise we get messed up alias memory and this simple test case will
segfault:
python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
see bug report in blackfin tracker for more info:
http://blackfin.uclinux.org/tracker/index.php?func=detail&aid=1503&group_id=17&atid=141
|
|
defined, gettimeofday has other prototype and tm_gmtoff/tm_zone do not exist
|
|
|
|
most of global data relocations are back
|
|
|
|
|
|
gone from libc. The remaining are left as exercise for others ;-)
|
|
|
|
|
|
missing headers, other jump relocs removed
|
|
|
|
was indeed a badly chosen name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x_internal, do not use cascading aliases
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
addr.c also as int. Rename mylock/LOCK/UNLOCK in resolv.c to allow IMA compiling
|
|
by 'nslookup www.yahoo.com' and 'nslookup mail.hotmail.com', and thus we
currently return ERANGE when trying to lookup some of the most popular hosts on
the planet. Whether these sites deserve to be popular is a question I'll leave
for someone else to worry about.
This change makes certain we have enough static buffer space to handle about 21
IPv4 IP address replies per DNS query. Far more than enough to handle common
cases such as www.yahoo.com and mail.hotmail.com.
|
|
This fix, based on this patch
http://bugs.uclibc.org/view.php?id=104
makes it so uClibc fills out round robin dns lists for
applications such as nslookup:
Before:
$ nslookup google.com
Server: mace.codepoet.org
Address: 10.10.10.1
Name: google.com
Address: 216.239.39.99
After:
$ nslookup google.com
Server: mace.codepoet.org
Address: 10.10.10.1
Name: google.com
Addresses: 216.239.57.99, 216.239.37.99, 216.239.39.99
|
|
|
|
|
|
|
|
uClibc resolver doesn't lookup all search domains.
For example, if you have computer 'jenda.prague.my.cz' and resolv.conf:
search my.cz
nameserver xx.xx.xx.xx
try this:
ping jenda.prague.my.cz #works
ping jenda.prague #unknown host
libc/inet/resolv.c doesn't want to try search domains if the domain name
contains '.'. I don't find any reason for the behaviour in literature
and it is inconsistent with the glibc.
Patch is attached.
regards,
- jenda
|
|
|
|
|
|
checking on 127.0.0.1 is still valid w/o resolv.conf
-Erik
|
|
return the length and the actual dns packet as received, rather than
making stuff up.
-Erik
|
|
> the gethostbyname_r() call itself is not segfaulting, but the memory
> returned in the h_aliases array seems to be wrong ...
was playing around with the source today and eventually the obvious answer hit
me ... while read_etc_hosts_r() generatings an array of strings fo h_aliases
and populates it, the dns path does not :)
find attached a patch that'll actually generate the h_aliases list in the
normal dns code path ... i used the etc_hosts_r() code as a template for some
of it ...
note that this is just a simple fix ... it fills the alias list with just the
hostname gethostbyname_r was passed ... the proper fix i think would be to
parse the dns packet down in __dns_lookup() and pass the info back via the
resolv_answer struct ...
but this fix is better than the current state of things ... that is, h_aliases
currently is never initailized in the dns code path :)
|
|
Bug fix: gethostbyname_r checked errno without first setting it to a
known value.
|
|
Hi Erik
I have corrected a bug in uClibc/libc/inet/resolv.c in function
__dns_lookup(). Have attaced a txt file with my diffs regarding to
uClibc 0.9.26.
If two nameservers are included in /etc/resolv.conf and the first one is
wrong and the secondary is correct the algorithm never
looked up the secondary one. Please review my diff and feel free to
submit the patch onto your CVS.
If reading manual page resolv.conf(5) under nameserver and how the
algorithm should work the previous dns_lookup did not fully followed
that.
Regards
Imre Sunyi
|
|
but remove support for host aliases (the HOSTALIASES env variable)
which looks like a very bad idea.
-Erik
|
|
were including libc-lock.h which had a bunch of weak pragmas. Also,
uClibc supplied a number of no-op weak thread functions even though
many weren't needed. This combined result was that sometimes the
functional versions of thread functions in pthread would not override
the weaks in libc.
While fixing this, I also prepended double-underscore to all necessary
weak thread funcs in uClibc, and removed all unused weaks.
I did a test build, but haven't tested this since these changes are
a backport from my working tree. I did test the changes there and
no longer need to explicitly add -lpthread in the perl build for
perl to pass its thread self tests.
|
|
cause gethostbyaddr_r to keep looping allocating more and more
memory each time till alloca finally caused a segfault. Ugh.
This fixes that as well...
-Erik
|
|
I've created a patch for adding dn_expand() to uClibc 0.9.21.
dn_expand() is used by at least ipsec-tools and also openldap I think.
|