| View previous topic :: View next topic |
| Author |
Message |
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
 Posted: Tue Jan 20, 2015 5:59 pm Post subject: [WORKAROUND] DNS resolution broken in static busybox |
 |
|
Hi guys,
I emerged the latest version of busybox today (sys-apps/busybox-1.23.0, upgrade from 1.21.0). It now appears as if DNS resolution is broken: | Code: | # busybox nslookup www.google.com
Server: 192.168.19.13
Address 1: 192.168.19.13
nslookup: can't resolve 'www.google.com' |
The same thing happens for any other busybox command that requires resolution of names to IP addreses (e.g ping). I am positive that DNS resolution has worked before on the old busybox version because I use a few busybox commands in custom openrc init scripts and those worked prior to the upgrade. Reverting back to IP-addresses is a workaround, albeit a very nasty one which I would like to avoid.
Anybody out there who can confirm this bug which to me looks like a regression in busybox?
To be clear, DNS resolution pe se does still work on my system for everything else except busybox commands.
Thanks Atom2
P.S.: Furthermore for anybody stumbling across missing functionality in busybox's nc command after the upgrade: Unless you enable | Code: | | CONFIG_NC_110_COMPAT=y |
in /etc/portage/savedconfig/sys-apps/busybox-1.23.0 and you set | Code: | | sys-apps/busybox savedconfig |
in package.use before re-emerging busybox you are missing out on the following options: | Code: | -s ADDR Local address
-n Don't do DNS resolution
-u UDP mode
-v Verbose
-o FILE Hex dump traffic
-z Zero-I/O mode (scanning) |
For me it was mainly the -z option that I was missing which is now back.
Last edited by Atom2 on Wed Jan 21, 2015 7:17 pm; edited 2 times in total |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Jan 20, 2015 9:30 pm Post subject: |
|
|
Atom2 ... I can verify the above (x86), but having reverted to 1.21.0 the same issue occurs (at least similar, slightly different error message). I'd thought this might possibly be due to gcc/pie so built with EXTRA_ECONF="--disable-pie" ... no change. Like you I'm fairly sure that I didn't have this issue previously but I can't be 100% certain.
Sorry, I didn't make any logs of my tests above ... it was basically a spur of the moment thing. I'll reproduce shortly and post output.
best ... khay |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jan 20, 2015 9:49 pm Post subject: |
|
|
khayyam,
Thanks for your confirmation and appologies for me not being more specific as to the architecture: I am using amd64 and have a hardened kernel (currently 3.15.10) using the hardened toolchain. I don't know whether that makes any difference though.
And in contrast to you, I am 100% sure that it worked with the old version because there's a system name (as opposed to an IP address) in one of my init scripts (which did not change for quiet some time) and which currently fails, but worked up to yesterday (i.e. prior to the update). The command line in question in my script reads | Code: | | /bin/busybox nc -z -w 2 "$icinga_host" "$port" |
where both icinga_host and port are variables whose values are set in the corresponding /etc/conf.d file and icinga_host contains the name (i.e. not the IP address) of my icinga monitoring host.
| khayyam wrote: | | Atom2 ... I can verify the above (x86), but having reverted to 1.21.0 the same issue occurs (at least similar, slightly different error message) |
If reverting back to the old version (which I have not done so far) does not solve the problem, my money is on a changed library which is now also statically linked to your old version. If I had to provide a guess, I'd put my money on glibc which, as far as I know, is responsible for DNS resolution ... but I might be wrong.
Thanks again Atom2 |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jan 20, 2015 10:14 pm Post subject: |
|
|
I have just re-checked my old busybox version which is still available in the live image on a virtual machine under XEN (the emerge today was only done to the master image which is usually copied over to the live image in [more or less] regular intervals, but hasn't been copied over yet). The version on the live image (which also has all the now mssing options from nc included) is | Code: | www ~ [503] # ll /bin/busybox
-rwxr-xr-x 1 root root 2036200 Feb 2 2014 /bin/busybox
www ~ [504] # busybox nslookup www.google.com
Server: 192.168.19.1
Address 1: 192.168.19.1 pfsense.mydomain.com
Name: www.google.com
Address 1: 173.194.113.19 fra02s19-in-f19.1e100.net
Address 2: 173.194.113.20 fra02s19-in-f20.1e100.net
Address 3: 173.194.113.16 fra02s19-in-f16.1e100.net
Address 4: 173.194.113.17 fra02s19-in-f17.1e100.net
Address 5: 173.194.113.18 fra02s19-in-f18.1e100.net
Address 6: (null)
|
So this binary dates back to February last year and it does work as can be seen from the output of the same command that failed with the most recent version.
According to my emerge.log files the latest update from glibc-2.17 to glibc-2.19-r1 happened on 30 July 2014. The update of glibc prior to this update was on Jan 28 2014 (from glibc-2.16.0 to glibc-2.17). To me this clearly proves that the (static) busybox from February in my virtual machine couldn't possibly have used glibc-2.19-r1 from July but was rather linked with the Jan 28 version (i.e. glibc-2.17).
I guess that's probably the culprit unless you find something different or my suspicion pointing to glibc is incorrect.
Regards Atom2 |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Wed Jan 21, 2015 6:45 pm Post subject: |
|
|
Further investigations have confirmed my earlier suspicion: The problem in fact lies in the latest version of glibc and there's already a bug filed.
There is, however, a workaround available which I can easily implement for my script: I just need to prepend my busybox command with a LD_LIBRARY_PATH variable assignment that points to the directory where the nss libraries are stored. For amd64 this is /lib64 and for x86 this is /lib32. As /lib is a symbolic link to the correct library per architecture, it is sufficient to use /lib for both cases. So in a nutshell my new line in the script now reads as follows and everything works again as before: | Code: | | LD_LIBRARY_PATH=/lib /bin/busybox nc -z -w 2 "$icinga_host" "$port" |
I wouldn't want to prepend this variable assignment for every interactive invocation of a busybox command, but that could be sorted by adding a LD_LIBRARY_PATH variable pointing to the /lib directory to the shell's environment. As in my case it is only relevant for scripts, I decided to not go down that route and I also did not think further about any other side-effects this change might have on a global basis.
Clearly this is only a workaround and not a bugfix, but for use in my script it's good enough for the time being. I'll have the thread title marked with a [WORKAROUND] to indicate that at least there's a temporary solution available until the bug is finally ironed out.
Thanks Atom2 |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Thu Jan 22, 2015 3:55 pm Post subject: |
|
|
Gentoo changed busybox configuration in 1.22.1-r1 from allyesconfig to defconfig. That caused a lot of configuration and behaviour changes.
I haven't tried DNS resolution recently... can you confirm this method no longer works? https://wiki.gentoo.org/wiki/Custom_Initramfs#DNS
Edit: Just tried it. As you say, it does need the LD_LIBRARY_PATH to be set. What a nag... |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Jan 22, 2015 7:16 pm Post subject: |
|
|
| Atom2 wrote: | | Further investigations have confirmed my earlier suspicion: The problem in fact lies in the latest version of glibc and there's already a bug filed. |
Atom2 ... thanks for looking into it ... and sorry for being remiss in doing so myself :) I'd figured it probably was glibc, given that going back to the pervious version of busybox ... which similarly to you was merged prior to glibc-2.19 ... didn't undo the issue, and as you rightly point out glibc dishes out how dns will be resolved.
I'll take a look at the bug ... best ... khay |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Fri Jan 23, 2015 6:55 pm Post subject: |
|
|
| frostschutz wrote: | | Gentoo changed busybox configuration in 1.22.1-r1 from allyesconfig to defconfig. That caused a lot of configuration and behaviour changes. |
This has now been reverted back to allyesconfig in the latest version (1.23.0-r1) which has hit the tree yesterday night. In essence 1.23.0-r1 also brings back the missing functionality in busybox's nc command (see the P.S. section in my first post) as a result of this. It, however, does not resolve the DNS resolution issues.
| khayyam wrote: | Atom2 ... thanks for looking into it ... and sorry for being remiss in doing so myself  |
Don't worry about that; I have always and still do value your input.
| khayyam wrote: | | I'll take a look at the bug ... best ... khay |
I'll appreciate that, but given that I have found a workaround, the urgency isn't very high, so take your time.
Thanks Atom2 |
|
| Back to top |
|
|
|
Networking & Security
