From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 23:08:45 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 992B01065672; Mon, 28 Mar 2011 23:08:45 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4BBE28FC21; Mon, 28 Mar 2011 23:08:45 +0000 (UTC) Received: by iyj12 with SMTP id 12so5186761iyj.13 for ; Mon, 28 Mar 2011 16:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jLl8j/v2jbbFl6yacgCtFWXZ+uy3h2tUFSpukm6DNoA=; b=FPn+SlbZyRGWLKM5qNHvz1S6iKFb9x/wPdOcZ241jXzk6mxZIEijz6leYcA0Irlvl/ ivTaNs6j9czu0HfmE5c2c0euqxr/5BPsL2AgMvnD+QHzJ3FsolLZV7QGVnp0NV3EVcWz oi/8pomYXuP0aFmv3KbfBWzs7xZ/1SWbAThVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QmVOTQ/SVerZiHMWOpvfQ5HRHlTZuFK7tSnWGM2LPW2HLw+JkAu68Pm0yIJWaY3/b7 xk0ID73fwQUP15FlYA+Q+u0CztD7vsE8i1aY/RoAeL8WFwVKKlzfZbCI+mE8L0WEV14G bDwtU07Kvr3SUQTxEyrNNaZxgHbi2nfXfkyBA= MIME-Version: 1.0 Received: by 10.43.60.205 with SMTP id wt13mr7657691icb.253.1301353724684; Mon, 28 Mar 2011 16:08:44 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 16:08:44 -0700 (PDT) In-Reply-To: <20110328225208.GA51932@freebsd.org> References: <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> <20110328215503.GA43845@freebsd.org> <20110328225208.GA51932@freebsd.org> Date: Mon, 28 Mar 2011 16:08:44 -0700 Message-ID: From: Maksim Yevmenkin To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: l2ping(8) and -f switch X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:08:45 -0000 On Mon, Mar 28, 2011 at 3:52 PM, Alexander Best wrote: > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> On Mon, Mar 28, 2011 at 2:55 PM, Alexander Best wrote: >> > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> On Mon, Mar 28, 2011 at 2:37 PM, Alexander Best wrote: >> >> > On Mon Mar 28 11, Alexander Best wrote: >> >> >> On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> >> > On Mon, Mar 28, 2011 at 12:59 PM, Alexander Best wrote: >> >> >> > > On Mon Mar 28 11, Maksim Yevmenkin wrote: >> >> >> > >> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert wrote: >> >> >> > >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> >> > >> > >> >> >> > >> >> On Mon Mar 28 11, Iain Hibbert wrote: >> >> >> > >> >> > On Mon, 28 Mar 2011, Alexander Best wrote: >> >> >> > >> >> > >> >> >> > >> >> > > thus i believe making the -f switch only accessable to super-users (in >> >> >> > >> >> > > accordance with ping(8)/ping6(8)) would increase security. >> >> >> > >> >> > >> >> >> > >> >> > what stops the user from recompiling l2ping without this restriction? >> >> >> > >> >> >> >> >> > >> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the >> >> >> > >> >> restriction? still it's there. >> >> >> > >> > >> >> >> > >> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats >> >> >> > >> > why ping is traditionally a suid program and making a new binary won't >> >> >> > >> > help normal users.. I'm guessing that l2ping doesn't have the same >> >> >> > >> > restrictions? >> >> >> > >> >> >> >> > >> Guys, >> >> >> > >> >> >> >> > >> first of all thanks for the patch. >> >> >> > >> >> >> >> > >> i think one really needs to understand what "flood" really means in >> >> >> > >> l2ping(8). "flood" ping(8) basically floods the link with icmp echo >> >> >> > >> requests without waiting for remote system to reply. yes, this is >> >> >> > >> potentially dangerous and thus its reasonable to require super-user >> >> >> > >> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is >> >> >> > >> "flood" mode >> >> >> > >> >> >> >> > >> 1) sends l2cap echo request >> >> >> > >> 2) waits for l2cap echo response (or timeout) >> >> >> > >> 3) repeats >> >> >> > >> >> >> >> > >> in other words, there is no delay between each l2cap echo >> >> >> > >> request-response transaction. its not really "flood". i'm not sure if >> >> >> > >> it really worth to go all the way to restricting this. however, if >> >> >> > >> people think that it should be restricted, i will not object. >> >> >> > > >> >> >> > > how about removing the term "flood" from the l2ping(2) man page, if the -f >> >> >> > > semantics can't actually be called that way? >> >> >> > >> >> >> > that would be fine. l2ping(8) -h calls it >> >> >> > >> >> >> > -f No delay (sort of flood) >> >> >> > >> >> >> > and l2ping(8) man page calls it >> >> >> > >> >> >> > -f ``Flood'' ping, i.e., no delay between packets. >> >> >> > >> >> >> > it would be nice to make those consistent :) i'm not sure what the >> >> >> > best name would be though. >> >> >> >> >> >> another possibility would be to allow l2ping -i 0 and say that the -f flag is >> >> >> an alias for that. >> >> >> >> the existing code provides exactly this behavior. perhaps just a man >> >> page and usage() change? >> > >> > hmmm...no actually. l2ping -i 0 is not a valid parameter, since -i has to be >> > greater than 0. so it's not possible to simply say "-f is an alias for -i 0", >> > because that implies that -i 0 should work (which it doesn't). >> >> well, don't call it an "alias" then :) call it "effectively -i 0", "no >> delay" or something like that :) >> >> >> > the following patch will implement this behavior. >> >> >> >> if we are going to go this route then why not just get rid of the >> >> "flood" variable all together? just set wait to 0 (zero) if -f was >> >> specified. also, we should probably use strtol(3) instead of atoi(3). >> > >> > i've thought of that. however that would mean l2ping -f -i 3 would set the >> > delay to 3 seconds and usually an -f switch implies "force". so i think the >> > current behavior of -f having a higher priority than any -i X option should be >> > kept. >> >> i think that this is not worthy of long discussion :) i agree that >> word 'flood' is not appropriate and/or confusing. all the patches >> provided were fine, imo. please make a decision and commit the best >> (in your opinion) fix. > > sorry, but i don't own a src commit bit. however i think the following patch > should be fine. i've also eliminated a few var = NULL, since they're all being > initialised properly and unconditionally at some point. also the defenitions > didn't apply to style(9). plus i've converted all the atoi() calls to strtol() > calls. committed, thanks! max