From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 28 21:44: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 614AA106564A; Mon, 28 Mar 2011 21:44: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 11E968FC0A; Mon, 28 Mar 2011 21:44:44 +0000 (UTC) Received: by iyj12 with SMTP id 12so5096341iyj.13 for ; Mon, 28 Mar 2011 14:44: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=SG8jpKvrQ8LX1s2AIhRXbdAXuqmoKqXM6LMV4fSp8qs=; b=dnVI9KLclSFZtOWpuNzI4WQUg27QaDoXFGfxSM2WvrLbFXjl8YYiNk3ayrbGSMr4rF 0WDeOlMYQ93hGTfOXgC18u5tRsuuYgkt10AvXJ3beZ9iEjK01VoB5O+WM080sfUGsyO+ zw6IN5CFenHfVQ4ijAdF5lxRRvoxCbkVtHG0A= 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=cCFrytDVEIkjS8IULkzEVOnpaDnbgJXQHHHVfjVLJhL2AnkIqMJuJCahmF5i0dbjKZ eCOudcceILwQIVfvAgexJqzCYjI9Ur5Fg/HSmhwZRzBqI1uLQyv7HPkNpqfl8V+bKUlG fpLYbAPuNCS02w+o8t1R4uKL3X/mCJgzZf1RU= MIME-Version: 1.0 Received: by 10.43.53.6 with SMTP id vo6mr1939164icb.387.1301348684452; Mon, 28 Mar 2011 14:44:44 -0700 (PDT) Received: by 10.42.166.71 with HTTP; Mon, 28 Mar 2011 14:44:44 -0700 (PDT) In-Reply-To: <20110328213746.GA42088@freebsd.org> References: <20110328001258.GA70156@freebsd.org> <20110328101804.GA39095@freebsd.org> <20110328195952.GA26987@freebsd.org> <20110328203413.GB26987@freebsd.org> <20110328213746.GA42088@freebsd.org> Date: Mon, 28 Mar 2011 14:44: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 21:44:45 -0000 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? > 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). thanks, max