Bug#889144: stricter PIDfile handling breaks several daemons
On 04/02/18 20:26, Sven Hartge wrote: > Does dnsmasq need a PIDfile when running under systemd? Can't it just > not double fork, stay in the foreground using a Type=simple systemd unit? > > That way the whole problem could be avoided all together. > Sending signals to the dnsmasq process cause it to take various actions, so it's likely that there are scripts out there that do the equivalent of kill - `cat /run/dnsmasq/dnsmasq.pid` The double-fork code in dnsmasq is also quite careful about error handling; for instance passing an error code back through a pipe from the forked process to the original process, so that any failure gets reflected in the return code when the original process exits. That's relevant to Michael's point, I think. Cheers, Simon.
Bug#889144: stricter PIDfile handling breaks several daemons
With my dnsmasq maintainer hat on, the current arrangement looks like this. 1) /run/dnsmasq is a directory owned by dnsmasq:nogroup 2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops root, so is root:root 3) The reason /run/dnsmasq is owned by dnsmasq is so that dnsmasq can unlink the pidfile at shutdown, after it has dropped root and is running as 'dnsmasq' There's a potential security hole here, since an attacker who can become user dnsmasq, can create a symlink at /run/dnsmasq/dnsmasq.pid to anywhere, and have the target of the symlink overwritten (as root) at startup. The dnsmasq PID-file creation code detects and blocks this case: see src/dnsmasq.c around line 507. I think that this can be fixed in dnsmasq by chown()ing the pid file to the same user dnsmasq is about to drop privs too, but I'm not sure is that's enough to keep the new systemd checks happy. Cheers, Simon.
Bug#819856: dnsmasq: diff for NMU version 2.76-1.2
Hi, Thanks for this. I need to upload 2.76-2, which has a fix for a different bug, #831372. I've patched this with the 2.76-1.1 and 2.76-1.2 NMUs, so they're included. However by the time 2.76-1.2 gets to the end of the delay, 2.76-2 will be in place. That's not going to confuse things, is it? 2.76-2 > 2.76-1.2, so the NMU won't overwrite my later upload, which includes the NMU patch? Cheers, Simon. On 16/07/16 01:31, z...@debian.org wrote: > Control: tags 819856 + patch > Control: tags 819856 + pending > > Dear maintainer, > > I've prepared an NMU for dnsmasq (versioned as 2.76-1.2) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. > > Best, > Chris > > > diff -u dnsmasq-2.76/debian/changelog dnsmasq-2.76/debian/changelog > --- dnsmasq-2.76/debian/changelog > +++ dnsmasq-2.76/debian/changelog > @@ -1,3 +1,11 @@ > +dnsmasq (2.76-1.2) unstable; urgency=medium > + > + * Non-maintainer upload. > + * dnsmasq: Install marker file to determine package installed state, > +for the benefit of the init script. (Closes: #819856) > + > + -- Christian HofstaedtlerSat, 16 Jul 2016 00:17:57 + > + > dnsmasq (2.76-1.1) unstable; urgency=medium > >* Non-maintainer upload. > diff -u dnsmasq-2.76/debian/init dnsmasq-2.76/debian/init > --- dnsmasq-2.76/debian/init > +++ dnsmasq-2.76/debian/init > @@ -33,7 +33,7 @@ > # The following test ensures the dnsmasq service is not started, when the > # package 'dnsmasq' is removed but not purged, even if the dnsmasq-base > # package is still in place. > -test -d /usr/share/doc/dnsmasq || exit 0 > +test -e /usr/share/dnsmasq/installed-marker || exit 0 > > test -x $DAEMON || exit 0 > > diff -u dnsmasq-2.76/debian/rules dnsmasq-2.76/debian/rules > --- dnsmasq-2.76/debian/rules > +++ dnsmasq-2.76/debian/rules > @@ -105,6 +105,7 @@ > -d debian/daemon/etc/dnsmasq.d \ > -d debian/daemon/etc/resolvconf/update.d \ > -d debian/daemon/usr/lib/resolvconf/dpkg-event.d \ > + -d debian/daemon/usr/share/dnsmasq \ > -d debian/daemon/etc/default \ > -d debian/daemon/lib/systemd/system \ > -d debian/daemon/etc/insserv.conf.d > @@ -113,6 +114,7 @@ > install -m 755 debian/init debian/daemon/etc/init.d/dnsmasq > install -m 755 debian/resolvconf > debian/daemon/etc/resolvconf/update.d/dnsmasq > install -m 755 debian/resolvconf-package > debian/daemon/usr/lib/resolvconf/dpkg-event.d/dnsmasq > + install -m 644 debian/installed-marker debian/daemon/usr/share/dnsmasq > install -m 644 debian/default debian/daemon/etc/default/dnsmasq > install -m 644 dnsmasq.conf.example debian/daemon/etc/dnsmasq.conf > install -m 644 debian/readme.dnsmasq.d > debian/daemon/etc/dnsmasq.d/README > only in patch2: > unchanged: > --- dnsmasq-2.76.orig/debian/installed-marker > +++ dnsmasq-2.76/debian/installed-marker > @@ -0,0 +1,2 @@ > +# This file indicates dnsmasq (and not just dnsmasq-base) is installed. > +# It is an implementation detail of the dnsmasq init script. >
Bug#776530: dnsmasq: fails to start when dbus is not installed and running systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/02/15 09:17, Simon McVittie wrote: On Mon, 09 Feb 2015 at 16:33:31 +, Simon McVittie wrote: If I was the maintainer, I'd go for option 2, Type=forking, which makes the systemd unit work even more like the init script does now - signalling readiness via the parent process exiting. I'll look into doing a patch at some point. See attached. Tested successfully in a jessie 'standard' virtual machine with and without dbus. Thanks, that looks good, but I think that probably the default - --enable-dbus should go as well. It's only there for the previous use with systemd's dbus method. DBus is not enabled by default when dnsmasq is started by sysvinit. I'll make a patch with that too. Are you happy if I upload it rather than your NMU, to save you grief with my mangled config files :) Cheers, Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU28khAAoJEBXN2mrhkTWirxsP/1Qb8ZZlbx999z1BKKR8OWp6 Gv0/GXWIRYf+1SeIcLio+ukMCl+EhNVgWrtCasbCDBkav1INqOAX7b0StI6Ubeig SPQtLyaus0NypY1t7vo97nt7y3D3DMYaERqRoKn+gFBbwozMRnDQZ0xdG1OKIxiP uKz/c4yQ4QfN+YJDGV3gaR7F53pURjs7kyIyFs/8uERMdDQZ55HC+R2YOQEP7Ob4 WfivYrZF+yUwIrYpWhzQSc1HnfynEP8mgBwYTIXpqhz5mLyR6iAJ7vswG2Dbteq8 FuGb83UK9+uGpeYnGbvSZbAhBJNVXnKRvZXNrIHg8+qZWjCRFMJgBJzdkPlLOh+Z 3IhwS3hXqeneyen7ucK/yJWBLw46s3bz2qMXBQaPWvNnzYI8zHUk3GcQubZRYmeW tM2511Ukhh+4PF/c5PqqSk/lw5ji2ERVYz5GVFgK1ZtHj3ypScjHPqnoVtZMIkad zSzETJwHWhjVjGk9zjEZHOnd1wbiPSMOPJGyYwbjM0VTtCKnJpb/zgtEE3ny1wPT nUP9w1bqtQO2cbrjwtTVDpqQ89iceXfru9CvUP0yyacnETvkajtYmESe6Trd6FQY 6WVHFyIDfcvI5SkzRbVmGVmfH16rCq6B/kZVN/NkaKV3jgLs5mrO+WEKXAN1K23u LixgpogYIuSW0AH43ruB =qjNN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776530: dnsmasq: fails to start when dbus is not installed and running systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/02/15 21:56, Simon McVittie wrote: On 11/02/15 21:26, Simon Kelley wrote: Thanks, that looks good, but I think that probably the default --enable-dbus should go as well. It's only there for the previous use with systemd's dbus method. DBus is not enabled by default when dnsmasq is started by sysvinit. I wondered about this, but I was a little concerned that it would be a regression for any systemd users who are currently remote-controlling dnsmasq via D-Bus without having specifically enabled it. If it was also enabled when sysvinit was in use, I'd agree, but a system which is working as a side-effect of using systemd probably should be fixed, so it will work with sysvinit too. Given that a D-Bus-enabled dnsmasq seems to cope equally gracefully with dbus present or absent, is there a cost to enabling it? There is. Dnsmasq will poll, attempting to create a connection, so there's some CPU cost. I'll make a patch with that too. Are you happy if I upload it rather than your NMU, to save you grief with my mangled config files :) Upload whatever you prefer. I mainly prepared my patch in the form of an NMU so I wouldn't have to rebuild and re-test if you asked me to NMU it later. S OK. My sid VM is currently updating to allow the test. Will upload soon. Cheers, Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU29LrAAoJEBXN2mrhkTWiVwUP/2bDRUk158rS2YoNQqF9BPdm yPrydm2OMyr+cG5pYQhlcPdXXtVLY1/wd7HAFAbum36tE53APpuSqairdlv/bKRY bbqyboAqHw04PBqKNJnwkhGuOjXQrkySMXV/tu2CDZjZ+xqGtgB2Nwy+xJKPUpp6 vPSU7FPhXEp1Ik2Bv95mWhRaH9erFL44wbYuUKXYuQeU69vE6Zaj8gQZdQNBVdtP XOzR4pN75HmVEHFjlCSlQAVec0+mAyCUfEjwbT3yd+be0V6fR0ayF9zr82oRtrEX sZhhXto14BE5qFwjQUrzqwBn30TuCrucmAC847NXeRbt85wNf2vxmqTMTVcs5J2B u50Fm1AXFPEwWN8VZMyJOxPXcznNtc5DQgyDgG9r7vNIqLDZewONlbZWIyOERtXX 50YH4ajhzZx5VIjLM1TNEo5hvq+snPqULbd8b4/Py57jMSb5zrZkIHhIDao5nHDT S040YfTXOGNRObJva+YVcQkPnJb8gTEN05D8nrfucEocvECYxonzZg9q8AwalvAl XAR8cOnRXDGHpTDbMRgBco0u9Il6g/XjRz3KbEnM1MXYD0NorYMjCL8vyLGERFJ3 luQ6NvrpXM+gaLLKIS/QMD9Sjkxt1UZerylGc/oY6VMBvdA6cLtjmPnkh+n/7sV3 ZAb5girZxA6Bp9HqkJoy =L8Mk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776530: dnsmasq: fails to start when dbus is not installed and running systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Simon. Many thanks for the offer of help, not having to wade into the intricacies of systemd is a big win for me. The current arrangements are something which was made to work without big code changes so I'm not wedded to using the dbus method at all, and most installations of dnsmasq won't need dbus, so removing the compulsory dependency is good. That eliminates option one. Of two or three, I'm not sure and I'll take your advice. Two needs no code changes and adds no dependencies, and that's good, but if there are advantanges to going with three, then I can handle that by making the libdbus code conditionally compiled. Cheers, Simon. The current code is Som On 07/02/15 12:08, Simon McVittie wrote: On Wed, 28 Jan 2015 at 17:37:38 -0800, Vagrant Cascadian wrote: When runnning dnsmasq with systemd on a freshly installed system, without dbus installed, dnsmasq fails to start. It seems like dnsmasq should depend or at least recommend dbus if it needs dbus in order to function on a default install with systemd. Some ugly chain of dbus | sysvinit-core | upstart might also be worth entertaining... There are three ways this could potentially be fixed: * depend on dbus or optionally dbus | sysvinit-core | upstart (systemd will think dnsmasq is ready when it claims its bus name, as it does now) * change from Type=dbus to Type=forking, add PIDFile, and stop using --keep-in-foreground in '/etc/init.d/dnsmasq systemd-exec' (systemd will think the dnsmasq child process is ready when the parent process exec'd by the init script exits 0, and will determine what the child process is by reading the PIDFile) * change from Type=dbus to Type=notify, link to libsystemd, and call sd_notify(0, READY=1) when ready (systemd will think dnsmasq is ready when it does that) I can put together a patch for one of these options if the dnsmasq maintainer is too busy (the first two are easy, the third is slightly harder but not rocket science), but I'd like to know which one you'd prefer. S -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU2NJQAAoJEBXN2mrhkTWiQ2wP/3xrPZKauBip1lrQ+KMcoq+A kcxyUkG7Culdmk+j6o1YXaqGGL10+hWc9Dc8Qf6keOQmSEwHcjpb/xhAYTk7TK0z c//339hE+XhtQKMQRh3DlEx47NqAkAqI68/P9XaHmP7VDAmI/ngGmU4MubajW4NL 80D6Z2e0ej/wp3ks/vwcSzDtDg+Z7yI0wYPrGlmq2C2ke2NCpjzllLwPytVq22eM VSHFxcwVERmiugIe456tMOAzt6Rhsi1rP+I+xDKwM+Pdo4f/Gw5ulS+DR4xc5maz YQLFfwioGRyl95weltrLE96YKw4Ma/lF2BaXNne+cOYznbQHKGRkBegK05cN6eFQ tYVa95IXw71/EJkfKQuVftIH7m4xoE/F/Q/Awa4qcVaH4LmzDK8xqVkUkKA73+UX 13kIl5gef3r9SEQoIOwUMiVefPT/uENMLded7C3DhlIX+0xtdI/IFiOQMJ5Momre oqQ4ykKaa/P1fJxiGfkAfa716PK6oFvfeMYLFuPRCslJoJE5k/5Xpp74HymaSWjr LlK04Q+t+EsjrWpuU7uGd+Vywb4QI/HOVO5onGyXo0cYiB+jpANvDzkG1sSvzAWx rTXHYRcte4LkiJswuCOZeUsVXOvdICU4CGRsh4n3tC5y6CbsCT6vqSmKC+pRdFm5 i2THtdMze50+33HfIBZk =OYQ2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724602: dnsmasq: Please enable systemd unit on install and fix it
On 11/05/14 15:11, Andreas Metzler wrote: On 2014-05-11 Michael Biebl bi...@debian.org wrote: Am 11.05.2014 10:13, schrieb Andreas Metzler: On 2013-09-25 Julian Andres Klode j...@debian.org wrote: [...] dnsmasq currently does not enable its systemd unit in postinst. It should probably use dh-systemd. [...] Isn't this severity serious? I have just gone from sysv to systemd Agreed, I bumped the severity accordingly. (using apt-get --purge install systemd-sysv), and was switched from dnsmasq enabled before the upgrade to dnsmasq disabled, completely breaking DNS resolution. Simon, first of all, thanks for shipping a native .service file for systemd. If you need help getting the service enabled (using dh-systemd), please let us know. We are happy to assist you with this or provide a patch. Hello, dnsmasq is packaged without debhelper, making this a little bit more work. However I have simply checked what dh_systemd /would/ do and have manually applied the changes to maintainerscripts and dependencies to come up with the the attached patch. Could you please doublecheck? Thanks, cu Andreas This looks fine to me, and I'm happy to apply the patch, but I have no way to definitively test it. (I'm working on a laptop with a two-year-old Ubuntu installation and a sid chroot for package building. My net connection is flaky 3G which won't allow me to pull enough stuff to build a sid VM.) I propose to upload a new version, if someone can test it ASAP and file a new serious bug if I've botched it. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686484: chowning pid directory and writing there as root may lead to security issue
On 02/09/12 08:44, Michael Tokarev wrote: Package: dnsmasq Version: 2.55-2 Severity: serious Tags: security The initscript (and postinst script) of dnsmasq creates /var/run/dnsmasq directory and chowns it to dnsmasq:nogroup. However, dnsmasq daemon writes the pidfile (which apparently is the only file there) as root user. Here's the code which does this (in src/dnsmasq.c): FILE *pidfile; /* only complain if started as root */ if ((pidfile = fopen(daemon-runfile, w))) { fprintf(pidfile, %d\n, (int) getpid()); fclose(pidfile); } So there's no checking for this file to exist, being a symlink etc. This way, we effectively making dnsmasq user equal to root: dnsmasq user can (sym)link /var/run/dnsmasq/dnsmasq.pid to, say, /etc/shadow, and it will be overwitten the next time dnsmasq (re)starts. This is obviously wrong. The only good side of this is that dnsmasq writes only controlled data to this file (its pid, as per above), so the damage is minimal, ie, only a denial of service, not gain of service (hence Severity is only serious). Besides, documentation says the pid file is /var/run/dnsmasq.pid, not /var/run/dnsmasq/dnsmasq.pid - it is the initscript which sets the option behind the scenes. Also, there's no mentions in the changelog about WHY pid file is in this location. And more, it one can change the user dnsmasq runs as. It looks like this pidfile stuff needs to be removed entirely (moving it to a subdir silently and chowning that subdir to dnsmasq user). Thanks, /mjt The explanation for the current state of affairs is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508560 /var/run/dnsmasq is owned by user dnsmasq so that dnsmasq can unlink the pid file when it shuts down, even though at that point it is running as user dnsmasq, not as user root. I can see a couple of ways of fixing this, without just removing the whole edifice, but neither are perfect. 1) stat the pid file and check for symlinks, etc (or just unlink it) just before creating the new one. There's a race between the unlink and the creation though - an attacker could create the symlink then. 2) Create the pid file after changing user. That works fine in this case, but not in the default case when dnsmasq writes to /var/run/dnsmasq.pid and then changes to user nobody. The behaviour would therefore need to be enabled by a special config option or risk breaking nearly every dnsmasq installation other than Debian/Ubunutu. Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686484: chowning pid directory and writing there as root may lead to security issue
On 02/09/12 08:44, Michael Tokarev wrote: Package: dnsmasq Version: 2.55-2 Severity: serious Tags: security Ignore my previous question: currently educating myself about O_EXCL Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685204: dnsmasq: trying to overwrite config files in dnsmasq-base
On Sat, 18 Aug 2012 09:54:26 +0100, Neil Williams codeh...@debian.org wrote: Package: dnsmasq Version: 2.63-1 Severity: serious Justification: Fails to install Upgrading dnsmasq to 2.63-1 fails: E: /var/cache/apt/archives/dnsmasq-base_2.63-1_amd64.deb: trying to overwrite '/etc/dbus-1/system.d/dnsmasq.conf', which is also in package dnsmasq 2.62-3 Looks like a missing Replaces or an accidental move of the config file? Hmm, the intention was to move that conffile from dnsmasq to dnsmasq-base. I thought I had the correct Replaces: and it worked for me. I'm away for the next week, will look at this on my return. Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665008: keeps segfaulting
On 22/03/12 10:32, Stéphane Glondu wrote: Package: dnsmasq Version: 2.60-1 Severity: grave Hello, I cannot start a (squeeze) netboot install (on an eee pc 701) using dnsmasq on the server. In the past, I have already installed (successfuly) computers this way. Today, dnsmasq keeps segfaulting after downloading the kernel image. It also seems to segfault randomly when there is DHCP traffic that should be ignored on the network. Cheers, OK, this is not a known bug. Could you build a version of dnsmasq with debugging symbols and either run it in in the foreground with cd /tmp ulimit -c unlimited /usr/sbin/dnsmasq -d When it crashes, send me the core file from /tmp and the binary /usr/sbin/dnsmasq To build the package, get the source and then run fakeroot debian/rules DEB_BUILD_OPTIONS=nostrip noopt binary if you're not familiar with building packages from source, let me know, and I'll send you a pre-built package. Thanks for your help. Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635383: dnsmasq no longer replies to DHCP requests
Paul Millar wrote: As a shot-in-the-dark, I've checked for dnsmasq reply packets on the other interfaces (lo, eth0, br1). There's no sign of the reply packets. This used to work, so it looks like a bug introduced with a recent upgrade of the dnsmasq package. There have been no recent changes to the code-paths involved that I can point a finger to, and this sort of setup depends on so much setup external to dnsmasq that I'm inclined to look elsewhere first. Can you downgrade dnsmasq and point me to a version which works _now_? Also, the output of strace in the dnsmasq process during the attempted lease aquisition would be useful. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584754: crash in dhcp_reply on last /etc/ethers entry when i18n is enabled
Gianluigi Tiesi wrote: Package: dnsmasq Version: 2.53-1 Severity: serious Tags: sid I've got this nasty bugs, when I connect using my nokia n97 dnsmasq crashes, after a lot of trials/debugs I've found that the place where it crashes is only a side effect even if the code looks a bit 'obscure': 645. if (config) 646. { 647. struct dhcp_netid_list *list; 648. 649. for (list = config-netid; list; list = list-next) 650. { 651. list-list-next = netid; 652. netid = list-list; 653. } 654. } src/rfc2131.c list-list-next seems to be bogus but looks like it's a circular list I think the problem is that config-netid is uninitialised if the config is derived from a line in /etc/ethers. Disabling i18n fixes it because there's different random junk there. Please could you try http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.55test1.tar.gz and see if it fixes the problem? (If you can't easily build the source, let me know and I'll find a 64 bit machine to make a binary package). Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547696: dhcpcd screws up /etc/resolv.conf when there are several name servers.
Philippe Combes wrote: Subject: dhcpcd screws up /etc/resolv.conf when there are several name servers. Package: dhcpcd Version: 1:3.2.3-1.1 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** When the dhcpd server adds option domain-name-servers with two (or more) arguments, then the nameservers are listed with a comma in /etc/resolv.conf, e.g. nameserver ns1.mydomain.com,ns2.mydomain.com instead of nameserver ns1.mydomain.com nameserver ns2.mydomain.com I can't reproduce this at all: there are two places in the dhcpcd where resolv.conf may be written: one in the main C code, which is disabled by default but can be enabled by editing /etc/default/dhcpcd, and one in the script /etc/dhcpcd.sh which updates /etc/dhcpc/resolv.conf for compatibility. Both of these do the right thing. Are you sure that there's not something else on your system overwriting /etc/resolv.conf? Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490123: backport for stable
Siim Põder wrote: any plans to fix this for stable release as well? siim A backport to Etch is about to be released. Cheers, Simon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364800: no answer to dnsmasq broadcasts
Frederic MASSOT wrote: Package: dnsmasq Version: 2.32-2 Followup-For: Bug #364800 Hi, I have the same problem after an upgrade from 2.22-2 to 2.32.2. Below the logs, I recorded the input/output with iptables: kernel: IN=br0 OUT= PHYSIN=eth1 PHYSOUT=tap0 MAC=ff:ff:ff:ff:ff:ff:00:03:93:83:72:78:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=19201 PROTO=UDP SPT=68 DPT=67 LEN=308 dnsmasq[2336]: DHCPDISCOVER(br0) 00:03:93:83:72:78 dnsmasq[2336]: DHCPOFFER(br0) 192.168.2.3 00:03:93:83:72:78 kernel: IN= OUT=br0 PHYSOUT=eth1 SRC=192.168.2.254 DST=192.168.2.3 LEN=338 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=67 DPT=68 LEN=318 [etc] There is neither DHCPREQUEST nor DHCPPACK. The output of lsof -c dnsmasq : # lsof -c dnsmasq COMMAND PIDUSER FD TYPE DEVICESIZENODE NAME dnsmasq 2336 dnsmasq cwdDIR3,14096 2 / dnsmasq 2336 dnsmasq rtdDIR3,14096 2 / dnsmasq 2336 dnsmasq txtREG3,1 106428 2592770 /usr/sbin/dnsmasq dnsmasq 2336 dnsmasq memREG0,0 0 [heap] (stat: No such file or directory) dnsmasq 2336 dnsmasq memREG3,1 42472 3686528 /lib/tls/i686/cmov/libnss_files-2.3.6.so dnsmasq 2336 dnsmasq memREG3,1 38420 3686627 /lib/tls/i686/cmov/libnss_nis-2.3.6.so dnsmasq 2336 dnsmasq memREG3,1 30428 3686464 /lib/tls/i686/cmov/libnss_compat-2.3.6.so dnsmasq 2336 dnsmasq memREG3,19436 2596238 /usr/lib/gconv/ISO8859-1.so dnsmasq 2336 dnsmasq memREG3,19436 2600723 /usr/lib/gconv/ISO8859-15.so dnsmasq 2336 dnsmasq memREG3,1 1678848 2605096 /usr/lib/locale/locale-archive dnsmasq 2336 dnsmasq memREG3,1 80888 3686460 /lib/tls/i686/cmov/libnsl-2.3.6.so dnsmasq 2336 dnsmasq memREG3,1 1266832 3686448 /lib/tls/i686/cmov/libc-2.3.6.so dnsmasq 2336 dnsmasq memREG3,1 191324 2592691 /usr/lib/libdbus-1.so.2.0.0 dnsmasq 2336 dnsmasq memREG3,1 17888 2592763 /usr/share/locale/fr/LC_MESSAGES/dnsmasq.mo dnsmasq 2336 dnsmasq memREG3,1 92260 3686807 /lib/ld-2.3.6.so dnsmasq 2336 dnsmasq0u CHR1,3 584 /dev/null dnsmasq 2336 dnsmasq1u CHR1,3 584 /dev/null dnsmasq 2336 dnsmasq2u CHR1,3 584 /dev/null dnsmasq 2336 dnsmasq3u sock0,45106 can't identify protocol dnsmasq 2336 dnsmasq4u IPv4 5111 UDP *:domain dnsmasq 2336 dnsmasq5u IPv4 5112 TCP *:domain (LISTEN) dnsmasq 2336 dnsmasq6u IPv4 5113 UDP *:bootps dnsmasq 2336 dnsmasq7u REG3,1 0 770329 /var/lib/misc/dnsmasq.leases dnsmasq 2336 dnsmasq8r FIFO0,55114 pipe dnsmasq 2336 dnsmasq9w FIFO0,55114 pipe dnsmasq 2336 dnsmasq 10u unix 0xc7d729605120 socket dnsmasq 2336 dnsmasq 11u IPv4 5121 UDP *:2051 The output of /proc/pid/status : # cat /proc/2336/status Name: dnsmasq State: S (sleeping) SleepAVG: 98% Tgid: 2336 Pid:2336 PPid: 1 TracerPid: 0 Uid:100 100 100 100 Gid:30 30 30 30 FDSize: 32 Groups: VmPeak: 3912 kB VmSize: 3908 kB VmLck: 0 kB VmHWM: 860 kB VmRSS: 860 kB VmData: 304 kB VmStk:84 kB VmExe: 104 kB VmLib: 1660 kB VmPTE:12 kB Threads:1 SigQ: 0/4294967295 SigPnd: ShdPnd: SigBlk: SigIgn: 1000 SigCgt: 00016201 CapInh: CapPrm: 3000 CapEff: 3000 The output of tcpdump : # tcpdump -i br0 'portrange 67-68' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 14:43:30.821278 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:03:93:83:72:78 (oui Unknown), length: 300 14:43:30.825208 IP dagon.juliana-multimedia.com.bootps 192.168.2.3.bootpc: BOOTP/DHCP, Reply, length: 310 14:43:36.074691 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:f2:ee:10:57 (oui Unknown), length: 300 14:43:36.077090 IP dagon.juliana-multimedia.com.bootps 192.168.2.92.bootpc: BOOTP/DHCP, Reply, length: 316 14:43:39.382560 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:03:93:83:72:78 (oui Unknown), length: 300 14:43:42.074028 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:f2:ee:10:57 (oui Unknown), length: 300 14:43:42.153023 IP dagon.juliana-multimedia.com.bootps 192.168.2.3.bootpc: BOOTP/DHCP, Reply, length: 310 14:43:42.153873 IP dagon.juliana-multimedia.com.bootps 192.168.2.92.bootpc: BOOTP/DHCP, Reply, length: 316 14:43:48.242643 IP 0.0.0.0.bootpc
Bug#362499: - precisions
Alain Richoux wrote: Please find below more accurate information about this problem. Version: the problem occurs with the most recent dnsmasq testing packages, in other words version 2.27-1 Syslog messages: Apr 13 21:51:32 Sartre dnsmasq[6827]: started, version 2.27 cachesize 150 Apr 13 21:51:32 Sartre dnsmasq[6827]: compile time options: IPv6 GNU-getopt RTNetlink ISC-leasefile no-DBus I18N Apr 13 21:51:32 Sartre dnsmasq[6827]: cannot bind netlink socket: Operation not permitted Apr 13 21:51:32 Sartre dnsmasq[6827]: FAILED to start up After reinstalling version 2.22 (no other change): Apr 13 21:53:40 Sartre dnsmasq[7446]: started, version 2.22 cachesize 150 Apr 13 21:53:40 Sartre dnsmasq[7446]: read /etc/hosts - 11 addresses Apr 13 21:53:40 Sartre dnsmasq[7446]: reading /etc/resolv.conf Apr 13 21:53:40 Sartre dnsmasq[7446]: using nameserver 195.238.2.21#53 Apr 13 21:53:40 Sartre dnsmasq[7446]: using nameserver 195.238.2.22#53 I have attached my dnsmasq.conf file. Alain Thanks for that: I have a couple of questions: 1) What kernel version are you using. 2) If you enable the DHCP part of dnsmasq, does the problem go away? Cheers, Simon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]